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

Re: i28 proposed replacement text

From: Joe Orton <joe@manyfish.co.uk>
Date: Fri, 23 May 2008 23:17:24 +0100
To: Mark Nottingham <mnot@mnot.net>
Cc: Henrik Nordstrom <henrik@henriknordstrom.net>, Brian Smith <brian@briansmith.org>, Jamie Lokier <jamie@shareable.org>, Yves Lafon <ylafon@w3.org>, ietf-http-wg@w3.org
Message-ID: <20080523221724.GA23425@manyfish.co.uk>

On Fri, May 23, 2008 at 02:30:25PM +1000, Mark Nottingham wrote:
> Changing things to refer explicitly to "chunked" may help;
> 2. If the Transfer-Encoding header field (section 14.41) is present and 
> contains the "chunked" value, the transfer-length is defined by the use of 
> the "chunked" transfer encoding.
> Note that 3.6 already requires that the chunked value be listed if chunking 
> is in use.
> 3.6 would still benefit from:
> Whenever a transfer-coding is applied to a message-body, the set of 
> transfer-codings MUST include "chunked", unless the message indicates it is 
> terminated by closing the connection.

I'm still just as confused.

What delimits the end of the message in the gzip transfer-coding?  Must 
it always used with chunked or not?  You gave the message:

HTTP/1.1 200 OK 
Transfer-Encoding: gzip
Connection: close

as an example, presumably to illustrate that the gzip coding is 
delimited by connection closure and not used with chunked?  So what 
about use of the gzip transfer-coding in request messages?  The client 
is supposed to do a half-shutdown of the TCP connection to indicate 

I think someone mentioned the gzip transfer-coding is actually use by 
some implementations - what do they do?  Wrap it in chunked or not?

Received on Friday, 23 May 2008 22:18:17 UTC

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