Re: Stream State and PRIORITY Frames

laike9m <> Fri, 20 January 2017 13:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B7FB4129B9E for <>; Fri, 20 Jan 2017 05:26:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.699
X-Spam-Status: No, score=-9.699 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_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id h8wd-bWZahNg for <>; Fri, 20 Jan 2017 05:26:25 -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 9B88B129B9F for <>; Fri, 20 Jan 2017 05:20:52 -0800 (PST)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1cUZ4U-0007b6-Hi for; Fri, 20 Jan 2017 13:17:38 +0000
Resent-Date: Fri, 20 Jan 2017 13:17:38 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1cUZ4R-0007Zd-1V for; Fri, 20 Jan 2017 13:17:35 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <>) id 1cUZ4K-0001gi-ST for; Fri, 20 Jan 2017 13:17:29 +0000
Received: by with SMTP id r185so20050041ita.0 for <>; Fri, 20 Jan 2017 05:17:08 -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=Mj9UgXS/WygwaLwLBlN0O7tfm06nfyn70UQloUe2hmQ=; b=PttvEffYxvq7wMUAwEtrAo0fZ7i1687+iee/cmwF349JcMFy4MrV17x87qPlZ+B6U5 HNz5l6B+hGSdTVSpqtCsj8lAw8NvY3GknTMPsUdgLlpkbcYjQop7AP2fL/OeS2uQjJas 2OdLvavWMt2XmDkI9HqcaguAadn2eCkded7AbgFzIui6klSQixISW4yXBapv0PfSoLg3 Dg02xgkWbTZ0A1W3eFS8P/3NN5G7JxxcAlXKKYVPjq6LsLSJcIZVHpOOXdNppbVqrSkL ADH+KW6baP2UEmQaV5mdFR5b9fJYO0we1AqIpJMvym4QjENOcUnK0KfzBbm/FmlmoSY7 Rzvw==
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=Mj9UgXS/WygwaLwLBlN0O7tfm06nfyn70UQloUe2hmQ=; b=pSioK3EX4zQxUFTIpDL/4j4QTDDnt3lWmDi3mtOpNmgu+EAhiad+NkFZAX4bwLBp1+ ZaWOYW7gdf5LNP4J8VYZRZNlG9SceNqnF2Y67BRGX1jdfwhnXNLPLPjx8lH+ytJJ+t2N NU32CcLKQQznu9GNmmPEEulGl59jjeqbvHPtCD7ZlhxymHP9x+8Dtz3I7CJTcb07DvX9 JmZV0zYDCS3D6vOO1L/ivD8GRXVfSG5aSxlTcHWXdIrLgrm3w0+fjkWEPESAaeqkX+ji A1Vab3sPMjujuG5/Oy4oinxlJmoRKbII05MMhXXb6T+qSlIAABU46nnPOWSb7Q1wFBmX P//Q==
X-Gm-Message-State: AIkVDXIr+ImNB8gT/KLw9kZMnNMulnfdv3lAj2PkDX+khhkOf0AVV4cenJPIYfiR9bbu8nE8pHvjR45cFIawAQ==
X-Received: by with SMTP id y30mr3293051ita.119.1484918222837; Fri, 20 Jan 2017 05:17:02 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Fri, 20 Jan 2017 05:17:02 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <>
From: laike9m <>
Date: Fri, 20 Jan 2017 21:17:02 +0800
Message-ID: <>
To: Scott Mitchell <>
Cc: Martin Thomson <>, Tatsuhiro Tsujikawa <>, HTTP Working Group <>
Content-Type: multipart/alternative; boundary="001a11c149143161130546867757"
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.2
X-W3C-Scan-Sig: 1cUZ4K-0001gi-ST 50b9b2a0a9cf2606957a2ae1af330d68
Subject: Re: Stream State and PRIORITY Frames
Archived-At: <>
X-Mailing-List: <> archive/latest/33343
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

If you don’t include RESERVED streams in the count for
SETTINGS_MAX_CONCURRENT_STREAMS then how do you limit the amount of
RESERVED streams, and how does your peer know about this limit? I have
imposed an implementation specific metric in the past, but this seems less
preferable than relying on something in the RFC that the peer is aware of.
Either way having infinite of something doesn’t work in practice.

As Martin has explained, H2 doesn’t limit the amount of RESERVED streams,
based on the notion that HEADERS are close to free. It’s true that one
trying to send infinite number of PUSH_PROMISEs to client can cause
problems, but 1. This only happens if the server is malicious, and if it’s
malicious, having a limit in the RFC won’t prevent anything, and 2. Not
counting PUSH_PROMISEs is a tradeoff for fast delivery of PUSH_PROMISEs,
which stops client from sending more requests. I guess this is what Martin
meant by “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.”

(Forgot to reply to all :P)

On Thu, Jan 19, 2017 at 9:21 AM, Scott Mitchell <>

> On Tue, Jan 17, 2017 at 2:43 PM, Scott Mitchell <>
> wrote:
>> From my perspective I would like to see two clarifications:
>> 1. It is clear to me that PRIORITY doesn't impact state.
> Just to clarify ... it is clear that a PRIORITY frame doesn't impact the
> state of the stream  it is carrying priority information for. The impacts
> PRIORITY frames have on other streams is not clear due to the wording in
> section 5.1.1.
>> However Section 5.1.1 states "first use of a new stream identifier"
>> which makes no reference to stream state. If stream state is
>> important/implied here better to be specific about it. I don't think the
>> one-off example below this text is sufficient to convey the intended
>> implications of this statement.
>> 2. Section 5.1.2 states "Streams in either of the 'reserved' states do
>> not count toward the stream limit." which seems to conflict with section
>> 8.2.2 "A client can use the SETTINGS_MAX_CONCURRENT_STREAMS setting to
>> limit the number of responses that can be concurrently pushed by a
>> server.". These two statements appear to contradict each other. Since
>> SETTINGS_MAX_CONCURRENT_STREAMS is really the only mechanism to limit
>> resources due to server push I'm assuming section 5.1.2 is overly
>> restrictive.
>> On Tue, Jan 17, 2017 at 2:27 PM, Martin Thomson <
>> > wrote:
>>> On 18 January 2017 at 01:37, Tatsuhiro Tsujikawa <>
>>> wrote:
>>> > If my understanding is correct, this only refers to the new stream ID
>>> used
>>> > by HEADERS, and PUSH_PROMISE frames which open or reserve streams.  The
>>> > example text following that statement uses HEADERS which opens new
>>> stream.
>>> > PRIORITY frame does not change stream state, and there is no reason to
>>> close
>>> > all unused streams lower than bearing stream ID.  That said, I agree
>>> that
>>> > this is not crystal clear in the document.  In practice, this is
>>> probably
>>> > rather rare case.
>>> This is, I think, the expectation.
>>> I think that we probably want to clarify the point by explicitly
>>> saying that PRIORITY doesn't affect stream states.  We say that it can
>>> be sent in any state, but we don't also mention that important point.
>>> Do people here agree that an erratum on this point is appropriate
>>> here?