Re: Specifying Range in Link preload header for HTTP/2 Push?

Mark Nottingham <> Thu, 11 July 2019 06:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 36A2E1200EF for <>; Wed, 10 Jul 2019 23:05:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.751
X-Spam-Status: No, score=-2.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=Jj3yEfSX; dkim=pass (2048-bit key) header.b=POsfFqZg
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jIgRBEcCuEvW for <>; Wed, 10 Jul 2019 23:05:18 -0700 (PDT)
Received: from ( [IPv6:2603:400a:ffff:804:801e:34:0:38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7028B12008B for <>; Wed, 10 Jul 2019 23:05:18 -0700 (PDT)
Received: from lists by with local (Exim 4.89) (envelope-from <>) id 1hlSAD-0005up-Ij for; Thu, 11 Jul 2019 06:02:41 +0000
Resent-Date: Thu, 11 Jul 2019 06:02:41 +0000
Resent-Message-Id: <>
Received: from ([2603:400a:ffff:804:801e:34:0:4f]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <>) id 1hlSAB-0005tt-MK for; Thu, 11 Jul 2019 06:02:39 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <>) id 1hlSAA-0004oh-4y for; Thu, 11 Jul 2019 06:02:39 +0000
Received: from compute3.internal (compute3.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 1FBA821E92; Thu, 11 Jul 2019 02:02:16 -0400 (EDT)
Received: from mailfrontend2 ([]) by compute3.internal (MEProxy); Thu, 11 Jul 2019 02:02:16 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=8 vnpB/zHPL/6IyPisUH3AYl2HF22v4jdcOi7rKq2DkY=; b=Jj3yEfSX+gw8zfSJm aKKi0gEgzr423s70jGA4ojF/0pnfmt9rPjVras5gMdzFLxqSPZr+UC3RUXhW6DvN 3PympwKHdxKl/IJLYPgcmu/caokJjeowt/+NtxHK9HoKN9rtFIrr1U4UJxaHOHVL KSqERAAT22D+dluu5hxUJKZ4xCJeupReF3LEwDLF4iHy5X3NGQkL301IY220oueY ol4+kOGTLudUTjhgOQXMt30ACUN8imaWV+8/nhMHF+Q1PFcEj3kmXRmeyMpWHcpb HtAw/AmNOCQT3trK0hYWxA+QlGRU0qP/bnoknFsuWVjj4e8Boz7hkca2QkVvIegh zVckw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=8vnpB/zHPL/6IyPisUH3AYl2HF22v4jdcOi7rKq2D kY=; b=POsfFqZgBpua5Z2mSP1r1w8KfazvFY8O/o0OGNHVf5YE9WL+ryJuFC3sx gm6RHZnYsnFC1KESOAahd5lA9T7vhvztq5ZZYoe+/y27uqK9T6PjveS6BHOcsHZZ 4ZkYFcszuy+YTFuBYpWjVGIrM7gbRuAAZPUVTLW8ZKY0XQPxQV0DLb1xSkFlxuDU PhXhZP7T1oIWRIGYQ/7Ksdq+/cMory5ZKvyU7lfOyTWX5szWH6YL1zVY5fY3OQeZ iWrWRhN8KG+dKB4VQk39ka+s2MtiYc4OOxBui3OU7SYWkw68G/NBf72dZEXME+ON iidkt4pXWjES6OQlcTpCvbQuXKXiA==
X-ME-Sender: <xms:59AmXWCqPM7WECOPSZA_RBl3qa_bwNt_21ICwuXQmeWMUar05pwgjQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrgeejgddutdduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne goufhushhpvggtthffohhmrghinhculdegledmnecujfgurheptggguffhjgffgffkfhfv ofesthhqmhdthhdtjeenucfhrhhomhepofgrrhhkucfpohhtthhinhhghhgrmhcuoehmnh hothesmhhnohhtrdhnvghtqeenucffohhmrghinhepfiefrdhorhhgpdhgihhthhhusgdr ihhopdhmnhhothdrnhgvthdphhhtthhpvdhpuhhshhhofhhrrghnghgvrhgvqhhuvghsth hsfhhorhhmvgguihgrshhtrhgvrghmihhnghdrihhtnecukfhppedugeegrddufeeirddu jeehrddvkeenucfrrghrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvth enucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:59AmXUzAi0Kjj6gDyPdM-ygfMeS1c_JZsHuCXhHbVKkLdDJlzLQn2A> <xmx:59AmXUkVANSQG6em1sg_6xtC3rbqzDrXKVmwlh_Eh4otzFBxbgi8LA> <xmx:59AmXZGvc1NQTaHsUNKzGKlgCGRG3p3_T-xR_xamGY2dWwGi8Ploww> <xmx:6NAmXbCqZmgZ9e-sH7HFPMAnx4uZAWOLOT94Ve9D7TWzGeS6cjI3BA>
Received: from (unknown []) by (Postfix) with ESMTPA id E3458380083; Thu, 11 Jul 2019 02:02:13 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Mark Nottingham <>
In-Reply-To: <>
Date: Thu, 11 Jul 2019 16:02:10 +1000
Cc: "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Roger Pantos <>
X-Mailer: Apple Mail (2.3445.104.11)
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-6.2
X-W3C-Hub-Spam-Report: AWL=3.593, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: 1hlSAA-0004oh-4y d126e00f9a7cdb7b67d152f10c7a9462
Subject: Re: Specifying Range in Link preload header for HTTP/2 Push?
Archived-At: <>
X-Mailing-List: <> archive/latest/36788
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Hi Roger,

The philosophy of RFC8288 (which obsoleted 5988) is that individual link relation types are responsible for defining what the appropriate / meaningful set of target attributes is. So, in this case, "preload" would need to define it; as Yoav pointed out, the right place to talk about that is the preload repo and the Web Performance WG in the W3C.

We have previously talked about common parameters that are useful for more than one link relation type, but they still need to be "opted into." A while back I wrote down a starter collection of these, it might be good to dust them off and consider adding something like this. See:


> On 10 Jul 2019, at 2:55 am, Roger Pantos <> wrote:
> Greetings HTTP experts,
> I’m interested in employing HTTP/2 Push of Range requests for media streaming. It seems like the core h2 protocol handles this well enough; the PUSH_PROMISE can contain a Range header, and at the very least if that ends up in the client push cache then a request for that exact Range should match.
> That being said, I’d also like to signal the push request to downstream HTTP caches. Push is typically signaled via the Link header with rel=preload, but doesn’t seem to define signaling and associated Range.
> Has anyone defined a Link extension to signal an associated Range?
> If not, would anyone object to the following Link extension?
> range-link-extension = “range” = ranges-specifier
> where ranges-specifier is defined in RFC 2616.
> An example would be:
> Link: </media.mp4>; rel=preload; as=video; type=video/mp4; range=1380-14226

Mark Nottingham