- From: Conrad Parker <conrad@metadecks.org>
- Date: Mon, 13 Apr 2009 03:10:51 +0900
- 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 :-) Conrad.
Received on Sunday, 12 April 2009 18:11:28 UTC