HTTP Range Refer

Introduction

This proposal specifies an ordered list of tuples of (URI, byte range) which the concatenation of is byte-wise identical to the byte contents of the requested URI

This response can also contain data, so if you want to refer to this response you can include a tuple of (this, range) where this is the literal string "this", and refers to the body of the current response.

This syntax then allows the server to include parts from many different URLs. The custom data is then centralized in this response, and can be used for any parts of construction of the response so that it can be used for tail data (such as ID3 tags, DIVX seek tables etc.)

Headers

Request header:

       Accept-Range-Refer:

Response:

       Range-Refer:
       Vary: Accept-Range-Refer

As the response is negotiated, it must include a Vary header.

Accept-Range-Refer specifies accepted units for range referral, eg:

       Accept-Range-Refer: bytes

The response consists of [a list of] URIs, range units and ranges within them, eg:

       Range-Refer: URL1 bytes a-b

It optionally contains an ETag for the URL being referred to.

List and tuple separator characters

The list separator should be commas, as this then allows the list to be separated over HTTP response lines (without re-ordering).

Hence the tuple separator should not be commas; it can simply be whitespace:

   Range-Refer: http://www.example.com/video.ogv?headers bytes 0-1280
   Range-Refer: http://content1.example.com/video.ogv bytes 5380-48204
   Range-Refer: this bytes 0-950
   Range-Refer: http://content1.example.com/video.ogv bytes 60880-238382

By comma replacement, this set of headers is equivalent to the single header:

   Range-Refer: http://www.example.com/video.ogv?headers bytes 0-1280, http://content1.example.com/video.ogv bytes 5380-48204, this bytes 0-950, http://content1.example.com/video.ogv bytes 60880-238382

Interpretation of other response headers

The body of this request is simply all the custom parts for this view, concatenated bytewise. The Range-Refer header explains how to use this data.

Content-Length: is the length of the body.

A Range request is made relative to the body. So for example a client could just do a HEAD request to get the Range-Refer headers, and then do multiple Range requests to retrieve the required parts in sequence (rather than locally caching all the data for tailers etc.). Coherence of the concatenated responses can be assured by the use of existing HTTP/1.1 caching identifiers.

So, this constructed response is only special in that a user agent knows how to use it in conjuction with other URI response data to display a media segment. Otherwise it is standard HTTP, and can have caching headers/tags attached, be cached by intermediate proxies, and itself be the subject of range requests.

Generalization to other segment types

This mechanism allows a complex sequence of byte-ranges to be specified. It explicitly marks data ranges which are re-usable, allowing them to be cached. It generalizes so that any complex data subview can be served, where re-usable data is keyed canonically and can be cached on the network.

For example, it may be useful for specifying the data for a spatial subrange of video.