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

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.

Conrad.

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