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

tor 2007-02-15 klockan 12:39 +1300 skrev Adrien de Croy:

> We may have to leave proper (end to end) flow control for HTTP/2.0 then

And stop calling it flow control. Abandoning the body transfer when one
is indicated is not flow control.

> Unless we ban it if there's a via header, but many proxies do not insert
> these for security reasons.

Well.. specs says they MUST. Nothing except for the HTTP version numbers
contained therein needs to mean anything however..

> So if we go back to chunking then, so that any intermediaries can be
> satisified as to request being completed, then
> we could still possibly do something about the issue of
> connection-oriented auth?

Yes. The scheme I outlined earlier should work in nearly all situations.
The exception being if the capability of the forwarding path changes
drastically if the client disconnects and tries again after the initial
dummy auth challenge. But even then at least for PUT/POST it should fail
gracefully. For other methods which MAY have a request-body (for example
GET) the analysis is not so easy, but thankfully a chunked body can not
be misread as a valid HTTP request so the likelyhood for bad things to
happen as result of a chunked request being sent to a HTTP/1.0
proxy/server is quite distant..

The problem with NTLM auth is not so much the 100 Continue timer, but
the fact that the connection MUST be kept persistent once the client
"challenge"/capability-negotiation packet has been sent and therefore
the request body MUST be transmitted. RFC2616 only allows this when
using chunked (8.2.2 Monitoring Connections for Error Status Messages)
so to comply with RFC2616 transmission requirements any session using
NTLM auth MUST use chunked during the handshake until the final
credentials is sent.

Regards
Henrik