-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allows limiter headers to be written via setting instead of sending them at all times #15
Comments
These headings are common practice. |
+1 for a configuration option to disable adding X-RateLimit-* headers and Retry-After header, as users may wish to only respond with these under certain circumstances. |
Sorry but I don’t understand the request of this ticket. |
These headers are very useful for coordinating rates with a cooperative client that just needs to bound resource usage over time, but in a scenario where the rate limits are set to limit the impact of malicious actors, I don't believe it is valuable or appropriate to give them any information about the state or configuration of the rate limiter. |
I agree with this. |
These headers are a de-facto standard for rate-limiting (see https://www.ietf.org/archive/id/draft-ietf-httpapi-ratelimit-headers-07.html draft). Let's keep them as is. Lines 99 to 101 in 3327e65
If you need to remove the headers for some reason, you can write a middleware that explicitly removes the response headers. Something like
|
I've just noticed this unlinked PR: #16. Reopening. |
The headers output by this middleware "X-RateLimit-Limit", "X-RateLimit-Remaining", "X-RateLimit-Reset", "Retry-After" should be output depending on a configuration for it.
The text was updated successfully, but these errors were encountered: