Re: Stream State and PRIORITY Frames

Scott Mitchell <> Tue, 17 January 2017 18:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CC32C129424 for <>; Tue, 17 Jan 2017 10:20:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.219
X-Spam-Status: No, score=-10.219 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, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WpBe9tAn81k8 for <>; Tue, 17 Jan 2017 10:19:58 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5AC371293D8 for <>; Tue, 17 Jan 2017 10:19:57 -0800 (PST)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1cTYJY-0001bQ-48 for; Tue, 17 Jan 2017 18:17:00 +0000
Resent-Date: Tue, 17 Jan 2017 18:17:00 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1cTYJP-0001aa-0K for; Tue, 17 Jan 2017 18:16:51 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <>) id 1cTYJI-0006ZI-31 for; Tue, 17 Jan 2017 18:16:45 +0000
Received: by with SMTP id n124so46318631lfd.2 for <>; Tue, 17 Jan 2017 10:16:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6hICEZkv5zxet4+TD19x/w9mPG1q6RcOgs8wmXO3ICU=; b=vSdfqiA6jxdcvqPsC78/MZCwqPi8+fBLI8QvpFqtRsMrsigHWPImaZZSj3L5ru4PiA cFH2Ah+dDnDexDg37inzS7TiKZRUOvYG08/BPo/czizNJSIKlsEjZQy08E2j6TjmOn/5 cdefulp7WDObw8MTuEXMETNJWBweVjVzOehFq+0IVdf+W3MMJDjnY4C29VCzsc8vvfil i43vO1pumyn+e9PBQPfkbRns2uDlMkpI1XHpMucKVnvHwu+lMG5zOkz645ZmRNGYqnsa xrx3aXeT/VCeLuT+Wzw10BHjOP+JdHV1rHT9Tj9gQ/paQxVlfT1SluxK8fBHHNKZo8Uz gZcw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6hICEZkv5zxet4+TD19x/w9mPG1q6RcOgs8wmXO3ICU=; b=eR2bwrVs1KjBtvwBGAzL11Y8InuFoPyGM4Pex1JSvol427WqiwpWODycpVYbXLxX42 iFmWENJvtOhG0uwWWLliX28yywZTzv6Hp4XvDpuysVUFDrTFrf3VjmlGacekSTSs9C9O hAjAn8IpbxHCaUIP6Rp+rC91yMEKmTaU0qED9ACo4A3C4IoaBkN4WFnAEVLhssWeMH63 9LfsyPgGdW0zNcb2yrsNBkJJiwifBKN8Acpkdf+IDU/o89FGQMSt6OQnoorv+mrEvBnY bcQgHCpYzIyyPyLYDLr7VB+OBoWGuABp06UAchSAFkqExKGoAnSRvyGOtkzr1K7AsKH1 NMqA==
X-Gm-Message-State: AIkVDXLukKmyRi8QA+BsYzh3F1pJFa5EhK6AguxO42HfoOrCYny2yitROBb5N/RgqNlO6oorPuRdTW5ggVKQZg==
X-Received: by with SMTP id z10mr12275777lja.9.1484676976728; Tue, 17 Jan 2017 10:16:16 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 17 Jan 2017 10:16:16 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
From: Scott Mitchell <>
Date: Tue, 17 Jan 2017 10:16:16 -0800
Message-ID: <>
To: Cory Benfield <>
Cc: Benedikt Christoph Wolters <>, HTTP Working Group <>
Content-Type: multipart/alternative; boundary="f403045ea29ecddf6505464e4b64"
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-4.1
X-W3C-Scan-Sig: 1cTYJI-0006ZI-31 634bd3f81577f97c7062a6dcc2d4bcf9
Subject: Re: Stream State and PRIORITY Frames
Archived-At: <>
X-Mailing-List: <> archive/latest/33305
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Thanks for responses everyone. There seems to be recognition that the
specification lacks clarity but there also seems to be momentum behind
"Option 1".

