could add throttle status to response headers when not exceed throttle

[iamroody]

I know we could add these headers to response in controller from "request.env['rack.attack.throttle_data'][name]"， but if we could config add this custom header in rack-attack, it would be great.

[ktheory]

Hi @iamroody. I don't think I follow. Are you wanting to customize how rack attack annotates the request? You could do that with your own custom middleware.

Could you clarify your use case with an example?

[ktheory]

I'm going to close this for now. Feel free to reopen with clarification.

[johnmcdowall]

Sorry to Necro this, but I also expected this to be the default behaviour - seems like something rack-attack should do out of the box.

To clarify, when a throttle is specified, the response should include headers to indicate the throttle limit, and the remaining calls available for the period, like twitter does:

X-Rate-Limit-Limit: the rate limit ceiling for that given request
X-Rate-Limit-Remaining: the number of requests left for the 15 minute window
X-Rate-Limit-Reset: the remaining window before the rate limit resets in UTC epoch seconds

Any chance this will be added? Seems like a very common expectation and use case.

[ktheory]

@johnmcdowall: Good points. It is a common expectation & use case, especially when designing an API. I'm unconvinced it should be the default, b/c sometimes it's nice to not expose that info if you're trying to slow down malicious attackers. And modifying app response headers feels like a big increase in the scope of rack-attack. E.g., would we override the X-RateLimit-* response headers if they're already set by the app?

What would the X-RateLimit-* headers be if multiple throttles were hit?

What would be least surprising for developers?

That uncertainty is why I punted on it for now. There's enough throttle info in the env for developers to add the headers themselves.

If you have a good solution, please implement a proof-of-concept rack middleware, and I'll gladly consider including it in rack-attack.