- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Mon, 14 Dec 2009 14:15:08 +1100
- To: Yves Lafon <ylafon@w3.org>
- Cc: Raphaël Troncy <Raphael.Troncy@cwi.nl>, Media Fragment <public-media-fragment@w3.org>
Hi all, I've gone through this thread and included what I learnt into the current spec. Am about to send a final email with the changes I have made, but want to reply to this thread now. 2009/12/3 Yves Lafon <ylafon@w3.org>: > On Wed, 2 Dec 2009, Raphaël Troncy wrote: > >> 2) Case 2: Resolving URI fragments in a proxy cachable manner >> ------------------------------------------------------------- >> >> Context: see Section 3.4 [2]. >> We have a fully media fragment conformant user agent and wish to make sure >> fragments will be cached by the network >> User request: >> http://www.w3.org/2008/WebVideo/Fragments/media/fragf2f.mp4#t=12,21 >> >> * 2.1: Current proposal: >> The following HTTP request will be generated. >> GET /2008/WebVideo/Fragments/media/fragf2f.mp4 HTTP/1.1 >> Host: www.w3.org >> Accept: video/* >> Range: time:npt=12-21 >> X-Accept-Range-Redirect: bytes >> >> --> We introduce the 'X-Accept-Range-Redirect' header >> >> The following HTTP response is returned (200 code) >> HTTP/1.1 200 OK >> Accept-Ranges: bytes >> Content-Type: video/mp4 >> X-Accept-TimeURI: npt, smpte-25 >> X-Range-Redirect: bytes 1113724-2082711/4500000 >> Vary: X-Accept-Range-Redirect >> Location: http://www.w3.org/2008/WebVideo/Fragments/media/fragf2f.mp4 > > First: s/X-//. Dropped the "X-" from the currently new proposed headers. > Also your reply is a 200 but what is sent back (the empty body Raphael > refers to)? What would a UA or a cache do with that? > > It might be better to send back a 307, redirecting to itself, but I am > wondering what a cache would do if there is already something cached (in > bytes, as if it's cached in the time range, it can serve it directly). > > Another way would be to do conneg with a mime type > application/time-range-resolver and send back the info in the body with a > Vary: accept (but would it trash an already cached entry in the cache?) I'm using 307 for now with a redirect to self. It's not a content negotiation in itself that we're doing, so conneg didn't seem to apply - (though it's an interesting idea to provide media fragment resolvers that are not the server itself). >> --> We introduce the 'X-Range-Redirect' header to tell the UA to issue >> another request >> --> I don't like the 'X-Accept-TimeURI' header that could be more generic >> --> Do we have an empty body at this step? >> >> Another HTTP request is issued >> GET /2008/WebVideo/Fragments/media/fragf2f.mp4 HTTP/1.1 >> Host: www.w3.org >> Range: bytes 1113724-2082711 >> >> Triggering the following response (206 code) >> HTTP/1.1 206 Partial Content >> Accept-Ranges: bytes >> Content-Type: video/mp4 >> Content-Range: bytes 1113724-2082711/4500000 >> >> --> I don't understand how the cache can now map the bytes range with the >> original request in seconds? > > Well, in that case the request is in bytes only. However we miss the > information about the real time range it identifies, most probably not > exactly the requested "time:npt=12-21", so we need to convey that > information back in the first reply. I've added an extra Content-Range header for that - need to discuss in the next meeting if that is too much information overload on one header. Cheers, Silvia.
Received on Monday, 14 December 2009 03:16:08 UTC