HTTP bytes-live Range Unit for Live Content

Some Hypertext Transfer Protocol (HTTP) clients use Range requests for random access to large representations. And in some cases these representations have content continuously or periodically appended - such as representations originating from live audio or video sources. These types of clients cannot easily access the appended/live content using a Range request with the bytes range unit. HTTP clients have the ability to access appended content by transfersferring the entire representation from the very beginning. For large representations, however, newly appended content may never be transferred due to bitrate limits. And even when the appended content is reached, it will be at the cost of start-up latency and wasted network bandwidth. HTTP clients can also attempt to access appended content by sending periodic bytes Range requests using the last-known end position. Performing periodic bytes Range requests (polling) introduces latency since the client will necessarily be somewhat behind the aggregated content - mimicking the behavior of segmented content representations such as HLS or MPEG-DASH. And performing these Range requests at higher frequency incurs more processing overhead and HTTP traffic as the requests often return no content - since content is usually aggregated in groups of bytes (e.g. a video frame or audio sample). To accommodate byte range requests on large representations which have data appended over time, this document defines a new HTTP range unit named "bytes-live". The "bytes-live" range unit adds the ability for a client to specify a byte range in a GET or HEAD request which starts at an arbitrary byte offset within the representation and ends at an indeterminate offset, represented by "*". A client can also specify a request that immediately starts transferring aggregated/live content. The server indicates supports for the "bytes-live" range unit via the Accept-Ranges header. If a client performs a "bytes-live" Range request on a dynamic representation (a representation that has data appended over time), the server can provide a non-fixed-length payload in response to one of these requests. For instance, a server can use chunked transfer mode to return currently available data and data that is appended to the representation as it becomes available. Normal TCP flow control ensures new chunks are received by the client as soon as they are added to the representation with very low latency and overhead for the HTTP client and server.

As with the "bytes" range unit, a "bytes-live" Range request allows a client to designate a subset of bytes from the representation data to be transferred in payloads as a sequence of octets. But the form of a "bytes-live" request is focused on accessing data that may be appended to the representation over time. The bytes-live range unit has the following syntax: bytes-live-range-specifier = "bytes-live=" bytes-live-range-spec bytes-live-range-spec = [ first-byte-pos "-" ] "*" first-byte-pos = 1*DIGIT The first-byte-pos value in a byte-range-spec gives the byte-offset of the first byte in a range. An asterisk character ("*") indicates that the end of requested range is indeterminate and will include appended data if/when available. Examples of bytes-live-ranges-specifier values: Bytes 50000 to the end of the representation (including appended data, potentially unbound): bytes-live=500000-* All bytes appended to the end of the representation after the request is processed: bytes-live=* All bytes currently in the representation and those appended to the end of the representation after the request is processed: bytes-live=0-* A bytes-live-range-specifier is considered unsatisfiable if the first-byte-pos is larger than the current length of the representation.

As with the "bytes" Content-Range response form, a "bytes-live" Content-Range response indicates the satisfyable or unsatisfyable range of a "bytes-live" range request. The "bytes-live" Content-Range header is compliant with the Content-Range header rules defined in Section 4.2 and has the following syntax: bytes-live-content-range = "bytes-live" SP bytes-live-range-resp bytes-live-range-resp = bytes-live-range "/" ( complete-length / "*" ) bytes-live-range = "*" / ( first-byte-pos "-" ( last-byte-pos / "*" ) ) last-byte-pos = 1*DIGIT complete-length = 1*DIGIT For bytes-live range responses, the sender MUST indicate the offset of the first available byte in the returned range using the first-byte-pos. The sender MUST indicate the complete length of the representation and the last byte position of the returned range if the representation is no longer having data appended to it. Otherwise an asterisk character ("*") MUST be used in place of the last-byte-pos to indicate the returned range and any associated payload is not bounded. As is the case with byte ranges, an asterisk character ("*") in place of the complete-length indicates that the representation length was unknown when the header field was generated. The following example illustrates when the last byte of the selected representation is known by the sender to be 50000 bytes and is no longer being appended to: Content-Range: bytes-live 40000-49999/50000 This second example illustrates when the complete length of the selected representation is unknown: Content-Range: bytes-live 40000-*/* As is the case with a bytes unit Content-Range field, the bytes-live Content-Range field value is invalid if it contains a bytes-live-range-resp that has a last-byte-pos value less than its first-byte-pos value or a complete-length value less than or equal to its last-byte-pos value.

The bytes-live 206 response MUST comply with section 4.1 of . Additionally, responses to bytes-live requests that include an asterisk character ("*") in place of the last-byte-pos of the bytes-live Content-Range header field and precede a payload MUST use a transfer encoding mode appropriate for transferring dynamically generated payload, such as chunked transfer encoding for HTTP/1.1 clients. Dynamic representations may stop being aggregated at any point in time. So the transfer mode used for bytes-live 206 responses MUST indicate when the end of a dynamic representation being transferred is reached. For chunked mode transfer encoding in HTTP/1.1, this is signaled with a 0-length chunk. For HTTP/1.0 clients, this can be signaled by the server closing the connection.

For bytes-live ranges, failing to overlap the current extent means that the first-byte-pos of the byte-range-spec is greater than the current length of the selected representation. When this status code is generated in response to a bytes-live-range request, the sender MUST generate a Content-Range header field specifying the currently available range of the selected representation (Section 4.2 of ). For example, if the representation is no longer being appended: HTTP/1.1 416 Range Not Satisfiable Date: Wed, 23 Mar 2015 11:21:12 GMT Content-Range: bytes-live 5000-97229/97230 And if the representation is still being appended: HTTP/1.1 416 Range Not Satisfiable Date: Wed, 23 Mar 2015 11:21:12 GMT Content-Range: bytes-live 5000-97229/*

The "Accept-Ranges" header field described in Section 2.3 of allows a server to indicate that it supports range requests for the target resource. An origin server that supports bytes-live range requests for a given target resource MUST send Accept-Ranges: bytes-live to indicate it supports bytes-live range units.

The "HTTP Range Unit Registry" defines the namespace for the range unit names and refers to their corresponding specifications. The registry has been created and is now maintained at . Registration of the bytes-live Range Unit is as follows: Range Unit Name Description Reference bytes-live a range of octets with increasing length

There are no known security concerns introduced by use of the bytes-live range unit.