Re: Stream State and PRIORITY Frames

Scott Mitchell <> Thu, 19 January 2017 23:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B640E129462 for <>; Thu, 19 Jan 2017 15:01:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.719
X-Spam-Status: No, score=-9.719 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=-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 8Mwgac83a6Y6 for <>; Thu, 19 Jan 2017 15:01:56 -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 D9AEB128E19 for <>; Thu, 19 Jan 2017 15:01:56 -0800 (PST)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1cULg4-0003Rm-PL for; Thu, 19 Jan 2017 22:59:32 +0000
Resent-Date: Thu, 19 Jan 2017 22:59:32 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1cULg0-0003QB-2a for; Thu, 19 Jan 2017 22:59:28 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <>) id 1cULft-00074Y-OK for; Thu, 19 Jan 2017 22:59:22 +0000
Received: by with SMTP id k86so46688437lfi.0 for <>; Thu, 19 Jan 2017 14:59:01 -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=EjWCt1Y/CesA8X3hIM7BlF1uCR3hbfd9RAqgyOu9nsI=; b=fSN+twuRNX7qT9b85iYwL3th9iKSE0BTrlYee9KeYThMpi8OC/nUJ+PK4uVr59Adjl rhohz3QfPoVgxeApJcjzHGniDLIzMjB6fLXu7z59dMzvZ4WvmRZ7dIBYpR3DIurEzakG lmKoF7qzWPcBl6fUjODoe+85rnlxZdcGb8fW1Uwg1Rr58pvVBzhhf418nEqG0PsLRRjh CIB6FuM+OhOshRHyYHkBi0cnrujFPTAUvqn7JPMzjKf6SzEwhWwru8bOShJqHh3DbOql Gp3YWOL0etd3yl+UyO1lBxvwpdX/vbFrJK2nhQKDwDwYCjZYNuVdZcz/9MEsFQ7F6hFQ Ey1Q==
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=EjWCt1Y/CesA8X3hIM7BlF1uCR3hbfd9RAqgyOu9nsI=; b=raRdp1ZrQUJJN3ItBYWB2L2bUnDf6YX8Mm3lqIrYEoVvITmU5KX+wJKzj1KmybocuH 1hK/wtpEsa5v9QMxnxSExGuZdyJQuya95YUdyxdhvG3QQW8LG5lPJLgqDMGENxERem3i o/HAW0sz92vISLYV0HAtj/XusbwIHX1gHU+L1jR5XSivFyp5k4rl+JhuTheQfKpHaRJ1 xFSFZOTX+1u+HE4ZvLR4XoOJnn/JlyViPx8/DksD5u6Rik1+ItlCrdACSK18US0zGmwl xcHaMjeH41hECR8QozW1UzWNh25OwUQ1Yeb6AfGsdUORKQc1Koh9cOWW3K82/IES8bnc VbdQ==
X-Gm-Message-State: AIkVDXK00/YR4bVJswIRr3hTolwsCnmk02ulWmGi6mGTuxjJJRd6ZEFWuUS2C7sGANW8iqZHYYTKhD/yKObxfg==
X-Received: by with SMTP id 1mr5479628ljg.34.1484866734582; Thu, 19 Jan 2017 14:58:54 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 19 Jan 2017 14:58:53 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
From: Scott Mitchell <>
Date: Thu, 19 Jan 2017 14:58:53 -0800
Message-ID: <>
To: Patrick McManus <>
Cc: Cory Benfield <>, Benedikt Christoph Wolters <>, HTTP Working Group <>
Content-Type: multipart/alternative; boundary="f403045f9f8440f15d05467a7a21"
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-2.5
X-W3C-Scan-Sig: 1cULft-00074Y-OK 1d2d31e3f0ce0cc93c92123aea3ce072
Subject: Re: Stream State and PRIORITY Frames
Archived-At: <>
X-Mailing-List: <> archive/latest/33334
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Thu, Jan 19, 2017 at 7:55 AM, Patrick McManus <>

> On Wed, Jan 18, 2017 at 7:53 PM, Scott Mitchell <>
> wrote:
>> Based on the RFC it seems like stream ids {3, 5, 7, 11} should be closed
>> at step (6). Note that FF is not doing anything wrong here. It shouldn't
>> have to care that the streams are CLOSED in this scenario (assuming these
>> streams only ever have PRIORITY frames exchanged). It would be interesting
>> to get a FF dev to comment on the expected stream state here just to be
>> sure these streams will only be used for PRIORITY.
> Yes, they are grouping nodes and serve no other purpose. I personally
> believe they are in the idle state, but I know some people believe they are
> closed with a priority attached. That doesn't seem to matter in practice.

The state transition I mentioned above is triggered by a HEADERS frame. So
far I have not heard any dispute over this. It seem to be clearly defined
in section 5.1.1 (see below). Do you have a different interpretation of
this section?

The first use of a new stream identifier implicitly closes all streams
in the "idle" state that might have been initiated by that peer with a
lower-valued stream identifier.  For example, if a client sends a
HEADERS frame on stream 7 without ever sending a frame on stream 5,
then stream 5 transitions to the "closed" state when the first frame
for stream 7 is sent or received.

Either way maintaining/interpreting the priority is at the discretion of
>> the server and these streams being closed does not impact the server's
>> ability to do this (as discussed previously the RFC suggests retaining
>> priority for closed streams).
> So yes, and no. Certainly the server is in compliance in just ignoring
> everything it knows about priority indications from the client. OTOH,
> things can get very very screwed performance wise if dependencies are
> disregarded and the state of priority is just determined by the local
> weights on each stream. I've seen servers do this and create terrible
> results.

I'm not suggesting that servers should ignore priority, and I agree this
can be detrimental to page load times and general performance. My point was
meant to clarify the actual behavior of FF since it was used as an example
of "transitioning the stream state would be unexpected". The way FF
currently behaves these streams should be closed because a HEADERS frame is
used anyways.