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