HTTP/3 Server using Jetty 11 not responding

I'm trying to implement a HTTP/3 test server using Jetty 11 with Java 11 (as experiment). I'm following the code in the documentation:

public class HTTP3Server {
    public static void main(String[] args) {
        Server server = new Server();

        // The SSL Context
        SslContextFactory.Server sslContextFactory = new SslContextFactory.Server();
        sslContextFactory.setKeyStorePath("/etc/java/keystore.jks");
        sslContextFactory.setKeyStorePassword("password");

        // The HTTP configuration object
        HttpConfiguration httpConfig = new HttpConfiguration();
        SecureRequestCustomizer src = new SecureRequestCustomizer();
        src.setSniHostCheck(false);
        httpConfig.addCustomizer(src);

        // Create and configure the HTTP/3 connector.
        HTTP3ServerConnectionFactory h3Factory = new HTTP3ServerConnectionFactory(httpConfig);
        HTTP3ServerConnector connector = new HTTP3ServerConnector(server, sslContextFactory, h3Factory);
        connector.setPort(3443);
        server.addConnector(connector);

        // Create and configure a ResourceHandler.
        ResourceHandler handler = new ResourceHandler();

        // Configure the directory where static resources are located.
        handler.setBaseResource(Resource.newResource("/var/www/"));

        // Configure directory listing.
        handler.setDirectoriesListed(false);

        // Configure welcome files.
        handler.setWelcomeFiles(new String[]{"index.html"});

        // Configure whether to accept range requests.
        handler.setAcceptRanges(true);
        server.setHandler(handler);

        // Start server
        server.start();
    }
}

The keystore works fine when used in HTTP/1.1 or HTTP/2 (do I need to do anything different for HTTP/3 here?).
/var/www/index.html exists.
The server is launched without warnings or errors:

2023-05-25 10:31:06.305:INFO :oejs.Server:main: jetty-11.0.15; built: 2023-04-11T18:37:53.775Z; git: 5bc5e562c8d05c5862505aebe5cf83a61bdbcb96; jvm 11.0.19+7-post-Ubuntu-0ubuntu122.04.1
2023-05-25 10:31:06.338:INFO :oejhs.HTTP3ServerConnector:main: HTTP/3+QUIC support is experimental and not suited for production use.
2023-05-25 10:31:06.623:INFO :oejus.SslContextFactory:main: x509=X509@4af0df05(localhost,h=[icl test],a=[],w=[]) for Server@674bd420[provider=null,keyStore=file:///etc/java/keystore.jks,trustStore=null]
2023-05-25 10:31:06.661:INFO :oejs.AbstractConnector:main: Started HTTP3ServerConnector@4bd31064{h3, (h3)}{0.0.0.0:3443}
2023-05-25 10:31:06.733:INFO :oejs.Server:main: Started Server@30c93896{STARTING}[11.0.15,sto=0] @1189ms

The UDP port 3443 seems open (while TCP port 3443 is closed):

PORT     STATE         SERVICE
3443/udp open|filtered ov-nnm-websrv

I'm not sure if that is expected or not.

Finally, opening https://localhost:3443/ in Chrome fails as if it doesn't exists (no activity is registered in the server logs).

What do I need to do to make it work?

Solution

I'm afraid it is much more complicated than that, unfortunately.

Jetty's HTTP3Client can communicate with HTTP/3 servers such as Google and others. In the same way, Jetty's HTTP3Client can communicate with Jetty's HTTP/3 server. Because Jetty's implementation of HTTP/3 is shared between client and server, one would think it is a breeze to make a browser talk to a Jetty HTTP/3 server.

However, each browser has a secret sauce that (to my knowledge) needs to be reverse engineered, and each sauce is different.

For example, it is quite common that browsers refuse self-signed certificates, so your server must have a CA-signed certificate for a legit domain in order to work with a browser.

Furthermore, it is also common that browsers do not allow HTTP/3 communication other than on port 443, so you must start your server with admin/root privileges. We also believe that the strength of the ciphers negotiated plays a role.

There's more: browser do not establish a first direct communication via QUIC. They first try HTTP/2, and if the server announces support for HTTP/3, then the browser may switch to use HTTP/3. However, it is unclear what is exactly the policy to switch, for example whether a HTTP/2 ALTSVC frame is necessary, or the Alt-Svc header is enough, or if both are required.

Bottom line, it is going to be a daunting task, and even if the secret is unveiled for one browser, it may not work for other browsers.

The Jetty team is committed to discover and document at least 1 secret sauce, but so far we have been unsuccessful.

I for one would be very happy if someone knowing a browser's secret sauce would share it, but the information out there seems sparse and often outdated. We will insist and find it, eventually.