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

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.

On 17 April 2013 14:29, Gabriel Montenegro
<Gabriel.Montenegro@microsoft.com> wrote:
>> 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:50:34 UTC