RE: HTTP/2.0 section 2.4 "Starting HTTP/2.0 with Prior Knowledge"

> On 17 April 2013 04:39, Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote:
> > On Wed, Apr 17, 2013 at 01:15:34AM +0000, Gabriel Montenegro wrote:
> >> http://http2.github.io/http2-spec/#known-http says:
> >>
> >> A client can learn that a particular server supports HTTP/2.0 by
> >> other means. A client MAY immediately send HTTP/2.0 frames to a
> >> server that is known to support HTTP/2.0. This only affects the resolution
> of "http:"
> >> URIs, servers supporting HTTP/2.0 are required to support protocol
> >> negotiation in TLS<http://http2.github.io/http2-spec/#TLSNPN> [TLSNPN].
> >>
> >> The above fails to include "https:" URIs. It only mentions "http:" URIs.
> >
> > HTTPS is over TLS, so NPN (ALPN) is a requirement and will reveal if
> > server supports HTTP2 without additional RTTs.
> 
> That was certainly the intent of the text.  However, I know that Gabriel is a
> pretty smart guy and he has been paying attention.  If this isn't obvious, we
> should definitely make it more so.
> 
>    This only affects the resolution of "http:" URIs, servers supporting HTTP/2.0
> are required to
>    support <xref target="TLSNPN">protocol negotiation in TLS</xref> for
> "https:" URIs.
> 
> https://github.com/http2/http2-

> spec/commit/329d29e58a88628435ebd4678d3a3bd250155d47
> 
> (Note, the ALPN edit isn't in yet, the reference will need to change.)

I was just wondering about the twitter apps scenario. Jeff Pinner indicated in Tokyo that for some scenarios (non-browser based apps using their specific servers), they forgo any TLS negotiation as the client simply knows that those particular servers talk HTTP/2.  This allows them to deploy with no dependency on anything but the usual TLS on their target platforms. 

It seems like a valid scenarios for "prior knowledge", but I'll let Jeff argue for that. I'm ok with requiring ALPN as the text currently implies (might help to make it explicit, yes).

Received on Wednesday, 17 April 2013 21:33:21 UTC