Re: Keep-Alive Notes

> "Roy T. Fielding" <fielding@avron.ICS.UCI.EDU> wrote:
>   > [summarized current state of keep-alive for HTTP/1.1]
>   > [...]
>   >    Keep-Alive  = "Keep-Alive" ":" 1#( token ["=" word ] )
>   > 
>   > The presence of the Keep-Alive keyword in a Connection header signals
>   > that the sender wishes to maintain a persistent connection.  The presence
>   > of a Keep-Alive header field defines parameters for the persistence.
> Is the Keep-Alive header mandatory or optional?  That is, is the presence
> of just
> 	Connection: Keep-Alive
> sufficient?

> I would argue that "max" and "timeout", at least serve no useful purpose.
> Here's why.
> 
> Take "max" first.  The client must check for Connection: keep-alive in
> each response anyway, before sending the next (at least currently)
> serial request.  So "max" conveys no useful information.  If we're
> anticipating pipelined requests, let's wait for then, rather than
> clutter the HTTP/1.1 spec.
> 
> Now for "timeout".  Because of propagation and roundtrip delays, the
> meaning of any particular value of "timeout" as received by the client
> is suspect.  Suppose the value is "10" (seconds).  The client surely
> has less than ten seconds to issue a new request.  But how much time is
> there?  Does the client know the current round-trip time, so it knows
> how much less time there is?  Does it know how long the server will
> take to get to the request (during which time the timer may be
> ticking)?  I think the answer is "No".
> 
> I argue, therefore, that the Keep-Alive header conveys no useful
> information and ought to be dropped.

I agree that many implementations won't actually need the Keep-Alive 
information. As an example, in the W3C Reference code I currently only use the 
fact that the connection is persistent. As all sockets are non-blocking, I get 
a notification from the select call when a connection is closed by the peer. 
This may in special cases leed to race conditions but they should be easy to 
catch.

However, the timeout information can have an important role if the client has 
a queue of pending requests and needs to order the queue in such a way that 
the number of sockets stays within a certain limit but with a maximum of 
outstanding requests.

An example - imagine that you hit two pages simultanously with 100 inlined 
images each. One returns a timeout of 300 secs and the other returns 30 secs. 
If you do not have the resources to fill both channels then it might be a good 
idea to concentrate on the one that will close within 30 secs.

Therefore at least the timeout does convey useful information. As HTTP is 
"measured in seconds" I don't think that roundtrip delays will have a 
significant influence in this game.

-- 

Henrik Frystyk Nielsen, <frystyk@w3.org>
World-Wide Web Consortium, MIT/LCS NE43-356
545 Technology Square, Cambridge MA 02139, USA

Received on Thursday, 12 October 1995 09:15:24 UTC