Re: ACTION-63: Expanded HTTP examples

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.

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


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

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

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

Received on Monday, 22 June 2009 09:05:45 UTC