W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1995

Re: Worries about content-length

From: James Gosling <jag@scndprsn.eng.sun.com>
Date: Mon, 8 May 1995 16:33:30 +0800
Message-Id: <9505082333.AA04504@norquay.Eng.Sun.COM>
To: mogul@pa.dec.com
Cc: NED@sigurd.innosoft.com, masinter@parc.xerox.com, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
>     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.
Received on Monday, 8 May 1995 16:32:42 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:21 EDT