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

On 3 mrt 2010, at 13:48, Raphaël Troncy wrote:

> Problem: according to some preliminary investigations from Yves, we cannot have multiple Content-Range in a response :-( Which means that the example described in the spec at [1] is *wrong*. We MUST correct it at the F2F meeting.
> 
> As alternatives, Yves proposed this:
>  Content-Range : bytes 19147-22880/35614993
>  Content-Range-Equivalent: { {t:npt 24.85-100.34/653.791} {track audio/653.791} }
> with the introduction of a new header Content-Range-Equivalent.
> 
> Which is more or less similar to Conrad's proposal:
>  Content-Range : bytes 19147-22880/35614993
>  Fragment: { {t:npt 24.85-100.34/653.791} {track audio/653.791} }
> with the introduction of the header Fragment.
> 
> But another possibility is to use:
>  Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
> ... and write the multiple byte ranges
> Q: can they overlap?


Upon reading the HTTP spec it is indeed clear that the authors want the Content-Range value to be canonical, unique and in bytes. I think I also se the value of that decision.

I would be more in favor of a separate header (either Content-Range-Equivalent or Fragment) than of the multipart solution, because the multipart solution would introduce yet another "language" inside the multipart bit.

But: I'm not sure I understand the value of the {} expressions. Do we really think there are real-world cases where we could do byte-range based caching if a media item was fragmented along any axis other than the time axis? So, something like

	Content-Range-Equivalent: t:npt 28.85-100.34/653.791

should be good enough, I think.
--
Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma Goldman

Received on Thursday, 4 March 2010 00:41:13 UTC