IETF Logo Mail Archive

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

Roger Pantos <rpantos@apple.com> Fri, 12 July 2019 18:54 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 75CD912091B for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 12 Jul 2019 11:54:57 -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, DKIMWL_WL_HIGH=-0.001, 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 RKvHFYDRW1Wg for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 12 Jul 2019 11:54:55 -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 1308F120912 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 12 Jul 2019 11:54:54 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1hm0ed-0000F7-Su for ietf-http-wg-dist@listhub.w3.org; Fri, 12 Jul 2019 18:52:23 +0000
Resent-Date: Fri, 12 Jul 2019 18:52:23 +0000
Resent-Message-Id: <E1hm0ed-0000F7-Su@frink.w3.org>
Received: from titan.w3.org ([2603:400a:ffff:804:801e:34:0:4c]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <rpantos@apple.com>) id 1hm0ec-0000EM-1b for ietf-http-wg@listhub.w3.org; Fri, 12 Jul 2019 18:52:22 +0000
Received: from nwk-aaemail-lapp02.apple.com ([17.151.62.67]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <rpantos@apple.com>) id 1hm0ea-0000Pt-EH for ietf-http-wg@w3.org; Fri, 12 Jul 2019 18:52:21 +0000
Received: from pps.filterd (nwk-aaemail-lapp02.apple.com [127.0.0.1]) by nwk-aaemail-lapp02.apple.com (8.16.0.27/8.16.0.27) with SMTP id x6CIpeRM041031; Fri, 12 Jul 2019 11:51:56 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=baaRD6JVEJij6rlL5SCLLoWm741AiL8QfxQPWx7GtFk=; b=wRzJCKx46Smmg07TenuBvKCYvFli808YiruX3HHPDuNqj2E3ie3RhCwahJFjYoP5uykC 1rDw+iGx8nbhZDcq1+k8I7Q/trCH5RAG53ME8YKKssILGyQ9sGfPhjAlwMl0GeFiBuEu SwyO6UUr0l0LkJw+urNf1LORWaWoV2ABfUspKjO7N7DP4ZkPTGrM8x10TgbT3hNXYnXK E8m55btLh9N9tF4KCAsI3cvXMDm+wrC8SZaRiWGdvh8WbetKASjd7sQzyMaYCZm/JIGs k0iUan/tkFDbs8I4Bld3AlxVkfEynXhGFWsx1shGFSTB9s9POmU3kQzqSbIrkKmrdl4g UA==
Received: from ma1-mtap-s02.corp.apple.com (ma1-mtap-s02.corp.apple.com [17.40.76.6]) by nwk-aaemail-lapp02.apple.com with ESMTP id 2tph32q64h-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 12 Jul 2019 11:51:56 -0700
Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by ma1-mtap-s02.corp.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0PUJ002DMLQGP550@ma1-mtap-s02.corp.apple.com>; Fri, 12 Jul 2019 11:51:54 -0700 (PDT)
Received: from process_milters-daemon.nwk-mmpp-sz09.apple.com by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0PUJ00B00LQ3KY00@nwk-mmpp-sz09.apple.com>; Fri, 12 Jul 2019 11:51:54 -0700 (PDT)
X-Va-A:
X-Va-T-CD: 81dad03cb0384fe51ee1837649d582d6
X-Va-E-CD: ebec9d363cb3e9032b1aa455ca769df0
X-Va-R-CD: c7d42333b7d05fd8c8092e8412552c6e
X-Va-CD: 0
X-Va-ID: f38402f8-db7c-4ac6-aa7a-dcb1b293f85d
X-V-A:
X-V-T-CD: 81dad03cb0384fe51ee1837649d582d6
X-V-E-CD: ebec9d363cb3e9032b1aa455ca769df0
X-V-R-CD: c7d42333b7d05fd8c8092e8412552c6e
X-V-CD: 0
X-V-ID: 1ae51d1f-6f21-4045-b1ed-4c3b2a1393ee
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-07-12_05:,, signatures=0
Received: from mesquite.apple.com (mesquite.apple.com [17.194.77.14]) by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0PUJ00FEELPWD6B0@nwk-mmpp-sz09.apple.com>; Fri, 12 Jul 2019 11:51:33 -0700 (PDT)
Sender: rpantos@apple.com
From: Roger Pantos <rpantos@apple.com>
Message-id: <660C795D-330E-41CA-9819-C221CF8C6A37@apple.com>
Content-type: multipart/alternative; boundary="Apple-Mail=_33856B7C-5E8F-4CBA-A892-FCBB3B23836B"
MIME-version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Fri, 12 Jul 2019 11:51:32 -0700
In-reply-to: <06f5a4ad-099a-87a8-9e26-ccc5132b963c@gmx.de>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
To: Julian Reschke <julian.reschke@gmx.de>
References: <63CAE7E1-34E9-42DA-A7DD-1E17223032AE@apple.com> <06f5a4ad-099a-87a8-9e26-ccc5132b963c@gmx.de>
X-Mailer: Apple Mail (2.3445.104.11)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-12_05:, , signatures=0
Received-SPF: pass client-ip=17.151.62.67; envelope-from=rpantos@apple.com; helo=nwk-aaemail-lapp02.apple.com
X-W3C-Hub-Spam-Status: No, score=-4.1
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1hm0ea-0000Pt-EH cb053664c8443cbac9db14e7da10e7e7
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/660C795D-330E-41CA-9819-C221CF8C6A37@apple.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/36796
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>


> On Jul 12, 2019, at 10:30 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
> 
> On 09.07.2019 18:55, 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 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?
>> 
>> 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
>> ...
> 
> Nitpicking: if you do this, please consider range units other than
> "bytes".  For instance, by embedding the range unit name into the parameter:
> 
> Link: </media.mp4>; rel=preload; as=video; type=video/mp4;
> range-bytes=1380-14226

Good point. Thanks Julian.


Roger.

v2.23.0 | Report a Bug | By Email