The draft says that some requests can consume different amounts of units
OK, that is a little tricky, but then it becomes harder to predict whether your request will be accepted.
in some cases impossible
Service providers decide their service management model and we don't want to constrain them.
Clients know how the service provider weights their requests, and thus the probability of success is lower when RateLimit-Remaining is low. In these cases either the clients stops earlier or the server has some tolerance.
I wonder whether a rejection might include an extension that says "that request would have consumed X units"
Or more generally, for any response, this request used X units.
In our landscaping #1 we have not found implementers interested in conveying this information per-request. Instead, they do it on contracts or other side-channels. You could use 429 + a RFC7807 payload though.
Guidance in returning headers :heavy_check_mark:
@darrelmiller
I would like to see guidance in the spec as to when to return these headers. There seems to be an existing pattern where these are returned on every request, which is concerning.
This is a point where we expect guidance from you and the WG, see #42
for now we focused on standardizing the semantic and syntax, because the primary goal was stopping proliferation.
[x] See #27
Complex quota policies :heavy_check_mark:
@mkalika
Some institutions may have additional constraints bounded to time. For example X units within Y seconds between 2am - 5am. Wouldn't that be good to take care of such cases too
Just return that quota-policy b/w 2am-5am setting the policy window accordingly, as @mthomson suggested.
IETF-109 Feedback
Here is a Q&A after the IETF-109 presentation.
Requests or Units :heavy_check_mark:
@mthomson @alficles
Service providers decide their service management model and we don't want to constrain them. Clients know how the service provider weights their requests, and thus the probability of success is lower when
RateLimit-Remaining
is low. In these cases either the clients stops earlier or the server has some tolerance.SH Syntax :heavy_check_mark:
@reschke help is needed, see https://github.com/ioggstream/draft-polli-ratelimit-headers/issues/35#issuecomment-713897345
Rejecting requests with motivation
In our landscaping #1 we have not found implementers interested in conveying this information per-request. Instead, they do it on contracts or other side-channels. You could use 429 + a RFC7807 payload though.
Guidance in returning headers :heavy_check_mark:
@darrelmiller
This is a point where we expect guidance from you and the WG, see #42 for now we focused on standardizing the semantic and syntax, because the primary goal was stopping proliferation.
Complex quota policies :heavy_check_mark:
@mkalika
Just return that quota-policy b/w 2am-5am setting the policy window accordingly, as @mthomson suggested.