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

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?

Thanks for clarifying - it's good to read and understand these things
thoroughly. I was indeed wondering how Microsoft's scheme could work
when they in fact used commas.

Cheers,
Silvia.

Received on Thursday, 4 March 2010 21:08:30 UTC