Re: Worries about content-length
Rick Troth (TROTH@ua1vm.ua.edu)
Fri, 16 Jun 95 12:40:17 CDT
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 ; < bar.ua
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 <troth@ua1vm.ua.edu>, Houston, Texas, USA
http://ua1vm.ua.edu/~troth/