Re: What is Content-Length?

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