- From: John Franks <john@math.nwu.edu>
- Date: Fri, 12 Dec 1997 10:17:44 -0600 (CST)
- To: "Life is hard... and then you die." <Ronald.Tschalaer@psi.ch>
- Cc: http wg <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
On Fri, 12 Dec 1997, Life is hard... and then you die. wrote: > On Thu, 11 Dec 1997, Scott Lawrence wrote: > > > There are no transfer encodings in 1.1 for which the length is > > ambiguous; we don't need to change the spec now. > > I'm not sure this is true. In the latest draft I discovered the > following > in Section 3.6: > > The Internet Assigned Numbers Authority (IANA) acts as a registry > for > transfer-coding value tokens. Initially, the registry contains the > following tokens: "chunked" (section 3.6.1), "identity" (section > 3.6.2), > "gzip" (section 3.5), "compress" (section 3.5), and "deflate" > (section > 3.5). > > Two questions: > > 1) Are gzip, compress and deflate really to be used as both transfer > encodings and content encodings? What's the rationale behind that? > Yes. A proxy may wish to compress an object before transmitting it to a client to improve bandwith utilization or perceived speed. The proxy can add a transfer encoding, but not a content encoding. > 2) I'm not very familiar with the details of these encodings, but I > believe they aren't self delimiting. Is this true? > I am not sure. But from the recent discussion it is very clear that it is cruicially important that all transfer encodings be explicitly defined to be self-delimiting or non-self-delimiting. I am not sure this is done in the IANA registry. John Franks john@math.nwu.edu
Received on Friday, 12 December 1997 08:23:53 UTC