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

William Chan (陈智昌) <> Tue, 21 May 2013 17:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E920621F97E5 for <>; Tue, 21 May 2013 10:31:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.365
X-Spam-Status: No, score=-9.365 tagged_above=-999 required=5 tests=[AWL=0.311, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jVXaNiTgXwl9 for <>; Tue, 21 May 2013 10:31:43 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5C60021F9794 for <>; Tue, 21 May 2013 10:31:43 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UeqOz-0005v9-FM for; Tue, 21 May 2013 17:31:09 +0000
Resent-Date: Tue, 21 May 2013 17:31:09 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UeqOn-0005u1-Ix for; Tue, 21 May 2013 17:30:57 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1UeqOi-0007lK-UC for; Tue, 21 May 2013 17:30:57 +0000
Received: by with SMTP id bs12so538479qab.12 for <>; Tue, 21 May 2013 10:30:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Zb+lsid4I7H+8vlVxOyqhmFHEamKA8g60SXFfGCiyrs=; b=lR+1CjIpG68X1e0jroyORFYkp3zvT4J6GHMLyYtlcr36Ypgxh9/g78uIpt3KMLjGwm kUUS7WAaBNS6ZGlMbcnn9fLpFuZVOaCXSKzHlwnpK+kgMn19yQHF5rF5auC8cTpI7Fh6 a2LKPcVXP3gnaCEMfoULJV1jDDK9cWGgr+tKw/Rx29yqMWFjvFLGENyqSHZTbiptH02H U5aOMqPT+SyWKtJwdk4sPHf0Spr9wq0Fq7tNPRXaBnZtvRWCzLPLNFpR0d9idW/q/O4I xvvPLoiaBWu9A/8IYK5mdF/At9m/IHs/B17gtPzz3AuMsuCM5YrFE05jmH8uLOeov0Cx htvA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Zb+lsid4I7H+8vlVxOyqhmFHEamKA8g60SXFfGCiyrs=; b=HXwhXczQMIPvyyVibXp3CjjXxGL91ZSR11WvIefku/dnLRdPFB5Bo54XbFRt75Q53I zGaUJEfoiOnDzqK1OYEVClebQCqycZfAZ+agTl4n0pmQ6ujCm7WpvLG87PHHSuI+gp32 CsdcvHYZP9/QfpPX7lQXZwN4jvxiU2P/MKZRY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=Zb+lsid4I7H+8vlVxOyqhmFHEamKA8g60SXFfGCiyrs=; b=Q3VRv/7wr9orvwO62BMp2CyGTVCmMttXvPoM2408HpGYxrqZBHjZ+jG/xl2FertRQ4 x/2oDyLv3DtDiZFKX3V4GUQjGLGIdZ1GItMPWIzUgMVOGmFCJx5kI90S8OgssBzO9R5B FKZLTNpnBZGcqhEziBArKt0gg+jCm11691vbRpNuLihqibfMwrm9WhbK82UTUl3EOVu2 hHDU3WpxMB4if1TAeuSrdnl4jp3N1dHjiPCPALEuklwoX3tuclNWdF+5MrIKE5GUEu1C oNRsQn9lxMKVd6WD+FQMNKswm5qd52cOTUIWvuenU9+pW//NXP8jRAlZwkxZHeA9+2i6 9wZQ==
MIME-Version: 1.0
X-Received: by with SMTP id v7mr3886337qen.10.1369157427036; Tue, 21 May 2013 10:30:27 -0700 (PDT)
Received: by with HTTP; Tue, 21 May 2013 10:30:26 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Tue, 21 May 2013 14:30:26 -0300
X-Google-Sender-Auth: is0n29HVBcSVc4ojPaHBM7RIZ-E
Message-ID: <>
From: =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= <>
To: Patrick McManus <>
Cc: James M Snell <>, "" <>
Content-Type: multipart/alternative; boundary=047d7b6da828149fb804dd3dce85
X-Gm-Message-State: ALoCoQkFwDoBaJmue0+ciWeTskjuLm67kaj8R4ftyS5ESiqsBJt9JP/OKrVSS9egwejohYvB9P64hfiFU7eZVnVwZupdFAmK6SWzQ86G99Ie/o9mtCVS0VAOw+li4cIW70hOXngUmVED637K+/Jx9g0+ukjXhJStCqOInRM9IdMuO734bCFlzGvj2D8MP9UPoD4OoUBpwHCf
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-4.1
X-W3C-Hub-Spam-Report: AWL=-2.184, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.07, SPF_PASS=-0.001
X-W3C-Scan-Sig: 1UeqOi-0007lK-UC 6174cda6b12d6ac573ecd5111bdadb40
Subject: Re: Design Issue: Separate HEADERS and PRIORITY Frames, Eliminate HEADERS+PRIORITY
Archived-At: <>
X-Mailing-List: <> archive/latest/18065
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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.

On Tue, May 21, 2013 at 2:09 PM, Patrick McManus <>wrote;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