Re: "Timeout" request header to tell server to wait for resource to become available

On 30/03/2015 4:34 a.m., Brendan Long wrote:
> I don't think the semantics I want are the same. RFC 7240's "wait"
> indicates how long a client is willing to wait for a server to finish
> processing, but what I'm looking for is a way to tell the server that we
> want it to wait, even though it could respond now.

So... in order to avoid latency of 1*RTT you are requiring to make a
request then have it *not respond* for T seconds.

Meaning the benefits kick in when the RTT > T. For most modern networks
that condition will simply not be true. RTT is generally in the order of
 0.0n seconds (or less).

Particularly given that time to receive the 404 message triggering the
retry just provided the latency value for 1*RTT, and the server reply
can contain Retry-After:T as a header value to complete the client pause
calculation.

> 
> Maybe the "Wait-Until: available" or "Wait-Until: etags-change" variant
> makes this more clear?
> 
> I don't think millisecond granularity of the timeout is particularly
> important. I picked milliseconds because they're a common unit, but
> seconds would be fine too.

I live in one of the more remote countries in terms of RTT latency and
we only have 350ms worst-case.

Implying the benefits threshold (RTT > T) even in normally bad network
conditions will still not be met.

> The main advantage of setting a timeout in
> the header is that it makes altering clients to support this easier
> (since they'll eventually get a valid response instead of a connection
> error).


And the main disadvantage is that some MBs of memory, and scarce TCP
socket resources are consumed for each HTTP/1 connection that is held
open by this.


Overall I dont see why this has to be a server-wait mechanism instead of
the existing HTTP client-wait mechanism.

Amos

Received on Monday, 30 March 2015 08:06:28 UTC