W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

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

From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
Date: Thu, 19 Dec 2013 17:09:16 +0000
To: Martin Thomson <martin.thomson@gmail.com>
CC: Kari Hurtta <hurtta-ietf@elmme-mailer.org>, HTTPBIS working group mailing list <ietf-http-wg@w3.org>
Message-Id: <20131219170841.A15035BC004@smtp6.welho.com>
> 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

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:20 UTC