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: Conrad Parker <conrad@metadecks.org>
Date: Thu, 4 Mar 2010 11:14:51 +0900
Message-ID: <dba6c0831003031814s62c6675fvdb820fb33ba14968@mail.gmail.com>
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Cc: raphael.troncy@eurecom.fr, Media Fragment <public-media-fragment@w3.org>
On 4 March 2010 10:25, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:
> On Thu, Mar 4, 2010 at 12:00 AM, Silvia Pfeiffer
> <silviapfeiffer1@gmail.com> wrote:
>> 2010/3/3 RaphaŽl Troncy <raphael.troncy@cwi.nl>:
>>
>>> 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.

why?

the comma thing is not about "will be parsed to", but "is equivalent
to". So, an application could add the two headers in order:

Content-Range: track audio
Content-Range: subtitle/653.791

and this pair would be equivalent to, and could be merged by an
intermediary proxy into,:

Content-Range: track audio, subtitle/653.791

So the comma thing is more about allowing the infrastructure to be
more flexible (ie. different parts of an application stack can append
headers without rewriting existing ones) while still being cacheable
(the two header representations are equivalent).

Conrad.
Received on Thursday, 4 March 2010 02:15:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 21 September 2011 12:13:38 GMT