- From: Conrad Parker <conrad@metadecks.org>
- Date: Sat, 27 Jun 2009 17:13:33 +0900
- To: Yves Lafon <ylafon@w3.org>
- Cc: Media Fragment <public-media-fragment@w3.org>
2009/6/24 Yves Lafon <ylafon@w3.org>: > On Wed, 24 Jun 2009, Conrad Parker wrote: > >> 2009/6/24 Yves Lafon <ylafon@w3.org> >>>> >>>> simply had the server include a response header acknowledging that >>>> this URI accepts time specifiers, which then allows the UA to >>>> construct such URIs for navigation. >>> >>> Well, that's the trick, you can't allow the UA to craft URIs in the wild >>> and expect the server will understand it. At best you hit a server >>> configuration bug that make the server ignore what's after the '?' instead >>> of getting a 404, but that's relying on bugs. >> >> Precisely, the UA should only craft such URIs if the server explicitly >> says that it is ok to do so. > > IMHO, UAs should _never_ craft URIs, only follow existing ones. Nevertheless UAs (including applications using XMLHttpRequest) will do exactly that, so it is within the scope of this WG, for both query and fragment cases. >> Of course the UA gets to such a URI in the first place by following a >> link from content, which is no problem. >> >>>>> The use of 'Fragment:' in 1.2 is interesting, but there is something >>>>> missing. The response must have a Vary: Fragment in it, otherwise a >>>>> cache >>>>> would store/serve the wrong bits for two requests with different >>>>> Fragment >>>>> header. (You don't have this issue with Range/Content-Range, as caches >>>>> already know how to handle the presence of those headers). >>>>> >>>>> However, in Track+Time Fragment URI, the need of Vary: Fragment is also >>>>> there. (and I am wondering if for the 'track' axis, servers should be >>>>> advised to send a Content-Location with the URI of the resource served, >>>>> as >>>>> crafting URI for a subresource of the original one for track would be >>>>> easy >>>>> and useful.) >>>> >>>> Thanks, I've added Vary headers to the examples and to >>>> http://www.w3.org/2008/WebVideo/Fragments/wiki/Server-parsed_Fragments >>>> >>>>> In "Query URI + Range-Refer: bytes" (3.1) there is a big issue >>>>> Basically, the request is done on a subresource URI identifying just >>>>> the >>>>> subresource without any link to the "original" one. >>>>> The response is 200 OK, meaning that we got a representation of that >>>>> URI, >>>>> which seems not entirely true, as it seems to trigger a redirect >>>>> mechanism. >>>>> (the example is not clear in saying that the returned bytes in the >>>>> first >>>>> request is only a crafted 'control' part of the resource.) >>>> >>>> perhaps the response should be a different code. >>>> >>>> I'll clarify that the returned bytes are the same as what would have >>>> otherwise been served if the client didn't offer Accept-Range-Refer. >>> >>> Hum, the bytes retrieved on the resource are the control ones, so it >>> changes for each fragment request, si no the returned bytes are not what >>> would have been served without the accept-range-referer. >> >> For "Query URI + Range-Refer: bytes", the URI is different if a >> different time is requested. Hence if a different time is requested, >> requiring a different control section, it is requested from a >> different resource. > > Yes, but it's not the case for fragment URIs. Query URIs have their own > issues :) Please point out specific issues for discussion. >>>>> In the other examples, the request is sent on video.ogv then only the >>>>> control bytes are returned, then the content bytes on the same URI. >>>>> Note >>>>> that each time control bytes are sent, it will invalidate the stored >>>>> 'content' bytes in the caches, so defeating the use of caches. >>>> >>>> For the "Fragment + Range-Refer: bytes" examples the cache is not >>>> invalidated as the Fragment requested is different. I've added a note >>>> clarifying this. >>> >>> Well, all the control sections are served from a single URI, the one used >>> also for the whole content, no? In that case the control bytes invalidate >>> the content (unless the example was incorrect and the same URI was not what >>> was meant to server the control sections and the content). >> >> The idea is that the same or a different URI could be used, depending >> on the implementation. A simple server might just use the same URI, a >> distributed hosting environment might choose from many. >> >> If the same URI is used, perhaps the response to the second request >> (for the non-control data) also needs to include "Vary: Fragment". > > Well, even if a Vary is there, the actual data will never be cached then > served, as an invalidation will always get in the way. In the first request the fragment text is converted to an HTTP request header, and that header is marked as a variant. The second request also marks that header as a variant. Normal rules for caching negotiated HTTP responses follow, including caching of byte ranges. If my understanding of this situation is incorrect then please explain where an invalidation occurs. cheers, Conrad. >>>> The "Range-Refer: time" examples are wrong, we should discuss more how >>>> time ranges are supposed to work with caching ... >>>> >>>>> That's why >>>>> having a Link: header indicating the URI of a "mapper" URI able to act >>>>> as in >>>>> 3.1 but with a proper redirect mechanism, or using a mime multipart >>>>> with the >>>>> control bytes, then the URI and information of the content bytes would >>>>> be >>>>> better. >>>> >>>> I like the Link: header as it is informative, but can you give more >>>> detail about how the mapper URI should work? >>> >>> If we specify a specific relationship, like "mediafrag-byte-resolver" we >>> can lean on a std way of calling it. So the Link: would... link to such URI >>> in charge of sending the control bytes and indication on compressed content. >> >> ok, that would be interesting to specify. >> >> Conrad. >> >>> >>>> >>>> Regarding control bytes: the examples I've given are based on .ogv, >>>> where the control bytes are modified headers. The idea with >>>> Range-Refer is to allow arbitrary pieces to be stitched together, eg. >>>> to append tailer data. >>>> >>>> So if mime multipart was to be used, then we'd need to specify whether >>>> each part was a block of content or a reference. >>>> >>>> thanks for the feedback :) >>>> >>>> Conrad. >>>> >>> >>> -- >>> Baroula que barouleras, au tiéu toujou t'entourneras. >>> >>> ~~Yves >>> >> > > -- > Baroula que barouleras, au tiéu toujou t'entourneras. > > ~~Yves > >
Received on Saturday, 27 June 2009 08:14:14 UTC