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.
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
