Re: ACTION-63: Expanded HTTP examples

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.

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

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

>>> 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 Wednesday, 24 June 2009 11:35:53 UTC