Subject: [quicwg/base-drafts] Extract request cancellation from GOAWAY (#1100)

From: Mike Bishop <[email-masked]>
Date: Tue, 06 Feb 2018 19:08:03 +0000 (UTC)

Fixes #756.

Currently, all the discussion about CANCELLED requests is bound up in GOAWAY.  While GOAWAY is one way that requests can be CANCELLED, there are others.  This lifts out the text about request cancellation to its own section, then shortens the GOAWAY section to reference it.

I don't think there are new normative requirements here, but there are definitely some requirements that are easier to find now.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/1100

-- Commit Summary --

  * Extract request cancellation from GOAWAY

-- File Changes --

    M draft-ietf-quic-http.md (61)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/1100.patch
https://github.com/quicwg/base-drafts/pull/1100.diff

-- 
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/pull/1100

---

From: Martin Thomson <[email-masked]>
Date: Tue, 06 Feb 2018 16:17:52 -0800

martinthomson requested changes on this pull request.

The "no processing" clause is - I think - in error.

No mention here of cancellation of pushes.  What's the plan there?

> @@ -376,6 +376,31 @@ as a stream error of type HTTP_CONNECT_ERROR ({{http-error-codes}}).
 Correspondingly, a proxy MUST send a TCP segment with the RST bit set if it
 detects an error with the stream or the QUIC connection.
 
+### Request Cancellation
+
+Either client or server can cancel requests by closing the stream (QUIC
+RST_STREAM or STOP_SENDING frames, as appropriate) with an error type of
+HTTP_REQUEST_CANCELLED ({{http-error-codes}}).  When the client cancels a
+request or response, it indicates that the response is no longer of interest.
+
+When the server cancels either direction of the request stream, it indicates
+that no application processing was performed.  The client can treat requests

I don't think that this can be true.  It might indicate that no processing was performed, but we can't prohibit a server from cancelling streams after it does something, and this implies that requirement.

(This WAS true, because a variation on this text was used in the context of GOAWAY.)

> -with HTTP_REQUEST_CANCELLED if the associated requests were not processed.
-Servers MUST NOT use the HTTP_REQUEST_CANCELLED status for requests which were
-partially or fully processed.
-
-The client can treat requests cancelled by the server as though they had never
-been sent at all, thereby allowing them to be retried later on a new connection.
-If a stream is cancelled after receiving a complete response, the 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 not possible, unless this is otherwise
-permitted (e.g., idempotent actions like GET, PUT, or DELETE).  Requests on
-Stream IDs less than or equal to the Stream ID in the GOAWAY frame might have
-been processed; their status cannot be known until they are completed
+indicated in the GOAWAY frame, those requests are considered cancelled
+({{request-cancellation}}).  Endpoints SHOULD reset any streams above this ID
+with the error code HTTP_REQUEST_CANCELLED.  Servers MAY also cancel requests on

s/Endpoints/Both server and client/ just to make that clear.

> @@ -832,33 +855,19 @@ identified by a QUIC MAX_STREAM_ID frame, and MAY be zero if no requests were
 processed.  Servers SHOULD NOT increase the MAX_STREAM_ID limit after sending a
 GOAWAY frame.
 
-  Note:
-  : 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.
-
-Once sent, the server will refuse requests sent on streams with an identifier
+Once sent, the server MUST cancel requests sent on streams with an identifier

This MUST is now inconsistent with the SHOULD below: "Endpoints SHOULD reset [...]".  Pick one.

-- 
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/pull/1100#pullrequestreview-94552636

---

From: Mike Bishop <[email-masked]>
Date: Tue, 06 Feb 2018 16:49:09 -0800

MikeBishop commented on this pull request.

I think the clarification needed here is that I've defined "cancel" := "RST_STREAM with CANCELLED".  The server can, of course, RST_STREAM with some other error code at any time.  We can, I think, prohibit the server from using a particular error code after it does something.

-- 
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/pull/1100#discussion_r166490040

---

From: Mike Bishop <[email-masked]>
Date: Wed, 07 Feb 2018 00:50:13 +0000 (UTC)

(Of course, we still have to spec the client behavior if the server fails in its obligation, which is what the subsequent text is about.)

-- 
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/pull/1100#discussion_r166490183

---

From: Martin Thomson <[email-masked]>
Date: Wed, 07 Feb 2018 21:35:54 +0000 (UTC)

martinthomson approved this pull request.

OK, my major concern is mostly gone (misreading on my part).

Please fix the nits.

-- 
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/pull/1100#pullrequestreview-94879362

---

From: Mike Bishop <[email-masked]>
Date: Wed, 07 Feb 2018 22:50:16 +0000 (UTC)

@MikeBishop pushed 1 commit.

7b64f16  Martin's nits

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1100/files/e59e2a4b009c555d05fb296d9edd240be63333bd..7b64f162f52c29a07aeb7cc0ce1ec945f31be832

---

From: Mike Bishop <[email-masked]>
Date: Wed, 07 Feb 2018 22:50:32 +0000 (UTC)

I think the resolution to both the MUST/SHOULD and the clarity of "endpoints" is to say that the server MUST cancel, but the client SHOULD go ahead and cancel as well.

-- 
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/pull/1100#issuecomment-363938364

---

From: Martin Thomson <[email-masked]>
Date: Wed, 07 Feb 2018 22:56:58 +0000 (UTC)

Yeah, that seems right.

-- 
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/pull/1100#issuecomment-363939865

---

From: Mike Bishop <[email-masked]>
Date: Wed, 07 Feb 2018 15:00:24 -0800

c4512c2  Wording

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1100/files/7b64f162f52c29a07aeb7cc0ce1ec945f31be832..c4512c2701286348587409a6a07b3d967e2e9b65

---

From: Mike Bishop <[email-masked]>
Date: Sat, 17 Feb 2018 09:06:22 -0800

Merged #1100.

-- 
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/pull/1100#event-1479204088