W3C home > Mailing lists > Public > public-media-fragment@w3.org > March 2010

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

From: Conrad Parker <conrad@metadecks.org>
Date: Sat, 6 Mar 2010 09:51:01 +0900
Message-ID: <dba6c0831003051651oad44638oc0e34308e358ba0f@mail.gmail.com>
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Cc: Yves Lafon <ylafon@w3.org>, raphael.troncy@eurecom.fr, Media Fragment <public-media-fragment@w3.org>
On 6 March 2010 06:14, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:
> On Sat, Mar 6, 2010 at 2:50 AM, Yves Lafon <ylafon@w3.org> wrote:
>> On Fri, 5 Mar 2010, Silvia Pfeiffer wrote:
>>> Thanks for clarifying - it's good to read and understand these things
>>> thoroughly. I was indeed wondering how Microsoft's scheme could work
>>> when they in fact used commas.
>> Btw "Cookie" is using a comma even if it is not permitted by the spec,
>> requiring special handling and caring by proxies to be sure that there is no
>> folding or split of that specific header.
> You're talking about the Cookie/Set-Cookie header? Surely there are
> many more other headers that have commas. Do only those that the
> proxies have to deal with create a problem with commas?
> Also, I wonder if Microsoft's Content-Range: rows
> (http://msdn.microsoft.com/en-us/library/ee159574%28EXCHG.80%29.aspx)
> has a similar problem.
> Maybe then we shouldn't even use comma as a separator at all, even in
> the URL? We might as well go straight to semicolon or some other
> separator, then we can keep the syntax the same between URL and HTTP
> headers and don't have to transform it, e.g.
> http://example.com/video.ogv#track=subtitle;audio
> =>  Content-Range: track subtitle;audio
> and
>      Content-Range-Equivalent: track subtitle;audio
> What do people think?

yep, I was about to suggest the same thing :) it is less error-prone
if apps can basically copy and paste (perhaps with some url
encode/decode or whatever) rather than have to parse it structurally
and generate new strings.

Received on Saturday, 6 March 2010 00:51:34 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:44 UTC