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

Re: ACTION-63: Expanded HTTP examples

From: Conrad Parker <conrad@metadecks.org>
Date: Mon, 29 Jun 2009 16:39:07 +0900
Message-ID: <dba6c0830906290039l3a40eec1i6e6f35f38bb1b66@mail.gmail.com>
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:


> If my understanding of this situation is incorrect then please explain
> where an invalidation occurs.



>>>>> 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

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