On Fri, 29 Aug 2008, Chris Brown wrote:

> I have encountered an issue with posts exceeding 1024 bytes in size with the
> 'Expect: continue-100' header. Running with CURLOPT_VERBOSE and using
> Wireshark I can see the server returning the 'HTTP/1.1 100 Continue' message
> but libcurl does not appear to transmit the "post data"- instead reporting
> error 28 (CURLE_OPERATION_TIMEOUTED).

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.

> If I add an "Expect:" header to prevent libcurl adding it automatically the
> post still times out as if it is still waiting for the Continue 100 message
> from the server.

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.

> The other odd thing is that in the application protocol I am using the first
> request is always quite large (3000 bytes) compared to the rest. This will
> always work whether the "Expect:" header has been disabled or not but the
> problem is occuring with any subsequent posts in the same session exceeding
> 1024 bytes. This is odd but seems to at least suggest that my server is
> handling the 'Expect" header correctly. What I can't understand is why it
> would work on the first post and then fail on the second post.

Well, it isn't in any way more sensible for libcurl to have trouble with the
second request than what it is for the server!

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.

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

-- 
  / daniel.haxx.se