Re: content-encoding and range headers

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.

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

HTH,

Alex.

-- 
                            | HTTP performance - Web Polygraph benchmark
www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite
                            | all of the above - PolyBox appliance

Received on Tuesday, 17 December 2002 14:00:18 UTC