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

Forbid HTTP versions we don't understand. #281

Closed
Lukasa opened this issue Apr 5, 2018 · 0 comments
Closed

Forbid HTTP versions we don't understand. #281

Lukasa opened this issue Apr 5, 2018 · 0 comments
Labels
kind/bug Feature doesn't work as expected.

Comments

@Lukasa
Copy link
Contributor

Lukasa commented Apr 5, 2018

Right now, NIO's sample server (and any server using NIO's HTTP layer) will be wildly over generous with the parsing in two different ways.

Firstly, it will accept later major versions of HTTP (e.g. a hypothetical HTTP/2.0, distinct from HTTP/2). This is a bad idea, because we don't know the semantics of those HTTP versions. We should treat those as parser errors.

Secondly, and more annoyingly, we will parse HTTP/0.9 requests, but don't know how to emit them. That means that incautious users of NIO may emit invalid HTTP responses that use the full-response format but claim a HTTP/0.9 version. Given that HTTP/0.9 is stupid, and given also that http_parser doesn't even parse 0.9 properly, we should not support HTTP/0.9 request or response formats, and treat them as errors.

Taken as a whole, this suggests a policy: NIOHTTP1 should enforce its own naming convention, and refuse to decode any HTTP message claiming a major version number other than 1. I don't propose to change the encoders, because users may want to have an escape hatch, but the decoders should refuse to emit such a message.

@Lukasa Lukasa added the kind/bug Feature doesn't work as expected. label Apr 5, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Feature doesn't work as expected.
Projects
None yet
Development

No branches or pull requests

1 participant