RE: How to handle HTTP/2 negotiation failure WRT TLS

I am not sure this is such a no brainer.  We should not mandate implementation fallback behavior.  If an implementer would successfully negotiate HTTP 1.1 if HTTP/2 is failing, the implementer should decide how or when to fallback.  For example an implementer could decide that falling back to HTTP 1.1 and a different TLS profile is better than forcing a user to disable HTTP/2 to get to a given site.

-Rob

From: patrick.ducksong@gmail.com [mailto:patrick.ducksong@gmail.com] On Behalf Of Patrick McManus
Sent: Monday, February 3, 2014 7:43 AM
To: William Chan (陈智昌)
Cc: Martin Thomson; Brian Smith; Michael Sweet; HTTP Working Group
Subject: Re: How to handle HTTP/2 negotiation failure WRT TLS



On Sat, Feb 1, 2014 at 4:42 PM, William Chan (陈智昌) <willchan@chromium.org<mailto:willchan@chromium.org>> wrote:
It's not clear to me what "this wasn't an issue" means. I'm guessing
that means that what we have in the spec is OK and it's not necessary
to discuss how to handle negotiation failure and just let
implementations figure it out. That's fine by me.

I observe that as per
http://dxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/Http2Session.cpp,

Firefox appears to hard fail. And my inclination is to enforce the
same policy in Chromium. This will affect other implementations that
wish to interoperate with these browsers.

This seems like a no brainer to me.
HTTP/2 is negotiated via ALPN. If the server selects HTTP/2 and also does something that is non-compliant with HTTP/2 that's a protocol error, not a negotiation error.

afaict, failing to use TLS 1.2 is an example that isn't really any different than sending a data frame > 14bits long. HTTP/2 has rules - if you can't follow them then run a different protocol, right?


want me/Chromium to share half-baked thoughts on stuff, that's fine
and I will stop sharing them. Sorry for the noise.

phhhbt.