Re: HTTP/2.0 protocol identifier string (#323)

On Sun, Nov 17, 2013 at 12:47 AM, Amos Jeffries <squid3@treenet.co.nz>wrote:

>
>
> Abbreviating this far and with the ALPN guys not wanting to use binary
> token prohibits ALPN being used for sub-versions of HTTP/2.x.
>  Do we consider that to be a good or bad thing?
>

the token is only valid as a whole string match.. so h2.1 would be fine.


>
> Where can we find the details substantiating those claims of backward
> compatibility and that the "HTTP/2.0" string is causing trouble?
>
>
a decent thread:
http://www.ietf.org/mail-archive/web/tls/current/msg10405.html

also agl's imeperial violet blog is a good source.

we're fortunate that there is a workaround now (round 256-512 up to 512
with padding). I hadn't offered this htp2-draft change before because ALPN
seemed completely unworkable without the workaround - at this point it
seems operationally plausible, but we do want to at least try and avoid the
padding when possible.

There are lot of factors that contribute to going over 256 (resumption,
SNI, ALPN set, etc..) - but keeping this new element as brief as possible
can only help if we're going to put it in every handshake.



> What is expected to happen with other h* / H* protocols?
>  HTCP-over-TLS for example?
>
>
Its handled at token registration time. Implementations would consider the
totallity of the imapct when they choose whether or not to include the alpn
string that the other protocol decides on.

overall not a big deal - just a little tweak.