On 6/18/20 12:21 PM, Stefan Eissing wrote:
>> 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.
Fair enough. I somehow missed this if. I will wait how this discussion evolves
to see what next steps are the best ones.
Regards
Rüdiger
