Re: Keep-Alive Notes

> Henrik Frystyk Nielsen <> wrote:
>   > [...]
>   > [argues that the relative values of timeouts can be used by the client
>  to order requests]
>   > 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.
> I'm not sure I follow your point.  When the network is slow and/or
> congested, the delays can be that bad, I think.

Maybe, but HTTP does not take this into account. It's just a design decision - 
same thing with Refresh and IMS - roundtrip times are left out.

> Consider, also, the role of intermediaries.  What timeout value should a
> proxy pass along?  Suppose we have the pipeline
> 	C -> P -> S	(client/proxy/server)
> and the server says timeout=5.  What does the proxy say to the client,
> assuming it keeps the whole pipeline open?  Timeout=5?  The client then
> thinks it has five seconds to respond.  But that five seconds applies
> only to the C-P connection.  Taking into consideration the proxy's
> processing time and the propagation times S-P and P-C, that's a
> misleading number.  So, should P say timeout=N for some N<5?  Certainly
> it doesn't want to pick N>5.
> (Roy, will you state rules for what an intermediary should say w.r.t.
> timeout?)

Persistent connections are between two parties and does not involve 
intermediary parties. A proxy can have persistent connections without letting 
the proxy client know about it.

> Henryk argues that the relative values can be used to order requests.
> But suppose C gets one response with timeout=5 and another with
> timeout=6.  Suppose the latter has come through a connection that
> involves several proxies.  The value of 6 may be well-degraded to the
> point where a failure to respond on that channel first will render the
> keep-alive useless.
> I find it hard to imagine the timeout information to be useful.

I guess that the summary of my example is that the timeout information isn't 
essential but can help the client to decide what to do next :-)


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

Received on Thursday, 12 October 1995 09:45:59 UTC