Re: [httpapi] client-specified timeout?

[Ben Bucksch <[e-mail]>]

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