Skip to content
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

Rate limit #114

Open
lucasdupin opened this issue Jan 9, 2015 · 1 comment
Open

Rate limit #114

lucasdupin opened this issue Jan 9, 2015 · 1 comment

Comments

@lucasdupin
Copy link

It would be nice to have rate limits for collections, restricting by IPs.
After n requests, the request should be dropped, for security reasons, as in a honey pot.

Suggestion:
It can be declarative, in the security.yml, like this:

collections:
  auths:
    max_request_per_minute: 100
@endel
Copy link
Contributor

endel commented Jan 13, 2015

I'll leave a quotation for further reference here:

To prevent abuse, it is standard practice to add some sort of rate limiting to an API. RFC 6585 introduced a HTTP status code 429 Too Many Requests to accommodate this.

However, it can be very useful to notify the consumer of their limits before they actually hit it. This is an area that currently lacks standards but has a number of popular conventions using HTTP response headers.

At a minimum, include the following headers (using Twitter's naming conventions as headers typically don't have mid-word capitalization):

  • X-Rate-Limit-Limit - The number of allowed requests in the current period
  • X-Rate-Limit-Remaining - The number of remaining requests in the current period
  • X-Rate-Limit-Reset - The number of seconds left in the current period

Source: http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants