Re: 9.2.2 Cipher fallback and FF<->Jetty interop problem

On 17 September 2014 16:59, Amos Jeffries <squid3@treenet.co.nz> wrote:

> To meet the 9.2.2 criteria for sending ALPN "h2" the client must send
> the intersection of those two sets, not the union.
>

That is not how 9.2.2 is written.  In fact is specifically calls out the
opposite:

   Clients MAY advertise support of cipher suites that are prohibited by
   the above restrictions in order to allow for connection to servers
   that do not support HTTP/2.

So in this case FF is advertising that it will accept h2 unacceptable
ciphers.  I'm running my server on java-7 that looks like by default it has
no h2 acceptable ciphers (now that's a big hurdle to adoption), and I'm
trying to write the future proof code that will let my implementation
realise that none of my available ciphers are h2 acceptable and thus fall
back to http/1 (another speed bump in the road to adoption) and I find that
I can't work out an algorithm for that without hard coding specific
knowledge of today's cipher names or using a black/white list that is
guaranteed not to be updated in sync with the clients.

Ie I can make this work today, but I can give cannot write something that
will I know will work tomorrow!

cheers



-- 
Greg Wilkins <gregw@intalio.com>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.