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

Re: What is Content-Length?

From: David W. Morris <dwm@xpasc.com>
Date: Fri, 12 Dec 1997 14:34:08 -0800 (PST)
To: Jeffrey Mogul <mogul@pa.dec.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <Pine.GSO.3.96.971212142649.28882C-100000@shell1.aimnet.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/4930

On Fri, 12 Dec 1997, Jeffrey Mogul wrote:

> After thinking about this some more, I believe we've (almost) all
> missed an obvious solution.
> We're concerned about how the sender specifies the actual length
> of the message body when a transfer-coding is used.
> Dave Morris has been saying "redefine the encoding to include a header
> (within the output of the encoding process) which gives the length."
> Which I had been thinking of as a bad idea, because it means that
> HTTP would be in the business of specifying the format of the
> message bodies.

Actually, I thought I was discussing the property of the encoding and
asserting by example that I believed it was trival for the implementer
of the transfer encoding to meet the requirement.

> But then I remembered something that Dave had written earlier:
>     We introduced CHUNKed transfer encoding because it is difficult for
>     some servers to know the content length prior to beginning to send
>     data.
> (in this case, he was discussing trailers, but it's an important
> observation.)

I'll take your word about the context ... I think I've attempted to
make that point more than once ... but what I've been trying to
say is that there is a catch-22 ... either the length of the
transfer encoding result is self defining OR we are right back where we
invented chunked encoding because we don't know the length til the
end of the transfer.

> And we already have the ability to specify multiple transfer codings
> in the Transfer-Encoding header.
> So: Instead of defining a Transfer-Length header, we could simply
> add this rule:
> 	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

Dave Morris
Received on Friday, 12 December 1997 14:39:44 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:21 UTC