W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2008

Re: estimated Content-Length with chunked encoding

From: Adrien de Croy <adrien@qbik.com>
Date: Fri, 14 Nov 2008 13:21:13 +1300
Message-ID: <491CC479.1050706@qbik.com>
To: Daniel Stenberg <daniel@haxx.se>
CC: ietf-http-wg@w3.org

this brings up another issue, since chunked requests was the suggested 
solution to the problem of coping with authentication (possibly of 
proxies and/or origin servers) for POST and/or PUT with large entities.

It's easy for a server to make the decision whether to use chunking or 
not, because it has the HTTP version of the connected client from the 

In the case of a client sending however, unless it has prior knowledge, 
it doesn't know whether the server supports chunking or not.

An HTTP1.0 server receiving a chunked request could break in a very bad 
way, since it will most likely

a) ignore the Transfer-encoding field
b) treat the chunk headers and trailers as part of the content.

leading to breaking the content on the server, and the client may have 
no way of undoing this.

Therefore before sending any chunked request, the client would need to 
establish a-priori that the request path was capable of successfully 
processing a chunked request.

It's not necessarily trivial to do this reliably.

Daniel Stenberg wrote:
> On Tue, 28 Oct 2008, Henrik Nordstrom wrote:
>>> Interesting enough, the MacOS X WebDAV Client already seems to use
>>> something like that:
>>>> C-68-#000000 -> [PUT /content/dam/STROMBERG_2_2.mp4 HTTP/1.1 ]
>>>> C-68-#000280 -> [Transfer-Encoding: Chunked ]
>> Oh, cool. A client daring to use chunked encoding in requests!
> Is that really so unusual? The "HTTP Implementations" spreadsheet 
> lists at least 4 clients supporting it, but it seems the info is 
> lacking for most of them:
> http://spreadsheets.google.com/pub?key=pAZLaupBqGqXrtsaexTjPYg&gid=0

Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
Received on Friday, 14 November 2008 00:19:33 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:47 UTC