Re: FYI: http timeout headers

Right. I think the authors hope that intermediaries (proxies and gateways) will adapt their policies (within configured limits) based upon what they see in incoming connection-timeout headers, and rewrite the outgoing connection-timeout headers appropriately.

I'm not sure whether that will happen, hence my question. I'm even less sure about the use cases for request-timeout, for the reasons you mention.

Cheers,

On 10/03/2011, at 2:10 PM, Robert Collins wrote:

> On Fri, Mar 11, 2011 at 6:22 AM, Mark Nottingham <mnot_at_yahoo-inc.com> wrote:
>> <http://tools.ietf.org/html/draft-thomson-hybi-http-timeout-00>
>>
>> In a nutshell, this draft introduces two new headers: Request-Timeout, which is an end-to-end declaration of how quickly the client wants the response, and Connection-Timeout, which is a hop-by-hop declaration of how long an idle conn can stay open.
>>
>> I'm going to give feedback to Martin about this (I can see a few places where there may be issues, e.g., it doesn't differentiate between a read timeout on an open request and an idle timeout), but I wanted to get a sense of what Squid developers thought; in particular -
>>
>> 1) is this interesting enough that you'd implement if it came out?
>
> Not personally, because the sites I'm involved with set timeouts on
> the backend as policy: dropping reads early won't save backend
> computing overhead (because request threads aren't cleanly
> interruptible), and permitting higher timeouts would need guards to
> prevent excessive resource consumption being permitted
> inappropriately.
>
>> 2) if someone submitted a patch for this, would you include it?
>
> If it was clean, sure. But again there will be an interaction with
> site policy. e.g. can a client ask for a higher timeout than the squid
> admin has configured, or can they solely lower it to give themselves a
> snappier responsiveness. (and if the latter, why not just drop the
> connection if they don't get an answer soon enough).
>
>> 3) do you see any critical issues, esp. regarding performance impact?
>
> I would worry a little about backend interactions: unless this header
> is honoured all the way through it would be easy for multiple backend
> workers to be calculating expensive resources for the same client
> repeatedly trying something with an inappropriately low timeout.
>
> I guess this just seems a bit odd overall : servers generally have a
> very good idea about the urgency of things it can serve based on what
> they are delivering.
>
> -Rob

--
Mark Nottingham       mnot_at_yahoo-inc.com