The wtransport server is not terminating the session upon receiving a closed CONNECT stream.

According to the WebTransport Internet Draft:

WebTransport sessions are initiated inside a given HTTP/3 connection by the client, who sends an extended CONNECT request. If the server accepts the request, a WebTransport session is established. The resulting stream will be further referred to as a CONNECT stream, and its stream ID is used to uniquely identify a given WebTransport session within the connection. The ID of the CONNECT stream that established a given WebTransport session will be further referred to as a Session ID.

A WebTransport session is terminated when the CONNECT stream that created it is closed.

Also under 5. Session Termination

A WebTransport session over HTTP/3 is considered terminated when either of the following conditions is met:

1. the CONNECT stream is closed, either cleanly or abruptly, on either side; or
2. a CLOSE_WEBTRANSPORT_SESSION capsule is either sent or received.

Ruling out quinn

I added tracing logs in quinn to see the various Frames processed and dispatched. Maybe the desired Frame wasn't being sent!

To verify this wasn't a problem on quinn's end, I wrote a JS client in Chrome. That is:

options = {
    "congestionControl":"low-latency",
    "requireUnreliable":true,
    "serverCertificateHashes": [
        {
            "algorithm":"sha-256",
            "value": "some_certificate_hash"
        }
    ]
}

webtransport = new WebTransport(url, options);

To close the session, I called:

await webtransport.close();

When closing, I immediately receive a Frame::Stream from quinn:

This payload indicates that the CONNECT stream has been closed. This is because the session_id is 0 and fin is set to true.

Testing this behavior on Firefox, I received a CLOSE_WEBTRANSPORT_SESSION upon closing the JS client. This is fine since it is specified in the Session Termination section of the internet draft.

Our wtransport server is similar to the implementation in examples. It seems other people are experiencing #176 (comment) @BiagioFesta hinted this may be a browser bug as well.

Specifications

• wtransport version: 0.1.12
• Browsers tested:
  - Chrome (Version 127.0.6533.89)
  - (Firefox 129.0 (64-bit))

Issues mentioned

#176 (comment)