On Wed, 10 Aug 2016, Farabet Olivier via curl-library wrote:

> I agree, the process polls 15 seconds to receive the data. In the tcpdump
> trace though, the same data arrive quickly, so something between low level
> networkand libcurl recv() on the socket generates this wait. Do you know of
> a parameter / reason that could explain this ?

No I don't. I personally would probably start with trying out from a different
host to see if this is somehow related to the specific kernel/TCP stack used
in this case.

If it is't related to that, I think there are a few interesting questions to
ask:

  1. What makes this particular response stand out in relation to the
     others your application does? I mean, what's the pattern that triggers
     this problem.

  2. If the whole data chunk has been delivered locally, why doesn't the recv()
     call get the entire body in a single call after having waited so long?

  3. Does your kernel/system have any particular TCP related tweaks or settings
     changed?

  4. Can you reproduce this problem in any way that others can repeat
     externally?

... and of course regular debugging techniques. As you seem to be able to
repeat it, setting break-points and checking out local state with libcurl
could possibly reveal something.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:  https://curl.haxx.se/mail/etiquette.html