- From: Roger Pantos <rpantos@apple.com>
- Date: Fri, 12 Jul 2019 11:51:32 -0700
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
- Message-id: <660C795D-330E-41CA-9819-C221CF8C6A37@apple.com>
> 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.
Received on Friday, 12 July 2019 18:52:22 UTC