- From: Conrad Parker <conrad@metadecks.org>
- Date: Thu, 4 Mar 2010 22:11:20 +0900
- 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 UTC