W3C home > Mailing lists > Public > public-media-fragment@w3.org > September 2010

Re: Media Fragment Question

From: Yves Lafon <ylafon@w3.org>
Date: Tue, 28 Sep 2010 17:06:21 -0400 (EDT)
To: Chris Double <chris.double@double.co.nz>
cc: public-media-fragment@w3.org
Message-ID: <alpine.DEB.1.10.1009281653510.4617@wnl.j3.bet>
On Thu, 1 Jul 2010, Chris Double wrote:

> When a user requests a user agent to make a request with a URL
> containing a media fragment, how should the user agent decide when if
> it needs to send Range headers? For example, the media fragment spec
> shows the request for URL http://www.example.com/video.ogv#t=10,20:
> GET /video.ogv HTTP/1.1
> Host: www.example.com
> Accept: video/*
> Range: t:npt=10-20
> Is it expected that for every URL request with a fragment that matches
> the syntax of media fragments that the user agent will attempt to send
> the Range header? It can't know in advance if a request is for a media
> file. Or does it first make a request, identify it as a media file,
> then does another request with a Range?

Well, the UA have hints, like being the address given in a <video> tag, 
but sending such Range r

> A user agent that does not support a particular media type (eg. a
> browser that doesn't support .ogv) obviously can't play a file. But if
> the page presents a link of the form:
> <a href ='http://example.com/video.ogv#t=10,20>right click me and save</a>
> Is it expected that the user agent, which supports media fragments,
> would send the range requests to ensure only the correct time range is
> saved even if the user agent itself can't play the file? If so, that
> seems to indicate that the Range request needs to be sent on every
> single request made by the user agent which doesn't sound like a good
> idea.

Such use of media fragment would be particulary bad, but in any case, an 
UA should not allow to save a 206 resonse on the disk as if it was the 
complete resource.

> A couple of minor nits:
> 1) "unnecssary" is incorrect spelling in one place.
> 2) "If the server doesn't understand these query parameters, it
> typically ignores them and returns the complete resource. This is not
> a requirement by the URI or the HTTP standard, but the way it is
> typically implemented in Web browsers." Should that be "typically
> implemented in Web servers"?

No, it is not a browser-implementation behaviour, see:
    If a range unit is not understood in a request, a server MUST ignore
    the whole Range header (Section 5.4).  If a range unit is not
    understood in a response, an intermediary SHOULD pass the response to
    the client; a client MUST fail.

> 3) "Wall-clock time codes are a way to address real-world clock time
> that is associated typically with a live video stream. These are the
> same time codes that are being used by ... and by HTML5 HTML 5." Were
> are wall clock time codes with dates used in HTML 5 media?
> 'currentTime' is seconds for example.
> 4) "This section defines the different exchange scenarios for the
> different situations explained in section 3 URI fragment and URI query
> over the HTT?protocol. " That should be "HTTP protocol" I think.
> Chris.

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

Received on Tuesday, 28 September 2010 21:06:24 UTC

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