Daniel Stenberg wrote:
> >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.

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.

> >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 agree.

There is a move afoot to clarify some parts of the RFC. Do you think
the change below which appeared on the libcurl list is an adequate
wording correction?

    http://curl.haxx.se/mail/lib-2004-03/0445.html

    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."

(Though, I think it's reasonable for a server to decide to keep open a
connection, read and discard for a few seconds, then device to close
the connection if it's continuing to see request body data).

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 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.

What about when an ordinary PUT/POST returns an error code or even a
redirect?

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?

-- Jamie
Received on 2004-08-02