W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1995

Re: Worries about content-length

From: Alex Hopmann <hopmann@holonet.net>
Date: Tue, 9 May 1995 18:59:29 -0700
Message-Id: <199505100159.SAA21887@nic.cerf.net>
To: David - Morris <dwm@shell.portal.com>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
On Tue, 9 May 1995, David Morris wrote:
>
>On Tue, 9 May 1995, Alex Hopmann wrote:
>
>> Unfortunatelly we have to deal with the pragmatic situation that previous
>> HTTP drafts were not specific about content-length and many servers are
>> sending "broken" contents in this respect. This is one reason why I do not
>> trust the content length unless I have negotiated the "Session" extension.
>
>I believe we are discussing what the standard should say, not guidance
>for dealing with broken software. It is really moot to discuss 
>character stuffing, random end sequences or content-length in terms
>of the 'correct' or best way to convey and manage the length of data
>unless we discuss the future. Perhaps I've misunderstood the direction
>of the thread?
I agree that the standard should not talk about the broken implementations.
However if the standard says "If you receive a content-length field as a
client you can rely on it", then the standard is not describing current
practice, and someone who implements a client that relies on content-length
fields will discover that their client doesn't work with a large part of the
installed base.
I'm not sure what to suggest other than a:
Content-Length-No-I-Really-Mean-It-This-Is-Accurate:
field. smile.

Actually, there are things we can do in the standard to provide a content
length in such a way that you can tell that it is accurate. Sending it in
conjunction with something else that vouches for the content-length being
accurate might work. For instace, we could say "For a server to claim
HTTP/1.1 it must send the content-length correctly".

As for sending multiple chunks each with a length, that sounds like
something better handled at a different OSI-layer, and as a matter of fact,
that is pretty much what HTTP-NG does. Lets leave it for HTTP-NG. I am
fairly happy with the combination of the Content-length, and MIME multipart
boundary solutions for HTTP/1.1.

Alex Hopmann
ResNova Software, Inc.
hopmann@holonet.net
Received on Tuesday, 9 May 1995 19:01:19 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:21 EDT