- From: Craig Pratt <craig@ecaspia.com>
- Date: Wed, 20 Apr 2016 14:08:00 -0700
- To: ietf-http-wg@w3.org
Reply in-line. cp On 4/20/16 1:14 PM, Matthew Kerwin wrote: > > > On 21/04/2016 5:37 AM, "Thorsten Lohmar" <thorsten.lohmar@ericsson.com > <mailto:thorsten.lohmar@ericsson.com>> wrote: > > > > Hi Craig, > > > > > What *is* missing is the ability to get a continuous byte range on > live content > > > that starts at an arbitrary offset and the ability to directly > jump to the live > > > point. > > > > Yes, and there are two solutions to the issue: > > A. Enable it on HTTP Layer through the definition of a new range > request method > > B. Enable working with existing HTTP procedures, i.e. client can > workout the precise byte offsets. > > C. Use a different URL (e.g. a ?start= query parameter). It's less > optimal for caching, but it works today without any new specs. > [cp] We can't use a different URI in our application (the UPnP CDS and DLNA RUIH guidelines only one URI per resource). [cp] We can define a custom header. But (a) it appears that the feature we're describing has been requested many times over, (b) at least having an RFC enables caches to be implemented. Using a custom header or URI will require caching to be disabled by the origin server. [cp] One point I haven't mentioned about caching with bytes-live: Since the bytes-live Range Unit is designed to work in concert with the bytes Range Unit (not superceded it), caching can still be performed by proxies that don't understand bytes-live. The read-through and hit ratio will be reduced. But there's still opportunities to cache. > > > > > BR, > > /Thorsten > > > > Cheers > -- craig pratt Caspia Consulting craig@ecaspia.com 503.746.8008
Received on Wednesday, 20 April 2016 21:08:32 UTC