Provide a method to indicate rate-limit issues #60
Conversation
| A push service MAY return a 429 (Too Many Requests) status code <xref target="RFC6585"/> | ||
| when an application server has exceeded its rate limit for push message | ||
| delivery. The push service SHOULD also include a Retry-After header <xref target="RFC7231"/> | ||
| to indicate how long the application server must wait before it makes another request. |
There was a problem hiding this comment.
"to indicate how long the application is requested to wait before making another request" Using lowercase "must" just confuses some people.
Then there is the question of scope: does this apply to the endpoint, or to the entire server as a whole. RFC 6585 doesn't answer that question, and I don't think that we should either, but we might suggest something. Maybe just add that the scope of the 429 status code is determined by the push service and may apply globally, on an application server basis, or for a specific URL.
There was a problem hiding this comment.
Thanks for the guidance on "must".
If scope is determined by the push service, then how would a application server understand how to interpret whether the policy was targeted at the application server in general or a specific URL managed by the application server? Are you suggesting some type of out-of-band policy/contract documented by the PS to the AS?
There was a problem hiding this comment.
Nah, the application server would be left guessing. After all, there are valid reasons to send 429 on any scope.
The best response to this is for the application server to stop pushing to this resource for the requested period, but not stop for other resources until they responded. Then you might have some heuristic to decide that all endpoints are busy so that you can stop entirely.
|
Looks good aside from that one thing, the resolution of which I'll leave to your discretion. |
Provide a method to indicate rate-limit issues
Closes #58