Re: Worries about content-length
James Gosling (jag@scndprsn.eng.sun.com)
Mon, 8 May 1995 16:33:30 +0800
> One can make algorithmic arguments on both sides fairly persuasively: I
> believe they end up being very close in the limit. For example, I
> would implement byte-stuffing on the server side by having the files in
> the cache be pre-stuffed. Since my server has a RAM cache, it's
> particularly easy. Then I just do a single firehose write to the socket.
> (Of course, the pre-computation technique can be used in the random
> delimiter case to guarantee 100% safety)
>
> But if you have the files already cached and precomputed, you might
> as well just use Content-Length and make everyone's life easier.
> The problem comes for non-cachable results (such as the output of
> a CGI script subprocess), when the response has to be generated "live."
Absolutely, but the performance concerns seem to be mostly with non-script
generated results, so performance in that case is important. In the
cgi script case, the fork/exec cost is more than high enough to swamp
either the cost of either byte-stuffing or random delimiter generation.
The problem with content-length today is that it's so untrustworthy
that it's almost useless.
But this is all really a moot point: we should be concentrating on
http-ng so that the existing practice, warts and all, can disappear
as soon as possible.