How should an HQ server respond to RST_STREAM?

[afrind]

If a client sends a RST_STREAM with code HTTP_REQUEST_CANCELLED, the server also needs to reset its end of the stream. As I read the spec, I'm unsure what error code best suits this purpose.

1. STOPPING says it is reserved by the transport in response to STOP_SENDING, so that's not it.
2. HTTP_REQUEST_CANCELLED is allowed S->C, but only if no processing of the request has occurred. What if part of the request has been processed?

A corollary question is, if a server cancels a request with a reset_stream, and does not send a STOP_SENDING, is the client expected to reply with HTTP_REQUEST_CANCELLED, a different error code, or continue sending until told to stop? CANCELLED seems ok here, but I dislike the asymmetry.

[LPardue]

Some random thoughts:

• use HTTP_NO_ERROR
• Can't you just FIN the stream?
  • Section 3.1 says "Servers MUST NOT abort a response in progress as a result of receiving a solicited RST_STREAM." - which might rule this out...

[afrind]

I don't want to FIN a stream in response to a RST. For me, FIN implies successful completion and RST applies some kind of exception. I read section 3.1 to mean that if I shouldn't abort the response if I receive RST_STREAM/STOPPING (eg, I asked for one via STOP_SENDING).

NO_ERROR could be OK, though perhaps something with more semantic meaning would be better. "I'm terminating my half because you terminated your half". STOPPING more closely matches that but is reserved for transport.

[LPardue]

I understand your points and don't have a strong preference.

The HTTP mapping has previously been accused of too many, too specific errors. So the question to ask would be, would your implementation do anything different if it received RST_STREAM with different application error codes?

[afrind]

Perhaps it would not do anything different - but I think this is a confusing area where more explicit text about the expectations of endpoints would help implementers.