Subject: Stream state and PUSH_PROMISE

From: Hadil Sabbagh <[email-masked]>
Date: Mon, 10 Jul 2017 16:37:48 -0700

What is the state of the stream when a PUSH_PROMISE is sent or received when the stream is in the OPEN state?

Thanks,
Hadil G. Sabbagh, Ph. D.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 11 Jul 2017 10:14:50 +1000

> What is the state of the stream when a PUSH_PROMISE is sent or received when the stream is in the OPEN state?

Which stream is open, the stream on which the PUSH_PROMISE is sent, or
the one that is promised?

The latter case is interesting because that means that you are
sending/receiving two PUSH_PROMISE frames that promise the same stream
(and the first one has been acted upon already).  That's an error,
according to the following text from Section 5.1:

> In the absence of more specific guidance elsewhere in this document, implementations SHOULD treat the receipt of a frame that is not expressly permitted in the description of a state as a connection error (Section 5.4.1) of type PROTOCOL_ERROR.

---

From: Hadil Sabbagh <[email-masked]>
Date: Mon, 10 Jul 2017 17:56:12 -0700

Hi Martin:

I am interested in the case where an open stream receives a PUSH_PROMISE on that stream with another stream id to be used. The RFC, as best I read it, does not specify that it goes into a half-open local/remote or any other state for the promised stream. 

Thanks,

Hadil G. Sabbagh, Ph. D.

> On Jul 10, 2017, at 5:14 PM, Martin Thomson <[email-masked]> wrote:
>

---

From: Martin Thomson <[email-masked]>
Date: Tue, 11 Jul 2017 11:03:25 +1000

> I am interested in the case where an open stream receives a PUSH_PROMISE on that stream with another stream id to be used. The RFC, as best I read it, does not specify that it goes into a half-open…

When you send PUSH_PROMISE, there are two streams:

1. The stream that carries the PUSH_PROMISE is a client-initiated
stream, one where the client made a request.  That stream will always
be open or half-open when the PUSH_PROMISE is sent/received.  That
stream doesn't change state as a result of the PUSH_PROMISE.

2. The promised stream is a server-initiated stream.  That stream will
always be idle when the PUSH_PROMISE is sent/received.  The promised
stream then becomes "reserved" when the PUSH_PROMISE is send/received.

Does that help?

---

From: Hadil Sabbagh <[email-masked]>
Date: Mon, 10 Jul 2017 18:04:31 -0700

Thank you Martin. That clears it up for me.

Hadil

> On Jul 10, 2017, at 6:03 PM, Martin Thomson <[email-masked]> wrote:
>