Re: Questions about ALPN

On 22/10/2013 12:48 p.m., Andrei Popov wrote:
> Hi Amos,
>
> The ALPN draft currently specifies the following initial set of registrations:
>        Protocol: HTTP/1.1
>        Identification Sequence: 0x68 0x74 0x74 0x70 0x2f 0x31 0x2e 0x31 ("http/1.1")
>
>        Protocol: SPDY/1
>        Identification Sequence: 0x73 0x70 0x64 0x79 0x2f 0x31 ("spdy/1")
>
>        Protocol: SPDY/2
>        Identification Sequence: 0x73 0x70 0x64 0x79 0x2f 0x32 ("spdy/2")
>
>        Protocol: SPDY/3
>        Identification Sequence: 0x73 0x70 0x64 0x79 0x2f 0x33 ("spdy/3")
>
> These protocol IDs are currently used in a number of deployed implementations, so they would have to be preserved even if their upper-case versions were also registered. To avoid confusion, I would recommend against registering upper-case versions of these protocol IDs.

https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p1-messaging.html#http.version 
clearly states the octets for the protocol name (HTTP-name) are 
%x48.54.54.50.
RFC 2068 and 2616 are not quite so loud about it, the BNF definition is 
written in upper case ("HTTP" "/" ...) and only permit lower-case to 
match against the upper-case definition. In practice the implementations 
use upper-case.

"http/1.1" is a malformed version for RFC 2608/2616 HTTP-version, 
existing only within the fluffy BNF tolerant interpretation. That 
tolerance is in the process of being removed from the HTTP/1.1 
specifications as the draft linked above shows.

When the registries containing HTTP version name token are considered 
ALPN is clearly the odd one out.

I would suggest that it is far easier for the few existing ALPN 
implementations to update themselves (already having demonstrated high 
speed of rollout) with a new draft or even RFC formal version in a 
backward-compatible way than it will be to get uncounted numbers of HTTP 
implementations to add duplicate parsing code for accepting the ALPN 
lower-case token. Or possibly causing them to violate the updated HTTP 
specification in the process if they choose to re-implement existing 
parser code case-insensitive.

Amos

Received on Wednesday, 23 October 2013 13:30:22 UTC