requirement on HTTP DATAGRAMs requires servers to buffer requests

[marten-seemann]

In order to establish a WebTransport session, both client and server need to enable HTTP DATAGRAM support.

This is a problem on the server side, since SETTINGS are sent on a different stream, and the server might not have received the client's SETTINGS when it processes the Extended CONNECT request. If the server wants to verify the requirement from the draft, it will need to buffer the Extended CONNECT request until it has received the client's SETTINGS. Obviously, this is suboptimal, especially since a malicious client can delay sending of the SETTINGS.

A possible solution would be to revisit our previous decision to require datagram support for WebTransport. It would then be valid to have a WebTransport session that doesn't support datagrams.

[vasilvv]

WebTransport already requires the server to not read any data from incoming bidirectional streams until it receives settings, because WebTransport changes the syntax of those in non-backwards-compatible manner.

[marten-seemann]

That's not my understanding.

As soon as a server sent the SETTINGS frame (containing all the extensions needed to use WebTransport), you need to be prepared to receive WebTransport streams. This shouldn't be a problem, since they start with the Signal Value (0x41), so the HTTP layer knows that it's a WebTransport stream. The WebTransport layer might need to buffer the stream if there's no session for that session ID, but there shouldn't be a situation where the HTTP layer needs to buffer anything.

[kixelated]

Is this specific to datagrams? Wouldn't a pedantic WebTransport server also have to buffer the CONNECT and any streams until SETTINGS_WEBTRANSPORT_MAX_SESSIONS has been verified?

I agree that the race between SETTINGS and CONNECT is strange. The receipt of a CONNECT request with :protocol WebTransport implies that the client has sent the associated SETTINGS. But I think the draft is right:

Similarly, the server MUST NOT process any incoming WebTransport requests until the client settings have been received, as the client may be using a version of the WebTransport extension that is different from the one used by the server.

This behavior is inevitable if the any SETTINGS changes the encoding/behavior of the CONNECT request. Until then, a smart server could defer verifying the SETTINGS frame but there's really no point.

[marten-seemann]

Is this specific to datagrams? Wouldn't a pedantic WebTransport server also have to buffer the CONNECT and any streams until SETTINGS_WEBTRANSPORT_MAX_SESSIONS has been verified?

Right, that's why I opened #141. I'd like to get to a state where the server doesn't need to wait for SETTINGS.

Similarly, the server MUST NOT process any incoming WebTransport requests until the client settings have been received, as the client may be using a version of the WebTransport extension that is different from the one used by the server.

This behavior is inevitable if the any SETTINGS changes the encoding/behavior of the CONNECT request. Until then, a smart server could defer verifying the SETTINGS frame but there's really no point.

It's my understanding that the client's SETTINGS don't change the meaning of CONNECT. It's the server's SETTINGS that enable Extended Connect.

[DavidSchinazi]

Chair: we didn't discuss this specific issue in the WG session at IETF 118, but see related issues #135, #141, and #143.

[DavidSchinazi]

Chair: discussed in editor's meeting. Plan is to write one PR that resolves #135, #140, #141, and #143. That PR would say:

• client MUST wait for server settings
• endpoints MUST send SETTINGS_H3_DATAGRAM (however servers that want to validate this MUST need to take into account the fact that the request might arrive before the client's SETTINGS)
• client no longer sends the WEBTRANSPORT_MAX_SESSIONS setting
• Add a "Considerations for future versions of WebTransport" section that explain that if a future version of WebTransport changes the syntax of the request, it'll need to change the Upgrade Token. Similarly, changes to stream formats will require changes to the Unidirectional Stream Type and Bidirectional Stream Signal Value.