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 <[email protected]>:
>>
>>
>>
>> On 6/18/20 12:09 AM, Roy T. Fielding wrote:
>>>> On Jun 8, 2020, at 12:56 AM, Ruediger Pluem <[email protected]> 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.
>
>
>> 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
