- From: Stefan Eissing <stefan.eissing@greenbytes.de>
- Date: Tue, 17 Dec 2002 14:54:38 +0100
- To: ietf-http-wg@w3.org
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 UTC