W3C home > Mailing lists > Public > public-media-fragment@w3.org > April 2009

Re: Review of section 7

From: Conrad Parker <conrad@metadecks.org>
Date: Mon, 13 Apr 2009 03:10:51 +0900
Message-ID: <dba6c0830904121110t681167fdj734e10329bc9c1eb@mail.gmail.com>
To: Yves Lafon <ylafon@w3.org>
Cc: Media Fragment <public-media-fragment@w3.org>
2009/4/13 Yves Lafon <ylafon@w3.org>:
> On Sun, 12 Apr 2009, Silvia Pfeiffer wrote:
>> * we need to mention that the replies are not cachable for the full
>> resource, but cache only the fragmented resource, which can result in
>> n copies of some subset of the resource in caching web proxies. Since
>> it is typically expected that a fragment request will be used
>> repeatedly (e.g. a fragment URI being shared around), this is
>> potentially acceptable. But we have no experimental data to confirm or
>> deny that this may pose a challenge to caching web proxies.
> Why? it is the case only if the cache can't handle merging timed fragment,
> which is the case of general purposes caches (they will handle only bytes),
> but media procies might be able to do so. Once again, it is not sure that
> they will do that as requesting the whole resource and serve fragments from
> the cache might be more efficient for such caches anyway :)

HTTP/1.1 byte-range caching is a format-agnostic method, and already
specified in an established standard. This WG has already determined
that format-specific media proxy caching is not necessary for at least
Ogg and MP4. If it is necessary for any other formats, we need to
specify in detail what the format developers need to implement.

>>   Example:
>>    GET http://example.com/fragf2f.mp4 HTTP/1.1
>>    Accept: video/*
>>    Range: seconds=12-21
>>    X-Accept-Range-Redirect: bytes
> One thing that I wonder is what happen if the reply is with two Range:
> header, one in bytes, one in seconds.

What is the use-case for both HTTP request headers?

I haven't yet seen a use for Range units other than bytes that does
not cause complications :-)

Received on Sunday, 12 April 2009 18:11:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:42 UTC