Change:
entire request if the response does not depend on any portion of the request that has not been sent and received.  When the server does not need to receive the remainder of the request, it MAY abort <del> reading the request stream with error code H3_EARLY_RESPONSE, send a complete response, and cleanly close the sending part of the stream. Clients MUST NOT discard complete responses as a result of having their request terminated abruptly, though clients can always discard responses at their discretion for other reasons.  If the server sends a partial or complete response but does not abort reading, clients SHOULD continue sending the body of the request and close the stream normally. </del> <ins> reading the request stream, send a complete response, and cleanly close the sending part of the stream.  The error code H3_NO_ERROR SHOULD be used when requesting that the client stop sending on the request stream.  Clients MUST NOT discard complete responses as a result of having their request terminated abruptly, though clients can always discard responses at their discretion for other reasons. If the server sends a partial or complete response but does not abort reading, clients SHOULD continue sending the body of the request and close the stream normally. </ins> 4.1.1.

Discussion:
Does it matter if the the STOPSENDING error code is something other than EARLY RESPONSE? Originally posted by NAME in URL Moving this out to a separate issue to avoid complicating ; my inclination is to propose the following rules: When a STOPSENDING is received, if the error code has semantics in the context in which you received it, follow the semantics. If the error code has no semantics in that context (or is unknown), then it has no direct effect on the viability of the request or the response. If resetting your request stream causes the server to be unable to generate a response, it will reset its stream. If it sends a complete response, the server clearly got everything it needed; the response is usable. If a response stream is reset after all bytes have been received, the response remains usable; no takebacks.
Several of these are already in the draft: Perhaps the clarification that's needed is to keep the "MAY abort reading," but separately say that "H3EARLYRESPONSE SHOULD be used as the error code"? (Which does raise the question of whether it needs to be a separate error code from H3NOERROR....)
I think a normal transport assumption is that a change of path implies a (potential) loss of congestion state, and that the endpoint should reset the path CC parameters. Transport-ID: “On confirming a peer's ownership of its new address, an endpoint SHOULD immediately reset the congestion controller and round-trip time estimator for the new path.” • Does the "reset" require setting the CC to the initial window value for a connection? I think so. • Why not MUST? Transport-ID: “An endpoint MUST NOT return to the send rate used for the previous path unless it is reasonably sure that the previous send rate is valid for the new path. “ This could therefore be seen as a “significant” departure from conventional approaches considered safe - and extends this to “reasonably sure”. • Is there a rationale for extending this to “reasonably sure”, because this seems bolder than permitted for a new TCP connection. How do people quantify reasonably sure, and why not just in this case grow from the Initial window?
Yes. We should articulate this better though. To allow for pre-existing knowledge, such as stored values.

I think this can be changed to say "unless an endpoint has other knowledge, it MUST reset" (or some such). Fair point. The intent here again was to allow pre-existing knowledge to be used, but I think the wording can be changed to reflect that more explicitly.
Discussed in London: NAME to provide a PR
Re-opening issue. This needs a bit more work.