[wildfly-dev] HTTP/2 out of the box in Wildfly 10.1
Emmanuel Hugonnet
ehugonne at redhat.com
Thu Jun 2 03:30:25 EDT 2016
Hum,
What about domain mode, should the self-signed certificate be shared among the domain or one per HC/server ?
Emmanuel
On 02/06/2016 01:22, Stuart Douglas wrote:
> Hi All,
>
> I would like to propose that we add support for HTTP/2 out of the box in Wildfly 10.1.
>
> At the moment there are two main barriers to getting HTTP/2 two work:
>
> - You need to set up a HTTPS connector, including generating keys etc. For new users this is not as straightforward as it could be.
> - You need to find the correct version of the Jetty ALPN jar and add it to your boot class path. This is essentially a hack that modifies
> the JDK SSL classes to allow them to support ALPN. A new version is needed for every JDK8 release, so if you ever update the JVM HTTP/2 will
> stop working (JDK9 has support for ALPN so this is not nessesary).
>
> I am proposing that we do the following to address these issues:
>
> - Add support for lazily generated self signed certificates, and include this in the default config. This would mean that we would have a
> working HTTPS connector in the default config, although the first request would be a bit slow as it would need to generate a new self signed
> certificate for localhost. This allows for SSL out of the box, without any impact on startup time or any need for an installer to generate
> the certificate.
>
> - I have dealt with the ALPN issue in Undertow using a reflection based hack. I have created some code that parses and modifies the SSL
> Server/Client hello messages to add/read APLN information, and I then use reflection to update the HandshakeHash maintained by the engine so
> the engines internal hash state used to generate the Finished frames matches the data that was actually sent over the wire.
>
> Yes I am aware that this is a massive hack, however I think it is preferable to the current boot classpath hack, which has a lot of a
> drawbacks. If this ever stops working at some point due to internal JDK changes the boot classpath hack would still be usable, however I
> don't think this is particularly likely, as the part of the JDK that this modifies seems unlikely to change.
>
> I think this would be a great usability feature, allowing developers to get started with HTTPS and HTTP/2 straight away.
>
> Thoughts?
>
> Stuart
>
>
>
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160602/27f4954c/attachment.bin
More information about the wildfly-dev
mailing list