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.
