HTTP/2 out of the box in Wildfly 10.1

classic Classic list List threaded Threaded
67 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

HTTP/2 out of the box in Wildfly 10.1

Stuart Douglas
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: HTTP/2 out of the box in Wildfly 10.1

jtgreene
Administrator
You know my opinion on this, but just to share with everyone else, I think these are huge usability improvements and IMO a high priority for 10.1.

> On Jun 1, 2016, at 6:22 PM, Stuart Douglas <[hidden email]> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: HTTP/2 out of the box in Wildfly 10.1

Emmanuel Hugonnet
In reply to this post by Stuart Douglas
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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: HTTP/2 out of the box in Wildfly 10.1

Juraci Paixão Kröhling
In reply to this post by Stuart Douglas
On 02.06.2016 01:22, Stuart Douglas wrote:
> I think this would be a great usability feature, allowing developers to
> get started with HTTPS and HTTP/2 straight away.

This sounds absolutely fantastic. We were starting to figure out a way
to do this for Hawkular and would be awesome to have this handled in
Wildfly instead.

- Juca.
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: HTTP/2 out of the box in Wildfly 10.1

Heiko Braun
In reply to this post by Stuart Douglas
+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



On 02 Jun 2016, at 01:22, Stuart Douglas <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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



On 02 Jun 2016, at 01:22, Stuart Douglas <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: HTTP/2 out of the box in Wildfly 10.1

Darran Lofthouse
In reply to this post by Stuart Douglas
Not a fan of dynamically generated self signed certificates - a recipe
for leading users into shooting themselves in the foot.

I say that after witnessing myself a user tricking themselves with their
own man in the middle attack.

Darran.


On 02/06/16 00: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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: HTTP/2 out of the box in Wildfly 10.1

Stuart Douglas
You are always going to be able to MITM with self signed certs though, dynamically generated or not.

Stuart

On Thu, Jun 2, 2016 at 8:18 PM, Darran Lofthouse <[hidden email]> wrote:
Not a fan of dynamically generated self signed certificates - a recipe
for leading users into shooting themselves in the foot.

I say that after witnessing myself a user tricking themselves with their
own man in the middle attack.

Darran.


On 02/06/16 00: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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: HTTP/2 out of the box in Wildfly 10.1

Darran Lofthouse
The dynamically generated is the worst part of it though as they have no certificate information to compare when the browser complains.

Probably not the end of the world though, we will still be able to guide them in the future to do it properly.  Location wise I think we should see if the generation can be wrapped in the legacy security realms to minimise compatibility issues once we get to WildFly 11.

Darran.



----- Original Message -----
From: "Stuart Douglas" <[hidden email]>
To: "Darran Lofthouse" <[hidden email]>
Cc: [hidden email]
Sent: Thursday, 2 June, 2016 11:38:04 AM
Subject: Re: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1

You are always going to be able to MITM with self signed certs though,
dynamically generated or not.

Stuart

On Thu, Jun 2, 2016 at 8:18 PM, Darran Lofthouse <[hidden email]
> wrote:

> Not a fan of dynamically generated self signed certificates - a recipe
> for leading users into shooting themselves in the foot.
>
> I say that after witnessing myself a user tricking themselves with their
> own man in the middle attack.
>
> Darran.
>
>
> On 02/06/16 00: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
> > [hidden email]
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: HTTP/2 out of the box in Wildfly 10.1

David Lloyd-2
In reply to this post by Stuart Douglas
On 06/01/2016 06:22 PM, 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.

+1 from me.

> 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.

Nice.  I think this is a pretty decent interim solution (though I think
we'll want to verify that this works on IBM too, and maybe come up with
a parallel code path for that case; also we'll want to be JDK 9
compatible ASAP so we should detect that too).  Yeah it's kind of ugly,
but not so much when you compare it against the alternatives of using
the boot classpath for the Jetty kludge or writing our own JSSE.

--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: HTTP/2 out of the box in Wildfly 10.1

Heiko Braun
In reply to this post by Stuart Douglas
gRPC requires http/2

On 02 Jun 2016, at 12:05, Stuart Douglas <[hidden email]> wrote:

I am not sure how gRPC comes into it?

Stuart

On Thu, Jun 2, 2016 at 6:26 PM, Heiko Braun <[hidden email]> 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



On 02 Jun 2016, at 01:22, Stuart Douglas <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev




_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> wrote:
gRPC requires http/2

On 02 Jun 2016, at 12:05, Stuart Douglas <[hidden email]> wrote:

I am not sure how gRPC comes into it?

Stuart

