Sounds reasonable to me. I'm not real familiar with the libcurl code,
though. If there is no proxy, what would the value of
data->state.authproxy.done be at lone 2252? Hopefully it will be true,
otherwise it seems like all non-proxied requests would satisfy that
condition (&& might help in that case).

I'd be happy to help out with testing any fixes for this, just let me know.

Thanks again Daniel!
Andrew

Daniel Stenberg wrote:
> On Tue, 8 Aug 2006, Andrew Biggs wrote:
>
>> At the moment I'm just relying on the output from having set
>> CURLOPT_VERBOSE, but I could set up Ethereal and confirm if you think
>> that would be more reliable.
>
> Nope, what you did is enough. I now know what you're seeing.
>
>> When the pszPostData string in the test code contains data that
>> equals or exceeds 1024 bytes, I see the following verbose output:
>
> This actually isn't strictly related to the Expect: header or not, but
> I'm quite sure it is still a little bug in libcurl we see here.
>
> At line 2252 in lib/http.c there's this little section:
>
> if((data->state.authhost.done || data->state.authproxy.done )
> && (postsize < MAX_INITIAL_POST_SIZE)) {
> /* If we're not done with the authentication phase, we don't
> expect
> to actually send off any data yet. Hence, we delay the
> sending of
> the body until we receive that friendly 100-continue
> response */
>
> /* The post data is less than MAX_INITIAL_PORT_SIZE, then
> append it
> to the header. This limit is no magic limit but only set to
> prevent really huge POSTs to get the data duplicated with
> malloc() and family. */
>
> I think we see two different flaws:
>
> 1 - This magic doesn't have to be done if Expect: is explicitly
> disabled,
> since that's kind of an implied way to tell libcurl we want to
> just fire
> away as much as possible as early as possible. (I just committed
> a fix
> a few minutes ago for the minor bug I mentioned in an earlier
> response of
> mine).
>
> 2 - The condition above doesn't match the comment. It should rather
> check for
>
> if((!data->state.authhost.done || !data->state.authproxy.done )
>
> so that this is done if one of the variables are _not_ true.
>
> Does this seem like a reasonable conclusion?
>
> Still, even with this bug libcurl will just split up the sending of
> the request into two (or more) send() invokes but it will not wait for
> any 100 response. This makes the response from that server look really
> weird and non-compliant to me.
>
Received on 2006-08-09