search

ietf-wg-httpapi / ratelimit-headers

Repository for IETF WG draft ratelimit-headers
Other
42 stars 4 forks source link

Status code when `RateLimit-Remaining: 0` #42

Closed mfortini closed 3 years ago

mfortini commented 3 years ago

I noticed in the example in 8.1.1 You return a 200 response with RateLimit-Remaining: 0 . It is not completely clear in the document that a remaining value of 0 should be returned to the caller as a success when the quota has been used exactly. In 2.2. you present a case where the cost of a more expensive call deducts two from the remaining pool and results in a 429. I am conflicted as to whether it should be a server decision whether the call is respected or whether the spec should strictly define this behaviour. I lean toward the former but some feel guidance is needed.

ioggstream commented 3 years ago

It is not [] clear [] that a remaining value of 0 should be returned to the caller as a success when the quota has been used exactly

we should clarify that this is a server choice. The spec does not mandate any correlation between the RL values and the returned status code §1.4 Goals.

A server MAY return RateLimit response fields independently of the response status code. This includes throttled responses.

The server can always decide to serve requests even when quota is over.

We need to clarify this both in the text and in the example.

V7k3ng commented 3 years ago

The server can always decide to serve requests even when quota is over

That is something that was not clear to me when reading the spec. The assumption being that when RateLimit-Remaining is exhausted, a user will be rate limited and an error response (429) will be issued.

It would seem as per #41 and #44 that there is no specific intention to require a server implementation to deny further responses, but rather in some cases the expectation would be for the client to gracefully comply and back off. My feeling is though that this use case would be the exception rather than the rule, with most implementations opting to deny further requests. Should we not at least provide guidance that a 429 response should be issued in this scenario ?