Draft: draft-ietf-webtrans-http3

Commentary: In order to save a round - trip on connection establishment , a client could optimistically open streams just after sending the CONNECT request , before it has received a reply from the server . As both unidirectional and bidirectional streams are identified by the session ID , the server will be able to associate these streams with the WebTransport session as soon as it has processed the CONNECT request . In case the server rejects the CONNECT request , the client should probably reset / cancel these streams . Note that this does n't require any additional logic on the server side , as the server needs to be prepared to receive streams for sessions that it did n't establish anyway ( a malicious client might open streams with arbitrary session IDs , and a server should better be prepared for that ) . Currently , the spec forbids opening unidirectional streams before the session is established : There 's no such restriction for bidirectional stream . 
 I believe this is a left - over from the older text of the draft . We 've agreed in that both types of streams should be sent immediately , and as far as I remember , that is what the  implementation does . 
 That 's great ! I 'll write up a PR . How does that work ? I tried it out , but it seems like waits for the response to the CONNECT request . This is my JS code : Removing the also does n't work , then I 'm getting this error : Any hint would be highly appreciated . 
 Good question . I am not sure the current API state machine allows this ; when I said " what the  implementation does " , I meant that it supports receiving streams before it considers them confirmed ( for the client , it means that streams received before HTTP 200 for the CONNECT stream are buffered instead of dropped ) . We should probably figure out how to allow this on the client side , but that 's a W3C issue . 
 From my reading of the W3C spec this is already allowed : So maybe this is just a bug in  that it returns the ? 
 Sounds like we need an editorial PR to clarify that this is allowed 
 adds some text to clarify that opening streams as well as sending datagrams is permitted as soon as the CONNECT request has been sent out . 
 We need to pick one . The main two options are and . We 've discussed this separately within W3C ( see w3c / webtransport ) , and the conclusion there was that it would make more sense to just use URIs . We should discuss this at the upcoming IETF meeting . 
 ( No hats ) I think using  would be the simplest option here , so I 'd be inclined to go with that 
 Discussed at IETF 110 . Consensus in the room was for using . 
 Consensus confirmed on the list , the scheme in the draft is already . Closing this . 
 ( no hats )
Once established, both endpoints can open unidirectional streams.
The HTTP/3 unidirectional stream type SHALL be 0x54.  The body of the
stream SHALL be the stream type, followed by the session ID, encoded
as a variable-length integer, followed by the user-specified stream
data (fig-unidi).
The client MAY optimistically open unidirectional and bidirectional
streams, as well as send datagrams, for a session that it has sent
the CONNECT request for, even if it has not yet received the server's
response to the request.  On the server side, opening streams and
sending datagrams is possible as soon as the CONNECT request has been
received.
WebTransport endpoints can initiate unidirectional streams.  The
HTTP/3 unidirectional stream type SHALL be 0x54.  The body of the
stream SHALL be the stream type, followed by the session ID, encoded
as a variable-length integer, followed by the user-specified stream
data (fig-unidi).