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 19:14:10 +1100
Message-ID: <2c0e02831003040014x24a8e18bw33b5d15df8a10198@mail.gmail.com>
To: Conrad Parker <conrad@metadecks.org>
Cc: raphael.troncy@eurecom.fr, Media Fragment <public-media-fragment@w3.org>
On Thu, Mar 4, 2010 at 4:59 PM, Conrad Parker <conrad@metadecks.org> wrote:
> On 4 March 2010 11:55, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:
>> On Thu, Mar 4, 2010 at 1:14 PM, Conrad Parker <conrad@metadecks.org> wrote:
>>> 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.
>>>
>>
>> I am not even sure that comma thing actually works in this way.
>>
>
> RFC2616, Section 4.2 Message Headers:
>
> Multiple message-header fields with the same field-name MAY be present
> in a message if and only if the entire field-value for that header
> field is defined as a comma-separated list [i.e., #(values)]. It MUST
> be possible to combine the multiple header fields into one
> "field-name: field-value" pair, without changing the semantics of the
> message, by appending each subsequent field-value to the first, each
> separated by a comma. The order in which header fields with the same
> field-name are received is therefore significant to the interpretation
> of the combined field value, and thus a proxy MUST NOT change the
> order of these field values when a message is forwarded.

Ah thanks. I wasn't able to find this. I wonder if this implies that a
proxy can split a field-value at a comma as it likes.


>> BTW: what the above was supposed to mean was:
>> take tracks "audio" and "subtitle" - so the split out Content-Range
>> header doesn't really signify that any longer, right?
>
> oh, you mean that the comma is in the argument to track? right, that
> is silly. It should be something like "track audio, track subtitle" if
> you want to be able to combine headers.

Yes, that's what I meant. What you propose is much easier to split,
but then I'm not sure we wanted to allow more than one track
name-value in a fragment URI.

Cheers,
Silvia.
Received on Thursday, 4 March 2010 08:15:02 GMT

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