I actually have another (very hacky) ALPN implementation that will be
part of Wildfly 10.1. At the moment it works on Oracle JDK's (I have
not looked into getting it to work on IBM).
Basically it works by modifying the handshake that is sent over the
wire by manually parsing and modifying the TLS frames, and then using
reflection to update the engines internal hash state to match what was
actually sent over the wire (like I said, very hacky).
The advantage of this approach is that as long as the SSLEngine
internals do not change too much it works across different versions of
the Oracle JDK and does not require modifying the boot class path. The
major disadvantage is that it is possible that a future JDK update
could break this (and potentially break it in a way that it cannot be
fixed), which makes it very problematic from a support point of view.
Stuart
On Fri, Jul 29, 2016 at 12:08 AM, Martin Mulholland <mmulholl_at_us.ibm.com> wrote:
> We have been discussing ALPN support for Servlet 4.0 here at IBM and do not
> consider the current solution acceptable. A reasonable option would be to
> provide a Java 8.1 release which includes ALPN support which Servlet 4.0
> would then require. I strongly recommend that this is considered by Oracle.
>
> The current solution employed by Jetty works for the most part but is
> problematic,
> 1. The OpenJDK patch needs to be rebuilt and then re-installed by customers
> for every new JDK version. This creates a significant service overhead.
> 2. Different patches will be needed for other JDK's. IBM could provide one
> for the IBM JDK, what Oracle will do is not known.
> 3. The Jetty OpenJDK patch has dependencies on Jetty code and as a result is
> not re-usable by other providers. Requiring each provider to provide their
> own set of patches is asking a lot. Not even sure if it would be legal, for
> example, for IBM to provide a patch for the Oracle JDK which must then be
> installed to run Liberty. It is also Also not clear how other provides can
> support the IBM JDK.
> 4. Need to understand how the Servlet 4.0 TCK will test secure use of the
> push api running on Java8.
>
> We could alleviate 3. by agreeing to a common api which container providers
> implement and which is then used by all of the JDK patches created but that
> still does not make this a workable solution.
>
> Thank you,
> Martin Mulholland.
> WebSphere Application Server Web Tier Architect
> email: mmulholl_at_us.ibm.com
>
> IBM RTP, PO BOX 12195, 503/C227,
> 3039 Cornwallis Rd, RTP, NC 27709-2195
> t/l 444-4319, external (919)-254-4319
>
>
>
>
> From: Mark Thomas <markt_at_apache.org>
> To: jsr369-experts_at_servlet-spec.java.net
> Date: 07/13/2016 05:10 PM
> Subject: [servlet-spec users] [jsr369-experts] Re: Servlet 4.0 and
> ALPN
> ________________________________
>
>
>
> On 13/07/2016 22:41, Martin Mulholland wrote:
>> Section 1.2 of the Servlet 4.0 spec states that, to support HTTP/2,
>> there is an implied requirement to support APLN. This is consistent
>> with the HTTP/2 RFC. In the same section it also states a requirement to
>> support Java SE 8 which is consistent with the Java EE 8 requirement for
>> Java SE 8. However ALPN support is currently planned for Java SE 9 and
>> is not part of Java SE 8.
>>
>> Are there any plans to backport ALPN to Java SE 8 or are we expecting
>> container providers to provide their own, or an open source, version of
>> ALPN? Thank you,
>
> Short version: The EG asked Oracle for a back-port. Oracle refused.
>
> Long version:
> https://java.net/projects/servlet-spec/lists/jsr369-experts/archive/2014-11/message/7
>
> I believe Jetty has a JRE point release specific patches to back-port
> ALPN support.
>
> Tomcat requires that OpenSSL is used (either via the APR/native
> connector or via the OpenSSL JSSE 'implementation') for ALPN (and hence
> HTTP/2) support.
>
> Mark
>
>
>
>