cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: overriding automatic Expect: 100-continue behavior

From: Daniel Stenberg <daniel_at_haxx.se>
Date: Wed, 9 Aug 2006 00:40:04 +0200 (CEST)

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.

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html
Received on 2006-08-09