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

Patrick McManus <> Tue, 21 May 2013 17:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D8A5921F968F for <>; Tue, 21 May 2013 10:10:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.367
X-Spam-Status: No, score=-9.367 tagged_above=-999 required=5 tests=[AWL=0.309, 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 5lARg-uAnF-c for <>; Tue, 21 May 2013 10:10:52 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B018321F961C for <>; Tue, 21 May 2013 10:10:44 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1Ueq4P-0006tx-FG for; Tue, 21 May 2013 17:09:53 +0000
Resent-Date: Tue, 21 May 2013 17:09:53 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1Ueq4D-0006re-Pj for; Tue, 21 May 2013 17:09:41 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1Ueq4B-0006gz-Tx for; Tue, 21 May 2013 17:09:41 +0000
Received: by with SMTP id o6so1156414oag.16 for <>; Tue, 21 May 2013 10:09:13 -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=9aAeqnDNAI34hbaKhfobHiJwEanrcd8kqTITI1nZkQ4=; b=0gLdlMGa8n8+i9ebonig2QKsJD6eUF27+cY4fEwxuASaHGI42NTW0WkaH+qaNpa9Yp AVgwK5XW3laM5/2GcLm1yuWpq37Snlh+C1d9ZoSfOtdz/mt3/KPvUXiiySid2BTHm0F+ UP5dlR6TG7IGmZkCIbSZR6JyFanQpNyeeXXXrkhEoaPuZDe2nzJFndPM29XfnL8qM31T ccVvY8uBVGBtIBPuePDL4UYCMaqea2bvOC5aFtS/Wc+h22XKxOyAiTlttU7HNS4Ufhq5 0zFuaYI16G73J2g0YxCyBnGGZf//1jbzcCZq1obnPtboLKqw5AjylE4H//67k44Hgfcp dr1Q==
MIME-Version: 1.0
X-Received: by with SMTP id k9mr2081780oeq.30.1369156153679; Tue, 21 May 2013 10:09:13 -0700 (PDT)
Received: by with HTTP; Tue, 21 May 2013 10:09:13 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Tue, 21 May 2013 13:09:13 -0400
X-Google-Sender-Auth: GQZpOsT79F66ihRfGVF6ahPWUUg
Message-ID: <>
From: Patrick McManus <>
To: =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= <>
Cc: James M Snell <>, "" <>
Content-Type: multipart/alternative; boundary=089e0118299e2eb0db04dd3d8204
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.3
X-W3C-Hub-Spam-Report: AWL=-2.564, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: 1Ueq4B-0006gz-Tx 39bb6966315f6b29d770d3c5e068759d
Subject: Re: Design Issue: Separate HEADERS and PRIORITY Frames, Eliminate HEADERS+PRIORITY
Archived-At: <>
X-Mailing-List: <> archive/latest/18061
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Tue, May 21, 2013 at 12:32 PM, William Chan (陈智昌)

> 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

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

at least with a priority frame the client can make those adjustments in a