Re: Keep-Alive Notes

Jeffrey Mogul writes:

  [ lots of stuff ]
 > 
 > In summary: unless and until we have a consensus on what the
 > "timeout" value in the (badly-named) Keepalive header means,
 > and how it could be of use, I strongly object to putting it
 > into the spec.
 > 
 > -Jeff

BTW, I was thinking that "Stay-open" sounds better, as I have yet to
meet an abstraction like a connection that I would like to call "alive".

This is a first reaction to the discussion so far, and obviously not
completely worked out:

It seems to me that it might make more sense for timeout values to
occur on requests rather than responses, though I'm far from sure that
"timeout" is right sort of control.

It is the server that has to decide what to do next to satisfy various
requests from various clients.  If a server is receiving large numbers
of requests, it might not be the best use of its resources to satisfy
them in FIFO order.  Let's assume that there would be a
process running on the server capable of monitoring HTTP requests and
making decisions about which requests to handle in which order.  If
the client sends a timeout value, that could indicate to the server,
"if you think you can satisfy this request within n seconds, let's
keep the connection open.  If not, then close it after this request."
The server may have some idea of the resource requirements for a given
request.  (For instance, file size, amount of computation, or expense
of reaching another remote host, for intermediaries).  The server
could use the timeout value from clients to juggle its own priorities,
given whatever information it has about the cost of fulfulling a
request.  In determining its own schedule, it can weigh the
desirability of keeping open a request with a given client, as closing
and immediately reopening a new connection will have costs to the
server This could also be construed as a very crude mechanism for
indicating the client's internal priority for the request, and this
information could also be used by a server to order its handling of
requests, although it wouldn't have to be obeyed.

This line of thinking suggests that another, perhaps more useful piece
of information that the client could send would be the number of
requests it expects to issue on this connection -- though this might
not be absolutely knowable at the time of the first request.  However
it could send an updated number-of-requests-remaining with each HTTP
request issued during the connection.

Shel Kaphan

Received on Friday, 13 October 1995 18:47:08 UTC