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

[Mark Nottingham <[e-mail]>]

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/

Cheers,


> On 10 Jul 2019, at 2:55 am, Roger Pantos <[e-mail]> 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/