Re: FYI: http timeout headers

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
Received on Thu Mar 10 2011 - 22:10:12 MST