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

Re: The problem of having multiple Content-Range headers in HTTP response

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Thu, 4 Mar 2010 00:00:42 +1100
Message-ID: <2c0e02831003030500ibd5538el592c70f1ea55b36f@mail.gmail.com>
To: raphael.troncy@eurecom.fr
Cc: Media Fragment <public-media-fragment@w3.org>
2010/3/3 RaphaŽl Troncy <raphael.troncy@cwi.nl>:
> Dear all,
> There has been a bit of (private) discussion between Silvia, Yves, Davy and
> myself, but it should actually be discussed here so I'm bringing the
> discussion on this mailing list.
> Context: The following media fragment has been made up:
> http://example.com/video.ogv#t=25,100&track='audio', i.e. I want to retrieve
> only the 'audio' track of the media resource 'video.ogv' between the
> temporal interval [25s, 100s]. Further, I have as assumption that the UA
> cannot do the mapping between this fragment and a byte ranges by itself so
> it needs some server help (see also section 5.2.2 [1]).
> The request might be something like:
> †GET /video.ogv HTTP/1.1
> †Host: www.example.com
> †Accept: video/*
> †Range: t:npt=25-100&track='audio'
> While we thought the answer could be:
> †HTTP/1.1 206 Partial Content
> †Accept-Ranges: bytes, t, track
> †Content-Length: 3743
> †Content-Type: video/ogg
> †Content-Range: bytes 19147-22880/35614993
> †Content-Range: t:npt 24.85-100.34/653.791
> †Content-Range: track audio/653.791
> †{ binary data }
> Problem: according to some preliminary investigations from Yves, we cannot
> have multiple Content-Range in a response :-(

I don't think that was the problem. The problem is that the
Content-Range headers cannot be regarded as describing each other, but
only as being additional requirements on each other. Thus, in this
instance, the receiver would consider three different conditions on
the Content-Range, when, in fact, the bytes would be sufficient by

> Which means that the example
> described in the spec at [1] is *wrong*. We MUST correct it at the F2F
> meeting.
> As alternatives, Yves proposed this:
> †Content-Range : bytes 19147-22880/35614993
> †Content-Range-Equivalent: { {t:npt 24.85-100.34/653.791} {track
> audio/653.791} }
> with the introduction of a new header Content-Range-Equivalent.
> Which is more or less similar to Conrad's proposal:
> †Content-Range : bytes 19147-22880/35614993
> †Fragment: { {t:npt 24.85-100.34/653.791} {track audio/653.791} }
> with the introduction of the header Fragment.
> But another possibility is to use:
> †Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
> ... and write the multiple byte ranges
> Q: can they overlap?

The multipart byteranges solution is orthogonal to the
Content-Range-Equivalent header proposal. It is a solution for how to
deliver multiple byte ranges. It will work well with the proposed
Content-Range-Equivalent header.

> Another problem is how should we express that when 2 tracks have been
> requested?

The background here is that using a comma as in track=audio,subtitle
will not work in the HTTP headers, since the comma is used to separate
headers from each other. As such, something like:
    Content-Range: track audio,subtitle/653.791
would be parsed to
    Content-Range: track audio
    Content-Range: subtitle/653.791
which is obviously incorrect.

Received on Wednesday, 3 March 2010 13:01:34 UTC

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