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: Sat, 6 Mar 2010 08:06:23 +1100
Message-ID: <2c0e02831003051306o16472e06v3bd1811919d5d73d@mail.gmail.com>
To: Yves Lafon <ylafon@w3.org>
Cc: RaphaŽl Troncy <raphael.troncy@eurecom.fr>, Conrad Parker <conrad@metadecks.org>, Media Fragment <public-media-fragment@w3.org>
2010/3/6 Yves Lafon <ylafon@w3.org>:
> On Thu, 4 Mar 2010, RaphaŽl Troncy wrote:
>
>>> 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?
>
> Section 4.2 says that it is allowed only if the syntax of the headers allows
> it, however:
>
> http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-08#section-5.2
> <<
> † Unlike byte-ranges-specifier values (see Section 5.4.1), a byte-
> † range-resp-spec MUST only specify one range, and MUST contain
> † absolute byte positions for both the first and last byte of the
> † range.
>>>
> Plus the grammar does not allow comma separated lists.

Well, it doesn't allow it for byte ranges. It says nothing about what
to do with other types of ranges. We're talking here about the track
range. But I guess it's already pretty much decided that we introduce
a different header for this.

Cheers,
Silvia.
Received on Friday, 5 March 2010 21:07:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 21 September 2011 12:13:38 GMT