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

ons 2007-02-14 klockan 16:09 +1300 skrev Adrien de Croy:

> > * client closes the connection to avoid transmitting the request body
> 
> Why would it though?   there's no actual need to close here.  Just 
> simply not send the request body,
> rather than closing, and pop up an auth dialog box.  It makes no sense 
> to waste resource by sending
> something the client KNOWS will be dumped.  The Greens will be after us !

Because you then make fundamental changes of the HTTP message format and
run into all the issues of my initial objection.

> clients I've seen are really good at keeping the connection to a proxy 
> open, even when connecting to
> multiple different sites requiring different auth.

Yes, and it's the intention of HTTP/1.1. But it's all hop-by-hop
transport connections not end-to-end connections.

> the request would have effectively been "completed", (i.e. there was a 
> non-interim response given to the
> client) although the request body would not have been sent. 

The request has not yet been completed. Only the response.

> understood.  It has been hacked a bit by MS to allow for NTLM, and all 
> windows browsers
> now support NTLM (because it's commercial suicide not to).  So it's 
> actually well supported out there.

Yes. And it works out relatively well as long as the first request is
not a very large request and the client has a direct connection to the
server..

> I guess more changes to the spec would need to be made to allow for the 
> request to be deemed complete
> without having to send the request body.
> 
> So, yes, it then is a change to the semantics of client requests.

Unless you use chunked encoding, in which case the client can
immediately finish the request at any time.

> It looks like I omitted some things from the spec.  But, since the spec 
> would require changes
> to HTTP, and clients and servers and proxies, then is it too much of a 
> divergence to allow for
> the spec to also then cover a relaxation in strict cases (clearly 
> indicated) of the definition of completeness
> of a request?

I still think you would have greater success looking into using chunked
encoding, which doesn't require any changes to the specs, just a usage
profile how it should be used.

> I foresee problems if the client arbitrarily terminates the request body 
> by sending a final chunk.  The
> proxy then has something that it no longer knows is complete or not.  It 
> may have already sent
> most of this to the server.  Who knows what the server will have done 
> with it.

Thats the thing. It's complete. Chunked encoding works that way.

> If the client supports the proposed spec though, we can avoid this 
> altogether.

And instead getting bitten by the major flaws I outlined before, and
resulting in a highly unstable migration path as it won't work at all as
soon as there is any HTTP/1.1 compliant proxy in the path.

> if the client doesn't support this proposal, we are where we are now.
> 
> If we are going to change the protocol, and change clients, then we may 
> as well change them to provide
> the best solution, not one that has known problems, simply to fall 
> within the current letter of the current
> HTTP spec which we would be changing anyway.

The chunked encoding proposal has very few problems in terms of the
protocol specifications. The only question mark there is how well
supported chunked encoding is in existing proxies having support for
proxying of connection oriented authentication (RFC4559).

> So, I guess I should go away and make a second draft of the proposal 
> which covers these aspects.

Please do. And I again encourage you to evaluate the digest alternative.

> Anyone know of a decent I-D formatting client?

http://tools.ietf.org/inventory/author-tools

Regards
Henrik