Jetty HTTP/3 Client fails when connecting to nghttpx server

[ChGen]

Jetty version(s)
12.0.0
(11.x affected too)

Jetty Environment
core?

Java version/vendor (use: java -version)
openjdk 17.0.8 2023-07-18

OS type/version
WSL2 Ubuntu 22.04 (Windows 11 22H2 Host)

Description

When trying jetty http3 client, I found out that it fails with nghttpx http3 server.
For example, the test below fails for https://nghttp2.org:4433 (or local nghttpx), but will pass for https://http3check.net
However, curl built with http3 support will connect both https://nghttp2.org:4433 and https://http3check.net successfully.

curl -kv --http3 https://nghttp2.org:4433

How to reproduce?

Test code:

    @Test
    public void testConnection_nghttp2() throws Exception {
        final HTTP3Client h3Client = new HTTP3Client();
        final HttpClientTransportOverHTTP3 transport = new HttpClientTransportOverHTTP3(h3Client);
        final HttpClient client = new HttpClient(transport);
        client.start();
        final ContentResponse response = client.GET("https://nghttp2.org:4433"); // will pass for 'https://http3check.net`
        assertEquals(200, response.getStatus());
        client.stop();
    }

Exception thrown:

java.util.concurrent.ExecutionException: java.util.concurrent.CompletionException: org.eclipse.jetty.http3.qpack.QpackException$StreamException: buffer_space_exceeded

Full stacktrace:
http3-exception.log

[sbordet]

What happens is that nghttp2.org sends a "grease" settings: MAX_FIELD_SECTION_SIZE=4611686018427387903.

We fail to interpret this as a "grease" setting, try to convert it to int, and we get -1 for the MAX_FIELD_SECTION_SIZE.
Eventually this number is used to allocate a buffer, which is now allocated 1 byte smaller, so we fail with the BufferOverflowException.

We should carefully review the "greasing" for stream ids, settings, frame types, error codes, etc, as specified in RFC 9114.

Note that the value sent by nghttp2.org is 4611686018427387903, which is not a "grease" value.
The closes grease value is 0x1F * 148764065110560899 + 0x21 = 4611686018427387902 which is off by 1 with what sent by nghttp2.org, so I guess also nghttp2.org has a bug.