- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 29 Jun 2010 09:46:41 -0700
- To: Martin Thomson <Martin.Thomson@andrew.com>, Salvatore Loreto <salvatore.loreto@ericsson.com>, Greg Wilkins <gregw@webtide.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
My .02 - First of all, the Timeout HTTP header field is already defined and registered: http://www.iana.org/assignments/message-headers/perm-headers.html http://www.rfc-editor.org/rfc/rfc4918.txt ... so you'll need to choose a different name. I'm inclined to think that passing specific timeout values from the client to the server isn't useful, and sometimes dangerous (because it will encourage creation of race conditions). The vast majority of intermediaries (whether HTTP, NAT, etc.) will NOT change this value according to their configuration, and so its value can't be trusted. For that matter, when set from some client tools (e.g., XHR), there won't even be any visibility into the local implementation's various timeouts; the value set will therefore be a shot in the dark. Furthermore, most client applications will want to set it for "a lot," without having any more specific guidance. All of this leads me to believe that there's little value in setting a timeout; what we really need is just a flag that says "I'm long-polling here." It's a lot easier to implement support for this (e.g., in Squid, Apache Traffic Server, elsewhere), and more difficult for it to cause problems. Regarding Connection-Timeout, why not just codify the Keep-Alive timeout parameter? It's already implemented in Apache (and others, IIRC). Cheers, On 09/06/2010, at 4:42 PM, Thomson, Martin wrote: >> Adrien writes: >> I don't see what the difference is between a new proxy connection >> returning a 504 (e.g. the proxy can't connect to the server) vs proxy >> reporting 504 connection aborted on an old connection before the proxy >> could send the request to the server. > > That's not the scenario that this mechanism seeks to avoid. The idea is that a new connection is less likely to time out during the (non-idempotent) request than one that has been sitting idle for a while. This is a hop-by-hop thing. > > Obviously, if the request was going to fail anyway (at any hop), there's no gain. > >>> To the extent that it ensures that the connection remains open, sure. >> You still need to know when the 1xx is required. >>> >> >> Sure, that could use the same heuristics at the server that a client >> would use. > > We seek to do away with such heuristics. They are brittle and inefficient. > >> >> Adrien >> > --Martin -- Mark Nottingham http://www.mnot.net/
Received on Tuesday, 29 June 2010 16:47:12 UTC