Skip to content
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

double quotes in headers can not be parsed #83

Open
clouduol opened this issue Jan 25, 2021 · 3 comments
Open

double quotes in headers can not be parsed #83

clouduol opened this issue Jan 25, 2021 · 3 comments

Comments

@clouduol
Copy link

In the header name map, index 34 is false. So when parsing headers, the program will return Error::HeaderName when meeting double quotes(ascii number is 34) . However, bouble quotes in headers can be parsed correctly in chrome. Is this intentional or a bug?

Test Example:

 #[test]
    fn test_double_quotes() {
        use std::mem;
        let bytes= b"HTTP/1.1 200 OK\r\nServer: nginx/1.14.2\r\nDate: Mon, 25 Jan 2021 06:20:06 GMT\r\nContent-Type: image/png\r\nContent-Length: 24623\r\nConnection: keep-alive\r\n\"Access-Control-Allow-Origin: *\"\r\nAccept-Ranges: bytes\r\nAccess-Control-Allow-Origin: *\r\nCache-Control: 2592000\r\n\r\n";
        let mut headers: [Header; 10] = unsafe { mem::uninitialized() };
        let mut res = Response::new(&mut headers);
        let parsed_res = res.parse(bytes);
        println!("parsed res= {:?}", parsed_res);
    }
@tari
Copy link

tari commented Sep 10, 2021

At least according to RFC 2616, Chrome's behavior seems correct. A header name is a sequence of token, and token is any character excluding CTLs or SEPARATORs, neither of which includes ". However RFC 7230 (which obsoletes 2616) defines a token as a sequence of tchar, a class which specifically excludes double quotes.

I'd think a parser should be able to handle the old definition because it's impossible to tell whether a given message conforms to RFC 2616 or 7230 (both describe HTTP/1.1), but practically the new definition seems to have been changed because parsing the old one is much more complex than it initially seems and many implementations differ in their interpretation.


As a related example, RFC 7230 (section 3.2.4) deprecates line folding for header values and allows servers receiving folded lines to reject them, but also requires user agents to accept folded lines by converting to sequences of spaces before interpreting. In that particular instance, it seems like this library should implement the behavior specified for user agents because that is also permitted for servers.

@tari
Copy link

tari commented Sep 10, 2021

It seems like the rationale in #68 applies here as well though: supporting the old behavior is difficult and probably slow, so it's simply not supported.

@nox
Copy link
Contributor

nox commented Apr 22, 2022

#114 will let you ignore the invalid header, which is what Chrome is doing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants