Ryan Hamilton
2018-11-14 23:02:41 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
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