Thank you very much Stéphane. I'd be happy to investigate it further - give me a little time to review http/2 (h2 and h2c) in pax-web in general.
regards Grzegorz Grzybek wt., 12 lis 2019 o 18:08 Stéphane Vaucher <[email protected]> napisał(a): > Hi Grzegorz, > > Comments inline > > 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. >> > > I don't exactly know the specific use-cases where http2 is better. From my > limited/theoretical understanding, it can help with certain loads (probably > unoptimized loads like images). > > >> [...] >> you said: >> >> I managed to get things working after upgrading to Java11 >>> >> >> Do you think it's required to use Java11? >> > > The change is not Java11-specific. I had many moving parts, and I got > everything running after doing my upgrade to Java 11. It's only Java 11 > tested. For execution on Java 8, it should be a matter of following the > steps to configure the bundles correctly. These steps are documented > outside pax-web (on the jetty web site). > > > 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. > > I only changed the JettyFactoryImpl class, so, unless Tomcat and Undertow > use that class, it won't work. I didn't see any existing automated tests > for HTTP1.1 vs HTTP2 support. That actually why I was suspecting that HTTP2 > wasn't supported correctly. I ran my tests using curl as detailed in my > previous message. I'm on equinox, so my runtime infrastructure is likely > different than yours. > > For now, I can only say - please send the PR, I'll be happy to merge it. >> > > https://github.com/ops4j/org.ops4j.pax.web/pull/272 > > Regards, > Stephane > > 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 >> <https://groups.google.com/d/msgid/ops4j/CAAdXmhrXn%3DHRceXnW9gc6vrrE_qRGMRmQ-nEHnb-WHZVzSGC-w%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > > > -- > -- > Benchmark Consulting > 460 rue St-Catherine St Ouest, Suite 612 > Montréal, Québec H3B-1A7 > (514) 798-2042 o > (514) 798-2044 f > > > CONFIDENTIALITY NOTICE: The information contained in this e-mail is > confidential and may be proprietary information intended only for the use > of the individual or entity to whom it is addressed. If the reader of this > message is not the intended recipient, you are hereby notified that any > viewing, dissemination, distribution, disclosure, copy or use of the > information contained in this e-mail message is strictly prohibited. If you > have received and/or are viewing this e-mail in error, please immediately > notify the sender by reply e-mail, and delete it from your system without > reading, forwarding, copying or saving in any manner. Thank you. > AVIS DE CONFIDENTIALITE: L’information contenue dans ce message est > confidentiel, peut être protégé par le secret professionnel et est réservé > à l'usage exclusif du destinataire. Toute autre personne est par les > présentes avisée qu'il lui est strictement interdit de diffuser, distribuer > ou reproduire ce message. Si vous avez reçu cette communication par erreur, > veuillez la détruire immédiatement et en aviser l'expéditeur. Merci. > > -- > -- > ------------------ > 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/CAMiyyEzM4tgGduayniLbcksXUABG5xB-qp2yc%3D%2Bb_Re6t6gXTw%40mail.gmail.com > <https://groups.google.com/d/msgid/ops4j/CAMiyyEzM4tgGduayniLbcksXUABG5xB-qp2yc%3D%2Bb_Re6t6gXTw%40mail.gmail.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/CAAdXmhqoBZpGHa%3Dbk-cKquiVoCFvuxVv6ppDVBSEnQTYfCGmjg%40mail.gmail.com.
