Subject: http2: what is the purpose of the "reserved" states?

From: Tom Bergan <[email-masked]>
Date: Mon, 19 Sep 2016 19:56:34 -0700

What is the purpose of the "reserved" states? A stream transitions into a
"reserved" state after sending or receiving a PUSH_PROMISE (Section 5.1).
However, sending a PUSH_PROMISE seems equivalent in spirit to receiving
HEADERS with END_STREAM. So, why doesn't sending a PUSH_PROMISE transition
directly to "half-closed (remote)"?

AFAICT, there are only two differences between "reserved (local)" and
"half-closed (remote)":

1) A stream in "reserved (local)" cannot send DATA, but a stream in
"half-closed (remote)" can. This means a promised response must start with
HEADERS. But this seems redundant, as this requirement already exists for
all responses. See step #2 in Section 8.1.

2) Section 5.1.2 says that "Streams in either of the reserved states do not
count toward the stream limit [specified by
SETTINGS_MAX_CONCURRENT_STREAMS]." Why? Each endpoint must allocate some
state when sending or receiving a PUSH_PROMISE. It seems like the client
might as well apply its limit when receiving the PUSH_PROMISE rather than
waiting for the first HEADERS. Otherwise, the server can send an arbitrary
number of PUSH_PROMISEs without push back. This same question was asked in
the following mail, but not answered:
https://www.ietf.org/mail-archive/web/httpbisa/current/msg24452.html

Given the above, I believe a conforming implementation could merge
"reserved (local)" into "half-closed (remote)" and "reserved (remote)" into
"half-closed (local)". Does that sound right?

-Tom

---

From: Martin Thomson <[email-masked]>
Date: Tue, 20 Sep 2016 13:21:45 +1000

You correctly identified the key difference, which is that the stream
accounting counts half-closed streams, but not reserved streams.  The
reason we ended up in this state was to avoid hitting limits for
promises.  If you limit server push by applying a stream limit, then
you prevent it from being used in time for the client to use it.

I can theorize that this is all predicated on the notion that headers
are close to free.  This theme is consistent throughout HTTP/2, and
while it's obviously false, it informs much of the design.

On 20 September 2016 at 12:56, Tom Bergan <[email-masked]> wrote:
> Given the above, I believe a conforming implementation could merge "reserved
> (local)" into "half-closed (remote)" and "reserved (remote)" into