Subject: [httpapi] client-specified timeout?

From: "Salz, Rich" <[email-masked]>
Date: Fri, 5 Feb 2021 18:54:25 +0000

Is it reasonable for a client to want the ability to say things like “if this takes more than 300ms send a failure status code back” ?
Anyone in the WG interested in thinking/working on this?

---

From: James <[email-masked]>
Date: Fri, 5 Feb 2021 20:03:56 +0100

If your ask is about standardisation of the request header and
negotiation of it, yes I would be interested. But my biggest question
is about how the server should respond - 504 assumes the server is a
proxy, 408 is for unused connections, neither of these at initial
glance appear to fit the use case.

- J

On Fri, 5 Feb 2021 at 19:54, Salz, Rich
<rsalz=[email-masked]> wrote:
> --
> httpapi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/httpapi

---

From: Sanjay Dalal <[email-masked]>
Date: Fri, 5 Feb 2021 11:49:09 -0800

Should there be a standard way for a client to ask for this using the
Prefer header https://tools.ietf.org/html/rfc7240?

sanjay

On Fri, Feb 5, 2021 at 11:04 AM James <[email-masked]> wrote:

> > Is it reasonable for a client to want the ability to say things like “if
> this takes more than 300ms send a failure status code back” ?
> >

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 5 Feb 2021 19:58:23 +0000

300ms is a measurement of what exactly?

This seems like something very hard to get right with a multiplexed
protocol.

---

From: Ben Bucksch <[email-masked]>
Date: Fri, 5 Feb 2021 21:38:00 +0100

Am 05.02.21 um 19:54 schrieb Salz, Rich:
>
> Is it reasonable for a client to want the ability to say things like 
> “if this takes more than 300ms send a failure status code back” ?
>

Question:

What would that mean for the server, exactly?

Do you mean the server should attempt to make the query (e.g. against a 
SQL database or similar), and if 300ms have passed and no result could 
be obtained yet, abort the query? If that's what you want, then the 
client can already abort the HTTP request/connection, and the server 
should notice that and abort the backend query. Many servers already do 
that (abort query when client aborts), and many clients already have 
implemented such a timeout feature.

Or do you mean the server should make guess whether the query will take 
more than 300ms (possibly with the help of the database, which checks 
how the query would look like and perform), and return a failure code 
immediately, *without* attempting to actually make the query?

This detail would be important to specify. The whole purpose of such a 
header field would be to save server resources. (Otherwise the client 
should just abort the request and/or ignore a late result, which many 
clients already do as-is.) So the purpose of such a header would be to 
avoid wasting server resources. If that's the goal, then the question 
whether a server would attempt a slow query or would make a quick and 
cheap reply "too slow", would be really important for the client. I 
could even see that client logic depends on exactly these semantics: 
Attempt to make a few queries, and if they are slow, narrow them down, 
or make other queries, or whatever. But if such attempts already use 
server resources, that wouldn't be a viable client strategy.

So, if you define such a header, I think it would be important to 
clarify whether the server is expected to abort queries right away, 
before running them, or whether the server is expected to make an 
attempt, and abort only when the query actually took too long.

In the "make an attempt and abort after the time elapsed" case, I would 
argue that it would be better to give the client a clear and clean way 
to abort a query, and then the client can do the timeout. Or abort based 
on other criteria, e.g. whether the user has already moved on to 
something else or clicked on something else. I think that would be more 
generic.

Ben

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 5 Feb 2021 20:47:14 +0000

*   Or do you mean the server should make guess whether the query will take more than 300ms (possibly with the help of the database, which checks how the query would look like and perform), and return a failure code immediately, *without* attempting to actually make the query?

This.

I think the “start and abort if time exceeded” is already handled, as you point out.

---

From: Ben Bucksch <[email-masked]>
Date: Sat, 6 Feb 2021 00:18:00 +0100

Am 05.02.21 um 21:47 schrieb Salz, Rich:
>
>   * Or do you mean the server should make guess whether the query will
>     take more than 300ms (possibly with the help of the database,
>     which checks how the query would look like and perform), and
>     return a failure code immediately, *without* attempting to
>     actually make the query?
>
> This.
>

Perfect. Glad for that clear answer. That makes sense.

It would be good to put that into the spec.

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 5 Feb 2021 23:40:04 +0000

So one way to squint at this problem is as a time dimension* in HTTP
prioritization and scheduling.

Just because a server might be able to retrieve a resource in the desired
time doesn't necessarily mean it can return it to the client in the same
window. In HTTP/2 or 3 imagine a small API response getting stuck behind a
larger resource (whether purposeful scheduling or HoL blocking).

So one way to approach this problem might be to define an extension
parameter to Extensible Prioirities [1] that augments urgency with a time
bound. For example priority: u=0, target-time=300 would describe a request
that is the most urgent until its target time elapsed.  What happens after
that can be further refined (5xx, reset stream, lower urgency). There's
probably a bunch a problem with this in practice but just sayin'.

Cheers
Lucas

* There's a totally different use case for time dimensions related to the
timely delivery of real-time AV, after which the object becomes useless.

[1] https://tools.ietf.org/html/draft-ietf-httpbis-priority-03

On Fri, 5 Feb 2021, 23:18 Ben Bucksch, <[email-masked]> wrote:

>    - Or do you mean the server should make guess whether the query will
>    take more than 300ms (possibly with the help of the database, which checks

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 6 Feb 2021 13:42:56 +1100

Something like:

GET /foo HTTP/1.1
Host: example.org
Prefer: wait=2

?

<https://tools.ietf.org/html/rfc7240#section-4.3>

IIRC that was specified in seconds, not ms, because of concern that very small periods desired by the client would effectively be a race with the network; e.g., if your client wants a result in 200ms and you make a request to a server even mildly far away (due to connection setup times, etc.), the response is likely to take longer.

If we wanted something with finer granularity, we'd probably want to caution against such assumptions on the client side -- i.e., that 200ms is *server-side* processing, and the client shouldn't try to enforce the timeout. 

It might also be interesting to think about sending a 103 Early Hints response with a Preference-Applied header in some circumstances, so that the client knows the server is honouring the preference...

Cheers,

> On 6 Feb 2021, at 5:54 am, Salz, Rich <rsalz=[email-masked]> wrote:
> 

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