Re: [httpapi] client-specified timeout?

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, <news@bucksch.org> wrote:

> 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.
>
> I think the “start and abort if time exceeded” is already handled, as you
> point out.
>
>
> Perfect. Glad for that clear answer. That makes sense.
>
> It would be good to put that into the spec.
> --
> httpapi mailing list
> httpapi@ietf.org
> https://www.ietf.org/mailman/listinfo/httpapi
>