<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>Yes, thats what meant saying it needs a server transport (grpc term) based on undertow.</div><div><br>Am 02.06.2016 um 14:44 schrieb Jason T. Greene <<a href="mailto:jason.greene@redhat.com">jason.greene@redhat.com</a>>:<br><br></div><blockquote type="cite"><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div>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.</div><div><br>On Jun 2, 2016, at 7:03 AM, Heiko Braun <<a href="mailto:hbraun@redhat.com">hbraun@redhat.com</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8">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.<div class=""><br class=""></div><div class="">But I don’t want to hijack this thread. When the time comes I get back to this in a separate thread.</div><div class=""><br class=""></div><div class="">[1] <a href="https://github.com/grpc/grpc-java" class="">https://github.com/grpc/grpc-java</a></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 02 Jun 2016, at 13:54, Stuart Douglas <<a href="mailto:stuart.w.douglas@gmail.com" class="">stuart.w.douglas@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">Ah, sorry, I miss read your original email.<br class=""><br class=""></div><div class="">You can do HTTP/2 at the moment, it is just a bit of a pain to set up.<br class=""></div><div class=""><br class=""></div>Stuart<br class=""></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Jun 2, 2016 at 9:44 PM, Heiko Braun <span dir="ltr" class=""><<a href="mailto:hbraun@redhat.com" target="_blank" class="">hbraun@redhat.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="">gRPC requires http/2<div class=""><div class="h5"><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 02 Jun 2016, at 12:05, Stuart Douglas <<a href="mailto:stuart.w.douglas@gmail.com" target="_blank" class="">stuart.w.douglas@gmail.com</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class=""><div class="">I am not sure how gRPC comes into it?<br class=""><br class=""></div>Stuart<br class=""></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Jun 2, 2016 at 6:26 PM, Heiko Braun <span dir="ltr" class=""><<a href="mailto:hbraun@redhat.com" target="_blank" class="">hbraun@redhat.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="">+1<div class=""><br class=""></div><div class="">This would be a great step forward. </div><div class=""><br class=""></div><div class="">On a related note: I was looking into gRPC [1] for Swarm the other day,</div><div class="">and it seems this would be pre-requisite.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Regards, Heiko</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">[1] <a href="http://www.grpc.io/" target="_blank" class="">http://www.grpc.io/</a></div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class=""><div class=""><div class="">On 02 Jun 2016, at 01:22, Stuart Douglas <<a href="mailto:stuart.w.douglas@gmail.com" target="_blank" class="">stuart.w.douglas@gmail.com</a>> wrote:</div><br class=""></div></div><div class=""><div class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class="">Hi All,<br class=""><br class=""></div>I would like to propose that we add support for HTTP/2 out of the box in Wildfly 10.1.<br class=""><br class=""></div>At the moment there are two main barriers to getting HTTP/2 two work:<br class=""><br class=""></div>- You need to set up a HTTPS connector, including generating keys etc. For new users this is not as straightforward as it could be.<br class=""></div>- 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). <br class=""><br class=""></div>I am proposing that we do the following to address these issues:<br class=""></div><br class="">- 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.<br class=""><br class=""></div>- 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.<br class=""><br class=""></div>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.<br class=""><div class=""><br class=""></div><div class="">I think this would be a great usability feature, allowing developers to get started with HTTPS and HTTP/2 straight away. <br class=""><br class=""></div><div class="">Thoughts?<br class=""></div><div class=""><br class=""></div><div class="">Stuart<br class=""></div><div class=""><br class=""><br class=""><div class=""><br class=""><br class=""><br class=""></div></div></div></div></div><span class="">
_______________________________________________<br class="">wildfly-dev mailing list<br class=""><a href="mailto:wildfly-dev@lists.jboss.org" target="_blank" class="">wildfly-dev@lists.jboss.org</a><br class=""><a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" target="_blank" class="">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a></span></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></div></div></div></div></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>wildfly-dev mailing list</span><br><span><a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a></span><br><span><a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a></span></div></blockquote></div></blockquote></body></html>