W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1997

Re: What is Content-Length?

From: John Franks <john@math.nwu.edu>
Date: Thu, 11 Dec 1997 10:36:52 -0600 (CST)
To: Scott Lawrence <lawrence@agranat.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <Pine.LNX.3.95.971211101032.5124A-100000@hopf.math.nwu.edu>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/4906
On Thu, 11 Dec 1997, Scott Lawrence wrote:

>   This is getting out of hand.  We have multiple interoperable
>   implementations in which the current definition of content length
>   and its interaction with transfer encoding has been shown to work.

The Rev01 spec contains TWO contradictory definitions of content
length.  One says it is the length AFTER transfer encoding is applied
the other says it is the length BEFORE transfer encoding is applied.
It works at present only because the only current transfer encoding
is chunked and it is self-delimiting so the Content-length header
is omitted.  If there will ever be a transfer encoding which is
not self-delimiting then the spec must resolve this issue.

>   However flawed it may be in some theoretical sense, it does work and
>   should not be changed, nor should any other header to carry a length
>   be added, unless it can be shown that it actual practice something
>   is broken.

Something is broken.  What is broken depends on which definition of
Content-length you use.  

If content length is the length AFTER transfer encoding then digest
authentication definitively broken.  You can't create
Authentication-info in a trailer of a chunked object if it needs to
know the length of the chunked object.

On the other hand if Content-length is the length BEFORE transfer
encoding is applied then there is no way to have a non-self delimiting
transfer encoding (e.g. a compression).  This is because
Content-length would be the uncompressed length so the client wouldn't
know when the body ended.

>   As for the digest authentication entity digest, the content length
>   is not one of the elements that presents a problem, since it does
>   not change based on the transfer encoding.  

That depends on the definition of Content-length.  Larry Masinter
argues that Content-length should be the length AFTER chunking.
If that is the case then digest is broken.

I would prefer Content-length to be the length BEFORE any transfer
encoding.  From Scott's remarks it is clear this is what he
understands content length to be.  But if Content-length is length
before transfer encoding we must introduce a Transfer-length header or
forbid any future transfer encodings which are not self-delimiting.

I worry that defining content length to be the length after transfer
encoding might have some serious gotcha's we haven't thought of.
For example, with that definition, if a client does a HEAD on 
resource and then a GET on the same resource the Content-lengths
for the two responses could be completey different.  Would this
break anything?

John Franks
Received on Thursday, 11 December 1997 08:39:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:16:28 UTC