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

Lucas Pardue <lucaspardue.24.7@gmail.com> Tue, 09 July 2019 23:06 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F50512009C for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 9 Jul 2019 16:06:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.751
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-8sIzs11Z4a for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 9 Jul 2019 16:06:23 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [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 ietfa.amsl.com (Postfix) with ESMTPS id 6811A120059 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 9 Jul 2019 16:06:23 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1hkz9F-0005Oa-CG for ietf-http-wg-dist@listhub.w3.org; Tue, 09 Jul 2019 23:03:45 +0000
Resent-Date: Tue, 09 Jul 2019 23:03:45 +0000
Resent-Message-Id: <E1hkz9F-0005Oa-CG@frink.w3.org>
Received: from mimas.w3.org ([2603:400a:ffff:804:801e:34:0:4f]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <lucaspardue.24.7@gmail.com>) id 1hkz9D-0005Nk-KP for ietf-http-wg@listhub.w3.org; Tue, 09 Jul 2019 23:03:43 +0000
Received: from mail-vs1-xe2f.google.com ([2607:f8b0:4864:20::e2f]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <lucaspardue.24.7@gmail.com>) id 1hkz9C-00076a-7N for ietf-http-wg@w3.org; Tue, 09 Jul 2019 23:03:43 +0000
Received: by mail-vs1-xe2f.google.com with SMTP id u3so247984vsh.6 for <ietf-http-wg@w3.org>; Tue, 09 Jul 2019 16:03:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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: <63CAE7E1-34E9-42DA-A7DD-1E17223032AE@apple.com>
In-Reply-To: <63CAE7E1-34E9-42DA-A7DD-1E17223032AE@apple.com>
From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Wed, 10 Jul 2019 00:03:11 +0100
Message-ID: <CALGR9oaNnSKp-a8tj+7ojc_g+AhJQ4jF5Z738mjhXhoesfYqLg@mail.gmail.com>
To: Roger Pantos <rpantos@apple.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="00000000000024a42d058d4791d1"
Received-SPF: pass client-ip=2607:f8b0:4864:20::e2f; envelope-from=lucaspardue.24.7@gmail.com; helo=mail-vs1-xe2f.google.com
X-W3C-Hub-Spam-Status: No, score=-2.5
X-W3C-Hub-Spam-Report: AWL=1.340, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1hkz9C-00076a-7N ce14426f2da285b64a6445631a2f80f8
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Specifying Range in Link preload header for HTTP/2 Push?
Archived-At: <https://www.w3.org/mid/CALGR9oaNnSKp-a8tj+7ojc_g+AhJQ4jF5Z738mjhXhoesfYqLg@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/36776
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

Hi Roger,

On Tue, 9 Jul 2019, 21:36 Roger Pantos, <rpantos@apple.com> 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 https://www.w3.org/TR/preload/ 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
interesting.

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.

Cheers
Lucas



>