Change:
In order to verify that the client's origin is allowed to connect to the server in question, the user agent has to communicate the origin <del> to the server.  This is accomplished by sending a special message, called client indication, on stream 2, which is the first client- initiated unidirectional stream. </del> <ins> to the server.  This is accomplished by performing a handshake on the first client-initiated bidirectional stream, stream 0.  The handshake is performed as follows: </ins> <del> The client indication is a sequence of key-value pairs that are formatted in the following way: </del> <ins> The client sends its headers on stream 0. </ins> <del> The pair includes the following fields: </del> <ins> The client sends FIN on stream 0.  This indicates that all headers have been sent, and the server can now process them. The server processes the headers and makes access control decision based on the origin.  Before this happens, the server MUST NOT process any non-header application data receiver from the client, or send its own header block. The server sends its header block on stream 0, followed by a FIN indicating that the handshake has been successfully completed. </ins> <del> Indicates the field that is being expressed. </del> <ins> The QuicTransport header stream payload SHALL be a header block.  A header block is a sequence of key-value pairs that are formatted in the following way: The pair includes the following fields: </ins> <del> Indicates the length of the value (the length of the key and the length itself are not included). </del> <ins> Indicates the name of the field that is being expressed.  The name of the field is case-insensitive, and when encoded on the wire, it MUST consist of ASCII characters in range from "a" to "z", "0" to "9", "-", or ".".  It MUST begin with an alphanumeric character. </ins> <del> The value of the field, the semantics of which are determined by the key. </del> <ins> The value of the header field, the semantics of which are determined by the name. </ins> <del> A FIN on the stream 2 SHALL indicate that the message is complete. The client MUST send the entirety of the client indication and a FIN immediately after opening the connection.  The server MUST NOT process any application data before receiving the entirety of the client indication.  The total length of the client indication MUST NOT exceed 65,535 bytes. </del> <ins> A FIN on the stream 0 SHALL indicate that the message is complete. The client MUST send the entirety of the header block and a FIN immediately after opening the connection.  Before receiving the entirety of the headers, the server MUST NOT process any datagrams or any data on streams other than 0.  The total length of a header block MUST NOT exceed 1,048,576 bytes; implementations MAY impose additional limit on the header block size. </ins> <del> In order to ensure that the user agent can send the client indication immediately, the server MUST set "initial_max_streams_uni" transport </del> <ins> In order to ensure that the user agent can send the headers immediately, the server MUST set "initial_max_streams_bidi" transport </ins> parameter to at least "1".  The user agent MUST close the connection <del> if the server sets "initial_max_streams_uni" to "0". </del> <ins> if the server sets "initial_max_streams_bidi" to "0". </ins> The server MUST ignore any field it does not recognize.  All of the fields MUST be unique; the server MAY close the connection if any of

Discussion:
We currently use 16-bit integers for header names. There probably won't ever be more than 65,000 headers, but this does not let users add their own custom headers easily. Thus, this commit changes uint16 to string. We currently provide a way for a server to explicitly reject client's origin, but no way to explicitly accept it. This commit solves this by turning the client indication stream into a bidirectional handshake stream. Server confirms the handshake by sending a FIN on its end of the handshake stream.
Reviewing , NAME wrote: I do agree that this is annoying, but at the same time adding a field that's redundant 90% of the time feels... weird? We should think more seriously about how to make header size limits work at some point (maybe using ALPS or something like that).
Closing this issue because the QuicTransport draft has been removed from this repository.
In WebTransport over QUIC, when an invalid Client Indication is received, the server treats the connection as an error(). This is an error that occurred in a layer above the QUIC, so I think the connection should be closed with CONNECTION_CLOSE (0x1d) indicating an error in the application using the QUIC. I think it is valuable to define an error code for WebTransport over QUIC. ( saids "the management of application error codes is left to application protocols." ) and, by specifying the error code that the endpoint uses when it close the connection, the specification becomes clear. for example
I realized that using Error Code is related to the . Do not conflict with error codes used by applications above WebTransport. so, I createted URL . Please point it out if there are any mistakes in my opinion. thanks
I agree, CONNECTION_CLOSE should provide an error code indicating why the connection was refused.
I seem to remember seeing non-zero error codes from other endpoints when interoperating. If so, I have no clue what those codes were supposed to mean. I think it would be useful to have some defined in the next draft version.
I think the non-zero error codes probably were random HTTP/3 error codes, because those are the only codes that Google's QUIC library supports (that's a known bug).

I see three options for reporting handshake error: 1) An application CONNECTIONCLOSE, 2) A RESETSTREAM on the handshake stream, 3) An error status code on the handshake stream. If we go with 1, we would have to reserve some of the application error code space. If we go with 2 or 3, we would have to describe how the server has to keep the connection open for some time in order to allow for retransmission of the RESET_STREAM/response error header.
Closing this issue because the QuicTransport draft has been removed from this repository.