Re: [Fwd: I-D ACTION:draft-decroy-http-progress-00.txt]

ons 2007-02-14 klockan 15:51 +0000 skrev Jamie Lokier:

> This is the reason why a client is only allowed to send a request
> body, or abort the connection.  And this is why it is said the only
> solutions are to use chunked request body (which is always sent, but
> can be truncated), or for the client to send a request header which
> means "I will definitely not send a request body unless I receive 100
> Continue".  But both of those will fail with some servers and some proxies.

As the root of this discussion is the NTLM authentication scheme the
situation isn't that bad for chunked. There is quite many exchanges
taking place, well sufficient to teach the client that the path is
HTTP/1.1 capable.

An NTLM authentication sequence typically looks like follows

1. Request sent without any credentials
2. Server responds with "WWW-Authenticate: NTLM"
3. Client sends it's initial challenge wrapped up as an HTTP NTLM
authenticication request.
4. Server responds with it's challenge wrapped up as an 401 auth
challenge. From here on the connection MUST be persistent end-to-end.
RFC4559 defines how this capability is negotiated via proxies.
5. Client responds with the user credentials.

Closing the connection after '2' if the server (or forwarding path)
isn't priorly known to support chunked is no big deal imho, and after
'2' the client has reasonably good indication of the capabilities of the
forwarding path to be able to determine if it's OK to use chunked
encoding.

The only significant trouble (ignoring non-conforming implementations)
is if the client connects via a mesh of HTTP proxies and only some of
them is HTTP/1.1 + RFC4559 capable and that the initial auth challenge
is delivered via a HTTP/1.1 + RFC4559 capable path but another path may
get selected if the client disconnects and retries the request on a new
connection.

This is btw the same problem which bites the client "server is 100
Continue capable" cache (8.2.3, where it talks about 100 Continue and
older implementations).

If proxies doing authentication is involved then the situation is quite
similar, except that the client may need to switch back to
Content-Length when finishing the proxy authentication in case the
complete path is not yet known..

Regards
Henrik