Re: Design Issue: PUSH_PROMISE and Stream Priority

James M Snell <> Fri, 26 April 2013 16:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5B5D921F9A09 for <>; Fri, 26 Apr 2013 09:29:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.418
X-Spam-Status: No, score=-10.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jNiXe2Nem1Pt for <>; Fri, 26 Apr 2013 09:29:19 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 11B2B21F9A07 for <>; Fri, 26 Apr 2013 09:29:19 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UVlVU-0001Zf-JS for; Fri, 26 Apr 2013 16:28:20 +0000
Resent-Date: Fri, 26 Apr 2013 16:28:20 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UVlVP-0001Yz-Lp for; Fri, 26 Apr 2013 16:28:15 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1UVlVO-0007Xy-Pn for; Fri, 26 Apr 2013 16:28:15 +0000
Received: by with SMTP id h1so4200653oag.31 for <>; Fri, 26 Apr 2013 09:27:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=tImxpN5GimJnYlkBaSb9/wBfV4kuDuarPPAQdIQWaOc=; b=iuQz+vhUUy8TSTXHRiQJ+AOfrhN78XIWgBhWKuybp5z2lqfEGIjCvXDFtCERI1y7Ch CIKIRDRMMCfSDc24A7xdRHC8xZMenujiOcSeCulU8lS4d9JMWsY013YJbVAdee50cMn2 zLkrj4xmPaB4ScS+un36OP0Wz2IGBcb6CndyuSld87/O3542A1xkPFDnP4VDZZZtFABT 3KjWYRihXUH7MPdMHcyjAp5chNkvJzXpDcICwzS8eIZAtM1/I4rNdGT8Gs9l1LWFCXNB pME9Tq42owTVWa6bfhfX3cw1CIit0rw/Y8mwDs0QrNwt4SqxqoOaomI6pFDjufNatEYD luRA==
X-Received: by with SMTP id rr2mr6353231oeb.35.1366993668873; Fri, 26 Apr 2013 09:27:48 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 26 Apr 2013 09:27:27 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
From: James M Snell <>
Date: Fri, 26 Apr 2013 09:27:27 -0700
Message-ID: <>
To: RUELLAN Herve <>
Cc: Martin Thomson <>, "" <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.699, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: 1UVlVO-0007Xy-Pn b4c0bb198bf537d0a1c0258012417b20
Subject: Re: Design Issue: PUSH_PROMISE and Stream Priority
Archived-At: <>
X-Mailing-List: <> archive/latest/17607
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Ok, there are a couple of issues that have been discussed in this
thread.. let me see if I can summarize the priority issue: The spec
currently states that all Streams can have a priority, but provides no
way for the Server to specify the priority of PUSH_PROMISE streams.
For this there are several possible solutions:

    A. We can simply say PUSH_PROMISE streams have no priority.
    B. We can say that PUSH_PROMISE streams inherit the priority of
their parent, client-initiated stream
    C. We can allow the server to use HEADERS+PRIORITY or a new
Reprioritization Frame to establish the priority of a pushed stream.

For Options B and C, there is an open question about whether and how
an http client would even make use of stream priority.

My recommendation at this point is to go with option A. If, at some
point down the road, someone wants to start experimenting with
prioritized push streams, then more power to them. For now, I just
don't see the justification for it.

- James

On Fri, Apr 26, 2013 at 3:43 AM, RUELLAN Herve
<> wrote:
>> -----Original Message-----
>> From: Martin Thomson []
>> Sent: vendredi 26 avril 2013 02:17
>> To: James M Snell
>> Cc:
>> Subject: Re: Design Issue: PUSH_PROMISE and Stream Priority
> [snip]
>> > Another question: do pushed streams inherit the same priority as their
>> > associated "parent" streams? That is, client initiates a stream #1 to
>> > the server with priority 5, server responds on that stream with two
>> > PUSH_PROMISES for server-initiated streams #2 and #4... do streams #2
>> > and #4 inherit the same priority as stream #1. (Please say no, Please
>> > say no)
>> I'm going to say yes and then make your day even worse by pointing out that
>> RST_STREAM(CANCEL) on stream #1 is expected to terminate all related
>> push streams, even if stream #1 is long gone.  (I'm assuming that one didn't
>> sink in when you read it.)  At least with priority you can copy that state over
>> when you copy over request headers (unless you want reprioritization of the
>> "parent" to also reprioritize pushes, which seems mega-crazy to me).  The
>> push cancellation thing is messy.
> I'm seeing the problem in a slightly different way: in the current usage of SPDY, the client initiates the stream #1 by sending the HEADERS+PRIORITY frame with the FINAL flag set to half close it. Therefore, the client is unable to send a RST_STREAM on stream #1 to terminate the related push streams.
> To take into account server push, the client will want to keep the stream #1 fully open until at least it is half closed by the server. This means that in HTTP/2.0, stream #1 will stay alive much longer.
> Hervé.