> Timed out? That seem strange. Do you have any timeout option set for the
> handle? Does it timeout too fast? What libc are you using? (embedded
> Linuxes do tend to use one of the various smaller ones)
>
> libcurl only waits 1000ms for the 100 Continue and continues with the send
> after that.

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'. I am using libc
version 2.2.3.

> 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. In wireshark no post is
received at the server. After the CURLOPT_TIMEOUT period I can get the same
error message I mentioned above. Once again if I reduce the post size to
less than 1024 bytes it works fine.

> Personally I would rather guess this is a bug or flaw in the server end
> since I'm pretty confident libcurl does the right thing for such basic
> functionality that numerous users have done for many years and over many
> libcurl releases.

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. I have spent
several days checking my code both on the server and the client and posting
to a mailing list is a last resort for me as I don't want to waste peoples
time. I'd be more than happy to put my hand up if the problem was elsewhere
but at the moment to me it looks like libcurl. The closest mailing list
archive article I could find about this was a conversation in August 2006
with Andrew Biggs who was reporting a similar problem but with an older
version of libcurl which did result in a couple of small flaws being
resolved.

> Do you have any other indications that this is the client's fault?

According to both the wireshark and verbose output the server is behaving as
expected and intended. Given that this problem occurs for post sizes of
greater than 1024 (which libcurl does appear to have a brief history with)
I'm not sure how the post size would be an issue on the server. In addition
the behaviour I mentioned above when 'Expect:' is disabled is occuring
entirely on the client.

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?

Thanks
Chris
 
Received on 2008-08-29