-
Notifications
You must be signed in to change notification settings - Fork 71
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
Global limit and routes setting a limit cause double response headers #33
Comments
Further investigation it seems the issue only appears when using a custom method to return the limit, but does not happen when using a string. |
The custom method to return a rate limit is simply:
So nothing fancy there. If I simply use a string on the limit decorator everything works as I would expect. |
anyone else experiencing this issue? |
I've been able to reproduce the issue in a test, but haven't had time to put together a complete fix. I'm not far off, I'll try to finish it over the weekend. |
@laurentS still happening for me |
@laurentS Did you manage to get a fix for this? Its causing some weird behaviour around the slowapi/extension.__limit_decorator:async_wrapper where the second request comes through as None throwing:
|
@papapumpnz no, sorry. I haven't found time to work on this any further. It would probably help if you could provide a couple of test cases that reproduce the error(s) you see (and the cases where you don't see an error). |
Ok @laurentS forked and have a new test suite called test_double_headers that produces double headers, or single headers. Difference is the limiter decorator uses either a callable (produces double headers) or a string (produces single headers). |
A default limit set as :
With routes that use the global limit, eg do not use the @limiter.limit decorator they respond with headers as expected with:
But routes that use the @limitier.limit decorator now get double headers as such:
and an error is thrown:
If the parameter 'swallow_errors' is set to False, SlowAPI throws an stack-trace with:
It seems since there is an existing header on the response, a string to datetime conversion is attempted on the response header '"Retry-After", but being less that 5 characters parsedate_tz returns None and we get the error above.
Question: why are routes that define a limit return double response headers?
The text was updated successfully, but these errors were encountered: