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: Fri, 5 Mar 2010 12:30:06 +0900
Message-ID: <dba6c0831003041930k1c6fe2f1j1dba105a1aa4b39b@mail.gmail.com>
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Cc: raphael.troncy@eurecom.fr, Media Fragment <public-media-fragment@w3.org>
On 5 March 2010 12:27, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:
> On Fri, Mar 5, 2010 at 11:36 AM, Conrad Parker <conrad@metadecks.org> wrote:
>> On 5 March 2010 06:07, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:
>>> On Fri, Mar 5, 2010 at 12:11 AM, Conrad Parker <conrad@metadecks.org> wrote:
>>>> 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.
>>>>
>>>
>>> So if I understand you correctly, you'd also suggest using something
>>> else than a comma to separate the list of tracks in a track fragment
>>> URI?
>>
>> If you want to express that the content contains tracks A and C, using
>> header Foo, then you could say:
>>
>> Foo: track A, track C
>>
>> but not:
>>
>> Foo: tracks A,C
>>
>> If you really wanted that form then you would have to replace the
>> comma with something else.
>>
>> On the other hand, perhaps the first form is more flexible; an
>> application (say. some simple CGI script) that adds subtitle track C
>> could simply add the "Foo: track C" header.
>>
>> Conrad.
>>
>
> So it would be
>
> http://www.example.com/video.ogv#track=A,C
>
> converted to
>
> Foo: track A, track C ?

yup, something like that :)

Conrad.
Received on Friday, 5 March 2010 03:30:43 GMT

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