Closed nox closed 3 years ago
I'm torn. The first sentence of that paragraph also clearly says that a space is no-no.
But, as long as we can keep the security and performance, I suppose it's fine to support when things are wrong.
relaxed_response_parsing
option seems to be a good idea with stricter parsing as default
I would rather not name any option relaxed_response_parsing
as it doesn't tell us how it is relaxed.
@nox I agree with you! may be something which is obvious like allow_spaces_in_header_names
and default being to false
@avinassh #91 chose allow_spaces_after_header_name_in_responses
.
Sorry, I edited my issue, mixed up two problems at once.
Note the space after
Access-Control-Allow-Credentials
.What does the spec says about this?
So first, I want to point out that the security vulnerabilities can't really happen through httparse (or at the very least, through Hyper), given Hyper does not keep around the literal text of the HTTP request, and thus those pesky spaces cannot be passed to anyone downstream AFAIK.
Second, and this is what matters to me (wearing my work hat), is that the spec itself implies that a proxy has to be able to parse those anyway to remove the headers, thus it needs to successfully be able to parse such a response. httparse (and thus Hyper) does not let any of that pass through, which is a problem for people implementing proxies.
Making a patch that makes those spaces not fail the entire parse is pretty trivial, but I wonder if we want a
relaxed_response_parsing
option of some sort. Such an option exists in Squid.In the browser space, Firefox (and AFAIK Chrome too) happily ignore spaces between the header name and the colon, and will also ignore spaces in header names themselves (ignoring the whole "name: value" pair and just skipping to the next header in the response.
Note el famoso
Updated Preferences: []
header in the response.We can discuss whether or not to let that through at a later date.