Re: [quicwg/base-drafts] Clients can send GOAWAY too (#3129)

[Mike Bishop <[e-mail]>]

MikeBishop commented on this pull request.



> +The information in the GOAWAY frame enables a client and server to agree on
+which requests or pushes were accepted prior to the connection shutdown. Upon
+sending a GOAWAY frame, the endpoint SHOULD explicitly cancel (see
+{{request-cancellation}} and {{frame-cancel-push}}) any requests or pushes that
+have identifiers greater than or equal to that indicated, in order to clean up
+transport state for the affected streams. The endpoint SHOULD continue to do so
+as more requests or pushes arrive.
+
+Endpoints MUST NOT initiate new requests or promise new pushes on the connection
+after receipt of a GOAWAY frame from the peer.  Clients MAY establish a new
+connection to send additional requests.
+
+Some requests or pushes might already be in transit.  Upon receipt of a GOAWAY
+frame, if the endpoint has already sent requests or promised pushes with an
+identifier greater than or equal to that received in a GOAWAY frame, those
+requests or pushes will not be processed.  The endpoint that initiated these

I wound up separating these further, and in the process maybe breaking up the wall of text this section has become.

> +which requests or pushes were accepted prior to the connection shutdown. Upon
+sending a GOAWAY frame, the endpoint SHOULD explicitly cancel (see
+{{request-cancellation}} and {{frame-cancel-push}}) any requests or pushes that
+have identifiers greater than or equal to that indicated, in order to clean up
+transport state for the affected streams. The endpoint SHOULD continue to do so
+as more requests or pushes arrive.
+
+Endpoints MUST NOT initiate new requests or promise new pushes on the connection
+after receipt of a GOAWAY frame from the peer.  Clients MAY establish a new
+connection to send additional requests.
+
+Some requests or pushes might already be in transit.  Upon receipt of a GOAWAY
+frame, if the endpoint has already sent requests or promised pushes with an
+identifier greater than or equal to that received in a GOAWAY frame, those
+requests or pushes will not be processed.  The endpoint that initiated these
+requests or pushes MAY cancel them.  Clients MAY retry such requests on a

I reduced the MAY to a "can" and made it a separate paragraph further down.

> +sending a GOAWAY frame, the endpoint SHOULD explicitly cancel (see
+{{request-cancellation}} and {{frame-cancel-push}}) any requests or pushes that
+have identifiers greater than or equal to that indicated, in order to clean up
+transport state for the affected streams. The endpoint SHOULD continue to do so
+as more requests or pushes arrive.
+
+Endpoints MUST NOT initiate new requests or promise new pushes on the connection
+after receipt of a GOAWAY frame from the peer.  Clients MAY establish a new
+connection to send additional requests.
+
+Some requests or pushes might already be in transit.  Upon receipt of a GOAWAY
+frame, if the endpoint has already sent requests or promised pushes with an
+identifier greater than or equal to that received in a GOAWAY frame, those
+requests or pushes will not be processed.  The endpoint that initiated these
+requests or pushes MAY cancel them.  Clients MAY retry such requests on a
+different connection.

By removing the intervening sentence, this seems like less of a throwaway sentence.  See if you like this flow better?

> -for a client-initiated, bidirectional stream (i.e. 2^62-4 in case of QUIC
-version 1).  This GOAWAY frame signals to the client that shutdown is imminent
-and that initiating further requests is prohibited.  After allowing time for any
-in-flight requests to reach the server, the server can send another GOAWAY frame
-indicating which requests it will accept before the end of the connection. This
-ensures that a connection can be cleanly shut down without causing requests to
-fail.
-
-Once all accepted requests have been processed, the server can permit the
-connection to become idle, or MAY initiate an immediate closure of the
-connection.  An endpoint that completes a graceful shutdown SHOULD use the
-H3_NO_ERROR code when closing the connection.
+when the server closes the connection.  An endpoint MAY send multiple GOAWAY
+frames indicating different identifiers, but MUST NOT increase the identifier
+value they send, since clients might already have retried unprocessed requests
+on another connection.

Symmetry.  If clients are going to send Push IDs, then I'd rather have the same processing rules in both directions -- even if the reason it really matters only applies to clients.

-- 
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/3129#discussion_r372543822