Version
h3 0.0.8
Platform
Linux desktop 7.1.7 NixOS x86_64 GNU/Linux
Summary
max_webtransport_sessions is advertised but not enforced
Code Sample
Static check:
rg -n 'max_webtransport_sessions' h3/src
For h3 0.0.8, references are limited to configuration defaults, settings parsing/serialization, and the builder setter; there is no runtime admission check.
Behavioral peer pseudocode:
let mut builder = h3::server::builder();
builder
.enable_extended_connect(true)
.enable_datagram(true)
.enable_webtransport(true)
.max_webtransport_sessions(1);
let mut h3 = builder.build(quic).await?;
// A non-compliant peer opens two valid WebTransport CONNECT requests.
let first = h3.accept().await?.unwrap().resolve_request().await?;
let second = h3.accept().await?.unwrap().resolve_request().await?;
// h3 delivers both to the application; it does not reject the second from
// the configured maximum. Application code must count/reject it itself.
Expected Behavior
The API contract should be explicit:
- If the value is only an advertised peer obligation, name and document it as such and expose enough information for the application to enforce violations.
- If it is a server limit, track active sessions and reject excess CONNECT requests with the protocol-appropriate response while allowing up to the configured count.
Actual Behavior
server::Builder::max_webtransport_sessions(value) stores value in configuration and serializes it into SETTINGS_WEBTRANSPORT_MAX_SESSIONS. No active-session counter or request rejection references the configured field after settings serialization.
The method's Rustdoc says it “Limits the maximum number of WebTransport sessions,” but h3 itself continues delivering extended CONNECT request streams without checking the limit. Moreover, h3-webtransport 0.1.2 moves the whole h3 connection into one WebTransportSession, so its public API cannot naturally operate the configured number of concurrent sessions when the value is greater than one.
Suggested upstream fix
Clarify whether the setting is declarative or enforced. Add active-session lifecycle hooks and admission enforcement, or rename the builder operation to make its settings-only behavior explicit. h3-webtransport should support multiple session drivers on one h3 connection if values greater than one are intended to be usable.
Version
h3 0.0.8
Platform
Linux desktop 7.1.7 NixOS x86_64 GNU/Linux
Summary
max_webtransport_sessionsis advertised but not enforcedCode Sample
Static check:
rg -n 'max_webtransport_sessions' h3/srcFor
h3 0.0.8, references are limited to configuration defaults, settings parsing/serialization, and the builder setter; there is no runtime admission check.Behavioral peer pseudocode:
Expected Behavior
The API contract should be explicit:
Actual Behavior
server::Builder::max_webtransport_sessions(value)storesvaluein configuration and serializes it intoSETTINGS_WEBTRANSPORT_MAX_SESSIONS. No active-session counter or request rejection references the configured field after settings serialization.The method's Rustdoc says it “Limits the maximum number of WebTransport sessions,” but h3 itself continues delivering extended CONNECT request streams without checking the limit. Moreover,
h3-webtransport 0.1.2moves the whole h3 connection into oneWebTransportSession, so its public API cannot naturally operate the configured number of concurrent sessions when the value is greater than one.Suggested upstream fix
Clarify whether the setting is declarative or enforced. Add active-session lifecycle hooks and admission enforcement, or rename the builder operation to make its settings-only behavior explicit.
h3-webtransportshould support multiple session drivers on one h3 connection if values greater than one are intended to be usable.