Re: Worries about content-length

On Tues, 9 May 1995, Patrick R. Michaud wrote:
>Overall, I think the idea of adding a "Content-Terminator:" header 
>and terminator strings to HTTP is a reasonable idea, and the idea of
>designating an escape-code (not as part of a Content-Transfer-Encoding)
>is a pretty bad one.  Generating content-terminator strings on behalf of a
>CGI script should be a server implementation decision, and I believe 
>that CGI scripts really ought to handle their own termination 
>(via either "Content-Length:" or "Content-Terminator:") anyway.
I'm not sure I see why we are talking about adding a Content-Terminator:
header field when MIME multipart boundary's:
1) Do exactelly the same thing.
2) Are part of an existing standard
3) Are already part of HTTP (In that HTTP says it transports MIME formatted
4) Work, from my personal experience & implementation.

On Tues, May 9th, David - Morris wrote: 
>On Mon, 8 May 1995, James Gosling wrote:
>> The "hack" aspect, in my opinion, to the random delimiter scheme comes
>> from being less than 100% solid.  Admittedly, the probability of a
>> false match can be pushed arbitrarily small, but it cannot be made 0.
>> Given a good random number generator, I wouldn't worry about it too
>> much, except that it really feels like a bug waiting for a place to
>> happen.
>Agree!  To the extent that content-length isn't specified.  If it is, and
>it isn't correct, it is an error condition. I have a real philosophical
>problem with the design of non-deterministic protocols. It is not an
>unreasonable burden on HTTP servers to require accurate content-length
>nor do I believe it an unreasonable burden on UA to do the same.
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.
Of course if all you are using the content-length is for giving
transfer-status feedback to the user, an inaccurate result might be good enough.
Which brings up another point. Should we have something that lets a CGI
which doesnt' know exactelly the size of its output, but does know roughly
the size of its output be able to give an "estimated-content-length:" or

Alex Hopmann
ResNova Software, Inc.

Received on Tuesday, 9 May 1995 15:40:15 UTC