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
|

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

Stuart Douglas
So I guess we should talk about how this should actually work.

In terms of auto generating the key I was thinking we would need to add a new attribute to the 'keystore' element under the security realm, something like 'auto-generate-cert-host="localhost"'. I am not sure what other options we would need, or how configurable we should make it, but as this is for testing/development purposes I don't think we need to expose full control over the certificate generation process.

In terms of the implementation we could just implement an SSLContext wrapper, that can do the generation and then create a 'real' SSLContext the first time it is asked to create and SSLEngine.

Stuart

On Fri, Jun 3, 2016 at 3:19 AM, Jason Greene <[hidden email]> wrote:

> 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
Reply | Threaded
Open this post in threaded view
|

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

Nicklas Karlsson
On a side note, it might be nice if the console would have support for CSR generation. If possible, why not for the whole process...

Sent from my Windows Phone

From: [hidden email]
Sent: ‎6/‎2/‎2016 23:01
To: [hidden email]
Cc: [hidden email]
Subject: Re: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1

So I guess we should talk about how this should actually work.

In terms of auto generating the key I was thinking we would need to add a new attribute to the 'keystore' element under the security realm, something like 'auto-generate-cert-host="localhost"'. I am not sure what other options we would need, or how configurable we should make it, but as this is for testing/development purposes I don't think we need to expose full control over the certificate generation process.

In terms of the implementation we could just implement an SSLContext wrapper, that can do the generation and then create a 'real' SSLContext the first time it is asked to create and SSLEngine.

Stuart

On Fri, Jun 3, 2016 at 3:19 AM, Jason Greene <[hidden email]> wrote:

> 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
Reply | Threaded
Open this post in threaded view
|

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

Martin Choma
In reply to this post by Stuart Douglas
Hi Stuart,

I have couple of questions regarding self-signed certificate autogeneration:

What happens, when autogenerated certificate expires?
How it will be decided if certificate should be autogenerate or not?
What will be default keysize? It has to be probably choosen to work also without "Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy"




On Thu, Jun 2, 2016 at 10:01 PM, Stuart Douglas <[hidden email]> wrote:
So I guess we should talk about how this should actually work.

In terms of auto generating the key I was thinking we would need to add a new attribute to the 'keystore' element under the security realm, something like 'auto-generate-cert-host="localhost"'. I am not sure what other options we would need, or how configurable we should make it, but as this is for testing/development purposes I don't think we need to expose full control over the certificate generation process.

In terms of the implementation we could just implement an SSLContext wrapper, that can do the generation and then create a 'real' SSLContext the first time it is asked to create and SSLEngine.

Stuart

On Fri, Jun 3, 2016 at 3:19 AM, Jason Greene <[hidden email]> wrote:

> 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


_______________________________________________
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


On Fri, 3 Jun 2016, 17:18 Martin Choma <[hidden email]> wrote:
Hi Stuart,

I have couple of questions regarding self-signed certificate autogeneration:

What happens, when autogenerated certificate expires?

I think we would go for ten year expiry so that would not be an issue. The developer could just delete the store and generate a new one anyway.

How it will be decided if certificate should be autogenerate or not?

An attribute in the management model would be needed to explicitly enable it.


What will be default keysize? It has to be probably choosen to work also without "Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy"

Probably the largest that is supported without JCE. It does not matter that much, self signed certs are inherently insecure, this is a developer usability feature, not something that can be used in production.

Stuart





On Thu, Jun 2, 2016 at 10:01 PM, Stuart Douglas <[hidden email]> wrote:
So I guess we should talk about how this should actually work.

In terms of auto generating the key I was thinking we would need to add a new attribute to the 'keystore' element under the security realm, something like 'auto-generate-cert-host="localhost"'. I am not sure what other options we would need, or how configurable we should make it, but as this is for testing/development purposes I don't think we need to expose full control over the certificate generation process.

In terms of the implementation we could just implement an SSLContext wrapper, that can do the generation and then create a 'real' SSLContext the first time it is asked to create and SSLEngine.

Stuart

On Fri, Jun 3, 2016 at 3:19 AM, Jason Greene <[hidden email]> wrote:

> 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

_______________________________________________
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 Nicklas Karlsson
Yes we do have plans for full CSR generation and the import step for the
signed certificate at a later point, this would be integrated with the
management tools to simplify SSL set up.

