Re: #273: HTTP-Version should be redefined as fixed length pair of DIGIT . DIGIT

On 2011-06-24 06:58, Willy Tarreau wrote:
> On Thu, Jun 23, 2011 at 09:53:31AM +0200, Julian Reschke wrote:
>> On 2011-06-23 00:08, Mark Nottingham wrote:
>>> It should treat it the same as receiving a message like this:
>>>
>>> GET / HTTP/A.B
>>>
>>> which hopefully we cover already...
>>
>> Really?
>>
>> I would have thought that an HTTP/1.1 compliant recipient would accept
>> something labeled HTTP/1.10.
>
> Julian, I have seen many times the version checked with :
>
>      memcmp(version, "HTTP/1.1", 8)
>
> One of the reasons probably is that the next char might be either a CR or
> an LF, so it's not easy to quickly check for an exact version. But as a
> result of the above, "HTTP/1.10" would be matched as "HTTP/1.1".

Yes.

>> If it does, and we change the spec, we will make it non-compliant.
>
> I don't think this is an issue, because even if the server understands
> HTTP/1.10 as major=1, minor=10, it will just not know this version, and
> the draft states that such a version will not exist anyway since only
> one digit can be used for the minor.

It won't know the version, but it doesn't need to, as 10 > 1.

> In my opinion, it would be an issue if we had already used such a version,
> which is not the case. Even HTTP/0.9 was post-named with a single digit.

True.

So, summarizing: it *could* make existing implementations non-compliant, 
but it really doesn't matter as there are no real-world HTTP messages 
that are affected (like in "outside test cases").

So we would:

- simplify the ABNF (that's the whole point, right?)

- adjust the prose

- mark this as change from RFC 2616

?

Best regards, Julian

Received on Friday, 24 June 2011 07:24:08 UTC