Re: 6.6 PUSH_PROMISE (Re: draft-ietf-httpbis-http2-08 / 5.1. Stream States)

On 19 December 2013 09:08, Kari Hurtta <hurtta-ietf@elmme-mailer.org> wrote:
> 6.6 PUSH_PROMISE
>
> | Similarly, a receiver MUST treat the receipt of a PUSH_PROMISE that
> | promises an illegal stream identifier (Section 5.1.1) (that is, an
> | identifier for a stream that is not currently in the "idle" state) as
> | a connection error (Section 5.4.1) of type PROTOCOL_ERROR, unless the
> | receiver recently sent a RST_STREAM frame to cancel the associated
> | stream (see Section 5.1).
>
> If recipient is sent RST_STREAM then it goes to "closed" state, not
> to "idle" state.

I think that the "unless..." here offers an option that doesn't make
sense.  The original problem, if I remember correctly, was that there
was a chance that a promise could arrive on a stream that was reset.

We deal with that elsewhere already:

"""
An endpoint might receive a PUSH_PROMISE frame after it sends
RST_STREAM. PUSH_PROMISE causes a stream to become "reserved". The
RST_STREAM does not cancel any promised stream. Therefore, if promised
streams are not desired, a RST_STREAM can be used to close any of
those streams.
"""

Thus, I'm going to remove the "unless..." here and avoid confusion.
While I'm there, I'll clarify that latter statement, because - having
now re-read it - it's a little ambiguous.

Received on Thursday, 19 December 2013 18:20:49 UTC