Implement RFC6585 Section-4 for Rate Limiting
Reported by Michael Roterman | February 23rd, 2014 @ 08:31 AM | in Marvel's Daredevil (closed)
Currently the implementation of Rate Limiting returns a 503 Service Unavailable, and as far as I've read from the documentation doesn't provide a "silence" time in the request headers.
Implementing the RFC as described here http://tools.ietf.org/html/rfc6585#section-4, the header returned would look like e.g.
HTTP/1.1 429 Too Many Requests
Retry-After: 3600
If the Retry-After header could then be used to negotiate the
"silence" time, which in turn would create an excellent entry point
to create some sort of "RetryAfterDelay" plugin.
And in my humble opinion is closer to the specification than using
the current 503 status.
Comments and changes to this ticket
-
Travis Bell February 23rd, 2014 @ 10:04 AM
Hey Michael,
Unfortunately this is out of our control currently. The version of Nginx we're on has the 503 hard coded. They didn't improve this until a later version where you can control not only the status but also things like a fully compatible RFC6585.
We do have plans to eventually upgrade our load balancers/front end HTTP servers but this is not on our immediate list of things to do.
-
Michael Roterman February 24th, 2014 @ 05:15 PM
Hi Travis,
This is unfortunate, however do you think it would be reasonable / possible to implement a "backoff" header to help implementations decide when to retry?
Thanks!
-
Travis Bell February 24th, 2014 @ 05:34 PM
This has been on the table for a few months as we've been talking about how we're going handle the eventual commercialization of the API (this won't affect developer accounts). We've settled on bringing this in app and outside of the server layer but that also means it's a pretty big job.
There's a lot more than just some headers that will be useful, we'll have individual control over each API key and improved metrics on our end to make sure we can continue offering our service. It's a necessary step in our evolution, our ops team doesn't like when we have runaway clients (which happens more often than you might think). Thing is, we won't be spending any time on this until we do it all.
To answer your specific question, no, I don't have an ETA but it will be in the next 6 months.
-
Michael Roterman February 24th, 2014 @ 06:04 PM
I can understand where you are coming from, as far as I understand the limitation lies at Nginx ( meaning the current version and how you limit-rate the API )?
I'm not sure if this is possible but, if not through headers could the "backoff" time be included in the response body for time being? Is this limited to the implementation combined with Nginx currently or is that still a part of the API?
-
Travis Bell February 25th, 2014 @ 01:14 PM
Right now, the implementation is purely in Nginx which means we can't do anything without upgrading Nginx itself. This isn't planned in the immediate future.
-
Michael Roterman February 25th, 2014 @ 03:25 PM
Alright thanks Travis, I'll implement this differently then for time being.
Did you receive my e-mail by the way?
-
Travis Bell March 5th, 2014 @ 04:43 PM
- State changed from “new” to “started”
- Tag set to “feature”
- Milestone changed from “Icebox” to “Magnolia”
-
Michael Roterman March 5th, 2014 @ 05:53 PM
Glad to see this is being worked on! Will implement it within a few days.
-
Travis Bell March 18th, 2014 @ 11:02 AM
- State changed from “started” to “hold”
Work for this has been completed. I'm just waiting for ops to deploy it into production. I'll update this ticket once it is.
-
Michael Roterman March 24th, 2014 @ 12:48 PM
Hi Travis,
Been off the radar for a bit, sorry for the delayed update.
The pull request is waiting for your go-ahead!
-
Michael Roterman September 13th, 2014 @ 01:33 AM
Hi Travis,
Been a while since I got back to this ticket, do you have any news on this? The pull request is far by outdated now, and will have to update it accordingly.
Michael
-
Michael Roterman December 18th, 2014 @ 06:16 AM
Hi Travis,
Any update on this yet? I'm about a week away or so from releasing 2.0 and it would be nice to have this implemented?
Sincerely,
Michael
-
Travis Bell December 21st, 2014 @ 09:36 AM
- State changed from “hold” to “started”
- Milestone changed from “Magnolia” to “Dawn of the Planet of the Apes ”
This has a good chance of getting pushed out in the next week or so. I'll update this ticket and forum post when we do.
-
Michael Roterman December 21st, 2014 @ 07:10 PM
Would be awesome to include this from 2.0 straight away, I have identified some issues that still need to be resolved on my side and also called upon some collaborators for help and opinions to get work done ASAP. My timeline for 2.0 is roughly 1-2 weeks, I was aiming for a Christmas release but I've had to deal with other personal things.
If this is going to be implemented by next week I'm pretty sure it's going to be included straight away, instead of making another 2.1 release for it.
-
Travis Bell January 2nd, 2015 @ 03:16 PM
- Milestone changed from “Dawn of the Planet of the Apes ” to “Jarhead”
-
Travis Bell February 3rd, 2015 @ 08:57 AM
- Milestone changed from “Jarhead” to “Fast and Furious”
-
Travis Bell March 9th, 2015 @ 09:29 AM
- Milestone changed from “Fast and Furious” to “Mad Men”
-
Travis Bell April 28th, 2015 @ 09:18 AM
- Milestone changed from “Mad Men” to “Marvel's Daredevil”
-
Travis Bell May 19th, 2015 @ 08:18 PM
- State changed from “started” to “resolved”
Hey Michael,
After 15 months, guess what? This is live in production :D
I'll post about this tomorrow on the Google group but I thought I'd let you know.
Please Sign in or create a free account to add a new ticket.
With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.
Create new ticket
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
Anmol Prakash
Travis Bell