RE: What is Content-Length?
David W. Morris (dwm@xpasc.com)
Fri, 12 Dec 1997 20:08:28 -0800 (PST)
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