Re: Worries about content-length

        This is olde ...

>> >  It is not an
>> > unreasonable burden on HTTP servers to require accurate content-length
>> It requires that all documents returned by the server by pre-scanned.

        Yes.   And ...

>> There are apparently often times it is unreasonable.

        ... specifically,  pre-scanning breaks pipelineability.

>Sorry, I haven't heard an example yet which doesn't reflect laziness or
>poor design.  For the subset of cases where the size isn't known
>(e.g., CGI output), data could be delivered in a series of precisely
>size computed chunks with the last chunk so marked.

        Maybe.   There was the  Content-Transfer-Encoding: packet
scheme proposed by Dan Connolly a while back.   This,  or anything
else you might suggest that's similar,  would be fine.   It's the use of
Content-Length:  headers that I object to.   Content-Length can be
rendered completely invalid so easily.   It's just plain Bad News.

>> Which do you prefer?
>> 	foo | bar
>> 	foo >tmp ; bar <tmp
>The burden for the two step process falls on the information provider,
>not the network and not the consumer. Performance optimizations can
>be applied best at the source.
>        foo | bar
>is really
>        foo | [net] | [ua] > tmp ; <

        I agree that optimizations which can be applied at the source
*should* be applied at the source.   But I don't know where you're
coming from w/r/t pipelining.   MS-DOS,  and I suppose Windows,
pipelines things by staging them to a disk file.   But UNIX doesn't,
and I'm sure OS/2 and NT don't either.   For multi-tasking systems,
as soon as the first packet is written by the producer,  it can be
read by the consumer.   This is a Good Thing.   So the network
transaction really looks more like

                foo | net | ua

        ... and "ua" might be doing all kinds of kinky things that
would be incompatible with the  Content-Length:  header,  and in any
case wouldn't want to wait ... and wait ... counting bytes.

Rick Troth <>, Houston, Texas, USA

Received on Friday, 16 June 1995 11:21:47 UTC