Re: New I-D: Retry-Scope header field

[Mark Nottingham <[e-mail]>]

Hi Roberto,

My initial personal thoughts --

"""
While Retry-After applies to the issued request, it may be useful for the server to communicate to the user agent that the conditions that lead to returning Retry-After are broader in scope than a single request.
"""

I don't know that it makes sense to put a different scope on retries; the only thing that's able to be retried is a request that's already been made, and the only one that a response knows about is _this_ request. In particular, Retry-After is also defined to be used by 413 Payload Too Large, and that doesn't make any sense to scope beyond the current request payload.

I _think_ the semantic you're looking for is attached to the status code (in the most obvious case, 503), not the Retry-After header.

If that's the case, the first thing I wonder is whether there are other status codes that might be relevant -- i.e., whether one should just do a "scope a 503" header, or one for any potential status code. 

After a quick look, I suspect that most of the 4xx status codes don't benefit from defining a scope (at least in terms of the server's resources). In theory 401 and 407 would, but the authentication framework already defines the concept of authentication realms. 403-406 and 410 might, but I really question what the concrete use cases would be, as well as the security considerations regarding exposing that information.

Of 5xx status codes, 503 is the only one that has an obvious fit. 

Even for 503, I wonder about the use cases. I very much doubt that a browser is going to stop making requests to a server or a portion of it based upon the value of this header (although I'd be happy to be proven wrong if one of the browser folks wants to chime in). Could you speak to what you expect a consumer to do with this information?

Cheers,


> On 19 Feb 2020, at 9:59 pm, Roberto Polli <[e-mail]> wrote:
> 
> Hi @all,
> 
> after a discussion with Martin and Roy on the scope of Retry-After [1]
> I wrote a brief I-D to address that issue.
> 
> - https://ioggstream.github.io/draft-polli-retry-scope/draft-polli-retry-scope.html
> 
> It's very short and it could even be integrated in httpbis-semantics.
> 
> Have a nice day,
> R.
> 
> [1]: https://github.com/httpwg/http-core/pull/317#issuecomment-585868767

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