Stefan Eissing
<green/>bytes GmbH Hafenweg 16 48155 Münster www.greenbytes.de > Am 18.06.2020 um 16:51 schrieb William A Rowe Jr <wr...@rowe-clan.net>: > > > >>>> 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. That is not issue. That works well. > 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. There are now several RFCs and they differentiate between HTTP/1.1 transport and the pure HTTP semantics. This split is not reflected in our code, yet. We have functions that mix both. Not as a mistake, it's historical. ap_parse_request_line() for example, checks the initial HTTP/1.1 request line *and* the method names, uri, header_only and other request_rec fields. We can either copy the latter into mod_http2 and maintain it in two places or have a core function for it to be invoked by mod_http and mod_http2. That seems to be the design decision to make. I used ap_parse_request_line() from mod_http2 to *not* duplicate the other code, and someone added checks in trunk that imply it only ever gets called for HTTP/1.x. So, now it pukes. Which is good, as it brought up this discussion. - Stefan
