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

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



>

Received on Tuesday, 9 July 2019 23:03:43 UTC