> >>>> On 6/18/20 12:09 AM, Roy T. Fielding wrote: > >>>>>> 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. >
Correct, it starts an HTTP/1.1 connection, and the response should reflect HTTP/1.1. >>>>> 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. > Precisely. If mod_http2 or quic/mod_http3 can do something with the connection based on the request line, it's up to them through the hook facility to take ownership of the connection. If they cannot/do not, then the core http1 connection/request processors remain in place and in response to "please speak in HTTP/4.0" this server will respond, "sure, here is your HTTP/1.1 response" as expected and defined by the RFC.
