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 22:11:20 +0900
Message-ID: <dba6c0831003040511n4b978ea0t29a3b0b75c39ee9a@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 17:14, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:
> 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.

no, as far as I understand it only the other way (combining) can be
done automatically.

This is becaues it's possible to define a header that does use comma
for something else, but in that case it's not allowed to have more
than one instance of that field -- ie. if you violate the "if and only
if" requirement of the paragraph I posted above. I think it's best to
avoid that when defining new headers, so that we allow the combining
behavior etc. In particular for our case we are defining a kind of
list, and the standard comma mechanism is useful.

Conrad.

>
>
>>> 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 13:11:54 GMT

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