-
-
Notifications
You must be signed in to change notification settings - Fork 369
Fails with wrong headers #1370
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
Comments
Original comment by Daniel Frischhut (Bitbucket: daniel_frischhut, GitHub: Unknown): I know that this is invalid, I got this header in a productive environment, so I have no influence on the browsers out there. The application returns a 500 error right now, this may is wanted in some cases - in other cases the application should continue and just ignore the wrong header element. |
Original comment by Sylvain Hellegouarch (Bitbucket: Lawouach, GitHub: Lawouach): Hi Daniel, I don't think it's a bug per-se and the server reacts accordingly by sending out a 500 error. Yet, from a user point of view, I can appreciate you'd want the encoding header to be more forgiving. This is more of a feature than a bug however. |
@jaraco I don't think there should be any forgiveness to malformed input. Do you? |
Malformed input should return a 40x error and not a 500 error. I'm less sure about whether the error should be silently suppressed or raise a 40x. |
This morning my website experienced the same issue, and due to the exact same malformed header:
What is this client out there in the wild that adds this erroneous close-parenthesis? For what it's worth, I came here to make the same request, i.e. that we tolerate the header. I think when the user sees a 500 error it makes me look bad, and I imagine they are probably totally unaware that they are sending this malformed header. They will never fix the problem, and my website will continue to appear broken to them. |
@webknjaz, @jaraco, I'll take this one. I'm considering a couple of approaches:
Any preference? |
@seils @skieffer Malicious requests have to result in client errors http 400 (40x). |
Originally reported by: Daniel Frischhut (Bitbucket: daniel_frischhut, GitHub: Unknown)
We got a request with the following header-fields:
and cherrypy faild with follwing Traceback:
i edited the httputil.py in line 207 and surrounded the return float(val) with a try - except and returned the default value.
The text was updated successfully, but these errors were encountered: