- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Thu, 4 Mar 2010 19:14:10 +1100
- To: Conrad Parker <conrad@metadecks.org>
- Cc: raphael.troncy@eurecom.fr, Media Fragment <public-media-fragment@w3.org>
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. >> 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 08:15:02 UTC