- From: Stefan Eissing <stefan.eissing@greenbytes.de>
- Date: 2002年12月17日 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 UTC