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

On 19 December 2013 09:08, Kari Hurtta <> wrote:
> | 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