Re: [quicwg/base-drafts] Rearrange discussion of cancellation and rejection (#3926)

[Mike Bishop <[e-mail]>]

@MikeBishop commented on this pull request.



> +requests if they are unable to or choose not to respond.  When possible, it is
+RECOMMENDED that servers send an HTTP response with an appropriate status code
+rather than canceling a request it has already begun processing.
+
+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].
+
+When the server cancels a request without performing any application processing,
+the request is considered "rejected."  The server SHOULD abort its response
+stream with the error code H3_REQUEST_REJECTED. In this context, "processed"
+means that some data from the stream was passed to some higher layer of software
+that might have taken some action as a result. The client can treat requests
+rejected by the server as though they had never been sent at all, thereby
+allowing them to be retried later on a new connection. Servers MUST NOT use the

Good point.  In some ways, this is a holdover from HTTP/2, where it was possible for the client to exceed the server's stream limit, and REJECTED was a mechanism to close those streams without penalizing the client.  A server might still do that under load -- you can't take back stream credit, but you can reject incoming requests and not replace the stream credit.

-- 
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/3926#discussion_r459059537