- From: Ryan Hamilton <rch@google.com>
- Date: Wed, 14 Nov 2018 15:02:41 -0800
- To: HTTP Working Group <ietf-http-wg@w3.org>
Received on Wednesday, 14 November 2018 23:03:08 UTC
The section on STOP_SENDING says: Receipt of a STOP_SENDING frame is only valid for a send stream that exists and is not in the "Ready" state (see Section 3.1). Receiving a STOP_SENDING frame for a send stream that is "Ready" or non- existent MUST be treated as a connection error of type PROTOCOL_VIOLATION. However, I'm not sure I'm clear on what should be done in the face of reordering, but maybe this is obvious. Say an HTTP client sends a request. This sends a STREAM frame to the server. This move the stream to the "Send" state. Then, the user cancels the request. So the client sends a RST_STREAM and a STOP_SENDING in order to completely nuke the stream. However, both the RST_STREAM and STREAM frames are lost/reordered such that the STOP_SENDING is the first frame to arrive at the server. As such, the stream is non-existent I think, which is prohibited. But maybe I'm not thinking about this the right way? Ryan
Received on Wednesday, 14 November 2018 23:03:08 UTC