Jetty 9.3.x supports HTTP/2. To get HTTP/2 up and running requires a small amount of work, mainly due to the requirements for TLS/SSL.
The following recipe makes configuring your HTTP stack with HTTP/2 relatively painless...
You will need a TLS certificate in a keystore. The details of how to install an official certificate (or for development, just create a self-signed certificate) are documented here...
The thing to take care of is that the certificate alias is jetty.
If you're using a CA you'll also need to make sure you have the necessary certificate signing chain in the keystore - in my experience this is the most likely cause of problems in setting up TLS/SSL.
If you're running Java 9 you can (hopefully) ignore this step.
Java 8 doesn't understand the ALPN protocol negotiation in its TLS implementation so you must provide this capability. You will need to provide an ALPN implementation library for your specific JVM version.
You can find which version of alpn-boot-xxxx.jar you need using the table here...
When you know the version you can download the jar file here...
Due to the low-level javax.security.xxxx packages that it provides you need to register it in the low-level Java classloader. You can do this by setting an extension in your NK install's bin/jvmsettings.cnf
Add the following:
(jvmsettings.cnf is a single line of switches to the java process - so keep it all on one line)
You can download a ready to use pre-configured example of the HTTPServerConfig.xml here.
Here's the details of how to configure Jetty with the HTTP2 connection factory.
Find your Frontend Fulcrum (FEF) module in modules/urn.org.netkernel.fulcrum.frontend-x.x.x/ and edit etc/HTTPServerConfig.xml
Add the SSL ServerConnector with a list of factories: SslConnectionFactory, ALPNServerConnectionFactory, HTTP2ServerConnectionFactory and, for HTTP/1.1 fallback, HttpConnectionFactory.
Note, the SslConnectionFactory must have its "next" argument set to "alpn" - which hooks in the protocol negotiation at the TLS level.
When you first set up ALPN its a good idea to enable debugging messages - so you can observe the protocol negotiation...
If you have Jetty's TLS stack correctly configured you'll see the following log message when NetKernel starts the HTTP transport...
I 10:57:39 HTTPTranspor~ Starting [Frontend SSL Fulcrum: 8443] with protocol(s) [ssl, alpn, h2, h2-17, h2-16, h2-15, h2-14, http/1.1]
The list of protocols must show alpn and h2.
All being well, if you've got an application deployed to the FEF it will now "just work" when you request it down the https://localhost:8443/xxxx path.
Fortunately there are absolutely no consequences in using HTTP/2 to an existing application at either client or server-side. If your browser supports it - your page requests will get multiplexed, if it doesn't then you'll default back to plain old HTTP/1.1. In either case the server-side logical ROC requests will arrive with exactly the same context as before.
One thing to note is that, because HTTP/2 is a low level protocol update, your browser's developer tools such as Firebug will not show any difference in the HTTP network request view (other than speed!). So how do you know if you've got it set up right?
Fortunately Chrome has a built-in HTTP/2 diagnostics tool. Open up a tab and paste this URL in...
You can then observe and capture HTTP/2 traffic to verify your solution is working as you intended.
If you need help configuring your HTTP stack please get in touch with 1060 Research support.