Hello I'm usually lagging behind, cleaning some rooms after party's over. I joined many hypes when they stopped being a hype and I quite enjoy it.
But seriously - same with http/2 (thought I don't think the hype is over - it's nice, future-proof technology) - I only recently read about how it works (frames, streams, ..), so I can't be of much help here. you said: I managed to get things working after upgrading to Java11 > Do you think it's required to use Java11? If not, then if you have PR + some test showing how to configure/use http2 with different containers (Jetty, Tomcat, Undertow) it'd be great to see it. If you checked only Jetty - that's still good. For now, I can only say - please send the PR, I'll be happy to merge it. regards Grzegorz Grzybek pt., 8 lis 2019 o 21:23 Stéphane Vaucher <[email protected]> napisał(a): > Hi everyone, > > I managed to get things working after upgrading to Java11, but I needed to > apply a few changes to JettyFactoryImpl. I'm unsure how alpn/h2 support is > functional for others with the current state of the code. > > When we find ALPN classes (alpnClassesAvailable), the main thing is that > SSLConnectionFactory will lead to *alpn* and not to *h2* following > (significant changes are in bold): > > //SAME > Class<?> comparatorClass = > bundle.loadClass("org.eclipse.jetty.http2.HTTP2Cipher"); > > Comparator<String> cipherComparator = (Comparator<String>) > FieldUtils.readDeclaredStaticField(comparatorClass, "COMPARATOR"); > sslContextFactory.setCipherComparator(cipherComparator); > > // Say that SSL should support *alpn*, not h2 > sslFactory = new SslConnectionFactory(sslContextFactory, *"alpn"*); > // was sslFactory = new SslConnectionFactory(sslContextFactory, "h2"); > > connectionFactories.add(sslFactory); > > Class<?> loadClass = > bundle.loadClass("org.eclipse.jetty.http2.server.HTTP2ServerConnectionFactory"); > http2Factory = (AbstractConnectionFactory) > ConstructorUtils.invokeConstructor(loadClass, httpsConfig); > connectionFactories.add(http2Factory); > > //Explicitely configure ALPN > * loadClass = > bundle.loadClass("org.eclipse.jetty.alpn.server.ALPNServerConnectionFactory");* > * alpnFactory = (NegotiatingServerConnectionFactory) > ConstructorUtils.invokeConstructor(loadClass, (Object) new String[] {"ssl", > "h2", "http/1.1"});* > * alpnFactory.setDefaultProtocol("h2");* > connectionFactories.add(alpnFactory); > > This leads the server to serve up h2 requests unless we explicitely > requested http1.1. > > Do these changes make sense to you? > > The negociation process succeeds with both: > curl -v for all requests lists: > * ALPN, offering h2 > * ALPN, offering http/1.1 > > $ curl -k *--http1.1* https://localhost:9443 > * ALPN, server accepted to use http/1.1 > > $ curl -k *--http2* https://localhost:9443 > > -v lists: * * ALPN, server accepted to use h2 > > Please let me know if these changes make sense. If so, let me know if you > want a PR. > > Regards, > Stephane Vaucher > > On Friday, August 16, 2019 at 3:57:18 PM UTC-4, Stéphane Vaucher wrote: >> >> Hi everyone, >> >> I've been using using pax web for HTTP/1.1 communications, and I've tried >> setting things up for HTTP/2 and have some configuration issues. I would >> like some guidance to help me diagnose what's going wrong. If this is a >> typical configuration issue, I'll gladly update documentation on your wiki >> to help future users. If this is a code issue, I'll gladly share a fix if I >> find one. *Questions are underlined.* >> >> Environment: >> >> - jetty 9.4.18 >> - pax-web 7.2.10 >> - equinox org.eclipse.osgi_3.12.0.v20170512-1932 >> - java *1.8.0_211* >> >> Main code I looked at *JettyFactoryImpl*.createSecureConnector. >> >> In order to see if HTTP/2 should be enabled, it checks for the presence >> of these classes: >> >> bundle.loadClass("org.eclipse.jetty.alpn.ALPN"); >> >> bundle.loadClass("org.eclipse.jetty.http2.server.HTTP2ServerConnectionFactory"); >> >> bundle.loadClass("org.eclipse.jetty.alpn.server.ALPNServerConnectionFactory"); >> >> This check is correct. At this point, I can access the server if I >> explicitly specify HTTP/2 (e.g., using cURL), but not from a browser [1,2]. >> ALPN does not seem to be configured out of the box. [3,4] >> >> *Is that the case? Is there a specific bundle that should ensure gets >> started?* >> >> I didn't see an explicit instantiation of a ConnectionFactory for ALPN >> org.eclipse.jetty.alpn.server.ALPNServerConnectionFactory. I tried >> adding one, but I haven't had much success. ALPNServerConnectionFactory >> fails to resolve an instance of org.eclipse.jetty.io.ssl.ALPNProcessor. >> *Server*. >> >> The test I ran was to add another connection factory. >> Class<?> alpnClass = >> bundle.loadClass("org.eclipse.jetty.alpn.server.ALPNServerConnectionFactory"); >> alpnFactory = (NegotiatingServerConnectionFactory) >> ConstructorUtils.invokeConstructor(alpnClass, (Object) new String[] {"ssl", >> "http/2", "http/1.1"}); *// << FAILS HERE* >> alpnFactory.setDefaultProtocol("http/1.1"); >> connectionFactories.add(alpnFactory); >> >> The class exists (precondition described above), but it fails running >> ServiceLoader.load(*Server*.class) where Server is ALPNProcessor. >> *Server.* >> >> *Is there an OSGI way of setting this up?* >> >> To set this up, I saw in the Jetty documentation, that I should have the >> alpn-boot on my bootclasspath (currently org.mortbay.jetty.alpn.boot is >> loaded as a bundle) . The version distributed with pax-web seems older >> (w.r.t. to my JDK). I updated the Java set-up from within dev environment >> to include a version of org.mortbay.jetty.alpn.boot that is supposed to >> compatible with my version of my JDK. I also added the >> org.eclipse.jetty.alpn.openjdk8.server bundle to my environment. As far >> as I can tell ServiceLoaders have to be dealt with a special way according >> to https://osgi.org/specification/osgi.cmpn/7.0.0/service.loader.html. >> >> *Are there steps I should be following? * >> *Does anyone have a set-up like up mine up and running? I suspect that >> people running Java9 might not have this type of issue.* >> *Thoughts?* >> >> Regards, >> Stephane Vaucher >> >> *[1] Access directly using http2* >> $ curl --http2-prior-knowledge -k https://dev.com:9443 >> % Total % Received % >> Xferd Average Speed Time Time Time Current >> Dload Upload Total Spent Left >> Speed >> 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- >> 0 >> >> *[2] Access using http* >> $ curl -k https://dev.com:9443/ >> % Total % Received % Xferd Average Speed Time Time Time >> Current >> Dload Upload Total Spent Left >> Speed >> 100 64 0 64 0 0 64 0 --:--:-- --:--:-- --:--:-- >> 2064 >> *invalid_preface <<<< * >> curl: (52) Empty reply from server >> >> *[3] Expected negotiation result* >> Checking with openssl, I see that I would expect something like: >> $ openssl s_client -connect google.com:443 -alpn h2 | grep ALPN\ p >> *ALPN protocol: h2* >> >> *[4] What I get* >> $ openssl s_client -connect dev:9443 -alpn h2 | grep ALPN\ >> *No ALPN negotiated* >> > -- > -- > ------------------ > OPS4J - http://www.ops4j.org - [email protected] > > --- > You received this message because you are subscribed to the Google Groups > "OPS4J" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/ops4j/8fe39fd4-5837-41df-bac6-d497cd20a759%40googlegroups.com > <https://groups.google.com/d/msgid/ops4j/8fe39fd4-5837-41df-bac6-d497cd20a759%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- -- ------------------ OPS4J - http://www.ops4j.org - [email protected] --- You received this message because you are subscribed to the Google Groups "OPS4J" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ops4j/CAAdXmhrXn%3DHRceXnW9gc6vrrE_qRGMRmQ-nEHnb-WHZVzSGC-w%40mail.gmail.com.
