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

Use HTTP Status 429 - Too Many Requests #20

Open
olliebennett opened this issue Oct 15, 2015 · 9 comments
Open

Use HTTP Status 429 - Too Many Requests #20

olliebennett opened this issue Oct 15, 2015 · 9 comments

Comments

@olliebennett
Copy link

When throttling, it might be more accurate to return the following status code:

429 Too Many Requests

The user has sent too many requests in a given amount of time.

This is apparently intended for use with rate limiting schemes.

I realise that defaulting to this error code would be a backwards incompatible, but I think this should be documented. I can provide a PR updating the README.

Related: #5 (which changed the default status code, rather than simply documenting it)

@jstoup111
Copy link

👍

@shishirsharma
Copy link

👍 Yeah, 429 is much better response. Also we need some rate limit indicating headers like these. http://stackoverflow.com/a/16022625/228589

@subodhkhanduri-oyo
Copy link

👍

@fidelisrafael
Copy link

How is this? 429 is way better and more correct HTTP Status code than 403, for clients it's too much also identify this kind of response from server, since 403 can means a lot of things(most of time: authenticated but now allowed)....so it's more hard to clients(such a mobile application or a web page) to report this behavior to user when this happen (for example, an application can have a error and sent a lot of requests without the user realizing).

https://httpstatuses.com/403
https://httpstatuses.com/429

@dentarg
Copy link
Contributor

dentarg commented Aug 17, 2017

It's pretty easy to use 429 if you want to: https://github.com/dryruby/rack-throttle/blob/v0.5.0/lib/rack/throttle/limiter.rb#L22. It's also documented in the README.

@fidelisrafael
Copy link

fidelisrafael commented Aug 17, 2017

We're talking about the default status

@dentarg
Copy link
Contributor

dentarg commented Aug 17, 2017

Oops, sorry, read too quickly. 👍

@FreekingDean
Copy link
Collaborator

This still has the potential to break lots of peoples setups if just done. I think it may be good to have this be listed as a deprecation for a period before deploying.

@fidelisrafael
Copy link

@FreekingDean Absolutely. Good point.

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

No branches or pull requests

7 participants