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

On Thu, Mar 4, 2010 at 11:40 AM, Jack Jansen <Jack.Jansen@cwi.nl> wrote:
>
> 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.



Raphael's question was not a question that poses itself in that
manner. The Multipart bit is already defined for retrieval actions
that create multiple byte ranges as a reply rather than just one. So,
these are complimentary options, not alternatives!!!

The HTTP spec explicitly says:
"When an HTTP message includes the content of multiple ranges (for
example, a response to a request for multiple non-overlapping ranges),
these are transmitted as a multipart message. The multipart media type
used for this purpose is "multipart/byteranges" as defined in appendix
19.2. See appendix 19.6.3 for a compatibility issue. "

I hoped to make that clear in the spec, where I wrote:

"In the case where a media fragment results in a multipart
message-body, the bytes Content-Range headers will be spread
throughout the binary data ranges, but the Content-Range of the media
fragment will only be with the main header. For example:

      Origin Server (3) → Proxy (4) → UA (5):

      HTTP/1.1 206 Partial Content
      Accept-Ranges: bytes, t, xywh, track, id
      Content-Length: 3743
      Content-Type: video/ogg
      Content-Range: track audio1,video1/653.791
      Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
      Etag: "b7a60-21f7111-46f3219476580"

      --THIS_STRING_SEPARATES
      Content-type: video/ogg
      Content-Range: bytes 123-2589/35614993
      {binary data}
      --THIS_STRING_SEPARATES
      Content-type: video/ogg
      Content-Range: bytes 14560-27891/35614993
      {binary data}
      --THIS_STRING_SEPARATES
      Content-type: video/ogg
      Content-Range: bytes 58909-81230/35614993
      {binary data}
      --THIS_STRING_SEPARATES--
"

I am happy to rename the Content-Range in the header to
Content-Range-Equivalent, but that doesn't change the main gist of
this approach.


> 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.

The idea is to return back in the HTTP headers which original request
this reply relates to. Thus, the reply also includes the track
specification and not just the time specification. The caching would
still be done based on bytes.

Cheers,
Silvia.

Received on Thursday, 4 March 2010 01:14:59 UTC