- From: James Gosling <jag@scndprsn.eng.sun.com>
- Date: Mon, 8 May 1995 16:33:30 +0800
- 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 UTC