On Mon, 2 Aug 2004, Jamie Lokier wrote:

>> 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.
>
> You're right. I wasn't thinking straight about those NTLM examples. Duh
> me!
>
> Of course the client can always close the connection if it knows the request
> is large and being discarded.

Not if using NTLM, since that authenticates *connections*.

> Reads: "If it responds with a final status
> code, it MAY close the transport connection or it MAY continue
> to read and discard the rest of the request."
>
> SHOULD read: "If it responds with a final status
> code, it MAY EITHER close the transport connection or continue
> to read and discard the rest of the request."

Yes, that would've made it much clearer!

> I think an explanation of why 100-continue works the way it does, and what
> is expected of the client, wouldn't go amiss in the RFC either.

I agree.

>> 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.
>
> What about when an ordinary PUT/POST returns an error code or even a
> redirect?

That's distinguishble from other error codes so they don't (or at least
shouldn't) cause any problems.

> Won't libcurl do the wrong thing then, or does it always close and use a new
> connection, or not use 100-continue, in those cases?

100-continue is of course used then too, since it can't know on beforehand
that it'll get redirected.

I'm not sure that all aspects of this is taken care of properly, and I guess I
won't be until we get more test cases written or users trying them out on live
servers.

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