Note that deployers have the option of terminating the TLS connection on an
offloader/load balancer and just going h2c to the actual server. This
avoid the java ALPN.
Problem then is that we probably need better standards for SSL offloaders
communicating TLS information to the server.
cheers
On 14 January 2015 at 01:19, Stuart Douglas <sdouglas_at_redhat.com> wrote:
>
>
> ----- Original Message -----
> > From: "Edward Burns" <edward.burns_at_oracle.com>
> > To: jsr369-experts_at_servlet-spec.java.net
> > Sent: Thursday, 8 January, 2015 7:25:51 AM
> > Subject: [jsr369-experts] Re: What to do about ALPN? (was: Question
> about TLS 1.2 Application-Layer Protocol
> > Negotiation Extension)
> >
> .....
>
> >
> > I have taken the matter to the authorities here at Oracle and I am told
> > that there will be no standard API in JDK 8 that will help with ALPN.
> >
> > It is possible that Oracle could provide help with ALPN with some
> > reusable API in GlassFish. If there is strong interest in that, please
> > let me know and I'll take up that thread.
> >
>
> What form would this implementation take? Basically the issue is that at
> the moment the only way to implement this is with JVM specific hacks, so it
> may break and require a new modified ALPN jar every minor release.
>
> From a customer point of view this really sucks, and may put them in the
> position of having to choose between HTTP2 support or running the latest
> JVM with all security holes patched.
>
> If this API would take the form of a jar that is guaranteed to work with
> all future JDK8 releases then I think this would be useful, otherwise its
> not really an improvement on the current status quo.
>
> Stuart
>
--
Greg Wilkins <gregw_at_intalio.com> @ Webtide - *an Intalio subsidiary*
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com advice and support for jetty and cometd.