Re: NEW ISSUE: Monitoring Connections text

On tor, 2007-11-22 at 10:40 +1300, Adrien de Croy wrote:

> OK, this is an issue close to my heart, since it affects POST / PUT 
> through a proxy which uses any sort of challenge/response (i.e NTLM) 
> authentication mechanism.

Yes, and have already been discussed already here..

> Our users have major problems with this.

Yes, and they are not alone, and if NTLM-clients would utilize this they
would fare much better, but no one does even if specified..

> It would be great if the concept of chunking could be stretched to 
> include notification of an abort of transfer.

Sending an last-chunk prematurely is an abort. But I guess we could
extend it with a chunk extension to clarify that it's an abort and not
just "I'm done".

> I haven't seen a client that uses chunking for POST or PUT though

Exactly. And not unsuprising. Chunked encoding of requests is a pretty
unchartered area, and quite heavily discouraged by the specs for legacy

but it would benefit many things, not only NTLM. Especially when taking
100 Continue into account.

> This actually could be a good use-case to use chunking AND specify a 
> content-length header (I hear the groans) - something specifically 
> deprecated in the spec.

Needs to be a different informative header in such case. Content-Length
is to entangled into the transport layer of HTTP to be used here.

> But actually I believe in the end, the issue can't be properly addressed 
> without a major protocol version change, one that then incorporates the 
> concept of negotiating (i.e. obtaining mutual consent for) transfer of 
> message bodies from client to server (as opposed to only having 
> negotiation in the other direction).

Sure it can. In fact it's already there in the form of 100 Continue and
chunked encoding. Just that nearly nobody is using it.

Client sends request header, waits for 100 Continue, gets a denial,
sends last-chunk to terminate the request and moves on to the next..

1. Client only allowed to use chunked if it knows within reasonable
doubt that the next-hop is HTTP/1.1.

2. Client recommended to time out waiting for 100 Continue, as it's not
supported by HTTP/1.0 and there is no guarantee the path is fully

So currently it's not often both conditions to use this negotiation is


Received on Wednesday, 21 November 2007 22:59:26 UTC