<div dir="ltr"><div><div>We are already JDK9 compatible, if the JDK9 API's are present they will be used. <br><br></div>I have not tested on IBM, although AFAIK the Jetty hack does not work there at the moment, so we are no worse off that what we currently are. If the ALPN reflection hack is disabled (either via system property or because a reflection lookup fails due to structural changes in the JDK) it will revert to trying to use the boot classpath hack.<br><br></div>Stuart<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 2, 2016 at 9:21 PM, David M. Lloyd <span dir="ltr"><<a href="mailto:david.lloyd@redhat.com" target="_blank">david.lloyd@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 06/01/2016 06:22 PM, Stuart Douglas wrote:<br>
> Hi All,<br>
><br>
> I would like to propose that we add support for HTTP/2 out of the box in<br>
> Wildfly 10.1.<br>
<br>
</span>+1 from me.<br>
<span class=""><br>
> At the moment there are two main barriers to getting HTTP/2 two work:<br>
><br>
> - You need to set up a HTTPS connector, including generating keys etc.<br>
> For new users this is not as straightforward as it could be.<br>
> - You need to find the correct version of the Jetty ALPN jar and add it<br>
> to your boot class path. This is essentially a hack that modifies the<br>
> JDK SSL classes to allow them to support ALPN. A new version is needed<br>
> for every JDK8 release, so if you ever update the JVM HTTP/2 will stop<br>
> working (JDK9 has support for ALPN so this is not nessesary).<br>
><br>
> I am proposing that we do the following to address these issues:<br>
><br>
> - Add support for lazily generated self signed certificates, and include<br>
> this in the default config. This would mean that we would have a working<br>
> HTTPS connector in the default config, although the first request would<br>
> be a bit slow as it would need to generate a new self signed certificate<br>
> for localhost. This allows for SSL out of the box, without any impact on<br>
> startup time or any need for an installer to generate the certificate.<br>
><br>
> - I have dealt with the ALPN issue in Undertow using a reflection based<br>
> hack. I have created some code that parses and modifies the SSL<br>
> Server/Client hello messages to add/read APLN information, and I then<br>
> use reflection to update the HandshakeHash maintained by the engine so<br>
> the engines internal hash state used to generate the Finished frames<br>
> matches the data that was actually sent over the wire.<br>
<br>
</span>Nice. I think this is a pretty decent interim solution (though I think<br>
we'll want to verify that this works on IBM too, and maybe come up with<br>
a parallel code path for that case; also we'll want to be JDK 9<br>
compatible ASAP so we should detect that too). Yeah it's kind of ugly,<br>
but not so much when you compare it against the alternatives of using<br>
the boot classpath for the Jetty kludge or writing our own JSSE.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
- DML<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
</div></div></blockquote></div><br></div>