Responding to RST_STREAM with RST_STREAM

[Sam Young]

The draft 3 spec states in section 2.4.2 (Stream Error Handling):
"After sending the RST_STREAM, the stream is closed to the endpoint,
so receipt of any further frames for that stream id will result in
sending additional RST_STREAM frames. Sending a RST_STREAM does not
cause the SPDY session to be closed."

It might be helpful to clarify that an additional RST_STREAM frame is
not considered a "further frame for that stream id." Without a special
case for RST_STREAM, implementations could enter an infinite loop of
exchanging RST_STREAM frames.

[William Chan (陈智昌)]

Thanks for taking a look! I agree, this should be clarified. Do you have a suggested wording? Perhaps "so the receipt of any further frames for that stream id, other than RST_STREAM, will result in sending additional RST_STREAM frames."?

[Karthik Ramakrishnan]

Well doesn't this sentence in section 2.6.3 clarify:

"After receiving a RST_STREAM on a stream, the recipient must not send additional frames for that stream, and the stream moves into the closed state."

As soon as the recipient receives a RST_STREAM he stops sending additional frames. For frames mid-air, the sender will send one (coalesced into a single RST_STREAM) or more RST_STREAMS.

--
Regards,
Karthik Ramakrishnan

[William Chan (陈智昌)]

On Fri, Dec 16, 2011 at 10:10 AM, Karthik Ramakrishnan <karthik.ra...@gmail.com> wrote:

Well doesn't this sentence in section 2.6.3 clarify:

"After receiving a RST_STREAM on a stream, the recipient must not send additional frames for that stream, and the stream moves into the closed state."

As soon as the recipient receives a RST_STREAM he stops sending additional frames. For frames mid-air, the sender will send one (coalesced into a single RST_STREAM) or more RST_STREAMS.

I don't think that clarifies it. That makes it ambiguous/inconsistent.

[Sam Young]

> On Fri, Dec 16, 2011 at 9:16 AM, William Chan (陈智昌) <willc...@chromium.org> wrote:
> Thanks for taking a look! I agree, this should be clarified. Do you have
> a suggested wording? Perhaps "so the receipt of any further frames for that
> stream id, other than RST_STREAM, will result in sending additional
> RST_STREAM frames."?

That sounds great to me.

[Sam Young]

Will, that wording sounds good to me.

On Dec 16, 11:46 am, William Chan (陈智昌) <willc...@chromium.org> wrote:
> On Fri, Dec 16, 2011 at 10:10 AM, Karthik Ramakrishnan <
>

> karthik.ramakrish...@gmail.com> wrote:
> > Well doesn't this sentence in section 2.6.3 clarify:
>
> > "After receiving a RST_STREAM on a stream, the recipient must not send
> > additional frames for that stream, and the stream moves into the closed
> > state."
>
> > As soon as the recipient receives a RST_STREAM he stops sending additional
> > frames. For frames mid-air, the sender will send one (coalesced into a
> > single RST_STREAM) or more RST_STREAMS.
>
> I don't think that clarifies it. That makes it ambiguous/inconsistent.
>
>
>
>
>
>
>
>
>

> > On Fri, Dec 16, 2011 at 9:16 AM, William Chan (陈智昌) <willc...@chromium.org

> > > wrote:
>
> >> Thanks for taking a look! I agree, this should be clarified. Do you have
> >> a suggested wording? Perhaps "so the receipt of any further frames for that
> >> stream id, other than RST_STREAM, will result in sending additional
> >> RST_STREAM frames."?
>

[Mike Belshe]

I've reworded to clarify sender and receiver and to avoid rst_stream loops.

Mike