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

[Mark Nottingham <[e-mail]>]

On 18/03/2011, at 3:14 PM, Thomson, Martin wrote:
>> 
>> Do you have use cases for Request-Timeout that aren't covered by a 
>> client-side timeout?
> 
> Since you ask, yes :)
> 
> In a lot of scenarios, a simple client-side connection drop is going to be sufficient.  That's true for the case where responses arrive atomically - the classic comet use case.
> 
> 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.

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. 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).


> 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.

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.


>> 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...



--
Mark Nottingham   http://www.mnot.net/