Re: [hybi] Fwd: New Version Notification for draft-thomson-hybi-http-timeout-00

["Thomson, Martin" <[e-mail]>]

On 2011-03-21 at 13:21:24, Mark Nottingham wrote:
> On 18/03/2011, at 3:14 PM, Thomson, Martin wrote:
> > It is a little inefficient to drop the connection.  After all, it's
> not always the case that the client really needs to drop the 
> connection, maybe they just wanted to ask about something else instead.
> 
> I don't see how request-timeout helps here; you seem to be saying that 
> the client can assume that it's OK after request-timeout seconds to 
> submit a new request on the connection, and assume that the old 
> request has been "cancelled" server-side. That fundamentally doesn't work.

That's not the intent.  I assume that if the server knows request-timeout, then they are able to send an error response at that time, making the connection available.  Obviously, if the client sends another request after that time, they are effectively pipelining...with all that entails.
 
> Its true that there's ambiguity between purposeful connection drop and 
> accidental (e.g., network-related) drop. However, it seems to me that 
> using timeouts is a very bad way to detect this. 

The draft talks about that.  There will always be a need to handle lost connections.  Timeouts can't help, and we wouldn't pretend that they would.

> Why not send a 
> request explicitly saying that you're dropping the connection instead? 
> E.g.,
> 
> OPTIONS * HTTP/1.1
> Expect: im-outta-here-and-i-mean-it
> 
> That's just one way, there are lots of others (e.g., a chunk- 
> extension).

I don't see how that would help at all.

> > In the business that I work in - location - knowing how long you 
> > have
> to answer up front is considered quite valuable.  A GPS receiver takes 
> a certain amount of time to start producing anything at all, and it's 
> a pretty power hungry beast.  You don't even bother trying the GPS 
> receiver unless you have some indication from your client that they 
> are willing to wait for the response.  If they don't have the time, 
> you can choose a quicker method, like round-trip timing or *waves 
> hands* myriad other options.  But each of those location determination 
> methods have their own limitations.
> >
> > Thus, it's not a case of just waiting until an atomic event occurs.
> It's about setting down the request constraints up front.
> 
> Ah -- OK, that's an interesting use case. I didn't get that from the 
> draft.
> 
> This smells a little bit like the Prefer header:
>   http://tools.ietf.org/html/draft-snell-http-prefer-02
> 	
> Did you consider using something like that? E.g.,
>   Prefer: response-fast
> 
> Where the parameters of 'response-fast' is specific to the resource.

Interesting thought, but ultimately it ends up with the same semantics of request-timeout:
   Prefer: response-within=10

A single bit doesn't quite suffice for this use case.  While there is some value in being able to choose between the slowest and the fastest response, that precludes a range of in-between options.

> As you can probably guess, I'm suggesting this because I'm concerned 
> that 95% of people who want to use something like Request-Timeout 
> won't have such a subtle use case in mind.

And if that's the case, that's a good reason not to define a new header and look for other options (like Prefer).

> >> if you
> >> are going to go down this road, you'll need to define 'idle' more 
> >> carefully.
> >
> > I'll admit that the definition of 'idle' is a little casual, but is 
> > there anything fundamentally wrong with the idea that it is
> > a) subjective
> > b) based on either sending or receiving of data
> > c) probably ignorant of buffering and any fancy TCP layer stuff 
> > (Nagle's algorithm, etc, though that's hardly measurable at a 
> > granularity of seconds)
> 
> It depends very much on how it's used by receiving software. Your 
> points only emphasise how little real information there is in the 
> number that's getting transmitted...

It is a promise to a peer that they wont close the connection until they think the connection is idle (as above) for the specified time, exceptional circumstances excepted.

For instance, a client that sees a value of 120 might choose to reuse a connection that is (subjectively) idle for 90s.  Whether they also reuse the connection at 100, 110 and 119 is up to implementation/local configuration/other unspecified heuristics.

--Martin