Re: [quicwg/base-drafts] STOP_SENDING in Ready state (#1797)

[Ryan Hamilton <[e-mail]>]

On the list, I raised the following question which seems quite related to this issue:

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?

>From @MikeBishop  "Ah, I see what you’re saying – the STREAM frame in the C2S direction is what moves the S2C direction from Ready to Send.  If STOP_SENDING can be reordered relative to that frame, this could cause a valid-when-sent STOP_SENDING frame to arrive while the S2C direction is still in the Ready state.

I think you’re correct; the prohibition on receiving STOP_SENDING in the Ready state is erroneous.  Please file an issue, and thank you!"



-- 
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/issues/1797#issuecomment-438912358