- From: Henrik Nordstrom <henrik@henriknordstrom.net>
- Date: Wed, 21 Nov 2007 23:59:11 +0100
- To: Adrien de Croy <adrien@qbik.com>
- Cc: Bjoern Hoehrmann <derhoermi@gmx.net>, "'HTTP Working Group'" <ietf-http-wg@w3.org>
- Message-Id: <1195685951.9028.73.camel@henriknordstrom.net>
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 reasons.. 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.. Problems: 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 HTTP/1.1. So currently it's not often both conditions to use this negotiation is fulfilled. Regards Henrik
Received on Wednesday, 21 November 2007 22:59:26 UTC