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

Roger Pantos <rpantos@apple.com> Fri, 12 July 2019 17:01 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 743B2120322 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 12 Jul 2019 10:01:42 -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 ELCE1Ed1AS5i for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 12 Jul 2019 10:01:40 -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 5C9A21202F0 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 12 Jul 2019 10:01:39 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1hlyt1-0000Xk-T7 for ietf-http-wg-dist@listhub.w3.org; Fri, 12 Jul 2019 16:59:07 +0000
Resent-Date: Fri, 12 Jul 2019 16:59:07 +0000
Resent-Message-Id: <E1hlyt1-0000Xk-T7@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 1hlysz-0000Wl-QN for ietf-http-wg@listhub.w3.org; Fri, 12 Jul 2019 16:59:05 +0000
Received: from nwk-aaemail-lapp03.apple.com ([17.151.62.68]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <rpantos@apple.com>) id 1hlysv-0005ol-JD for ietf-http-wg@w3.org; Fri, 12 Jul 2019 16:59:05 +0000
Received: from pps.filterd (nwk-aaemail-lapp03.apple.com [127.0.0.1]) by nwk-aaemail-lapp03.apple.com (8.16.0.27/8.16.0.27) with SMTP id x6CGui3b064050; Fri, 12 Jul 2019 09:58:35 -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=0XDfIblbDofYw4HGYiR4B4tcm2li2LsLSxLb9RoiZoo=; b=kppZiBVbqd6zcUcP0lBSd0zVO4YPxPisOrT9SSWc4s/Fx/5tILgUyzkU8vq8SLcIhLhI QOOIKxuDkpgb6sqTIORW2d3YnyESq9XJdydfjb6TQmWIdWT7gLJx8VRLb+Jo2HAuyL3E BbvOd2Jk3kT5qRFX+MIqTNgTQPH7V9hjHYqXuJw2HYtPwy8fYoI0Xk1HOExZaJMx9bLO awb2ZxOpjTWpsdKg6BZ3PPnzg+rvM1rUECr9KQL6Y3vqXpBQMqgoFhKKinvK9AdNNCE0 aU7D+7W1b1kdv1vjuJ0leuKSaNcp9P22uLPM37118uLBXIkdkkY3hzBlo5Tm30bQkrzj mA==
Received: from ma1-mtap-s03.corp.apple.com (ma1-mtap-s03.corp.apple.com [17.40.76.7]) by nwk-aaemail-lapp03.apple.com with ESMTP id 2tkbvpu4na-4 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 12 Jul 2019 09:58:35 -0700
Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by ma1-mtap-s03.corp.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0PUJ0051TGHMZX10@ma1-mtap-s03.corp.apple.com>; Fri, 12 Jul 2019 09:58:34 -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 <0PUJ00B00GF8C700@nwk-mmpp-sz09.apple.com>; Fri, 12 Jul 2019 09:58:34 -0700 (PDT)
X-Va-A:
X-Va-T-CD: 3c9e60238ff42d5d241adc7c098b7690
X-Va-E-CD: ebec9d363cb3e9032b1aa455ca769df0
X-Va-R-CD: c7d42333b7d05fd8c8092e8412552c6e
X-Va-CD: 0
X-Va-ID: 80411611-965d-4240-86f3-e40367fd8875
X-V-A:
X-V-T-CD: 3c9e60238ff42d5d241adc7c098b7690
X-V-E-CD: ebec9d363cb3e9032b1aa455ca769df0
X-V-R-CD: c7d42333b7d05fd8c8092e8412552c6e
X-V-CD: 0
X-V-ID: 7a1eae53-234a-4625-a21f-d1f18e71191a
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-07-12_04:,, signatures=0
Received: from [17.231.167.18] (unknown [17.231.167.18]) by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0PUJ009GUGHKGA90@nwk-mmpp-sz09.apple.com>; Fri, 12 Jul 2019 09:58:33 -0700 (PDT)
Sender: rpantos@apple.com
From: Roger Pantos <rpantos@apple.com>
Message-id: <D02EDDB2-BF5A-4FB9-9D24-1C125993013F@apple.com>
Content-type: multipart/alternative; boundary="Apple-Mail=_743B4FF3-919A-4C04-8195-E2CF1E9F4C41"
MIME-version: 1.0 (Mac OS X Mail 13.0 \(3566\))
Date: Fri, 12 Jul 2019 09:58:31 -0700
In-reply-to: <B3FACA5B-EF8B-4BD3-B718-18DD2C0AB5D0@mnot.net>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
To: Mark Nottingham <mnot@mnot.net>
References: <63CAE7E1-34E9-42DA-A7DD-1E17223032AE@apple.com> <B3FACA5B-EF8B-4BD3-B718-18DD2C0AB5D0@mnot.net>
X-Mailer: Apple Mail (2.3566)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-12_04:, , signatures=0
Received-SPF: pass client-ip=17.151.62.68; envelope-from=rpantos@apple.com; helo=nwk-aaemail-lapp03.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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1hlysv-0005ol-JD 83eca7705a06c530875fc377d53363aa
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/D02EDDB2-BF5A-4FB9-9D24-1C125993013F@apple.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/36794
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>

Thanks for the guidance, Mark. It sounds like the preload repo is the way to go. I went ahead and created a new issue there: https://github.com/w3c/preload/issues/139


Roger.

> On Jul 10, 2019, at 11:02 PM, Mark Nottingham <mnot@mnot.net> wrote:
> 
> 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:
>  https://mnot.github.io/I-D/link-hint/ <https://mnot.github.io/I-D/link-hint/>
> 
> Cheers,
> 
> 
>> On 10 Jul 2019, at 2:55 am, 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?
>> 
>> 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   https://www.mnot.net/ <https://www.mnot.net/>