Re: Worries about content-length

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 UTC