[5563] in www-talk@info.cern.ch
Re: holding connections open: a modest proposal
daemon@ATHENA.MIT.EDU (Gary Adams - Sun Microsystems Labs)
Wed Sep 14 01:14:49 1994
Date: Wed, 14 Sep 1994 07:05:29 +0200
Errors-To: listmaster@www0.cern.ch
Errors-To: listmaster@www0.cern.ch
Reply-To: Gary.Adams@east.sun.com
From: Gary.Adams@east.sun.com (Gary Adams - Sun Microsystems Labs BOS)
To: Multiple recipients of list <www-talk@www0.cern.ch>
> From www-talk@www0.cern.ch Mon Sep 12 18:28:44 1994
>
> In article <9409121903.AA21560@dxmint.cern.ch>, David Kristol writes:
> > There has been some discussion here about keeping connections open
> > between client and server after a transaction is complete. I don't
> > recall seeing a resolution, however, so I want to put forth what I
> > think is a simple solution, and I don't recall seeing anything
> > comparable proposed.
> >
>
> On the www-speed alias we discussed this a couple of months ago. One
> of the (simple) solutions we came up with was suggested by Gary Adams.
> He suggested adding a Pragma: Keep-connection header. The behaviour
> goes something like:
>
> 1) Client sends "Pragma: Keep-connection\n" along with the rest of the headers.
> 2) If the server supports this pragma, in the reply headers to the
> client, it includes "Pragma: Keep-connection\n" (real protocol negotition)
>
> At this point, either party can terminate the connection. Generally,
> the client will terminate the connection after it has retrieved all of
> the pieces of the document being viewed (suggested behaviour) or the
> server will terminate the connection based on inactivity by the client
> or server load.
>
> Code changes to support this on both the server and the client are very
> minimal.
The source changes on the server side are trivial. The client side
changes are a bit trickier, because the Content-Length bytes need
to be counted (which is a good thing to do anyway). We sent the
client and server mods off to NCSA a little while ago, but they were
too late for the next release train.
>
> We tended to stay away from MGET (as valuable as it may be) or other
> new methods as those should really be part of the next HTTP definition.
> The Keep-connection pragma allows good interop with virtually no
> changes to clients while addressing the basic problem of numerous
> session setups retrieving a single document. I think some people are
> working on reference implementations now.
>
> I haven't seen any complete digests of the www-speed alias. Can
> somebody give a pointer?
>
> John
>
