Code change:
.
cc NAME NAME
Looks great!
For a simple application that wants to send "hello world" over a WebTransport stream, it would take a minimum of 2.5 round trips for the data to arrive on the server. This is still an improvement over WebSockets but I'm wondering if we could do better. If the client is able to create streams prior to receiving the CONNECT response, then it would remove a round trip. The server would need to buffer any data received on streams associated with an unknown WebTransport session. If the server responds with a non-200 status code, then these streams are discarded. I believe 0-RTT is disabled for WebTransport because CONNECT is not idempotent and would be subject to replay attacks. An idempotent CONNECT would remove a round trip when 0-RTT is used... although I'm not sure this is a good idea.
I think this is a reasonable optimization
The client requirement is odd in comparison to MASQUE / CONNECT-UDP which says "client can risk sending datagrams before getting a 200 response, a different response means that datagrams will be discarded". What is the motivation for the requirement in WebTransport? If you need some kind of ordering guarantees, then stream IDs provide that.
Discussed at IETF 110. There were no objections to buffering (with some limits), so I think we should go ahead and add it.
After the client initiates the WebTransport session by sending a CONNECT request, the server sends a 200 response and is free to create streams. This means that a server-initiated stream may arrive prior to the CONNECT response. Is the client able to infer that the session was successfully established, or does the client need to buffer this stream until it receives a proper response?
Since there are no ordering guarantees across streams on the receiver side, I'd say you have to buffer until the 200 is processed.
I agree with Lucas here. We also had a similar problem in QuicTransport (server has to buffer streams before checking the origin), and we handled it by buffering.
Discussed at IETF 110. There were no objections to buffering (with some limits), so I think we should go ahead and add it.

Related discussion:
text: MTUs can vary.  TODO: Describe how the path MTU can be computed, specifically propagation across HTTP proxies. <ins> 4.5. In WebTransport over HTTP/3, the client MAY send its SETTINGS frame, as well as multiple WebTransport CONNECT requests, WebTransport data streams and WebTransport datagrams, all within a single flight.  As those can arrive out of order, a WebTransport server could be put into a situation where it receives a stream or a datagram without a corresponding session.  Similarly, a client may receive a server- initiated stream or a datagram before receiving the CONNECT response headers from the server. To handle this case, WebTransport endpoints SHOULD buffer streams and datagrams until those can be associated with an established session. To avoid resource exhaustion, the endpoints MUST limit the number of buffered streams and datagrams.  When the number of buffered streams is exceeded, a stream SHALL be closed by sending a RESET_STREAM and/ or STOP_SENDING with the "H3_WEBTRANSPORT_BUFFERED_STREAM_REJECTED" error code.  When the number of buffered datagrams is exceeded, a datagram SHALL be dropped.  It is up to an implementation to choose what stream or datagram to discard. </ins> 5. An WebTransport session over HTTP/3 is terminated when either