Re: Design Issue: PUSH_PROMISE and Stream Priority

Martin Thomson <> Fri, 26 April 2013 00:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5D59321F973F for <>; Thu, 25 Apr 2013 17:18:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ghv1HipiiCkd for <>; Thu, 25 Apr 2013 17:18:57 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 725CE21F9727 for <>; Thu, 25 Apr 2013 17:18:57 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UVWM4-00073H-4F for; Fri, 26 Apr 2013 00:17:36 +0000
Resent-Date: Fri, 26 Apr 2013 00:17:36 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UVWLz-00071Y-LJ for; Fri, 26 Apr 2013 00:17:31 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1UVWLy-0000jL-38 for; Fri, 26 Apr 2013 00:17:31 +0000
Received: by with SMTP id m6so50937wiv.3 for <>; Thu, 25 Apr 2013 17:17:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=01XnMJXFcLCQAL6nu5km/4vQQCCF5TL7iq6tl7hm4S8=; b=FMjgv5iOs8GdZeOt+gPIIVtnuAojEPdaW/JA8mbq6Ne1hIxn4JgCyDyZdPR4YtSr/B VH+xwgDO3bY8qDs2v3LjVV/Ba9GSL34aKWGxiug4eOr5qT16YttDQZnJfTVRy8Va0ZgR Std3Tvknzj9t3H+H9lBF//3sIwGuzvU757d779fHW1pPxz+ciSoZMu0IoHo19zndEzMS 8xusDZ2ZE9xV5tF8oJd8Pbd9Xf1i1W9vBeC5eqj5ZHkksrSOhyYE4AbNuDvUPxSW0WdQ MrBNBq8AQZzadPeLqU+UjcqNXWGvILva0RfTaMe8ozaveDQaQchrpRV++3Oi2g7Ww6Vc txeQ==
MIME-Version: 1.0
X-Received: by with SMTP id gf9mr688997wic.32.1366935423460; Thu, 25 Apr 2013 17:17:03 -0700 (PDT)
Received: by with HTTP; Thu, 25 Apr 2013 17:17:03 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Thu, 25 Apr 2013 17:17:03 -0700
Message-ID: <>
From: Martin Thomson <>
To: James M Snell <>
Cc: "" <>
Content-Type: text/plain; charset=UTF-8
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-4.4
X-W3C-Hub-Spam-Report: AWL=-1.738, BAYES_00=-1.9, 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: 1UVWLy-0000jL-38 7950af6d71c173f43f5c77f395841b8d
Subject: Re: Design Issue: PUSH_PROMISE and Stream Priority
Archived-At: <>
X-Mailing-List: <> archive/latest/17591
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On 25 April 2013 17:03, James M Snell <> wrote:
> A new frame is not required. We already have HEADERS+PRIORITY and
> HEADERS. The PUSH_PROMISE definition states that the promise will be
> followed up by a HEADERS frame, then data frames. If we allow it to be
> HEADERS or HEADERS+PRIORITY then we meet the requirement.
> That said, is there even a need for server pushed streams to specify a
> priority? Do we want to allow servers to dictate priority to the
> client? I can see a number of ways in which a naughty server could
> abuse that privilege.

Having the server tell you priority is fairly pointless.  The client
would need something.  Apparently, the new frame was considered better
than having an otherwise empty HEADERS+PRIORITY.

> 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.