HTTP Random Access and Live Content
RFC 8673
Internet Engineering Task Force (IETF) C. Pratt
Request for Comments: 8673
Category: Experimental D. Thakore
ISSN: 2070-1721 CableLabs
B. Stark
AT&T
November 2019
HTTP Random Access and Live Content
Abstract
To accommodate byte-range requests for content that has data appended
over time, this document defines semantics that allow an HTTP client
and a server to perform byte-range GET and HEAD requests that start
at an arbitrary byte offset within the representation and end at an
indeterminate offset.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for examination, experimental implementation, and
evaluation.
This document defines an Experimental Protocol for the Internet
community. This document is a product of the Internet Engineering
Task Force (IETF). It represents the consensus of the IETF
community. It has received public review and has been approved for
publication by the Internet Engineering Steering Group (IESG). Not
all documents approved by the IESG are candidates for any level of
Internet Standard; see Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8673.
Copyright Notice
Copyright (c) 2019 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
(https://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
1.1. Notational Conventions
2. Performing Range Requests on Random-Access Aggregating (Live)
Content
2.1. Establishing the Randomly Accessible Byte Range
2.2. Byte-Range Requests beyond the Randomly Accessible Byte
Range
3. Other Applications of Random-Access Aggregating Content
3.1. Requests Starting at the Aggregation/Live Point
3.2. Shift-Buffer Representations
4. Recommendations for Byte-Range Request last-byte-pos Values
5. IANA Considerations
6. Security Considerations
7. References
7.1. Normative References
7.2. Informative References
Acknowledgements
Authors' Addresses
1. Introduction
Some Hypertext Transfer Protocol (HTTP) clients use byte-range
requests (range requests using the "bytes" range unit) to transfer
select portions of large representations [RFC7233]. In some cases,
large representations require content to be continuously or
periodically appended, such as representations consisting of live
audio or video sources, blockchain databases, and log files. Clients
cannot access the appended/live content using a range request with
the "bytes" range unit using the currently defined byte-range
semantics without accepting performance or behavior sacrifices that
are not acceptable for many applications.
For instance, HTTP clients have the ability to access appended
content on an indeterminate-length resource by transferring the
entire representation from the beginning and continuing to read the
appended content as it's made available. Obviously, this is highly
inefficient for cases where the representation is large and only the
most recently appended content is needed by the client.
Alternatively, clients can access appended content by sending
periodic, open-ended byte-range requests using the last known end
byte position as the range start. Performing low-frequency periodic
byte-range requests in this fashion (polling) introduces latency
since the client will necessarily be somewhat behind in transferring
the aggregated content, effectively resulting in the same kind of
latency issues with the segmented content transfer mechanisms in
"HTTP Live Streaming" (HLS) [RFC8216] and "Dynamic Adaptive Streaming
over HTTP" [MPEG-DASH]. While performing these range requests at
higher frequency can reduce this latency, it also incurs more
processing overhead and HTTP exchanges as many of the requests will
return no content, since content is usually aggregated in groups of
Show full document text