Re: [quicwg/base-drafts] Firm up language around stream termination (#2888)

[Mike Bishop <[e-mail]>]

MikeBishop approved this pull request.



> @@ -2601,12 +2601,17 @@ connection in a recoverable state, the endpoint can send a RESET_STREAM frame
 ({{frame-reset-stream}}) with an appropriate error code to terminate just the
 affected stream.
 
-RESET_STREAM MUST be instigated by the protocol using QUIC, either directly or
-through the receipt of a STOP_SENDING frame from a peer.  RESET_STREAM carries
-an application error code.  Resetting a stream without knowledge of the
-application protocol could cause the protocol to enter an unrecoverable state.
-Application protocols might require certain streams to be reliably delivered in
-order to guarantee consistent state between endpoints.
+RESET_STREAM MUST be instigated by the protocol using QUIC.  RESET_STREAM
+carries an application error code.  Only the application protocol is able to
+cause a stream to be terminated.  A local instance of the application protocol
+uses a direct API call and a remote instance uses the STOP_SENDING frame, which
+triggers an automatic RESET_STREAM.

The guidance at line 657 says:
> An endpoint SHOULD copy the error code from the STOP_SENDING frame to the
> RESET_STREAM frame it sends, but MAY use any application error code.  The
> endpoint that sends a STOP_SENDING frame MAY ignore the error code carried in
> any RESET_STREAM frame it receives.

HTTP allows in one instance for the server to use a different error code if the transport implementation supports that, but everything's fine if the transport just reflects the code before the local application knows about it.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2888#pullrequestreview-272197175