Subject: [quicwg/base-drafts] Rearrange discussion of cancellation and rejection (#3926)

From: Mike Bishop <[email-masked]>
Date: Tue, 21 Jul 2020 12:25:14 -0700

Fixes #3895

I still don&#39;t feel like this flows quite right, so suggestions appreciated.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Rearrange discussion of cancellation and rejection

-- File Changes --

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

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/3926.patch
https://github.com/quicwg/base-drafts/pull/3926.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/3926

---

From: Bence Béky <[email-masked]>
Date: Wed, 22 Jul 2020 11:44:06 -0700

@bencebeky commented on this pull request.

> -some higher layer of software that might have taken some action as a result. The
-client can treat requests rejected by the server as though they had never been
-sent at all, thereby allowing them to be retried later on a new connection.
-Servers MUST NOT use the H3_REQUEST_REJECTED error code for requests which
-were partially or fully processed.  When a server abandons a response after
-partial processing, it SHOULD abort its response stream with the error code
-H3_REQUEST_CANCELLED.
-
-When a client resets a request with the error code H3_REQUEST_CANCELLED, a
-server MAY abruptly terminate the response using the error code
-H3_REQUEST_REJECTED if no processing was performed.  Clients MUST NOT use the
-H3_REQUEST_REJECTED error code, except when a server has requested closure of
-the request stream with this error code.
-
-If a stream is cancelled after receiving a complete response, the client MAY
+Once a request has been sent, it MAY be cancelled by either endpoint.  Clients

Does the request body (if exists) need to be sent completely before the client can cancel the request?  Do the request headers need to be sent completely?  Or may the stream be cancelled if only a the very first byte of the HEADERS frame has been delievered in a QUIC STREAM frame?

Would "Once a request stream is open, the request MAY be cancelled" be better?

> +requests if they are unable to or choose not to respond.  When possible, it is
+RECOMMENDED that servers send an HTTP response with an appropriate status code
+rather than canceling a request it has already begun processing.
+
+Implementations SHOULD cancel requests by abruptly terminating any
+directions of a stream that are still open.  This means resetting the
+sending parts of streams and aborting reading on receiving parts of streams;
+see Section 2.4 of [QUIC-TRANSPORT].
+
+When the server cancels a request without performing any application processing,
+the request is considered "rejected."  The server SHOULD abort its response
+stream with the error code H3_REQUEST_REJECTED. 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. The client can treat requests
+rejected by the server as though they had never been sent at all, thereby
+allowing them to be retried later on a new connection. Servers MUST NOT use the

Is there any scenario whereby the request could be retried on the same connection (in which case "on a new connection" would be too restrictive)?  BTW, why would a server reject a request but not close the connection?

-- 
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/3926#pullrequestreview-453581467

---

From: Mike Bishop <[email-masked]>
Date: Wed, 22 Jul 2020 13:17:57 -0700

@MikeBishop commented on this pull request.

Technically, the stream needn't have any bytes sent.

-- 
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/3926#discussion_r459057618

---

From: Mike Bishop <[email-masked]>
Date: Wed, 22 Jul 2020 13:21:26 -0700

Good point.  In some ways, this is a holdover from HTTP/2, where it was possible for the client to exceed the server's stream limit, and REJECTED was a mechanism to close those streams without penalizing the client.  A server might still do that under load -- you can't take back stream credit, but you can reject incoming requests and not replace the stream credit.

-- 
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/3926#discussion_r459059537

---

From: Mike Bishop <[email-masked]>
Date: Wed, 22 Jul 2020 13:24:54 -0700

@MikeBishop pushed 1 commit.

5c0d9735b190946bcc40688403f37d4ee73325f6  Bence's feedback

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3926/files/22c920ea5a4662f4946c9748bfa0de05becd550e..5c0d9735b190946bcc40688403f37d4ee73325f6

---

From: Bence Béky <[email-masked]>
Date: Wed, 22 Jul 2020 17:42:38 -0700

That makes sense.  In that case, a client is allowed to retry the request later on the same connection.

-- 
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/3926#discussion_r459159971

---

From: Bence Béky <[email-masked]>
Date: Wed, 22 Jul 2020 17:43:37 -0700

@bencebeky approved this pull request.

Thank you for improving the specs!

-- 
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/3926#pullrequestreview-453774907

---

From: Martin Thomson <[email-masked]>
Date: Wed, 22 Jul 2020 19:18:08 -0700

@martinthomson approved this pull request.

```suggestion
allowing them to be retried later. Servers MUST NOT use the
```

> +possible, it is RECOMMENDED that servers send an HTTP response with an
+appropriate status code rather than canceling a request it has already begun
+processing.
+
+allowing them to be retried later. Servers MUST NOT use the H3_REQUEST_REJECTED

```suggestion
allowing them to be retried later.

Servers MUST NOT use the H3_REQUEST_REJECTED
```

This seems like a good point to break this mega-paragraph.

-- 
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/3926#pullrequestreview-452864917

---

From: Mike Bishop <[email-masked]>
Date: Tue, 28 Jul 2020 12:09:49 -0700

8a96637f08396fb56f0aa07a42318ad30bbc4616  Break mega

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3926/files/5c0d9735b190946bcc40688403f37d4ee73325f6..8a96637f08396fb56f0aa07a42318ad30bbc4616

---

From: ianswett <[email-masked]>
Date: Thu, 30 Jul 2020 15:31:13 +0000 (UTC)

@ianswett approved this pull request.

-- 
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/3926#pullrequestreview-458515762