Re: content-encoding and range headers

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

> 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.

//Stefan