Hi Stuart,

I debugged into the ALPN code and found some issues with Http2Client. 

I started with the Http2Server example and found LoadBalancingProxyClient is using an instance of UndertowClient which can only load HTTP1.1 ClientProviders. The following is the code to get ClientProvider and only "http" or "https" can be the return from uri.getSchema().

ClientProvider provider = clientProviders.get(uri.getScheme());
If this is true, then the communication between the proxy and Http/2 server is Http/1.1
In addition, I have created a new class UndertowHttp2Client and Http2ClientTestCase in my forked repo to try 
the Http2ClientProviders and found all three http2 client providers don't work as expected. 
h2c and h2-prior got 200 response code back during handshake and h2 works but the connection is still http 1.1
I am debugging the ALPN code now but it is very slow as I have to dig into the spec to learn how the handshake works. 
As you have resolved the ALPN boot jar issue with the hack, I think Undertow is very usable for HTTP/2 and it would
be perfect if the client is working as well. Could you please confirm my findings and let me know direction I should
focus on? 

Thanks,

Steve

Here is my repo with UndertowHttp2Client and Test. 
https://github.com/stevehu/undertow

And here is the files I have added. 
https://github.com/stevehu/undertow/blob/master/core/src/main/java/io/undertow/client/UndertowHttp2Client.java
https://github.com/stevehu/undertow/blob/master/core/src/test/java/io/undertow/client/http/Http2ClientTestCase.java





On Sun, Mar 19, 2017 at 8:23 PM, Stuart Douglas <sdouglas@redhat.com> wrote:
I don't really have time to do it (there is no real benefit for
Undertow, so it is not high on my priority list), but the code is all
Apache licensed so there is no reason why you can't start a project
that provides this code as a standalone implementation.

You would still need to implement code in Netty etc to actually use
this as well, as there is no standardized ALPN API yet.

Stuart

