- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Sat, 6 Mar 2010 08:06:23 +1100
- 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 UTC