Re: Worries about content-length

>     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.