- From: Stefan Eissing <stefan.eissing@greenbytes.de>
- Date: Wed, 18 Dec 2002 16:31:45 +0100
- To: Alex Rousskov <rousskov@measurement-factory.com>
- Cc: ietf-http-wg@w3.org
Am Dienstag, 17.12.02, um 19:59 Uhr (Europe/Berlin) schrieb Alex Rousskov: > 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. Agreed. The response could carry a Connection: close 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). > > 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. You're right. Thanks for pointing that out. //Stefan
Received on Wednesday, 18 December 2002 10:32:18 UTC