Daniel Stenberg wrote:
> I honestly can't figure out any other way to avoid sending the whole
> contents twice! I just can't understand how they thought this should work
> when they wrote RFC2616.

The correct thing, according to RFC2616 and discussions on
ietf-http-wg, is this:

    1. Send the request with "Expect: 100-continue".
    2. Pause, waiting for "100 Continue" or a short delay of a few seconds.
    3. If the server sends an error response (which includes an auth error),
       it can either close the connection or read the rest of the request
       body.

So here's how the contents are not sent twice:

    1. Server responds with 401 asking for authentication, and closes
       the connection.
    2. Client never sends request body, because auth response is received
       before the delay. Or, if client has already started, it can abort
       after reading the whole response.
    3. Client opens a new connection and this time authenticates.

You'll notice that IIS6 among others doesn't close the connection.

That is fine, provided the request body is quite small. It's
reasonable for a server to prefer to reuse the connection in that
case, instead of the overhead of accepting a new one.

For large request bodies, you can close the connection yourself (in
the client), after you receive the 401 response and before
transmitting the request body (or before completing it if you've started).

(Note that Curl was buggy before: it didn't send the request body in
this case (i.e. no "100 Continue" received) but send the next
request's headers. That's not valid HTTP).

That works fine for Basic or Digest authentication. You'll notice
that those don't in any way depend on maintaining a persistent
connection. IETF HTTP is fundamentally stateless, and never depends
on persistent connections.

The only problem area is NTLM, which requires the connection to be
maintained.

NTLM is contrary to RFC2616 - precisely because it depends on a
persistent connection. Therefore, you won't find the answer to this
in RFC2616 or other HTTP RFCs.

Instead, if there is any answer to what's right for NTLM, it'll by
found elsewhere - in Microsoft documentation, for example.

Thus I expect the right answer (for NTLM) is: What does the Microsoft
client do for NTLM auth POST and PUT requests?

-- Jamie
Received on 2004-11-03