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

Lucas Pardue <> Tue, 09 July 2019 23:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8F50512009C for <>; Tue, 9 Jul 2019 16:06:25 -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, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Q-8sIzs11Z4a for <>; Tue, 9 Jul 2019 16:06:23 -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 6811A120059 for <>; Tue, 9 Jul 2019 16:06:23 -0700 (PDT)
Received: from lists by with local (Exim 4.89) (envelope-from <>) id 1hkz9F-0005Oa-CG for; Tue, 09 Jul 2019 23:03:45 +0000
Resent-Date: Tue, 09 Jul 2019 23:03:45 +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 1hkz9D-0005Nk-KP for; Tue, 09 Jul 2019 23:03:43 +0000
Received: from ([2607:f8b0:4864:20::e2f]) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <>) id 1hkz9C-00076a-7N for; Tue, 09 Jul 2019 23:03:43 +0000
Received: by with SMTP id u3so247984vsh.6 for <>; Tue, 09 Jul 2019 16:03:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nlG2HVymevqZdFmc4zSSJSO3nTapqN/ZxCZ458kM53w=; b=SPvvB22hVJKWkV/LWnZkkZdID2J3N8+OKSWYbjHRVYneWkyaU4wsiHQv5XjLXjMfzh vQlgzoDS2lWxomfnBX1ruNmJ0vhBYpdpYM3bKkfeTCHDbi3nw/wxETz8+YbdanGwzPyH n+dQWsJ/6qW7pSMKZvENqsTe60yRkCyad0wT9PWsxVU4zsgN8eLhMb/faC1KWG9sMxjS f7iJEA1nOmGMmn0Sykq4Vm5tTSWm09NrtKNgKO37JhJvRnnUXJT9E4HFWlqX7RE7/O8C IjQZjPwFkxVjhWmeiToFsVj5iPwKFUxfhu+ucehEOFdnma3hhOykJN83hVM1zIPJ13OA MJ2g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nlG2HVymevqZdFmc4zSSJSO3nTapqN/ZxCZ458kM53w=; b=lAfe0rgowg8RfbPxORrLIwD5MlHRYAkqgGxydhRu4mmFEB/nXZ7Q3lkO+JttG84NsI JfAR9Lx0g154vZT9m6NuwRNCr9ZUFvSzqd0SDvR8Y8sYzrqB9trNq3/t/GumPsQ2XrtQ gVgWFcHPBzmMi0rgU8lU9d02W3NTO4EjxxbQ8fvCEJsp0yoKD3xuYc6z/95yT9VXXfIA SKXp3i92txKBtoDFzutwPDmSEUxx/H7FxBAkqBNiSWILlaHFKMOXto21PnGnXxA1SUr/ Oel1tOm8zRJi2eb4rkU2m8hClfCSu7SOuemlPJdG2Brd0btsEqTG+wKZ/pk93eCkoUzX OZOQ==
X-Gm-Message-State: APjAAAUX92FxwA7i5bnaWIVw97jb69NHQT/5GZGPmMJe9AWYigbeRg+p mBDvBPsSyQ98YAC5QlUBhjMvG2G2pThZSSoh6PA=
X-Google-Smtp-Source: APXvYqzFjg4oY/GnbB4zESlH4Sm46owzkvIaZjxKcn7NKb0nrhu14wg5jCckV0U/9R1VQ6QEBcXrtjL1PFsL/hvkr9o=
X-Received: by 2002:a67:d58a:: with SMTP id m10mr16215275vsj.15.1562713400844; Tue, 09 Jul 2019 16:03:20 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Lucas Pardue <>
Date: Wed, 10 Jul 2019 00:03:11 +0100
Message-ID: <>
To: Roger Pantos <>
Cc: HTTP Working Group <>
Content-Type: multipart/alternative; boundary="00000000000024a42d058d4791d1"
Received-SPF: pass client-ip=2607:f8b0:4864:20::e2f;;
X-W3C-Hub-Spam-Status: No, score=-2.5
X-W3C-Scan-Sig: 1hkz9C-00076a-7N ce14426f2da285b64a6445631a2f80f8
Subject: Re: Specifying Range in Link preload header for HTTP/2 Push?
Archived-At: <>
X-Mailing-List: <> archive/latest/36776
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Hi Roger,

On Tue, 9 Jul 2019, 21:36 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?

I've spoken informally to some people on related topics. I presume this is
related to Apple's LHLS? Or in lay speak, one approach to low-latency
HTTP-based streaming. It'd be great to have a reference to cite when
talking around the topic.

> 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
> thanks,
> Roger Pantos
> Apple Inc.

The general impression I've observed is that such a range signal in Link
would be useful to a number of services, and that there would be benefit in
adopting a common signal.

Furthermore, while the use of server push might have debatable benefits for
the web browsing use case. I'm led to believe that it has affirmative uses
in this streaming model. Again, some evidential data would be really

Finally, server push and caching is an interesting area that might benefit
from some more information. Some of the WG might be interested in how this
gets implemented in your use case.