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

On Fri, Mar 5, 2010 at 11:36 AM, Conrad Parker <> wrote:
> On 5 March 2010 06:07, Silvia Pfeiffer <> wrote:
>> On Fri, Mar 5, 2010 at 12:11 AM, Conrad Parker <> wrote:
>>> On 4 March 2010 17:14, Silvia Pfeiffer <> wrote:
>>>> On Thu, Mar 4, 2010 at 4:59 PM, Conrad Parker <> wrote:
>>>>> On 4 March 2010 11:55, Silvia Pfeiffer <> wrote:
>>>>>> On Thu, Mar 4, 2010 at 1:14 PM, Conrad Parker <> wrote:
>>>>>>> On 4 March 2010 10:25, Silvia Pfeiffer <> wrote:
>>>>>>>> On Thu, Mar 4, 2010 at 12:00 AM, Silvia Pfeiffer
>>>>>>>> <> wrote:
>>>>>>>>> 2010/3/3 RaphaŽl Troncy <>:
>>>>>>>>>> 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,C

converted to

Foo: track A, track C ?


Received on Friday, 5 March 2010 03:28:44 UTC