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

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

From: Martin Thomson <martin.thomson@gmail.com>
Date: Tue, 20 Sep 2016 13:21:45 +1000
Message-ID: <CABkgnnUANKBaRUEbS+xTFUuyB7_60-vJO_7zkj1--ovBtAwG0Q@mail.gmail.com>
To: Tom Bergan <tombergan@chromium.org>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
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 <tombergan@chromium.org> wrote:
> 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 03:22:15 UTC

This archive was generated by hypermail 2.3.1 : Monday, 9 September 2019 17:48:32 UTC