RE: What is Content-Length?

On Fri, 12 Dec 1997, Paul Leach wrote:

> 
> 
> > ----------
> > From: 	David W. Morris[SMTP:dwm@xpasc.com]
> > Sent: 	Friday, December 12, 1997 2:34 PM
> > > 
> > > 	If a message is sent on a persistent connection using
> > > 	a transfer-coding that does not exactly preserve the
> > > 	length of the data being encoding, then the "chunked"
> > > 	transfer-coding MUST be used, and MUST be the last
> > > 	transfer-coding applied.
> > 
> > Sounds like a complete solution to me.  Of course, I think there
> > might still be a few words about content-length to bring into
> > alignment.
> > 
> There's a problem -- if no one implements any transfer coding other than
> identity or chunked, then we don't have the necessary two implementations to
> go to Draft.  If they do, then I'll be they don't follow this rule -- they
> probably believe that Content-length is the length of the message body, not

I would take that bet ... we've had multiple implementors report that
they thought 'content-length' was entity length, not message length.
NONE who reported the converse.


> the entity-body.
> 
> I also don't like having to impose chunked when it isn't needed. If a cache
> recieves a .txt file, and gzips it for later use in serving it to clients,
> it perfectly well knows the length, and can send it out with a TE of gzip
> and a Content-length (or Transfer-length, if we want to introduce that and
> get it implemented twice).

Can't speak to implementations ...

but imposing chunked is an almost ZERO overhead operation.  NO MORE
overhead than adding a transfer-length .... probably less:

     3039[crlf]
     encoded message content
     [crlf]
     0[crlf]

Nothing about chunked encoding requires more than a single chunk.

This also cleanly covers the case where the encoded length (as 
in compressed) is unknown UNTIL after encoding is complete. Just
use multiple chunks.

Dave Morris

Received on Friday, 12 December 1997 20:14:32 UTC