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

Re: content-encoding and range headers

From: Alex Rousskov <rousskov@measurement-factory.com>
Date: Tue, 17 Dec 2002 11:59:57 -0700 (MST)
To: Stefan Eissing <stefan.eissing@greenbytes.de>
cc: ietf-http-wg@w3.org
Message-ID: <Pine.BSF.4.44.0212171158210.48556-100000@measurement-factory.com>

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

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.



                            | 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

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