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

Hi Mark,

thanks for your great feedback!

replies inline:


Il giorno mar 21 apr 2020 alle ore 09:22 Mark Nottingham
<mnot@mnot.net> ha scritto:
> 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
>  for 503, I [..] doubt that a browser is going to stop making requests [..] based upon the value of this header[...]
>  [W]hat you expect a consumer to do with this information?
During API interactions (eg. the UA is a machine)  applications or api
gateways usually return either 503 or 429 if the service is saturated,
overloaded or over-quota. In those cases the scope helps shaping the
api client behavior.

> 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.
Agree, 413 is about _this_ request

> 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.
Retry-After is defined for 429 too, see
https://tools.ietf.org/html/rfc6585#section-4 and this kind of usage
is quite similar to the one I intend.

> 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. Of 5xx status codes, 503 is the only one that has an obvious fit.
While a `503-Scope` make sense, the fact that 429 refers to
Retry-After makes me lean on Retry-Scope.
I'll reference 429 it in the draft.

Spec link:

 - https://ioggstream.github.io/draft-polli-retry-scope/draft-polli-retry-scope.html

Thanks++ and let me know,
R.

Received on Wednesday, 27 May 2020 09:19:16 UTC