Bugs item #3039744, was opened at 2010-08-05 02:18
Message generated for change (Comment added) made by bagder
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=3039744&group_id=976

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: libcurl
Group: bad behaviour
>Status: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: Ben Darnell (bgdarnel)
Assigned to: Daniel Stenberg (bagder)
Summary: 100-continue timeout broken for multi_socket_action API

Initial Comment:
The timeout used when waiting for a 100-continue request from the server is not reflected in TIMERFUNCTION/curl_multi_timeout, and so is ineffective with the socket_action API. This means that POSTs that trigger the 100-continue behavior will simply time out and fail if the server does not support 100-continue.

I'm using libcurl 7.19.7 on Mac OS X 10.6.

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2010-08-06 11:00

Message:
Thanks for the report, this problem is now fixed in the git repository.

To try it out, you either checkout/update your git clone:
http://curl.haxx.se/source.html

or you try tomorrow's daily snapshot: http://curl.haxx.se/snapshots/

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2010-08-06 10:55

Message:
Right thanks, my patch was made against current git head so it might need
adjustments for other versions. And I think it should be done at two places
yes, both that sets "k->exp100 = EXP100_AWAITING_CONTINUE". I'll proceed
and push such a change to the git repo.

Weather to set it by default or not is a question I would urge you to
bring up on the curl-library mailing list as it isn't really a bug, but a
design decision and one that is that hard to revert now without affecting
quite a lot of applications is possibly bad ways.

----------------------------------------------------------------------

Comment By: Ben Darnell (bgdarnel)
Date: 2010-08-06 02:39

Message:
This patch didn't work - that code path isn't where the timeout is getting
set in my case. Making a similar change at line 2271 did work, however
(and presumably it's also needed at line 415)

By the way, the way I discovered this is that Google doesn't implement
100-continue (at least not for its openid endpoint, and the openid protocol
requires a POST which happens to be just over 1024 bytes). Neither does
Facebook. With major sites not supporting 100-continue, I would argue that
it should not be enabled by default.

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2010-08-06 00:16

Message:
Thanks a lot for your report and yes indeed this is quite correct.

I suggest a patch like the attached one. Any change you can try this and
see if it works for you before I proceed and push this to the mainline
code?

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=3039744&group_id=976
Received on 2010-08-06