RE: Questions about ALPN

I totally agree that the name of the HTTP protocol is all uppercase, and this is how this protocol is named in the ALPN protocol IDs registry:
"Protocol: HTTP/1.1".

ALPN protocol IDs, on the other hand, are opaque octet strings, not intended for display to the user, not required to consist of printable characters, not required to match names of protocols. E.g. 0x01 could be a valid ALPN protocol ID.

In the early days of ALPN, a combination of printable characters happened to be chosen as the protocol ID for HTTP/1.1:
"Identification Sequence: 0x68 0x74 0x74 0x70 0x2f 0x31 0x2e 0x31 ("http/1.1")".

The use of printable characters has some advantages (sometimes makes network capture analysis easier) and disadvantages (may result in more bytes on the wire). We may now wish that a different protocol ID had been chosen, we may even register alternative protocol IDs for HTTP/1.1. However, an interoperable implementation will have to keep sending the old protocol ID for years to come. Based on this, I believe that registering alternative protocol IDs for HTTP/1.1 will create more confusion and inefficiency than keeping the current (possibly imperfect) protocol ID.

Cheers,

Andrei

-----Original Message-----
From: Amos Jeffries [mailto:squid3@treenet.co.nz] 
Sent: Wednesday, October 23, 2013 6:30 AM
To: ietf-http-wg@w3.org
Subject: 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 22:26:10 UTC