Darran.


On 03/06/16 05:12, [hidden email] wrote:

> On a side note, it might be nice if the console would have support for
> CSR generation. If possible, why not for the whole process...
>
> Sent from my Windows Phone
> ------------------------------------------------------------------------
> From: Stuart Douglas <mailto:[hidden email]>
> Sent: ‎6/‎2/‎2016 23:01
> To: Jason Greene <mailto:[hidden email]>
> Cc: [hidden email] <mailto:[hidden email]>
> Subject: Re: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1
>
> So I guess we should talk about how this should actually work.
>
> In terms of auto generating the key I was thinking we would need to add
> a new attribute to the 'keystore' element under the security realm,
> something like 'auto-generate-cert-host="localhost"'. I am not sure what
> other options we would need, or how configurable we should make it, but
> as this is for testing/development purposes I don't think we need to
> expose full control over the certificate generation process.
>
> In terms of the implementation we could just implement an SSLContext
> wrapper, that can do the generation and then create a 'real' SSLContext
> the first time it is asked to create and SSLEngine.
>
> Stuart
>
> On Fri, Jun 3, 2016 at 3:19 AM, Jason Greene <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>
>     > On Jun 2, 2016, at 11:29 AM, Harold Campbell <[hidden email] <mailto:[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
>
_______________________________________________
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

Tomaž Cerar-2
In reply to this post by Harold Campbell
This is completely off topic for this thread, there was one earlier about what should go into 10.x....

Anywho, issue you mention was already resolved and hibernate updated in master some time ago.
which means it will be in next release, whatever that release will be.

--
tomaz

On Thu, Jun 2, 2016 at 6:29 PM, 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.

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


_______________________________________________
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 Stuart Douglas

What will be default keysize? It has to be probably choosen to work also without "Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy"

Probably the largest that is supported without JCE. It does not matter that much, self signed certs are inherently insecure, this is a developer usability feature, not something that can be used in production.

IIRC there is actually no limit on RSA key size, it's only symmetric algs that are limited, so we could use a standard 2048 bit key without issue.



Stuart





On Thu, Jun 2, 2016 at 10:01 PM, Stuart Douglas <[hidden email]> wrote:
So I guess we should talk about how this should actually work.

In terms of auto generating the key I was thinking we would need to add a new attribute to the 'keystore' element under the security realm, something like 'auto-generate-cert-host="localhost"'. I am not sure what other options we would need, or how configurable we should make it, but as this is for testing/development purposes I don't think we need to expose full control over the certificate generation process.

In terms of the implementation we could just implement an SSLContext wrapper, that can do the generation and then create a 'real' SSLContext the first time it is asked to create and SSLEngine.

Stuart

On Fri, Jun 3, 2016 at 3:19 AM, Jason Greene <[hidden email]> wrote:

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

Jorge Solórzano
In reply to this post by Tomaž Cerar-2
IMO this feature should be oriented to sysadmins not just developers. Is there really added value for developers to use HTTPS or HTTPS/2?

It should be easy for sysadmins to setup TLS/SSL with "production" quality, from the gereration of the CSR that has to be send to the CA to the generation of the keystore.

BTW... how is the performance of HTTPS using pure Java vs Apache for example? is this feature oriented for developers because for use in production is not recommended?


Ing. Jorge Solórzano

about.me/jorsol

On Fri, Jun 3, 2016 at 3:52 AM, Tomaž Cerar <[hidden email]> wrote:
This is completely off topic for this thread, there was one earlier about what should go into 10.x....

Anywho, issue you mention was already resolved and hibernate updated in master some time ago.
which means it will be in next release, whatever that release will be.

--
tomaz

On Thu, Jun 2, 2016 at 6:29 PM, 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.

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


_______________________________________________
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
Enhancing TLS set up with features such as CSR generation and the
importing of the resulting signed certificates is something we are
working on.

Regards,
Darran Lofthouse.


On 03/06/16 15:28, Jorge Solórzano wrote:

> IMO this feature should be oriented to sysadmins not just developers. Is
> there really added value for developers to use HTTPS or HTTPS/2?
>
> It should be easy for sysadmins to setup TLS/SSL with "production"
> quality, from the gereration of the CSR that has to be send to the CA to
> the generation of the keystore.
>
> BTW... how is the performance of HTTPS using pure Java vs Apache for
> example? is this feature oriented for developers because for use in
> production is not recommended?
>
> *
> Ing. Jorge Solórzano*
> about.me/jorsol
> <https://about.me/jorsol?promo=email_sig&utm_source=email_sig&utm_medium=email_sig&utm_campaign=external_links>
>
> On Fri, Jun 3, 2016 at 3:52 AM, Tomaž Cerar <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     This is completely off topic for this thread, there was one earlier
>     about what should go into 10.x....
>
>     Anywho, issue you mention was already resolved and hibernate updated
>     in master some time ago.
>     which means it will be in next release, whatever that release will be.
>
>     --
>     tomaz
>
>     On Thu, Jun 2, 2016 at 6:29 PM, Harold Campbell <[hidden email]
>     <mailto:[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.
>
>         --
>         Harold Campbell <[hidden email] <mailto:[hidden email]>>
>
>         Roses are red;
>                 Violets are blue.
>         I'm schizophrenic,
>                 And so am I.
>
>
>         _______________________________________________
>         wildfly-dev mailing list
>         [hidden email] <mailto:[hidden email]>
>         https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>     _______________________________________________
>     wildfly-dev mailing list
>     [hidden email] <mailto:[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 Tomaž Cerar-2
On Fri, 2016-06-03 at 11:52 +0200, Tomaž Cerar wrote:
> This is completely off topic for this thread, there was one earlier
> about what should go into 10.x....
>

Really? A week or so back there was talk of getting 10.1 out in the
next week or two. This feature looks like something which could put
that timing at risk.

> Anywho, issue you mention was already resolved and hibernate updated
> in master some time ago.
> which means it will be in next release, whatever that release will
> be.

All I'm saying is I'd really like to have a proper release containing
this fix, so I don't have to explain to my boss why we are using a
SNAPSHOT.

It's obviously not up to me when a release gets done. I'm just throwing
out there that some of us end users could really use a proper release
containing the bug fixes that affect us. Bringing in new features
probably means we don't get one for a while longer.

--
Harold Campbell <[hidden email]>

Change your thoughts and you change your world.


_______________________________________________
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 Jorge Solórzano

On Jun 3, 2016, at 9:28 AM, Jorge Solórzano <[hidden email]> wrote:

IMO this feature should be oriented to sysadmins not just developers. Is there really added value for developers to use HTTPS or HTTPS/2?

Yeah, server push is an example, we have an API where you can push resources to the client before they are requested.  Although we have a learning handler that can try to do it for you, but thats not as good as something designed for it. It also has different characteristics that you can exploit (e.g. being able to create a lot of streams without impacting connection count) that you might want to do if you are building an HTTP/2 centric application. Of course, not everyone will fall into this category because  they will need to support both h2 and h1.


It should be easy for sysadmins to setup TLS/SSL with "production" quality, from the gereration of the CSR that has to be send to the CA to the generation of the keystone.


Agreed. What Stuart meant was that out of the box auto-generation was a development focused feature. Obviously in production you don’t need /want keys automatically generated, you want to use your publicly signed cert.


BTW... how is the performance of HTTPS using pure Java vs Apache for example? is this feature oriented for developers because for use in production is not recommended?


Java based SSL is certainly usable and performant in production, many people deploy on it. 



Ing. Jorge Solórzano

about.me/jorsol

On Fri, Jun 3, 2016 at 3:52 AM, Tomaž Cerar <[hidden email]> wrote:
This is completely off topic for this thread, there was one earlier about what should go into 10.x....

Anywho, issue you mention was already resolved and hibernate updated in master some time ago.
which means it will be in next release, whatever that release will be.

--
tomaz

On Thu, Jun 2, 2016 at 6:29 PM, 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.

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


_______________________________________________
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

--
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
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 Harold Campbell

> On Jun 3, 2016, at 12:12 PM, Harold Campbell <[hidden email]> wrote:
>
> On Fri, 2016-06-03 at 11:52 +0200, Tomaž Cerar wrote:
>> This is completely off topic for this thread, there was one earlier
>> about what should go into 10.x....
>>
>
> Really? A week or so back there was talk of getting 10.1 out in the
> next week or two. This feature looks like something which could put
> that timing at risk.

It sounds complicated, but the feature isn’t too hard. The situation is we really want to get going on 11, but before we diverge too much we have a good opportunity to deliver usability improvements and nice additions for everyone deploying on 10.

>
>> Anywho, issue you mention was already resolved and hibernate updated
>> in master some time ago.
>> which means it will be in next release, whatever that release will
>> be.
>
> All I'm saying is I'd really like to have a proper release containing
> this fix, so I don't have to explain to my boss why we are using a
> SNAPSHOT.
>
> It's obviously not up to me when a release gets done. I'm just throwing
> out there that some of us end users could really use a proper release
> containing the bug fixes that affect us. Bringing in new features
> probably means we don't get one for a while longer.

Yeah I hear you, and totally understand, time is certainly a priority.

>
> --
> Harold Campbell <[hidden email]>
>
> Change your thoughts and you change your world.
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
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
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 jtgreene
So I just did up a very quick prototype that generates self signed certificates on startup and it looks like the difference in startup time is negligible (at least when generating 1024 bit RSA keys). Even if the difference is measurable it only affects the very first startup.

I think that in order to simplify the implementation of this it may be better to simply generate the key of first startup, instead of attempting to do it lazily.

Stuart

On Sat, Jun 4, 2016 at 12:09 AM, Jason T. Greene <[hidden email]> wrote:

What will be default keysize? It has to be probably choosen to work also without "Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy"

Probably the largest that is supported without JCE. It does not matter that much, self signed certs are inherently insecure, this is a developer usability feature, not something that can be used in production.

IIRC there is actually no limit on RSA key size, it's only symmetric algs that are limited, so we could use a standard 2048 bit key without issue.



Stuart





On Thu, Jun 2, 2016 at 10:01 PM, Stuart Douglas <[hidden email]> wrote:
So I guess we should talk about how this should actually work.

In terms of auto generating the key I was thinking we would need to add a new attribute to the 'keystore' element under the security realm, something like 'auto-generate-cert-host="localhost"'. I am not sure what other options we would need, or how configurable we should make it, but as this is for testing/development purposes I don't think we need to expose full control over the certificate generation process.

In terms of the implementation we could just implement an SSLContext wrapper, that can do the generation and then create a 'real' SSLContext the first time it is asked to create and SSLEngine.

Stuart

On Fri, Jun 3, 2016 at 3:19 AM, Jason Greene <[hidden email]> wrote:

> 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
_______________________________________________
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
We should really be generating 2048 bit keys. 

I don't like adding to our boot time, we have already seen it grow and this would be yet another case.

On Jun 5, 2016, at 8:57 PM, Stuart Douglas <[hidden email]> wrote:

So I just did up a very quick prototype that generates self signed certificates on startup and it looks like the difference in startup time is negligible (at least when generating 1024 bit RSA keys). Even if the difference is measurable it only affects the very first startup.

I think that in order to simplify the implementation of this it may be better to simply generate the key of first startup, instead of attempting to do it lazily.

Stuart

On Sat, Jun 4, 2016 at 12:09 AM, Jason T. Greene <[hidden email]> wrote:

What will be default keysize? It has to be probably choosen to work also without "Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy"

Probably the largest that is supported without JCE. It does not matter that much, self signed certs are inherently insecure, this is a developer usability feature, not something that can be used in production.

IIRC there is actually no limit on RSA key size, it's only symmetric algs that are limited, so we could use a standard 2048 bit key without issue.



Stuart





On Thu, Jun 2, 2016 at 10:01 PM, Stuart Douglas <[hidden email]> wrote:
So I guess we should talk about how this should actually work.

In terms of auto generating the key I was thinking we would need to add a new attribute to the 'keystore' element under the security realm, something like 'auto-generate-cert-host="localhost"'. I am not sure what other options we would need, or how configurable we should make it, but as this is for testing/development purposes I don't think we need to expose full control over the certificate generation process.

In terms of the implementation we could just implement an SSLContext wrapper, that can do the generation and then create a 'real' SSLContext the first time it is asked to create and SSLEngine.

Stuart

On Fri, Jun 3, 2016 at 3:19 AM, Jason Greene <[hidden email]> wrote:

> 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
_______________________________________________
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
2048 bits adds close to a second to first boot on my machine (obviously subsequent boots are unaffected).

This is probably a bit much, I will work on getting a POC for the lazy loading approach implemented.

Stuart

On Mon, Jun 6, 2016 at 12:27 PM, Jason T. Greene <[hidden email]> wrote:
We should really be generating 2048 bit keys. 

I don't like adding to our boot time, we have already seen it grow and this would be yet another case.

On Jun 5, 2016, at 8:57 PM, Stuart Douglas <[hidden email]> wrote:

So I just did up a very quick prototype that generates self signed certificates on startup and it looks like the difference in startup time is negligible (at least when generating 1024 bit RSA keys). Even if the difference is measurable it only affects the very first startup.

I think that in order to simplify the implementation of this it may be better to simply generate the key of first startup, instead of attempting to do it lazily.

Stuart

On Sat, Jun 4, 2016 at 12:09 AM, Jason T. Greene <[hidden email]> wrote:

What will be default keysize? It has to be probably choosen to work also without "Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy"

Probably the largest that is supported without JCE. It does not matter that much, self signed certs are inherently insecure, this is a developer usability feature, not something that can be used in production.

IIRC there is actually no limit on RSA key size, it's only symmetric algs that are limited, so we could use a standard 2048 bit key without issue.



Stuart





On Thu, Jun 2, 2016 at 10:01 PM, Stuart Douglas <[hidden email]> wrote:
So I guess we should talk about how this should actually work.

In terms of auto generating the key I was thinking we would need to add a new attribute to the 'keystore' element under the security realm, something like 'auto-generate-cert-host="localhost"'. I am not sure what other options we would need, or how configurable we should make it, but as this is for testing/development purposes I don't think we need to expose full control over the certificate generation process.

In terms of the implementation we could just implement an SSLContext wrapper, that can do the generation and then create a 'real' SSLContext the first time it is asked to create and SSLEngine.

Stuart

On Fri, Jun 3, 2016 at 3:19 AM, Jason Greene <[hidden email]> wrote:

> 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
_______________________________________________
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
Another option could be a post boot task. So it's still eager but don't block completed start. We'd still need to block Tls ports though. So maybe this does not help

On Jun 5, 2016, at 9:31 PM, Stuart Douglas <[hidden email]> wrote:

2048 bits adds close to a second to first boot on my machine (obviously subsequent boots are unaffected).

This is probably a bit much, I will work on getting a POC for the lazy loading approach implemented.

Stuart

On Mon, Jun 6, 2016 at 12:27 PM, Jason T. Greene <[hidden email]> wrote:
We should really be generating 2048 bit keys. 

I don't like adding to our boot time, we have already seen it grow and this would be yet another case.

On Jun 5, 2016, at 8:57 PM, Stuart Douglas <[hidden email]> wrote:

So I just did up a very quick prototype that generates self signed certificates on startup and it looks like the difference in startup time is negligible (at least when generating 1024 bit RSA keys). Even if the difference is measurable it only affects the very first startup.

I think that in order to simplify the implementation of this it may be better to simply generate the key of first startup, instead of attempting to do it lazily.

Stuart

On Sat, Jun 4, 2016 at 12:09 AM, Jason T. Greene <[hidden email]> wrote:

What will be default keysize? It has to be probably choosen to work also without "Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy"

Probably the largest that is supported without JCE. It does not matter that much, self signed certs are inherently insecure, this is a developer usability feature, not something that can be used in production.

IIRC there is actually no limit on RSA key size, it's only symmetric algs that are limited, so we could use a standard 2048 bit key without issue.



Stuart





On Thu, Jun 2, 2016 at 10:01 PM, Stuart Douglas <[hidden email]> wrote:
So I guess we should talk about how this should actually work.

In terms of auto generating the key I was thinking we would need to add a new attribute to the 'keystore' element under the security realm, something like 'auto-generate-cert-host="localhost"'. I am not sure what other options we would need, or how configurable we should make it, but as this is for testing/development purposes I don't think we need to expose full control over the certificate generation process.

In terms of the implementation we could just implement an SSLContext wrapper, that can do the generation and then create a 'real' SSLContext the first time it is asked to create and SSLEngine.

Stuart

On Fri, Jun 3, 2016 at 3:19 AM, Jason Greene <[hidden email]> wrote:

> 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
_______________________________________________
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 think that would actually end up being more complex.

Stuart

On Mon, Jun 6, 2016 at 12:45 PM, Jason T. Greene <[hidden email]> wrote:
Another option could be a post boot task. So it's still eager but don't block completed start. We'd still need to block Tls ports though. So maybe this does not help

On Jun 5, 2016, at 9:31 PM, Stuart Douglas <[hidden email]> wrote:

2048 bits adds close to a second to first boot on my machine (obviously subsequent boots are unaffected).

This is probably a bit much, I will work on getting a POC for the lazy loading approach implemented.

Stuart

On Mon, Jun 6, 2016 at 12:27 PM, Jason T. Greene <[hidden email]> wrote:
We should really be generating 2048 bit keys. 

I don't like adding to our boot time, we have already seen it grow and this would be yet another case.

On Jun 5, 2016, at 8:57 PM, Stuart Douglas <[hidden email]> wrote:

So I just did up a very quick prototype that generates self signed certificates on startup and it looks like the difference in startup time is negligible (at least when generating 1024 bit RSA keys). Even if the difference is measurable it only affects the very first startup.

I think that in order to simplify the implementation of this it may be better to simply generate the key of first startup, instead of attempting to do it lazily.

Stuart

On Sat, Jun 4, 2016 at 12:09 AM, Jason T. Greene <[hidden email]> wrote:

What will be default keysize? It has to be probably choosen to work also without "Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy"

Probably the largest that is supported without JCE. It does not matter that much, self signed certs are inherently insecure, this is a developer usability feature, not something that can be used in production.

IIRC there is actually no limit on RSA key size, it's only symmetric algs that are limited, so we could use a standard 2048 bit key without issue.



Stuart





On Thu, Jun 2, 2016 at 10:01 PM, Stuart Douglas <[hidden email]> wrote:
So I guess we should talk about how this should actually work.

In terms of auto generating the key I was thinking we would need to add a new attribute to the 'keystore' element under the security realm, something like 'auto-generate-cert-host="localhost"'. I am not sure what other options we would need, or how configurable we should make it, but as this is for testing/development purposes I don't think we need to expose full control over the certificate generation process.

In terms of the implementation we could just implement an SSLContext wrapper, that can do the generation and then create a 'real' SSLContext the first time it is asked to create and SSLEngine.

Stuart

On Fri, Jun 3, 2016 at 3:19 AM, Jason Greene <[hidden email]> wrote:

> 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
_______________________________________________
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
If you go to https://localhost:9993 it will generate the certificate (although all that will be served is a 404 page as the console is not installed).

Stuart

On Mon, Jun 6, 2016 at 12:46 PM, Stuart Douglas <[hidden email]> wrote:
I think that would actually end up being more complex.

Stuart

On Mon, Jun 6, 2016 at 12:45 PM, Jason T. Greene <[hidden email]> wrote:
Another option could be a post boot task. So it's still eager but don't block completed start. We'd still need to block Tls ports though. So maybe this does not help

On Jun 5, 2016, at 9:31 PM, Stuart Douglas <[hidden email]> wrote:

2048 bits adds close to a second to first boot on my machine (obviously subsequent boots are unaffected).

This is probably a bit much, I will work on getting a POC for the lazy loading approach implemented.

Stuart

On Mon, Jun 6, 2016 at 12:27 PM, Jason T. Greene <[hidden email]> wrote:
We should really be generating 2048 bit keys. 

I don't like adding to our boot time, we have already seen it grow and this would be yet another case.

On Jun 5, 2016, at 8:57 PM, Stuart Douglas <[hidden email]> wrote:

So I just did up a very quick prototype that generates self signed certificates on startup and it looks like the difference in startup time is negligible (at least when generating 1024 bit RSA keys). Even if the difference is measurable it only affects the very first startup.

I think that in order to simplify the implementation of this it may be better to simply generate the key of first startup, instead of attempting to do it lazily.

Stuart

On Sat, Jun 4, 2016 at 12:09 AM, Jason T. Greene <[hidden email]> wrote:

What will be default keysize? It has to be probably choosen to work also without "Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy"

Probably the largest that is supported without JCE. It does not matter that much, self signed certs are inherently insecure, this is a developer usability feature, not something that can be used in production.

IIRC there is actually no limit on RSA key size, it's only symmetric algs that are limited, so we could use a standard 2048 bit key without issue.



Stuart





On Thu, Jun 2, 2016 at 10:01 PM, Stuart Douglas <[hidden email]> wrote:
So I guess we should talk about how this should actually work.

In terms of auto generating the key I was thinking we would need to add a new attribute to the 'keystore' element under the security realm, something like 'auto-generate-cert-host="localhost"'. I am not sure what other options we would need, or how configurable we should make it, but as this is for testing/development purposes I don't think we need to expose full control over the certificate generation process.

In terms of the implementation we could just implement an SSLContext wrapper, that can do the generation and then create a 'real' SSLContext the first time it is asked to create and SSLEngine.

Stuart

On Fri, Jun 3, 2016 at 3:19 AM, Jason Greene <[hidden email]> wrote:

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

Martin Choma
In reply to this post by Stuart Douglas
I realized, that autogenerated JKS keystore probably won't work for Oracle/OpenJDK java in FIPS mode because of https://issues.jboss.org/browse/JBEAP-3789
.


On Fri, Jun 3, 2016 at 9:28 AM, Stuart Douglas <[hidden email]> wrote:


On Fri, 3 Jun 2016, 17:18 Martin Choma <[hidden email]> wrote:
Hi Stuart,

I have couple of questions regarding self-signed certificate autogeneration:

What happens, when autogenerated certificate expires?

I think we would go for ten year expiry so that would not be an issue. The developer could just delete the store and generate a new one anyway.

How it will be decided if certificate should be autogenerate or not?

An attribute in the management model would be needed to explicitly enable it.


What will be default keysize? It has to be probably choosen to work also without "Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy"

Probably the largest that is supported without JCE. It does not matter that much, self signed certs are inherently insecure, this is a developer usability feature, not something that can be used in production.

Stuart





On Thu, Jun 2, 2016 at 10:01 PM, Stuart Douglas <[hidden email]> wrote:
So I guess we should talk about how this should actually work.

In terms of auto generating the key I was thinking we would need to add a new attribute to the 'keystore' element under the security realm, something like 'auto-generate-cert-host="localhost"'. I am not sure what other options we would need, or how configurable we should make it, but as this is for testing/development purposes I don't think we need to expose full control over the certificate generation process.

In terms of the implementation we could just implement an SSLContext wrapper, that can do the generation and then create a 'real' SSLContext the first time it is asked to create and SSLEngine.

Stuart

On Fri, Jun 3, 2016 at 3:19 AM, Jason Greene <[hidden email]> wrote:

> 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


_______________________________________________
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

Martin Choma
In reply to this post by Darran Lofthouse
Hi Darran,

talking about enhancing certificate obtaining process, i wonder if https://letsencrypt.org/ for automation could be utilized.

On Fri, Jun 3, 2016 at 6:11 PM, Darran Lofthouse <[hidden email]> wrote:
Enhancing TLS set up with features such as CSR generation and the
importing of the resulting signed certificates is something we are
working on.

Regards,
Darran Lofthouse.


On 03/06/16 15:28, Jorge Solórzano wrote:
> IMO this feature should be oriented to sysadmins not just developers. Is
> there really added value for developers to use HTTPS or HTTPS/2?
>
> It should be easy for sysadmins to setup TLS/SSL with "production"
> quality, from the gereration of the CSR that has to be send to the CA to
> the generation of the keystore.
>
> BTW... how is the performance of HTTPS using pure Java vs Apache for
> example? is this feature oriented for developers because for use in
> production is not recommended?
>
> *
> Ing. Jorge Solórzano*
> about.me/jorsol
> <https://about.me/jorsol?promo=email_sig&utm_source=email_sig&utm_medium=email_sig&utm_campaign=external_links>
>
> On Fri, Jun 3, 2016 at 3:52 AM, Tomaž Cerar <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     This is completely off topic for this thread, there was one earlier
>     about what should go into 10.x....
>
>     Anywho, issue you mention was already resolved and hibernate updated
>     in master some time ago.
>     which means it will be in next release, whatever that release will be.
>
>     --
>     tomaz
>
>     On Thu, Jun 2, 2016 at 6:29 PM, Harold Campbell <[hidden email]
>     <mailto:[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.
>
>         --
>         Harold Campbell <[hidden email] <mailto:[hidden email]>>
>
>         Roses are red;
>                 Violets are blue.
>         I'm schizophrenic,
>                 And so am I.
>
>
>         _______________________________________________
>         wildfly-dev mailing list
>         [hidden email] <mailto:[hidden email]>
>         https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>     _______________________________________________
>     wildfly-dev mailing list
>     [hidden email] <mailto:[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
1234