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: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Thu, 4 Mar 2010 20:22:38 +1100
Message-ID: <2c0e02831003040122y6e571dddue34d8e6d8ff38c22@mail.gmail.com>
To: RaphaŽl Troncy <raphael.troncy@eurecom.fr>
Cc: Conrad Parker <conrad@metadecks.org>, Media Fragment <public-media-fragment@w3.org>
2010/3/4 RaphaŽl Troncy <raphael.troncy@eurecom.fr>:
>> 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
> My understanding was: this is invalid since we cannot have multiple
> Content-Range headers in a response. Now, you just verbatim in another email
> a paragraph from RFC2616 (Section 4.2 Message Headers) that seems to say
> that this is *valid*. So I'm now confused.
> Yves, could you please provide us a pointer that reference your original
> claim?

I don't think there is a contradiction any longer with what Conrad posted.

There is only one Content-Range header, but it can be split over
several Content-Range header fields and recombined by adding a comma.
We just cannot use several Content-Range headers for different things,
such as in the current spec with it being used to also signify what
the original ranges were.

So, I think all we have to do is change the field names and we have to
make sure we find a better separator than a comma for lists of tracks.

I volunteer to make the change on the field name (seeing as I
introduced the problem).

Received on Thursday, 4 March 2010 09:23:31 UTC

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