- 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
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 closure?! I think someone mentioned the gzip transfer-coding is actually use by some implementations - what do they do? Wrap it in chunked or not? joe
Received on Friday, 23 May 2008 22:18:17 UTC