This leads to the practical concern of bounding the amount of memory
committed to streams in this state. SETTINGS_MAX_CONCURRENT_STREAMS limits
number of streams in "open" or "half-closed", but the specification doesn't
(to my knowledge) define a way to limit the number of "reserved" streams or
"idle"/"closed" streams which have had only PRIORITY frames exchanged. The
specification allows for implementations to discard PRIORITY more or less
at their discretion [3], but limiting "reserved" streams is another issue. "
SETTINGS_ENABLE_PUSH" is limited to 0 or 1 [4] so there is no way for a
client to advertise how many "reserved" streams it is willing to accept.
What are the practical approaches folks have taken to address these issues?

> The retention of priority information for streams that are not counted
toward the limit set by SETTINGS_MAX_CONCURRENT_STREAMS could create a
large state burden for an endpoint. Therefore, the amount of prioritization
state that is retained MAY be limited.

> The initial value is 1, which indicates that server push is permitted.  Any value other than 0 or 1 MUST be treated as a connection error (Section 5.4.1 <>) of type PROTOCOL_ERROR.

On Tue, Jan 17, 2017 at 4:42 AM, Cory Benfield <> wrote:

> On 17 Jan 2017, at 08:38, Benedikt Christoph Wolters <
>> wrote:
> This question reminds me of a similiar issue we had a while ago at
> mitmproxy:
> As far as I understand this, sending PRIORITY does not initiate a
> stream or change the stream state.
> HEADERS and PUSH_PROMISE initiate a stream. PRIORITY can be sent and
> received in any stream state.
> In fact, I think it’s the same issue. Scott linked to
> summerwind/h2spec/pull/67, which is referenced from and opened by the
> same person who opened, which links
> to, which is related
> to because both cases
> were sites deployed behind Fastly.
> For those who want background and don’t want to follow all those links,
> mitmproxy bumped into problems with sites deployed behind Fastly. mitmproxy
> encountered these because it was forwarding on traffic from Firefox, which
> would on connection-setup send a whole bunch of PRIORITY frames. hyper-h2
> (which powers mitmproxy’s HTTP/2 support) would allow this. h2o would not.
> The crux of the discussion boils down to a few apparently contradictory
> sections in the specification. Scott linked to the first two:
> Section 5.1.1:
> - The first use of a new stream identifier implicitly closes all streams
> in the “idle” state that may have been initiated by that peer with a
> lower-valued stream identifier.
> - An endpoint that receives an unexpected stream identifier must respond
> with a connection error of type PROTOCOL_ERROR.
> *However*, there are a few other notes. The first thing to note is that
> the PRIORITY frame does not transition a stream out of the idle state. A
> stream that has only had PRIORITY frames sent on it is still in the IDLE
> state. That means that the Firefox-style priority setup (sending priority
> for stream IDs 1, 3, 5, and 7 immediate after the preamble) would have the
> effect of immediately closing streams 1, 3, and 5, if section 5.1.1
> applied. This is not what most people expect.
> More importantly, though, section 5.1.1 says this:
> - The identifier of a newly established stream MUST be numerically greater
> than all streams that the initiating endpoint has opened or reserved.
> This governs streams that are opened using a HEADERS frame and streams that
> are reserved using PUSH_PROMISE.
> This is not absolutely clear, but it seems to suggest that implementations
> may establish a stream with an ID lower than streams that have had PRIORITY
> frames sent on them. Put another way, it seems to suggest that only HEADERS
> and PUSH_PROMISE frames affect the lowest-acceptable stream ID. That seems
> to me to suggest that PRIORITY frames are not expected to force-close all
> streams with lower IDs that are in the idle state.
> As an implementers note, I have found it much more helpful to think of
> PRIORITY frames not as frames that are sent on a stream, but as frames that
> are implicitly sent on stream zero and are just tagged with a stream ID.
> PRIORITY frames ignore basically all restrictions on stream behaviour: they
> can be sent on idle streams, on closed streams. In practice, they can
> basically be sent whenever, and except for the case where they establish a
> loop in the priority tree must basically always be accepted.
> Cory