Re: holding connections open: a modest proposal
Rick Troth (troth@is.rice.edu)
Wed, 14 Sep 1994 11:05:07 -0500
On Sep 13, 12:22am, Marc VanHeyningen wrote:
>
> Re the original proposal, the main thing missing is specification of
> headers; the "Content-Length" header becomes mandatory whenever it is
> nonzero if multiple transactions are happening.
Content-length should not be used here.
Content-length requires that the server count bytes or acquire a
byte count from the filesystem. The latter may not be available.
The former involves potentially HUGE amounts of temporary storage.
Why must the output of a script be held until the program terminates?
What we need is a way to indicate end-of-file to the HTTP client.
> ... provides extensions that are rather stream-centric. Up to
> this point HTTP generally has not been like that. Should it be?
Being a streams fiend I may be blind here, but isn't TCP itself
nothing more or less than a stream? HTTPD really breaks down to just
client_producer | HTTPD | client_consumer
Personally I *love* this. It's simple. The only problem
with it is that client_producer and client_consumer are both
represented by the same file descriptor. :-(
> > Another proposal which has been discussed is to use MIME multi-part
> > document format to make an HTML document with 20 images into a
> > single document. The problem with this is that it represents
> > substantial effort on the part of browser and server writers and
> > is, for that reason, not likely to get implemented.
>
> Indeed; it also produces some flexibility problems, since the
> server has no way of knowing whether the client already has some of
> the images cached, or even whether the client can or wishes to
> retrieve and display the images at all.
Amen.
> --
> Marc VanHeyningen <http://www.cs.indiana.edu/hyplan/mvanheyn.html>