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

lör 2007-02-03 klockan 23:10 -0800 skrev S. Mike Dierken:

> Much of the document describes a single use-case dealing with authentication
> and NTLM specifically. Are there other specific situations other than
> authentication that can be described? Are there other styles of
> authentication other than NTLM that would benefit from a solution?

The draft is about two quite independent problems.

1. POST/PUT and authentication challenges. Mostly a problem for the
non-compliant connection oriented NTLM/Negotiate/Kerberos authentication
schemes, but may also be noticeable for Digest to some extent even if
just marginally so. To solve this the draft proposes a new 1xx response
type to indicate "please DO NOT send the request body, I am not
interested in what it contains", asking the client to diverge even more
from the standard message format. This is mostly a band-aid to make the
non-compliant connection oriented authentication schemes survive a large
PUT/POST as initial request. 

2. Servers taking a long time to finish processing a request before the
final response is known. To solve this the draft proposes a new
"Progress" header (both request and response) and reusing 100 Continue
to relay this to the user-agent. Very similar to the 102 Processing
response defined by rfc2518 but with a new header to provide additional
information to the end user explaining what is going on.

> What other approaches have been considered? 

For the second problem (servers taking a long time to process a request)
RFC 2518 already defines 102 Processing. But the new "Progress" header
proposed in this draft adds valuable information which the user agent
may display to inform the user why the request is taking so long to
complete.

The first problem has a couple of alternative solutions, none of which
is any better..
  * If an auth challenge is seen, close the connection and then retry
with a 0-length body until the credentials can be provided.
  * As above, but instead use another temporary request to initiate the
authentication handshake, assuming one knows a such request in the same
protection space..
  * Probably other hacks is possible as well to get around the problem.

> Regarding a connection oriented authentication approach, if the client
> submitted a request with no body (like a GET) would that be sufficient to
> establish the credentials that could be used with a larger request later on?

It is. Problems arise if there is no open authenticated connection where
to send the request, and the request has a large request body.

> Regarding large message bodies, would using chunked transfer-encoding with a
> small initial chunk be useful to quickly 'probe' for these chained
> authentication routes?

Not sure I follow what you think on here.

As for seeing that authentication is required before transmitting the
request body 100 Continue is quite sufficient.

Ah, now I follow. Yes, sending the request using chunked
transfer-encoding also allows getting around the PUT/POST authentication
problem very nicely. Just terminate the body immediately when seeing the
authentication challenge instead of 100 Continue.. this is how it should
be done. Nice catch.

So the draft should be reduced to just the new Progress header, suitable
to be used in the already defined "102 Processing" response, and
additionally implementation advice how to handle authentication
challenges to avoid having to repeatedly transmit the request body by
making use of chunked transfer encoding once it's known the resource is
a HTTP/1.1 resource, easily detected by the 401 challenge.

Regards
Henrik