On Tue, 9 Mar 2010, Silvia Pfeiffer wrote: > While I do not quite understand Conrad's use case, I agree partially > (and maybe fully) with the objection to that resolution. > > I think we can continue using "Range" as the request header from the > client for all of the dimensions we are talking about (Range on bytes, > t, track and id). > > But, I do not believe we can use "Content-Range" as the reply header > for any of the dimensions bar bytes. This is why we introduced > "Content-Range-Equivalent". You have video foo ---------------------------------------- | H | data | ---------------------------------------- s 0 10 20 60 b 0 8192 16384 32768 65536 (for seconds and byte scales) Why? Look at the example: GET /foo HTTP/1.1 Host: www.example.com Range: t:npt 10-20 You get back this: HTTP/1.1 206 blah Content-Range: t:npt=10-20/60 Content-Range-Equivalent: bytes=16384-32768/65536 But what you get is really a playable video, with a synthetic header So the data is -------------------------- | HS | | -------------------------- s 0 10 b 4096 20480 So if you reply with Content-Range in byte, it won't work because of the presence of the synthetic header, and the fact that it can't match the original data stream. What is interesting is to save the 16k chunk sent back and map it to the byte range, so that client asking for byte ranges after that will get what it needs. Sending back more data than expected, or a byte ranges with byte that can't correspond to the original byte stream can't work with old proxies. > > Incidentally, I have a few more questions on that resolution: > * why are we using comma as a separator for track HTTP headers? > * also note that the spatial dimension can be resolved on the client > as in Davy's demo rather than sending anything to the server. > > Cheers, > Silvia. > > -- Baroula que barouleras, au tiéu toujou t'entourneras. ~~YvesReceived on Tuesday, 9 March 2010 08:48:31 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 21 September 2011 12:13:38 GMT