Re: STOP_SENDING + reordering

Sigh, wrong list. Ignore me.

On Wed, Nov 14, 2018 at 3:02 PM, Ryan Hamilton <rch@google.com> wrote:

> 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
>