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

> Yes, you are correct.
> 
> https://github.com/http2/http2-spec/commit/3d0b6449425b7b7f1c0314136d323f9c019d913a

Possible other.

http://http2.github.io/http2-spec/#PUSH_PROMISE

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.

So I do not understand why there is "unless the receiver recently sent a
RST_STREAM frame to cancel the associated stream (see Section 5.1)."

http://http2.github.io/http2-spec/#RST_STREAM

6.4 RST_STREAM

| The RST_STREAM frame fully terminates the referenced stream and causes
| it to enter the closed state. 

And there is also:

| RST_STREAM frames MUST NOT be sent for a stream in the "idle" state.
| If a RST_STREAM frame identifying an idle stream is received, the
| recipient MUST treat this as a connection error (Section 5.4.1) of
| type PROTOCOL_ERROR.

So that associated stream can not have be on "idle" state either 
before recipient of PUSH_PROMISE was sent RST_STREAM.

What I have missing ?

/ Kari Hurtta

Received on Thursday, 19 December 2013 18:44:47 UTC