- From: Dave Kristol <dmk@allegra.att.com>
- Date: Thu, 12 Oct 95 12:27:27 EDT
- To: frystyk@w3.org
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Henrik Frystyk Nielsen <frystyk@w3.org> 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. 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?) 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. Dave Kristol
Received on Thursday, 12 October 1995 09:30:59 UTC