- From: Conrad Parker <conrad@metadecks.org>
- Date: Thu, 4 Mar 2010 14:59:51 +0900
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Cc: raphael.troncy@eurecom.fr, Media Fragment <public-media-fragment@w3.org>
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. > 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. Conrad.
Received on Thursday, 4 March 2010 06:00:30 UTC