[wildfly-dev] HTTP/2 out of the box in Wildfly 10.1

[Stuart Douglas]

I am not sure how gRPC comes into it?

Stuart

On Thu, Jun 2, 2016 at 6:26 PM, Heiko Braun <hbraun at redhat.com> wrote:

> +1
>
> This would be a great step forward.
>
> On a related note: I was looking into gRPC [1] for Swarm the other day,
> and it seems this would be pre-requisite.
>
>
> Regards, Heiko
>
>
> [1] http://www.grpc.io/
>
> On 02 Jun 2016, at 01:22, Stuart Douglas <stuart.w.douglas at gmail.com>
> 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 --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160602/ebdea072/attachment-0001.html