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

Re: What is Content-Length?

From: John Franks <john@math.nwu.edu>
Date: Thu, 11 Dec 1997 14:14:09 -0600 (CST)
To: "David W. Morris" <dwm@xpasc.com>
Cc: Scott Lawrence <lawrence@agranat.com>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <Pine.LNX.3.95.971211133549.5994A-100000@hopf.math.nwu.edu>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/4908
On Thu, 11 Dec 1997, David W. Morris wrote:

> On Thu, 11 Dec 1997, John Franks wrote:
> > 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.
> As I've already said, transfer encoding was introduced to resolve the
> problem that some servers don't know the total length until 
> the whole document has been sent.  

That was the reason "chunked" was introduced.  There are other reasons
one might want to use a Transfer-encoding, e.g. compression to conserve

> All future transfer encodings MUST
> be self-delimiting. 

What is the basis of this assertion?

I find no evidence this was the intent of the protocol authors.

> It would be stupid to introduce a new header
> whose value can't always be computed to define the length of 
> some possible new method of encoding.

Or it might be stupid to preclude the possibility of ever using 
lots of useful transfer encodings to avoid introducing a new

Here's one scenario that I think people have in mind.  A proxy
receives documents, compresses them on the fly and caches the
compressed version (saving disk space).  When a client requests the
document it is served in the compressed form (with the appropriate
Transfer-encoding header) to save bandwidth.  The proxy knows
the compressed length; the client needs to know it for the transaction
to work.

John Franks
Received on Thursday, 11 December 1997 12:19:46 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:04 UTC