W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: Questions about ALPN

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Thu, 24 Oct 2013 02:29:53 +1300
Message-ID: <5267CF51.4010105@treenet.co.nz>
To: ietf-http-wg@w3.org
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

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:18 UTC