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

[Stuart Douglas]

Ah, sorry, I miss read your original email.

You can do HTTP/2 at the moment, it is just a bit of a pain to set up.

Stuart

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

> gRPC requires http/2
>
> On 02 Jun 2016, at 12:05, Stuart Douglas <stuart.w.douglas at gmail.com>
> wrote:
>
> 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/aa20aa80/attachment.html