Subject: [quicwg/base-drafts] How should an HQ server respond to RST_STREAM? (#1596)

From: afrind <[email-masked]>
Date: Mon, 23 Jul 2018 10:10:13 -0700

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.

-- 
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/issues/1596

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 23 Jul 2018 10:15:32 -0700

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...

-- 
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/issues/1596#issuecomment-407133510

---

From: afrind <[email-masked]>
Date: Mon, 23 Jul 2018 13:38:34 -0700

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.

-- 
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/issues/1596#issuecomment-407193226

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 23 Jul 2018 21:51:17 +0000 (UTC)

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?

-- 
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/issues/1596#issuecomment-407212814

---

From: afrind <[email-masked]>
Date: Mon, 23 Jul 2018 15:21:45 -0700

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.  

-- 
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/issues/1596#issuecomment-407220085