Re: ACTION-63: Expanded HTTP examples

2009/6/22 Yves Lafon <ylafon@w3.org>:
> On Sun, 14 Jun 2009, Conrad Parker wrote:
>
>> Hi,
>>
>> I've added some examples using each part of the HTTP methods
>> (server-parsed fragments, time ranges and range-refer), along with
>> some brief explanations, at:
>>
>> http://www.w3.org/2008/WebVideo/Fragments/wiki/HTTP_Examples
>>
>> It's still fairly bare and I'd like to add more examples, especially
>> outlining what happens when the server doesn't understand a request,
>> or when the UA doesn't understand a response.
>>
>> Please let me know anything that's particularly ambiguous,
>> non-obvious, or plain wrong, so it can be improved before this week's
>> telecon :-)
>
> In "Basic Examples"
> The query URI part is a bit misleading, as using our syntax to identify
> sub-resources like that is just one possibility, so you can't try to infer
> what it is by looking at the URI.

I think it's useful for us to suggest this same syntax. For Annodex we
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.

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

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

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?

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.

Received on Wednesday, 24 June 2009 02:21:37 UTC