On Sun, 1 Aug 2004, Jamie Lokier wrote:

Thanks for your thoughts and insights on this topic!

> It may turn out to be unnecessary, as (a) IIS6 might be smart enough to
> close connections if it would have to discard a large request body (not a
> small one) -- I've not tested, but someone could; (b) for the specific
> problem of NTLM authentication, aren't the request bodies always small
> anyway?

Why would they be small if you POST a huge chunk of data? That isn't related
to the auth type, but to what the client sends. I could very well imagine a
formpost sending a 1GB file. Having the post include the data in each request
would make the operation... slow.

> Finally, it is clear that whatever fix is in libcurl for NTLM authentication
> to work with IIS6, there is still the general issue of libcurl's HTTP/1.1
> compliance. It is clear to me that libcurl MUST transmit a request body if
> it sends a request with "Expect: 100-continue" and receives a response
> without the "100 Continue" -- or alternatively close that connection.
> Hopefully this message has explained why.

I'll admit that your mail was long and detailed. It clearly spells out why the
previous approach was bad. We figured that out too.

I still think the wording in the RFC could be improved to reduce the risk of
misinterpretations such as mine.

> I have the impression from the mailing list threads in March that this
> remains a general bug in libcurl which was not fixed, but the use of HEAD
> for authentication hid it in those cases.

The use of HEAD avoids this "general bug" since the HEAD requests don't use
Expect: 100-continue.

But as you say, using HEAD to authenticate is probably not an approach that
works in all cases. If/when we decide to repair this flaw, we need to take
another stab at the request-body dilemma.

-- 
      Daniel Stenberg -- http://curl.haxx.se -- http://daniel.haxx.se
       Dedicated custom curl help for hire: http://haxx.se/curl.html