| Hypertext Transfer Protocol | C. Pratt |
| Internet-Draft | CableLabs |
| Intended status: Informational | B. Stark |
| Expires: October 6, 2016 | AT&T |
| D. Thakore | |
| CableLabs | |
| April 4, 2016 |
HTTP bytes-live Range Unit for Live Content
draft-pratt-httpbis-bytes-live-range-unit-00
To accommodate byte range requests for content that has data appended over time, this document defines a new HTTP range unit named "bytes-live". The "bytes-live" range unit provides 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 "*".
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 6, 2016.
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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:
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:
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:
For bytes-live ranges, 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:
This second example illustrates when the complete length of the selected representation is unknown:
As is the case with a byte 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 [RFC7233].
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 [RFC7233]).
For example, if the representation is no longer being appended:
And if the representation is still being appended:
The "Accept-Ranges" header field described in Section 2.3 of [RFC7233] 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
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 [RANGE-UNIT-REGISTRY].
Registration of the bytes-live Range Unit is as follows:
| Range Unit Name | Description | Reference |
|---|---|---|
| bytes-live | a range of octets with increasing length | Section 2 |
There are no known security concerns introduced by use of the bytes-live range unit.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC7233] | Fielding, R., Lafon, Y. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233, DOI 10.17487/RFC7233, June 2014. |
| [RFC7749] | Reschke, J., "The "xml2rfc" Version 2 Vocabulary", RFC 7749, DOI 10.17487/RFC7749, February 2016. |
| [RANGE-UNIT-REGISTRY] | IANA, "Hypertext Transfer Protocol (HTTP) Parameters", 2016. |
| [RFC4234] | Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, DOI 10.17487/RFC4234, October 2005. |