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: Tue, 17 Dec 2002 14:54:38 +0100
To: ietf-http-wg@w3.org
Message-Id: <154EE740-11C7-11D7-BAFF-00039384827E@greenbytes.de>


Am Dienstag, 10.12.02, um 17:59 Uhr (Europe/Berlin) schrieb Alex 
Rousskov:

> [...]
> Note that if the client really needs 10000-19999 unencoded content
> bytes, the request below could be used instead:
>
>   GET /foo HTTP/1.1
>   Host: example.com
>   TE: gzip
>   Range: 10000-19999
>
> Since transfer-coding is applied after the range is selected, the
> client is guaranteed to receive the same content bytes, and the server
> has an opportunity to compress the response to save bandwidth.
> Transfer-coding will probably (but not necessarily) cost extra CPU
> cycles.
>

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?
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
c) if Content-Length is set in the response, it is the amout of octets 
in
    the ungzipped body (i.e. entity).

And last: is there a public server which implements gzip TE? Apache 
seems to
have  the module hooks for doing so at least...

Thanks for the help,

Stefan
Received on Tuesday, 17 December 2002 08:54:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:49:21 GMT