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

Re: content-encoding and range headers

From: Stefan Eissing <stefan.eissing@greenbytes.de>
Date: Wed, 18 Dec 2002 16:31:45 +0100
Cc: ietf-http-wg@w3.org
To: Alex Rousskov <rousskov@measurement-factory.com>
Message-Id: <D0B447E7-129D-11D7-965C-00039384827E@greenbytes.de>

Am Dienstag, 17.12.02, um 19:59 Uhr (Europe/Berlin) schrieb Alex 

> On Tue, 17 Dec 2002, Stefan Eissing wrote:
>> While we're at it, maybe someone can confirm that I understood
>> Transfer-Encoding correctly:
>> If a server choses to use gzip transfer encoding in answer to the
>> request above, is it correct to assume that
>> a) the header
>>       Transfer-Encoding: gzip, chunked
>>     ot the combination
>>       Connection: close
>>       Transfer-Encoding: gzip
>> would be sent. And that there is no other way to implement transfer
>> encoding gzip than chunking the gzipped message body or closing the
>> connection at the end of the gzipped body?
> That is my understanding as well. Note that chunking support is an
> HTTP/1.1 MUST.
> For completeness sake, note that a combination of chunked encoding and
> non-persistent connection is also legal:
> 	Connection: close
> 	Transfer-Encoding: gzip, chunked

>> b) assuming chunked, gzip transfer encoding is used, the order in the
>>    header would be
>>       Transfer-Encoding: gzip, chunked
>>    and not
>>       Transfer-Encoding: chunked, gzip
> Yes, unless the connection is not persistent.

Agreed. The response could carry a
	Connection: close
	Transfer-Encoding: chunked, gzip

>> c) if Content-Length is set in the response, it is the amout of octets
>> in the ungzipped body (i.e. entity).
> I do not think it is that simple. You must not send Content-Length
> header if you are using non-identity transfer codings -- the value of
> Content-Length header (if it is given) must match _both_ entity-length
> and the transfer-length. See RFC 2616, section 4.4 for details.

You're right. Thanks for pointing that out.

Received on Wednesday, 18 December 2002 10:32:18 UTC

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