On Thu, Jun 2, 2016 at 6:26 PM, Heiko Braun <[hidden email]> 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



On 02 Jun 2016, at 01:22, Stuart Douglas <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev





_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: HTTP/2 out of the box in Wildfly 10.1

Stuart Douglas
In reply to this post by David Lloyd-2
We are already JDK9 compatible, if the JDK9 API's are present they will be used.

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.

Stuart

On Thu, Jun 2, 2016 at 9:21 PM, David M. Lloyd <[hidden email]> wrote:
On 06/01/2016 06:22 PM, 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.

+1 from me.

> 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.

Nice.  I think this is a pretty decent interim solution (though I think
we'll want to verify that this works on IBM too, and maybe come up with
a parallel code path for that case; also we'll want to be JDK 9
compatible ASAP so we should detect that too).  Yeah it's kind of ugly,
but not so much when you compare it against the alternatives of using
the boot classpath for the Jetty kludge or writing our own JSSE.

--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: HTTP/2 out of the box in Wildfly 10.1

Heiko Braun
In reply to this post by Stuart Douglas
yes, that’s what i was referring to. if HTTP/2 becomes the default, then we are one step closer to utilise gRPC in Swarm. But there are still many related issues that need to be solved. I.e. it would require server transport based on undertow. Currently gRPC only provides netty [1]. And we would need to discuss how this then integrates with the HTTP upgrade, etc.

But I don’t want to hijack this thread. When the time comes I get back to this in a separate thread.


On 02 Jun 2016, at 13:54, Stuart Douglas <[hidden email]> wrote:

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 <[hidden email]> wrote:
gRPC requires http/2

On 02 Jun 2016, at 12:05, Stuart Douglas <[hidden email]> wrote:

I am not sure how gRPC comes into it?

Stuart

On Thu, Jun 2, 2016 at 6:26 PM, Heiko Braun <[hidden email]> 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



On 02 Jun 2016, at 01:22, Stuart Douglas <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev






_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: HTTP/2 out of the box in Wildfly 10.1

jtgreene
Administrator
In reply to this post by Darran Lofthouse

IMO it's no different than ssh keys. Also we could just leave localhost as the default bind, and they are likely to add the browser exception before moving the bind address.

> On Jun 2, 2016, at 6:04 AM, Darran Lofthouse <[hidden email]> wrote:
>
> The dynamically generated is the worst part of it though as they have no certificate information to compare when the browser complains.
>
> Probably not the end of the world though, we will still be able to guide them in the future to do it properly.  Location wise I think we should see if the generation can be wrapped in the legacy security realms to minimise compatibility issues once we get to WildFly 11.
>
> Darran.
>
>
>
> ----- Original Message -----
> From: "Stuart Douglas" <[hidden email]>
> To: "Darran Lofthouse" <[hidden email]>
> Cc: [hidden email]
> Sent: Thursday, 2 June, 2016 11:38:04 AM
> Subject: Re: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1
>
> You are always going to be able to MITM with self signed certs though,
> dynamically generated or not.
>
> Stuart
>
> On Thu, Jun 2, 2016 at 8:18 PM, Darran Lofthouse <[hidden email]
>> wrote:
>
>> Not a fan of dynamically generated self signed certificates - a recipe
>> for leading users into shooting themselves in the foot.
>>
>> I say that after witnessing myself a user tricking themselves with their
>> own man in the middle attack.
>>
>> Darran.
>>
>>
>>> On 02/06/16 00: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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: HTTP/2 out of the box in Wildfly 10.1

Darran Lofthouse
In both cases users should be provided with the signatures before their
first attempt at connecting so they can verify they are genuine.

On 02/06/16 13:21, Jason T. Greene wrote:

>
> IMO it's no different than ssh keys. Also we could just leave localhost as the default bind, and they are likely to add the browser exception before moving the bind address.
>
>> On Jun 2, 2016, at 6:04 AM, Darran Lofthouse <[hidden email]> wrote:
>>
>> The dynamically generated is the worst part of it though as they have no certificate information to compare when the browser complains.
>>
>> Probably not the end of the world though, we will still be able to guide them in the future to do it properly.  Location wise I think we should see if the generation can be wrapped in the legacy security realms to minimise compatibility issues once we get to WildFly 11.
>>
>> Darran.
>>
>>
>>
>> ----- Original Message -----
>> From: "Stuart Douglas" <[hidden email]>
>> To: "Darran Lofthouse" <[hidden email]>
>> Cc: [hidden email]
>> Sent: Thursday, 2 June, 2016 11:38:04 AM
>> Subject: Re: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1
>>
>> You are always going to be able to MITM with self signed certs though,
>> dynamically generated or not.
>>
>> Stuart
>>
>> On Thu, Jun 2, 2016 at 8:18 PM, Darran Lofthouse <[hidden email]
>>> wrote:
>>
>>> Not a fan of dynamically generated self signed certificates - a recipe
>>> for leading users into shooting themselves in the foot.
>>>
>>> I say that after witnessing myself a user tricking themselves with their
>>> own man in the middle attack.
>>>
>>> Darran.
>>>
>>>
>>>> On 02/06/16 00: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
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: HTTP/2 out of the box in Wildfly 10.1

