race condition when closing the underlying QUIC connection

[marten-seemann]

A common use (at least for non-pooled WebTransport connections) will be to close the underlying QUIC connection when closing the WebTransport session.

This is inherently racy: The sender will send both a CLOSE_WEBTRANSPORT_SESSION capsule and a QUIC CONNECTION_CLOSE frame (unless you wait for the peer's FIN on the request stream, but why would you?). It's undetermined which one of the two will be received / processed first by the receiver.

This is not a problem if the sender uses the same error code and error message for the CONNECTION_CLOSE frame and for the CLOSE_WEBTRANSPORT_SESSION capsule. Assuming the QUIC stack properly exposes these values on its API, the receiver will be able to learn error code and error message.

Should we add that as a recommendation, or even a requirement?

[DavidSchinazi]

Chair: discussed during editor's meeting, see #95 (comment)