Echoing HTTP_REQUEST_CANCELLED from STOP_SENDING has unintended semantics

[afrind]

The current transport draft says:

A STOP_SENDING frame requests that the receiving endpoint send a RESET_STREAM frame. An endpoint that receives a STOP_SENDING frame MUST send a RESET_STREAM frame for that stream. An endpoint SHOULD copy the error code from the STOP_SENDING frame, but MAY use
any other application error code. The endpoint that sends a STOP_SENDING frame can ignore the
error code carried in any RESET_STREAM frame it receives.

For HTTP, the HTTP_REQUEST_CANCELLED application error code has different semantics in each direction. From C -> S, it means "I don't want this". From S -> C, it means "I didn't process this". I don't think the client can't distinguish whether the RESET_STREAM was sent before or after the STOP_SENDING was received.

Maybe it's ok to do nothing here, since the client isn't likely to attempt to retry the request it just abandoned, and the text says the sender can ignore the RESET_STREAM error code. Or maybe we should clarify it in some way.

[MikeBishop]

Probably means we need to not overload CANCELLED with those server semantics. The server should have a separate error code (that clients SHOULD NOT use) indicating that the request was not processed.

[martinthomson]

What Mike said. A new code for the server (like DID_NOT_PROCESS) is probably best. We don't want the transport at the server making false statements.

[MikeBishop]

What? @martinthomson advocates a new error code? Quick, get the peace treaty for the Middle East out too -- today's the day! 😉

[janaiyengar]

@MikeBishop 's suggestion seems sensible.