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

Tom Bergan <> Tue, 20 September 2016 03:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BFA9312B161 for <>; Mon, 19 Sep 2016 20:01:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.836
X-Spam-Status: No, score=-8.836 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-2.316, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fKpaldgYXU0v for <>; Mon, 19 Sep 2016 20:01:36 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E9B6B127071 for <>; Mon, 19 Sep 2016 20:01:35 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1bmBFD-0003JD-1K for; Tue, 20 Sep 2016 02:57:15 +0000
Resent-Date: Tue, 20 Sep 2016 02:57:15 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1bmBF6-0003Fv-Ch for; Tue, 20 Sep 2016 02:57:08 +0000
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1bmBEz-0000IP-Te for; Tue, 20 Sep 2016 02:57:07 +0000
Received: by with SMTP id r145so7144752ior.0 for <>; Mon, 19 Sep 2016 19:56:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:from:date:message-id:subject:to; bh=4VfUEMPuYFbbN6u1fSSAmiQX4cjEixTE4WKuKd7TjZk=; b=LdJNvB2vrucn0zDYAfgcnC1haj5E6nLVR61SrQSUUPfdska4djIW6pQqonWXXtC6I6 sXSdi6LViAEPRCESEU5crxDZpC6Luj6j3UOxYIA3VFTU2dv0O3g5mV8vs3iLJPDzcPMG 8EyV8VhAGjJ839Y7LywT19CYcc9X8SxtccYZw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=4VfUEMPuYFbbN6u1fSSAmiQX4cjEixTE4WKuKd7TjZk=; b=fqDCNDvnk+ddvGXpn0OtpkRniTtWtOZo1XtqfJvO3iuVKm3XBuoxXH60cwBP+fZzbG boAB1fTwtQ5LlOjfdAh86qTLH24P8+DfqwQzyj84iA93lzdq5G6nU5sgzpPMsUl7ikza UE8Fah7VTIVe3d4COj5dDkwVJ5nO1CnjWG9+LP9cA5B0RGE8amHm6tqDnhIkMLgn0bGW VQ9Vr/TVj3OFi1j1NxJZs0TzNyA9xdnb4/f6dgGSMRLpM+SsgaHa1bgGDRn4zbu/yl64 d6Ybv28WJXjuvOwFAunHKSn22QPErtINWhPOkKcgy/ckDYYkjC6NjKpjUN7v+MAJHMDe YjZg==
X-Gm-Message-State: AE9vXwN8YLbpsHQK1UT9RhYI854hnAzptWfiwR+lvHZob8fkkkiMtalRWU/4eekMp2nXJ9f+
X-Received: by with SMTP id j80mr39626343ioe.27.1474340195590; Mon, 19 Sep 2016 19:56:35 -0700 (PDT)
Received: from ( []) by with ESMTPSA id g78sm9319825itb.12.2016. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Sep 2016 19:56:35 -0700 (PDT)
Received: by with SMTP id q92so7090094ioi.1 for <>; Mon, 19 Sep 2016 19:56:34 -0700 (PDT)
X-Received: by with SMTP id j22mr39475746iod.2.1474340194593; Mon, 19 Sep 2016 19:56:34 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 19 Sep 2016 19:56:34 -0700 (PDT)
From: Tom Bergan <>
Date: Mon, 19 Sep 2016 19:56:34 -0700
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: HTTP Working Group <>
Content-Type: multipart/alternative; boundary=001a113f993e94055b053ce79303
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-5.2
X-W3C-Hub-Spam-Report: AWL=-1.010, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1bmBEz-0000IP-Te 9a52b24bd7bdcb555dcce9056118064c
Subject: http2: what is the purpose of the "reserved" states?
Archived-At: <>
X-Mailing-List: <> archive/latest/32414
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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:

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?