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

From: Martin Thomson <[email-masked]>
Date: Fri, 27 Mar 2015 20:46:31 -0500

2015-03-27 17:13 GMT-05:00 Brendan Long <[email-masked]>:
> hTmftQ6t4pJNuAjYvl8l49hAE7QYpyVi0/bvxnbU27QG9agVq4g53cWouIU+9uKF
> H39lF0vJJ8J3DQCXzgRirdaLoXZ+ZJZ0Jtu90FYE38afR763pPEVN02N6w7dgm+k
> SI7bSJeep2dG7LzffTg+qzzpJeYJO2KnezE6YOIcDvoHxd80qJCb8zhqQkfSw0AR
> OCVIgTG2x7f0i58Ls+/mcGSDnLWg1nZ8PACvuMte7V9B66fWvN9CCM8awcfdZ6w5

I believe that what you want is accomplished by RFC 7240:

Prefer: wait=5

The units are perhaps suboptimal for your use case (seconds instead of
milliseconds), but we might be able to make a change to support finer
grained timing.

---

From: Matthew Kerwin <[email-masked]>
Date: Sat, 28 Mar 2015 12:46:42 +1000

> milliseconds), but we might be able to make a change to support finer
Incidentally, I've just found an erratum in RFC 7240: Section 1.1 says that
"delta-seconds" is defined in Section 8.1.3 of [RFC7231], but it's actually
in RFC 7234, Section-1.2.1. ​I'll report it.

Regarding extending/modifying the header to accept sub-second timings, how
would current implementations treat:

    Prefer: wait=0.2

? It doesn't fit the syntax, so would it be ignored outright (as an
unrecognised header) most of the time?

Cheers
-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/

---

From: Brendan Long <[email-masked]>
Date: Sun, 29 Mar 2015 10:34:14 -0500

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.

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

---

From: Amos Jeffries <[email-masked]>
Date: Mon, 30 Mar 2015 21:05:52 +1300

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

> 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

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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 30 Mar 2015 08:20:40 -0700

> Maybe the "Wait-Until: available" or "Wait-Until: etags-change" variant

If-None-Match in combination with Prefer: wait does exactly what you want
here.

---

From: Brendan Long <[email-masked]>
Date: Mon, 30 Mar 2015 16:49:16 -0500

On 03/30/2015 10:20 AM, Martin Thomson wrote:

If-None-Match in combination with Prefer: wait does
exactly what you want here.

I've read RFC 7240 a few times now, and I'm not convinced that it's
specific enough, but I guess it will work.

1. Return a 202 (Accepted) response for asynchronous processing if
the request cannot be processed within 10 seconds. An undefined
"priority" preference is also specified:

POST /some-resource HTTP/1.1
Host: example.org
Content-Type: text/plain
Prefer: respond-async, wait=10
Prefer: priority=5

4.3. The "wait" Preference

The "wait" preference can be used to establish an upper bound on the
length of time, in seconds, the client expects it will take the
server to process the request once it has been received. In the case
that generating a response will take longer than the time specified,
the server, or proxy, can choose to utilize an asynchronous
processing model by returning -- for example -- a 202 (Accepted)
response.

Waiting for a file to appear or change doesn't really fit "the
request cannot be processed". It's just that we *don't want the
request to be processed*.

I'll make my server implement it with this header though, and I
guess if it takes off it'll become de-facto correct behavior.