Change:
serialized as described in the "serializing a request origin" section of FETCH. <ins> The server indicates that it accepts the origin by sending its header block and a FIN on the stream 0.  If the server does not accept the origin, it MUST close the connection. </ins> 3.2.2. In order to allow multiplexing multiple application on the same host- port tuple, QuicTransport allows specifying extra routing information in the path component of the URI.  That component is communicated <del> using the "Path" field in the client indication: </del> <ins> using the "Path" header: </ins> Path <del> 0x0001 </del> The path component of the QuicTransport URI. The user agent MUST send a non-empty "Path" field.  When the

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.