> On Jun 8, 2020, at 12:56 AM, Ruediger Pluem <rpl...@apache.org> wrote: > > I came across the question if we should not reject HTTP protocols >= 2.0 in > the request line when we parse it > in ap_parse_request_line. > This does not affect mod_http2 if loaded as HTTP/2.0 connections itself are > not parsed via ap_parse_request_line > and sending a > > GET /something HTTP/2.0 > > as request line is not a valid way to start a HTTP 2.0 connection and I doubt > that it will be for future major versions.
That isn't how these things typically work. New protocols are advanced with either deliberate backwards-compat or deliberate backwards-break, with an expectation that it will either do something useful on an older-protocol server or cause a safe error in an expected way. Hence, we might still see an HTTP/4.0 that is designed to be parsed like HTTP/1.1 (by an old server) while at the same time work perfectly for a new server. That would be some hefty magic, but it remains possible. Likewise, we might want to deploy a version of h2 or HTTP/3 that works on unix domain sockets or localhost over non-Internet TCP. This is why the existing code did not error on protocols >= 2.0. Doing so is both unnecessary and counterproductive. If parsing fails for some other reason, we want that other reason to be in the response (because that's what the new protocol will be expecting from an old protocol server). If it doesn't fail, we want to provide the successful response because the request was deliberately crafted that way to save a round trip. Note that the incoming request protocol version should always be distinct from any forwarded request protocol or response protocol versions. ....Roy
