Re: Design Issue: Separate HEADERS and PRIORITY Frames, Eliminate HEADERS+PRIORITY

James M Snell <> Tue, 21 May 2013 21:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 261BD21F961F for <>; Tue, 21 May 2013 14:21:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.231
X-Spam-Status: No, score=-9.231 tagged_above=-999 required=5 tests=[AWL=1.068, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ghiz76PKyGtw for <>; Tue, 21 May 2013 14:21:07 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6E31D21F911B for <>; Tue, 21 May 2013 14:21:07 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1Uetz6-0005aW-Dy for; Tue, 21 May 2013 21:20:40 +0000
Resent-Date: Tue, 21 May 2013 21:20:40 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1Uetyv-0005Z6-A6 for; Tue, 21 May 2013 21:20:29 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1Uetyq-00028J-Ov for; Tue, 21 May 2013 21:20:29 +0000
Received: by with SMTP id er7so1378967obc.15 for <>; Tue, 21 May 2013 14:19:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=IBwptt0k9OYZjUUtc5m5OtFH3V2Np/zZU5aB+X6xBVg=; b=nb1n4Yc4m/B4l8qcUeCgVw4fttQ92r4btaEUKQW2gmrUc2iTXljMsUCQgRnlolKEkE ATbBwij5akDSprBVzHstQPHo0pw0O0Fr7dn/RWFUXmnhyh1zAtCSM5Iy2eS+QaoHTJ4D nPWHt6sx11w5JvVC4y/rv7e9pPQadGkEZcEYLBsh0tMg8kI7avUaeFDGMzHkzFVm2KPu zgtgVD0SQCp9Ye4oiKTKIeHCSsrjcZi5bssgSslIjRE3ZBtbDra9i1tJnDXAokqWb3C6 ec/6nXF6Q5eIxOy3qyFOenWPin30fTEtV33nliKCaPqMQbMS9BYSqXiaPBGjeuRaEiEj sU1Q==
X-Received: by with SMTP id ns4mr2813329obb.22.1369171198837; Tue, 21 May 2013 14:19:58 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 21 May 2013 14:19:38 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
From: James M Snell <>
Date: Tue, 21 May 2013 14:19:38 -0700
Message-ID: <>
To: =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= <>
Cc: Patrick McManus <>, "" <>
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.667, 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: 1Uetyq-00028J-Ov 4407315e1065efbbfc923937621ab581
Subject: Re: Design Issue: Separate HEADERS and PRIORITY Frames, Eliminate HEADERS+PRIORITY
Archived-At: <>
X-Mailing-List: <> archive/latest/18071
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Tue, May 21, 2013 at 10:30 AM, William Chan (陈智昌)
<> wrote:
> Thanks for describing these cases now. I had not thought of them.
> If everyone's sold on reprioritization, then let's go ahead and do this and
> have the debate about ditching HEADERS+PRIORITY or not. I want to keep it. I
> don't like the idea of sending a PRIORITY frame first. Is sending a PRIORITY
> frame going to trigger stream state allocation at the receiver? What's the
> expectation? And if you don't have a priority for the HEADERS, then you have
> the race that Roberto described.

There is no reason to assume that sending a PRIORITY frame first would
trigger stream state allocation at the receiver. At most, it would
reserve the stream ID and store the priority value. The full state
allocation would not occur until the HEADERS frame is received. That
said, I'm not 100% dead set on removing HEADERS+PRIORITY, I would just
like to simplify the protocol where it makes sense to, and even then
only after it's been proven out in implementation. Having separate
HEADERS, HEADERS+PRIORITY and PRIORITY frames is confusing, if we can
do without separating them, we ought to do so.

- James

> On Tue, May 21, 2013 at 2:09 PM, Patrick McManus <>
> wrote:
>> On Tue, May 21, 2013 at 12:32 PM, William Chan (陈智昌)
>> <> wrote:
>>> I support adding a new additional PRIORITY frame for stream
>>> reprioritization.
>> me too. Specifically I support this as a mechanism for the client to be
>> able to explicitly prioritize an open pushed stream. I can wait for more
>> evidence about re-prioritizing, but in cases where the client hasn't ever
>> explicitly set the stream's priority I think we have evidence that its time
>> to do something.
>>> Unless there's a reason this needs to be in the current http/2 draft
>>> sooner rather than later, I'd rather punt on this discussion until we have
>>> implementation experience that can guide this debate.
>> I think there is experience here specifically related to push.
>> e.g. You can easily configure mod_spdy to push images when html is pulled.
>> but you can't effectively dictate the relative priorities of those two
>> things.
>> Sure, you can define an explicit priority for those images but priority
>> implementations are all about relative levels and the client set the
>> priority of the html.
>> You can argue that mod_spdy should have defined relative priorities (+/-
>> the associated stream) instead of constants.. that would be better but the
>> client still has no way to make sure those streams are at a higher priority
>> than a "save as" background stream (I've seen this one happen as mod_spdy
>> defaults to lowest priority when pushing), or a lower priority than a
>> real-time video stream..
>> plus there is no scale for the server to work with.. it might set a +2
>> priority for pushed images but the client might be using +3 for pulled
>> images causing a mismatch in something that was intended to be equally
>> weighted.
>> at least with a priority frame the client can make those adjustments in a
>> RTT.
>> Cheefully,
>> -Patrick