You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: