Hi Simone,
I'm interested to understand why you think this Http 2 requirement
is difficult or impossible to implement in the JDK currently.
I thought, cipher suite selection would be independent of the ALPN
mechanism.
So, a Http 2 client implementation would ensure that allowed ciphers
are in its list of proposed ciphers, and it's up to the server then to
choose
an allowed one. And presumably, a server implementation can do the same?
- Michael.
On 17/09/14 11:02, Simone Bordet wrote:
Hi,
On Tue, Sep 2, 2014 at 11:11 AM, Vincent Ryan <vincent.x.r...@oracle.com> wrote:
Your OCA is still being processed. When that has completed your name will be
listed at:
http://www.oracle.com/technetwork/community/oca-486395.html#b
Until then, we can discuss these TLS/HTTP issues but we cannot include your
APIs or source code.
Just an update on this...
While ALPN should offer mechanism independent from the protocol
advertised or the cipher used in the TLS connection, it seems that the
HTTP/2.0 spec has put some constraint that link the protocol
advertised to the ciphers negotiated
(http://tools.ietf.org/html/draft-ietf-httpbis-http2-14#section-9.2.2).
Currently it seems that this HTTP/2 requirement is difficult, if not
impossible, to implement in the JDK.
I am following the HTTP/2 expert group to see if this issue is
resolved, and working on the Jetty code to implement this feature.
The idea being to wait a bit to define the ALPN APIs until this issue
is resolved, to see if the resolution requires changes in the ALPN
APIs.
Thanks !
