Re: Post size 1024 with Continue 100
Date: Fri, 29 Aug 2008 23:41:19 +0200 (CEST)
On Sat, 30 Aug 2008, Chris Brown wrote:
> No it does not timeout too fast. By timeout I am referring to the
> CURLOPT_TIMEOUT. Whatever I set this to (10 by default) affects how long the
> client will wait before it returns the 28 error after it has received the
> Continue 100 from the server. With verbose output it says 'Operation timed
> out after 10000 milliseconds with 0 bytes received'.
Wow. That sounds very weird. And you only get this on the second POST with the
What if you do two such POSTs to another server? What if you do those POSTs
without any (Digest) auth?
BTW, I don't think you mentioned it but how is the POST being done? Using
POSTFIELDS or with a callback? If the latter, have you set the IOCTLFUNCTION?
>> Well it does not. And if I'm not mistaking, I believe libcurl even puts the
>> POST data in the same initial request-send when Expect: is disabled.
> In this scenario it appears as if the request never actually leaves the
> client despite verbose output reporting the post.
You can use CURLOPT_DEBUGFUNCTION to get to see exactly what libcurl sends, if
you don't want to run wireshark on the client side. Here's some example code
to get inspiration from: http://curl.haxx.se/lxr/source/docs/examples/debug.c
I find it highly unlikely that the request doesn't get sent.
See the lib/http.c:Curl_http() function and the cal within there to
add_buffer_send() (beware that it differs depending on what method you're
> With respect I understand what you are saying but even though there are
> literally millions of people using your software it doesn't necessarily
> guarantee that there couldn't be a problem however unlikely.
That's why I said it was a guess. I certainly don't claim to be sure of the
reasons for weird behavior until I have a lot more details.
> Do you have any further suggestions or could you point me to the appropriate
> area of code where this logic is handled and perhaps I could add some extra
> debugging and test further on my system?
My suggestions would be:
- DEBUGFUNCTION to see exactly what libcurl sends/receives
- some debug code/printfs added to Curl_http()
- writing up a small application that repeats the behavior to show us, so
that we can join in the debugging of things
-- / daniel.haxx.seReceived on 2008-08-29