Document HTTP/3 transport contract and bump incubator deps

Signed-off-by: jeroen.veltman <jeroen.veltman@nextend.nl>

Author: veltmanj

rsocket-transport-netty/QUIC_HTTP3_TRANSPORTS.md

@@ -0,0 +1,44 @@
+# QUIC and HTTP/3 transport notes
+
+This module now contains prototype Netty transports for:
+
+- `quic://` via `QuicClientTransport` and `QuicServerTransport`
+- `h3://` via `Http3ClientTransport` and `Http3ServerTransport`
+
+## Current HTTP/3 transport contract
+
+The current `h3://` transport uses a long-lived HTTP/3 `POST` request stream:
+
+- path defaults to `/rsocket`
+- content type defaults to `application/rsocket`
+- the request body carries raw RSocket frames in both directions once the server accepts the stream
+- `Http3ClientTransport.connect()` completes only after the client receives a successful response headers frame
+
+This is intentionally narrower than a general-purpose HTTP/3 tunnel, but it is the shape that is currently proven by the local integration tests in this repository.
+
+## Why the transport still uses `POST`
+
+An investigation was done into moving the transport to HTTP/3 `CONNECT`, including:
+
+- switching the request method from `POST` to `CONNECT`
+- enabling the HTTP/3 `ENABLE_CONNECT_PROTOCOL` setting on both peers
+- trying the newer Netty incubator pair `netty-incubator-codec-http3:0.0.30.Final` and `netty-incubator-codec-classes-quic:0.0.73.Final`
+- attempting an extended `CONNECT` request shape with the `:protocol` pseudo-header
+
+Those experiments still caused the request stream to close before the client observed a successful handshake response, so they were not kept in the working transport implementation.
+
+## Upstream findings that matter
+
+The current Netty HTTP/3 codec line does model both regular and extended `CONNECT`, but the details are stricter than a simple method flip:
+
+- regular `CONNECT` expects only `:method` and `:authority`
+- extended `CONNECT` expects `:method`, `:scheme`, `:authority`, `:path`, and `:protocol`
+- `ENABLE_CONNECT_PROTOCOL` is negotiated through HTTP/3 settings and is disabled by default
+
+In practice, that means a future `CONNECT`-based RSocket transport likely needs a more complete negotiation flow than the current prototype has.
+
+## Good next steps
+
+- keep `POST` as the default transport contract until the `CONNECT` path is validated end-to-end
+- if `CONNECT` is revisited, start with a dedicated experiment around response-header timing and remote settings negotiation
+- add a focused handshake-level test before changing the public default again

rsocket-transport-netty/build.gradle

@@ -26,8 +26,8 @@ if (osdetector.classifier in ["linux-x86_64", "linux-aarch_64", "osx-x86_64", "o
     os_suffix = "::" + osdetector.classifier
 }
 
-def netty_incubator_quic_version = "0.0.72.Final"
-def netty_incubator_http3_version = "0.0.29.Final"
+def netty_incubator_quic_version = "0.0.73.Final"
+def netty_incubator_http3_version = "0.0.30.Final"
 
 dependencies {
     api project(':rsocket-core')

rsocket-transport-netty/src/main/java/io/rsocket/transport/netty/internal/Http3TransportBootstrap.java

@@ -49,7 +49,6 @@
 import reactor.netty.Connection;
 
 public final class Http3TransportBootstrap {
-
   private Http3TransportBootstrap() {}
 
   public static Mono<DuplexConnection> connectClient(