Original text:
4.1.2. <del> Clients can cancel requests by resetting and aborting the request stream with an error code of H3_REQUEST_CANCELLED (http-error-codes). When the client aborts reading a response, it indicates that this response is no longer of interest.  Implementations SHOULD cancel requests by abruptly terminating any directions of a stream that are still open. When the server rejects a request without performing any application processing, it 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. </del>  Servers MUST NOT use the H3_REQUEST_REJECTED error code for requests that were partially or fully processed.  When a server abandons a response after partial processing, it SHOULD abort its response stream with the error code H3_REQUEST_CANCELLED. <del> When a client resets a request with the error code H3_REQUEST_CANCELLED, a server MAY abruptly terminate the response using the error code H3_REQUEST_REJECTED if no processing was performed.  Clients MUST NOT use the H3_REQUEST_REJECTED error code, except when a server has requested closure of the request stream with this error code. </del>  <del> If a stream is cancelled after receiving a complete response, the </del>  client MAY ignore the cancellation and use the response.  However, if a stream is cancelled after receiving a partial response, the response SHOULD NOT be used.  Automatically retrying such requests is were or might be processed in this connection.  The server sends a client-initiated bidirectional Stream ID; the client sends a Push ID. Requests or pushes with the indicated identifier or greater are <del> rejected by the sender of the GOAWAY.  This identifier MAY be zero if no requests or pushes were processed. </del>  The information in the GOAWAY frame enables a client and server to agree on which requests or pushes were accepted prior to the

Reviewer comments:
I still don't feel like this flows quite right, so suggestions appreciated.
it better be clarify Implementation means Client/Server or both. there are some of similar terms reset cancel reject abort (abruptly) terminate it seems better to make them more clarify what each of them describes and how they can be done.
"Implementations," throughout the document, refers to both clients and servers. Do you have a suggested place to clarify this? "reset" and "abrupt termination" are synonyms for the same operation in "cancel" and "reject" are separate actions an implementation can take, described in It looks like "abort" is used with relatively little context -- I'll try to clean that up a bit. It's intended to refer to "abort reading," another operation in .
I thought this section says about client, but suddenly appears. Clients can cancel requests by ~ When the client aborts reading a response ~ Implementations SHOULD cancel requests by ~ so I think this is also a client (that says about cancel response). but you mean this says both client/server ? server can cancel request too ? SGTM > I'll try to clean that up a bit
Yes, servers can cancel a request; that is, indicate that for some reason they will not be processing it any further. But perhaps it would be clearer to separately state that in a paragraph about server behavior.
Thank you for improving the specs!

Revised text:
4.1.2.  <ins> Once a request stream has been opened, the request MAY be cancelled by either endpoint.  Clients cancel requests if the response is no longer of interest; servers cancel 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. </ins> Servers MUST NOT use the H3_REQUEST_REJECTED error code for requests that were partially or fully processed.  When a server abandons a response after partial processing, it SHOULD abort its response stream with the error code H3_REQUEST_CANCELLED.  <ins> Client SHOULD use the error code H3_REQUEST_CANCELLED to cancel requests.  Upon receipt of this error code, a server MAY abruptly terminate the response using the error code H3_REQUEST_REJECTED if no processing was performed.  Clients MUST NOT use the H3_REQUEST_REJECTED error code, except when a server has requested closure of the request stream with this error code. </ins>  <ins> If a stream is canceled after receiving a complete response, the </ins> client MAY ignore the cancellation and use the response.  However, if a stream is cancelled after receiving a partial response, the response SHOULD NOT be used.  Automatically retrying such requests is were or might be processed in this connection.  The server sends a client-initiated bidirectional Stream ID; the client sends a Push ID. Requests or pushes with the indicated identifier or greater are  <ins> rejected (request-cancellation) by the sender of the GOAWAY.  This identifier MAY be zero if no requests or pushes were processed. </ins> The information in the GOAWAY frame enables a client and server to agree on which requests or pushes were accepted prior to the