On Mon, Mar 20, 2017 at 11:07 AM, Steve Hu <stevehu@gmail.com> wrote:
> I am reading the code in client package and they look really good. As
> currently none of the http/2 client library has a work around on alpn boot
> jar and this blocks majority of developers to move to http/2. I am wondering
> if you want to split client package to a standalone client module so that it
> can be used by other developers to connect to servers that implement http/2.
> If you are interested in it, I can help to create a pull request and add
> some test cases while I am working on my own client implementation. Thanks.
>
> On Sun, Mar 19, 2017 at 5:32 PM, Stuart Douglas <sdouglas@redhat.com> wrote:
>>
>> You could use Undertow's HTTP/2 client, although it's API was designed
>> around the reverse proxy use case and as a result is not ideal for the
>> general purpose HTTP client use case (although it is still perfectly
>> usable).
>>
>> In terms of using Undertow's ALPN implementation with Netty etc it
>> would require someone to port it over. The code is at [1] if you are
>> interested.
>>
>> Stuart
>>
>> [1]
>> https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io/undertow/protocols/ssl/ALPNHackSSLEngine.java
>>
>> On Mon, Mar 20, 2017 at 7:21 AM, Steve Hu <stevehu@gmail.com> wrote:
>> > Thanks Stuart for the quick response. Now I have server started with
>> > HTTP/2
>> > and it works perfect with some client tools. Now I am looking for Java
>> > HTTP/2 client libraries to update my client module to support HTTP/2
>> > protocol for microservices communication. There are three major
>> > libraries
>> > okhttp, jetty and netty but all of them require Jetty's ALPN boot JAR. I
>> > saw
>> > you have resolved the boot jar dependency in Undertow and am wondering
>> > if
>> > you could point me to the right direction. Do you have any
>> > recommendation
>> > for HTTP/2 client library? How do you work around the alpn boot jar? Is
>> > the
>> > same solution can be used by okhttp, jetty and netty before Java 9 is
>> > released?
>> >
>> >
>> >
>> > On Fri, Mar 17, 2017 at 11:03 PM, Stuart Douglas <sdouglas@redhat.com>
>> > wrote:
>> >>
>> >> No, that is a debug level message. The JDK8 ALPN provider should still
>> >> be registered.
>> >>
>> >> Stuart
>> >>
>> >> On Sat, Mar 18, 2017 at 12:18 PM, Steve Hu <stevehu@gmail.com> wrote:
>> >> > Hi,
>> >> >
>> >> > I searched this mailing list and one post mentioned that I don't need
>> >> > to
>> >> > use
>> >> > -Xbootclasspath/p:<path_to_alpn_boot_jar> after 1.4.0Final. I am
>> >> > trying
>> >> > HTTP/2 on my server with 1.4.10 and Oracle JDK 1.8 but when I start
>> >> > the
>> >> > server I got the following error. Do I have to use OpenJDK 8? If I
>> >> > switch to
>> >> > JBoss OpenSSL implementation?
>> >> >
>> >> > Thanks,
>> >> >
>> >> > Steve
>> >> >
>> >> > 21:00:36.468 [main]  DEBUG io.undertow - Configuring listener with
>> >> > protocol
>> >> > HTTPS for interface 0.0.0.0 and port 8843
>> >> >
>> >> > 21:00:36.486 [main]  DEBUG io.undertow - JDK9 ALPN not supported
>> >> >
>> >> > java.lang.NoSuchMethodException:
>> >> >
>> >> > javax.net.ssl.SSLParameters.setApplicationProtocols([Ljava.lang.String;)
>> >> >
>> >> > at java.lang.Class.getMethod(Class.java:1786)
>> >> >
>> >> > at
>> >> >
>> >> >
>> >> > io.undertow.protocols.alpn.JDK9AlpnProvider$1.run(JDK9AlpnProvider.java:47)
>> >> >
>> >> > at
>> >> >
>> >> >
>> >> > io.undertow.protocols.alpn.JDK9AlpnProvider$1.run(JDK9AlpnProvider.java:43)
>> >> >
>> >> > at java.security.AccessController.doPrivileged(Native Method)
>> >> >
>> >> > at
>> >> >
>> >> >
>> >> > io.undertow.protocols.alpn.JDK9AlpnProvider.<clinit>(JDK9AlpnProvider.java:43)
>> >> >
>> >> > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>> >> > Method)
>> >> >
>> >> > at
>> >> >
>> >> >
>> >> > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>> >> >
>> >> > at
>> >> >
>> >> >
>> >> > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>> >> >
>> >> > at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>> >> >
>> >> > at java.lang.Class.newInstance(Class.java:442)
>> >> >
>> >> > at
>> >> >
>> >> > java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:380)
>> >> >
>> >> > at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
>> >> >
>> >> > at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
>> >> >
>> >> > at io.undertow.protocols.alpn.ALPNManager.<init>(ALPNManager.java:40)
>> >> >
>> >> > at
>> >> > io.undertow.protocols.alpn.ALPNManager.<clinit>(ALPNManager.java:35)
>> >> >
>> >> > at
>> >> >
>> >> >
>> >> > io.undertow.server.protocol.http.AlpnOpenListener.<init>(AlpnOpenListener.java:67)
>> >> >
>> >> > at
>> >> >
>> >> >
>> >> > io.undertow.server.protocol.http.AlpnOpenListener.<init>(AlpnOpenListener.java:90)
>> >> >
>> >> > at io.undertow.Undertow.start(Undertow.java:179)
>> >> >
>> >> > at com.networknt.server.Server.start(Server.java:170)
>> >> >
>> >> > at com.networknt.server.Server.main(Server.java:90)
>> >> >
>> >> > 21:00:36.503 [main]  INFO  com.networknt.server.Server - Https Server
>> >> > started on ip:0.0.0.0 Port:8843
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > undertow-dev mailing list
>> >> > undertow-dev@lists.jboss.org
>> >> > https://lists.jboss.org/mailman/listinfo/undertow-dev
>> >
>> >
>
>