> Am 18.06.2020 um 11:49 schrieb Ruediger Pluem <rpl...@apache.org>: > > > > On 6/18/20 10:37 AM, Stefan Eissing wrote: >> >> 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 > > This is an interesting proposal, but I think that the two points I mentioned > below in 2. > would apply as well if the check is done there. > >> (which should then be named modules/http1)). > > Given Roy's comments above I think that at least in theory the stuff in > modules/http could > still be used for protocols > HTTP/2.x. So I am not sure if this rename is > justified.
The pre-condition was that *if* modules/http code refuses processing >= HTTP/2.0, it should be named modules/http1. But I agree that there is mostly stuff in there that we want to use for *any* http request. >> >> >>> 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
