Hypertext Transfer Protocol C. Pratt
Internet-Draft CableLabs
Intended status: Informational B. Stark
Expires: October 5, 2016 AT&T
D. Thakore
CableLabs
April 3, 2016
HTTP bytes-live Range Unit for Live Content
draft-pratt-httpbis-bytes-live-range-unit-00
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 5, 2016.
Pratt, et al. Expires October 5, 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 . . . . . . . . . . . . . . . . . . . . . . . 8
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 5, 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 5, 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 5, 2016 [Page 4]
Internet-Draft HTTP bytes-live Range Unit April 2016
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:
Content-Range: bytes-live 40000-49999/50000
This second example illustrates when the complete length of the
selected representation is unknown:
Content-Range: bytes 40000-*/*
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.
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 5, 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 5, 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,
<http://www.rfc-editor.org/info/rfc2119>.
[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,
<http://www.rfc-editor.org/info/rfc7233>.
[RFC7749] Reschke, J., "The "xml2rfc" Version 2 Vocabulary",
RFC 7749, DOI 10.17487/RFC7749, February 2016,
<http://www.rfc-editor.org/info/rfc7749>.
8.2. Informative References
[RANGE-UNIT-REGISTRY]
IANA, "Hypertext Transfer Protocol (HTTP) Parameters",
2016, <http://www.iana.org/assignments/http-parameters/
http-parameters.xhtml#range-units>.
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, DOI 10.17487/RFC4234,
October 2005, <http://www.rfc-editor.org/info/rfc4234>.
Pratt, et al. Expires October 5, 2016 [Page 7]
Internet-Draft HTTP bytes-live Range Unit April 2016
Authors' Addresses
Craig Pratt
CableLabs
16455 NW Comadrona Ln
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 5, 2016 [Page 8]