On the sending part of a stream, an application protocol can:
* write data, understanding when stream flow control credit
(Section 4.1) has successfully been reserved to send the written
data;
* end the stream (clean termination), resulting in a STREAM frame
(Section 19.8) with the FIN bit set; and
* reset the stream (abrupt termination), resulting in a RESET_STREAM
frame (Section 19.4) if the stream was not already in a terminal
state.
On the receiving part of a stream, an application protocol can:
* read data; and
* abort reading of the stream and request closure, possibly
resulting in a STOP_SENDING frame (Section 19.5).
HTTP/3 approaches this by saying
Implementations SHOULD cancel requests by abruptly terminating any
directions of a stream that are still open. This means resetting the
sending parts of streams and aborting reading on receiving parts of
streams; see Section 2.4 of [QUIC-TRANSPORT].
Would it be clearer to lean on HTTP/3 for the CONNECT-UDP client behavior, or is something specific intended with the current text?
The spec says:
While https://tools.ietf.org/html/draft-ietf-quic-transport-31#section-2.4 says:
HTTP/3 approaches this by saying
Would it be clearer to lean on HTTP/3 for the CONNECT-UDP client behavior, or is something specific intended with the current text?