Ability to extract remaining requests allowed

[ScheerMT]

This is usually included in headers such as described Here. For this kind of implementation with multiple rules.. I'm unsure of how to proceed with what the headers should contain. If you have rules that say no more than 5 requests in a second and 120 requests in a minute..

Perhaps a simpler starting point would be giving the reason for blocking in a header? In other words, including a header that would have a formatted response for Retry-After with the offending rule interval as the value?

[joshgummersall]

@ScheerMT you can use the violatedRules function to at least decipher which rule a given request has violated. That would be a start. Counting remaining requests is a little bit more challenging because of the sliding window. Something @dudleycarr and I could look into at some point, however.

[ScheerMT]

The sliding window aspect does complicate things but is the strength of this library! Thank you for the direction of the violatedRules functionality. The counting aspect would allow the proper headers to be passed back to the client like simpler rate limiters currently do. Thank you for the consideration.

[ScheerMT]

Returning to this issue again.. Something I have been thinking of as a solution is attaching information on all of the windows' information to the res object with a config option to include the header information for the window that should be of highest concern to the user at the time.

Deciding what this window would be could be difficult.. is it the one with the least number of tries left or is it the window with the smallest resolution that should (in theory) be hit first? I am leaning towards the first option because the smallest resolution will reset most often while the window with the least retries will always be of concern to the end user..

For sake of pulling over information from #23 the headers would be:

• X-RateLimit-Limit- the maximum number of requests that the consumer is permitted to make within the rate window.
• X-RateLimit-Remaining- the number of requests remaining in the current rate limit window.
• X-RateLimit-Reset- the time at which the current rate limit window resets in UTC epoch milliseconds.

The first header, X-RateLimit-Limit, has very little bearing on users interested in reacting to rate limits.. Should this even be included?

[apmcodes]

@ScheerMT, If need to know/ return when the next attempt (timestamp) can be made once rate limited, please refer to the comment on the below gist.

https://gist.github.com/josiahcarlson/80584b49da41549a7d5c#gistcomment-2759912