> On Jun 18, 2020, at 9:03 AM, Stefan Eissing <stefan.eiss...@greenbytes.de> > wrote: >> 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 think that is the right way forward, though we have always tried to minimize overhead for the common case. I guess the extra cycles are irrelevant now. > 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. Yep. The new RFCs should be "finished" by next month due to HTTP/3 being in WGLC this month. If anyone's interested: https://github.com/httpwg/http-core <https://github.com/httpwg/http-core> https://github.com/quicwg/base-drafts <https://github.com/quicwg/base-drafts> ...Roy
