- From: John Franks <john@math.nwu.edu>
- Date: Thu, 11 Dec 1997 18:00:00 -0600 (CST)
- To: Scott Lawrence <lawrence@agranat.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
On Thu, 11 Dec 1997, Scott Lawrence wrote: > At this point there are a great many reasons not to introduce a new > header without a compelling reason - they are called deployed > implementations. Any current implementation that is compliant would remain compliant if a Transfer-length header is added. > > There are no transfer encodings in 1.1 for which the length is > ambiguous; we don't need to change the spec now. > Ambiguity may be in the eye of the beholder, but many people believe that the content length of a chunked object is the length AFTER chunking. They have a very good case based on section 14.14 of the Rev01 spec. Even a smart guy like Dave Kristol expressed this view here recently, but I hope we've converted him. :) It can also be argued based on section 7 that the content length is the length before chunking. You and I agree that this is what it should be, but I don't in all honesty see how one can say the spec is unambiguous. The specification is very explicit that if a Content-length header exists it must contain the length AFTER the transfer coding is applied. The only reason this is not a problem for chunked is the spec also forbids the existence of a Content-length header if chunking is used. It would be possible to forbid the existance of a Content-length header whenever any transfer encoding exists, but then it is pretty stupid to say that Content-length is the length after encoding. For Authentication-info to work content-length must be the length before a transfer encoding is applied. If everyone could agree on that as the definition of content length, I would be happy. Then in the future we would either have to introduce Transfer-length or forbid the use of Content-length with all transfer encodings (as we do with chunked). John Franks john@math.nwu.edu
Received on Thursday, 11 December 1997 16:04:11 UTC