jtgreene
Administrator
In reply to this post by Heiko Braun
If you want to capitalize on all of the capabilities of the undertow web server (which is likely user expectation) then really it needs to be the one providing http instead of splicing in a different web server, which has a completely different feature set, and mechanism of configuration.  However, it would be possible to do so.

On Jun 2, 2016, at 7:03 AM, Heiko Braun <[hidden email]> wrote:

yes, that’s what i was referring to. if HTTP/2 becomes the default, then we are one step closer to utilise gRPC in Swarm. But there are still many related issues that need to be solved. I.e. it would require server transport based on undertow. Currently gRPC only provides netty [1]. And we would need to discuss how this then integrates with the HTTP upgrade, etc.

But I don’t want to hijack this thread. When the time comes I get back to this in a separate thread.


On 02 Jun 2016, at 13:54, Stuart Douglas <[hidden email]> wrote:

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 <[hidden email]> wrote:
gRPC requires http/2

On 02 Jun 2016, at 12:05, Stuart Douglas <[hidden email]> wrote:

I am not sure how gRPC comes into it?

Stuart

On Thu, Jun 2, 2016 at 6:26 PM, Heiko Braun <[hidden email]> 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



On 02 Jun 2016, at 01:22, Stuart Douglas <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev





_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: HTTP/2 out of the box in Wildfly 10.1

Heiko Braun
Yes, thats what meant saying it needs a server transport (grpc term) based on undertow.

Am 02.06.2016 um 14:44 schrieb Jason T. Greene <[hidden email]>:

If you want to capitalize on all of the capabilities of the undertow web server (which is likely user expectation) then really it needs to be the one providing http instead of splicing in a different web server, which has a completely different feature set, and mechanism of configuration.  However, it would be possible to do so.

On Jun 2, 2016, at 7:03 AM, Heiko Braun <[hidden email]> wrote:

yes, that’s what i was referring to. if HTTP/2 becomes the default, then we are one step closer to utilise gRPC in Swarm. But there are still many related issues that need to be solved. I.e. it would require server transport based on undertow. Currently gRPC only provides netty [1]. And we would need to discuss how this then integrates with the HTTP upgrade, etc.

But I don’t want to hijack this thread. When the time comes I get back to this in a separate thread.


On 02 Jun 2016, at 13:54, Stuart Douglas <[hidden email]> wrote:

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 <[hidden email]> wrote:
gRPC requires http/2

On 02 Jun 2016, at 12:05, Stuart Douglas <[hidden email]> wrote:

I am not sure how gRPC comes into it?

Stuart

On Thu, Jun 2, 2016 at 6:26 PM, Heiko Braun <[hidden email]> 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



On 02 Jun 2016, at 01:22, Stuart Douglas <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev





_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: HTTP/2 out of the box in Wildfly 10.1

Harold Campbell
In reply to this post by Stuart Douglas
On Thu, 2016-06-02 at 09:22 +1000, 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.
>

This lowly user desperately wants a release containing the fix to WFLY-
6283 sooner rather than later. I'm sure other people have other pet
bugs awaiting release.

I have no opinion on HTTP/2 being added other than to ask that pent up
bug fixes be kept in mind.

--
Harold Campbell <[hidden email]>

Roses are red;
        Violets are blue.
I'm schizophrenic,
        And so am I.


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: HTTP/2 out of the box in Wildfly 10.1

jtgreene
Administrator

> On Jun 2, 2016, at 11:29 AM, Harold Campbell <[hidden email]> wrote:
>
> On Thu, 2016-06-02 at 09:22 +1000, 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.
>>
>
> This lowly user desperately wants a release containing the fix to WFLY-
> 6283 sooner rather than later. I'm sure other people have other pet
> bugs awaiting release.
>
> I have no opinion on HTTP/2 being added other than to ask that pent up
> bug fixes be kept in mind.


Hi Harold,

That fix is already in master, so it will be included in 10.1.

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
1234