Stefan Eissing
<green/>bytes GmbH Hafenweg 16 48155 Münster www.greenbytes.de > Am 18.06.2020 um 09:48 schrieb Ruediger Pluem <rpl...@apache.org>: > > > > 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. >> >> 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. > > As always many thanks for the insights. I see two ways forward now: > > 1. Roll back r1878708 and all the follow ups and be done. +1 If we want the HTTP/1.x protocol handler to balk at higher protocol versions, this check should be done in ap_read_request() (which should be placed in modules/http (which should then be named modules/http1)). > 2. Keep r1878708 and all the follow ups but adjust the code in > ap_parse_request_line > to be more specific when to sent a 505. Given today's state I think a 505 > would still be > correct in case of > > 1. Protocol >= HTTP/3.0. Of course this would need to be adjusted if an > implementation of > HTTP/x.y with x > 2 pops up even if provided by a 3rd party module. > 2. If HTTP/2.0 is sent over the wire like a HTTP/1.x request as HTTP/2 has > that > deliberate backwards-break as I understand it. OTOH you could argue that > with > mod_http2 present 505 is the wrong reply since the server supports > HTTP/2 but not the > way it was tried and hence another code would be the correct response > (400 ??) if we see a > HTTP/1.x request with Protocol HTTP/2.0. > > Regards > > Rüdiger
