- From: Conrad Parker <conrad@metadecks.org>
- Date: Mon, 29 Jun 2009 16:39:07 +0900
- To: Yves Lafon <ylafon@w3.org>
- Cc: Media Fragment <public-media-fragment@w3.org>
2009/6/27 Conrad Parker <conrad@metadecks.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. Thinking about this more, Accept-Range-Refer is also negotiated so I've added that to the Vary headers in the examples, and to: http://www.w3.org/2008/WebVideo/Fragments/wiki/HTTP_Range_Refer#Headers > 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 Monday, 29 June 2009 07:39:49 UTC