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

Is this a reply to the wrong thread? If not, I have to say I don't follow.

On Wed, Feb 5, 2014 at 7:54 AM, Michael Sweet <msweet@apple.com> wrote:
> Mark,
>
> I think that *if* a user agent includes the charset in the Authorization header, then that should indicate the user agent is providing RFC 5198 conforming UTF-8 (NFC, limits on control characters, etc.)  Existing clients that are already supplying UTF-8 would be unaffected, but if you tell the server you are using UTF-8, we need it to mean something specific or we still won't have interoperability.
>
>
> On Feb 4, 2014, at 9:31 PM, Mark Nottingham <mnot@mnot.net> wrote:
>
>> What do people think about putting advisory text (not requirements) in Security Considerations?

I suspect that we won't be able to come to consensus on mandatory
requirements for handling negotiation failure, so I think the
pragmatic approach is to add advisory text.

>>
>>
>> On 5 Feb 2014, at 12:34 pm, Rob Trace <Rob.Trace@microsoft.com> wrote:
>>
>>> 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> 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.
>>>
>>
>> --
>> Mark Nottingham   http://www.mnot.net/
>>
>>
>>
>
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>

Received on Wednesday, 5 February 2014 23:53:59 UTC