- From: Brian Smith <brian@briansmith.org>
- Date: Wed, 17 Sep 2014 12:02:52 -0700
- To: Greg Wilkins <gregw@intalio.com>
- Cc: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>, HTTP Working Group <ietf-http-wg@w3.org>
On Wed, Sep 17, 2014 at 3:05 AM, Greg Wilkins <gregw@intalio.com> wrote: > If at some time in the future the client and server interpret 9.2.2 > differently the then current available ciphers, then it is possible for the > server select, in good faith a cipher that it thinks is h2 acceptable, but the > client does not. I think you can expect that browsers will not enforce requirements stricter than what draft 14 requires. > Worse yet, a server has to deal with multiple user-agents out there, that > might eventually have different interpretations of what an acceptable h2 > cipher is. This would be a bug in the client. I don't think it is worthwhile to worry about such buggy clients. > But my question is, how do I keep that regex and hard coded requirements > up to date with all browsers out there? What mechanism is there to ensure > that we all update our regex's and code in lockstep? "If the client offered the cipher suite in its ClientHello, and the cipher suite fulfills the requirements imposed by the HTTP/2 spec, then assume the client will accept it for HTTP/2. Otherwise, don't." > 9.2.2 is too vague and terms like "such as" are not defined in RFC2119 draft 14 is clear enough for me to classify cipher suites into "acceptable" and "not acceptable". By default, assume that a cipher suite is not acceptable and you'll be fine. Cheers, Brian
Received on Wednesday, 17 September 2014 19:03:20 UTC