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

From: Gabriel Montenegro <[email-masked]>
Date: Wed, 17 Apr 2013 01:15:34 +0000

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.

I don't believe this was intentional, correct? If so, please add "https" as well.

Thanks,

Gabriel

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 17 Apr 2013 14:39:26 +0300

On Wed, Apr 17, 2013 at 01:15:34AM +0000, Gabriel Montenegro wrote:
> 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].
>

HTTPS is over TLS, so NPN (ALPN) is a requirement and will reveal if
server supports HTTP2 without additional RTTs.

-Ilari

---

From: Martin Thomson <[email-masked]>
Date: Wed, 17 Apr 2013 14:08:14 -0700

> 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.)

---

From: Gabriel Montenegro <[email-masked]>
Date: Wed, 17 Apr 2013 21:29:51 +0000

> >> 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:"
> 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
> 

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).

---

From: Martin Thomson <[email-masked]>
Date: Wed, 17 Apr 2013 14:50:07 -0700

ALPN is going to add only a handful of bytes to the handshake.  It's
probably not going to cause the handshake to hit CWND limits (whatever
they are).  Larger certificates are more likely to do that.  So it
comes down to implementation cost - do you want to build the switch
and provide a way to actuate that switch?

Sure, some folks will build their own stack, but if they are at the
point of building their own stack, they aren't going to be overly
bothered by what some standard says if it turns out to be
inconvenient.   It's also likely that if they are sinking that much
engineering effort into it, then something like ALPN is probably a
flyspeck on the overall cost of the project.