W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2016

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

From: Tom Bergan <tombergan@chromium.org>
Date: Mon, 19 Sep 2016 19:56:34 -0700
Message-ID: <CA+3+x5H79mPO6zXTanA5uRML1UQrnfeJaAmG_EONZJkj1ZmetQ@mail.gmail.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
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
Received on Tuesday, 20 September 2016 02:57:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 September 2016 02:57:10 UTC