Hypertext Transfer Protocol C. Pratt Internet-Draft CableLabs Intended status: Informational B. Stark Expires: October 20, 2016 AT&T D. Thakore CableLabs April 18, 2016 HTTP bytes-live Range Unit for Live Content draft-pratt-httpbis-bytes-live-range-unit-01 Abstract 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 "*". Requirements Language 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]. Status of This Memo 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 20, 2016. Pratt, et al. Expires October 20, 2016 [Page 1] Internet-Draft HTTP bytes-live Range Unit April 2016 Copyright Notice 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. The "bytes-live" Range Request . . . . . . . . . . . . . . . 3 3. Responses to a bytes-live Range Request . . . . . . . . . . . 4 3.1. The "bytes-live" Content-Range header field . . . . . . . 4 3.2. The "bytes-live" 206 (Partial Content) response . . . . . 5 3.3. The "bytes-live" 416 (Range Not Satisfiable) response . . 6 4. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5.1. Range Unit Registry . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction 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 Pratt, et al. Expires October 20, 2016 [Page 2] Internet-Draft HTTP bytes-live Range Unit April 2016 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. 2. The "bytes-live" Range Request 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 Pratt, et al. Expires October 20, 2016 [Page 3] Internet-Draft HTTP bytes-live Range Unit April 2016 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. 3. Responses to a bytes-live Range Request 3.1. The "bytes-live" Content-Range header field 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 Pratt, et al. Expires October 20, 2016 [Page 4] Internet-Draft HTTP bytes-live Range Unit April 2016 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. 3.2. The "bytes-live" 206 (Partial Content) response 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. Pratt, et al. Expires October 20, 2016 [Page 5] Internet-Draft HTTP bytes-live Range Unit April 2016 3.3. The "bytes-live" 416 (Range Not Satisfiable) response 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: 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/* 4. Accept-Ranges 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 Accept-Ranges: bytes-live to indicate it supports bytes-live range units. 5. IANA Considerations 5.1. Range Unit Registry 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]. Pratt, et al. Expires October 20, 2016 [Page 6] Internet-Draft HTTP bytes-live Range Unit April 2016 Registration of the bytes-live Range Unit is as follows: +----------------+--------------------------------------+-----------+ | Range Unit | Description | Reference | | Name | | | +----------------+--------------------------------------+-----------+ | bytes-live | a range of octets with increasing | Section 2 | | | length | | +----------------+--------------------------------------+-----------+ 6. Security Considerations There are no known security concerns introduced by use of the bytes- live range unit. 7. Acknowledgements 8. References 8.1. Normative References [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., Ed., Lafon, Y., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233, DOI 10.17487/RFC7233, June 2014, . 8.2. Informative References [RANGE-UNIT-REGISTRY] IANA, "Hypertext Transfer Protocol (HTTP) Parameters", 2016, . [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, DOI 10.17487/RFC4234, October 2005, . Authors' Addresses Pratt, et al. Expires October 20, 2016 [Page 7] Internet-Draft HTTP bytes-live Range Unit April 2016 Craig Pratt CableLabs Portland, OR 97229-8910 US Email: craig@ecaspia.com Barbara Stark AT&T Atlanta, GA US Email: barbara.stark@att.com Darshak Thakore CableLabs 858 Coal Creek Circle Louisville, CO 80027 Email: d.thakore@cablelabs.com Pratt, et al. Expires October 20, 2016 [Page 8]