On 6/8/20 6:06 PM, Yann Ylavic wrote:
> On Mon, Jun 8, 2020 at 5:43 PM Julian Reschke <julian.resc...@gmx.de> wrote:
>>
>> On 08.06.2020 16:59, Yann Ylavic wrote:
>>> On Mon, Jun 8, 2020 at 9: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.
>>>
>>> Why not >= 1.2 ?
>>
>> In *theory*, there could a future HTTP/1.2 version that shares the wire
>> format with 1.0 and 1.1.
Exactly this was my reason for not >= 1.2 as this case is IMHO already handled
in a compliant way by the current code.
https://tools.ietf.org/html/rfc7230#section-2.6 states:
The interpretation of a header field does not change between minor
versions of the same major HTTP version, though the default behavior
of a recipient in the absence of such a field can change. Unless
specified otherwise, header fields defined in HTTP/1.1 are defined
for all versions of HTTP/1.x. In particular, the Host and Connection
header fields ought to be implemented by all HTTP/1.x implementations
whether or not they advertise conformance with HTTP/1.1.
New header fields can be introduced without changing the protocol
version if their defined semantics allow them to be safely ignored by
recipients that do not recognize them. Header field extensibility is
discussed in Section 3.2.1.
I interpret this that if we handle a potential HTTP 1.2 request as if
- headers already known in HTTP 1.1 are handled in the same way as if the
request was HTTP 1.1
- headers unknown in HTTP 1.2 and added and in HTTP 1.2 are ignored
we are on the safe side if we sent back a HTTP 1.1 response.
Furthermore I get from https://tools.ietf.org/html/rfc7231#section-6.6.6 that
505 indicates that we reject the processing of the major version which would be
wrong in the HTTP 1.2 case
as we will process HTTP 1.0 and HTTP 1.1.
Regards
Rüdiger
