Internet DRAFT - draft-kfall-httpbis-server-ranges
draft-kfall-httpbis-server-ranges
Httpbis K. Fall
Internet Draft Qualcomm Technologies Inc.
Intended status: Standards Track October 15, 2012
Expires: April 18, 2013
Server Oriented Range Responses
draft-kfall-httpbis-server-ranges-00.txt
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, except to publish it
as an RFC and to translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on April 18, 2013.
Copyright Notice
Copyright (c) 2012 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
Fall Expires April 18, 2013 [Page 1]
Internet-Draft Server Oriented Range Reponses October 2012
carefully, as they describe your rights and restrictions with respect
to this document.
Abstract
This document clarifies the semantics associated with the Content-Range
HTTP header and associated Partial Content (206) response code.
It specifically allows a server to produce a Content-Range response
whose range is a subrange of the corresponding range requested using a
previous Range request. The HTTP protocol syntax is not modified.
Instead, this document clarifies that a server responding to a client
requesting a range (x-y) may respond with a range ((x+e)-(y-f)) for
nonzero integers e,f such that (x+e) < (y-f). In addition, it clarifies
the semantics of Request ranges which contain only a starting value.
Table of Contents
1. Introduction...................................................2
2. Conventions used in this document..............................4
3. Server-Oriented Ranges.........................................4
4. Summary........................................................5
5. Security Considerations........................................5
6. IANA Considerations............................................5
7. Conclusions....................................................5
8. References.....................................................5
8.1. Normative References......................................5
8.2. Informative References....................................6
9. Acknowledgments................................................6
1. Introduction
The HTTP/1.1 specification [RFC2616] defines the concepts of range
requests, partial GET requests, and partial range responses. The
definitions of these and other related concepts have been updated in
[IDrange].
As originally conceived, these concepts allow a client to selectively
ask for, and receive, portions of an entity. Quoting from [RFC2616],
the intention is to "reduce unnecessary network usage by allowing
partially-retrieved entities to be completed without transferring
data already held by the client."
We may consider this case to be "client-driven", in that the client
is best positioned to know what it has received and what it still
wishes to obtain. Client-driven range requests become possible when
Fall Expires April 18, 2013 [Page 2]
Internet-Draft Server Oriented Range Reponses October 2012
a server indicates its support of range request processing using the
Accept-Ranges header (Section 14.5 of [RFC2616]). This header is
used to indicate the type of unit the server is willing to process.
Although various units could potentially be used, the only one
defined for use with HTTP/1.1 and in common use is bytes. Thus, we
shall assume a range refers to a byte range, and the notation (a-b)
indicates a range of bytes numbered a through b (inclusive). The
first byte of an entity is byte number zero.
A client wishing to make a partial GET request (i.e., a range
request) includes a Range header in its request (see Sections 9.3 and
14.35 of [RFC2616]).
This header may include one or more byte ranges. Although a byte
range may be expressed as (a-b), the value of b (called the last-
byte-pos) may be omitted in a byte range when it is not known by the
client. In this case, or in a case where b is larger than or equal
to the current length of the entity-body, the value of b is taken to
be is equal to one less than the current length of the entity-body in
bytes.
A server which supports the Range header and receives an appropriate
and satisfiable range request for an entity responds with status code
of 206 (Partial Content) to indicate success (instead of status code
206, which indicates OK). In addition, the response must include
either a Content-Range header or a multipart/byteranges Content-Type
including Content-Range fields for each part included in the
response.
Multiple byte ranges will only be used if the corresponding request's
Range header included multiple ranges. The presence of multiple
ranges in the request in effect indicates the client's ability to
process the multipart/byteranges Content-Type.
+------------------------------------------------+
| |
| |
| A ---- B ==== C |
| |
| |
+------------------------------------------------+
Figure 1 A simple network (A-B) is TCP/IP; (B=C) may not be.
Fall Expires April 18, 2013 [Page 3]
Internet-Draft Server Oriented Range Reponses October 2012
2. Conventions used in this document
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].
In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying RFC-2119 significance.
3. Server-Oriented Ranges
When range requests and responses are used successfully, the server
will typically respond to a byte range request with the contents of
the entire byte range(s) included in the Range header.
However, this behavior is not explicitly required by [RFC2616].
Furthermore, there are interesting use cases where certain portions
of an entity may not be available at a server at a particular point
in time, but other portions of the same entity may be of immediate
use to a requesting client. Support for this case may be termed
"server-driven," as the knowledge of which ranges are available at
which times are determined more by the server than the client.
Consider the simple network depicted in Figure 1. The path between A
and B is a conventional TCP/IP network and the path between B and C
may be some other type of network (e.g., a lossy one directional link
from C to B).
Assume that a web proxy agent on B aggregates blocks of an entity
together and provides the re-aggregated portions to A as soon as they
become available.
For concreteness, imagine the data being transferred are samples of
continuous media such as streaming audio or video. In this case it
would be useful to allow A to obtain whatever continuous byte ranges
are available on B in as timely a manner as possible.
Using the existing framework for range requests, A can issue a
partial GET request for the range (0-), indicating a desire to obtain
whatever is available from B.
B is able to respond with a byte range indicated using the Content-
Range header in a Partial Content (status code 206) response. It
may, but is not require to, respond with a range of bytes starting
with byte number zero.
Fall Expires April 18, 2013 [Page 4]
Internet-Draft Server Oriented Range Reponses October 2012
Continuing with the example, if A desires to obtain the missing parts
of the entity it is interested in, it may issue multiple range
requests of the form (a-b) and the server on B may respond with
ranges corresponding ranges (x-y). It is explicitly not required
that a=x or b=y. However, to be a legal byte range, a <= b and x &<=
y are both required.
4. Summary
This document specifies a normative behavior for range responses.
When a partial GET request contains a range (x-y), a response
utilizing the 206 response code MAY include a range other than (x-y).
However, if the entire range is available it SHOULD respond with the
requested range.
In addition, when a range request is of the form (x-), the server MAY
respond with a range response including an initial byte number y > x.
Finally, a response including multiple ranges is permitted so long as
the corresponding range request included multiple ranges.
If the number of ranges available at the server are greater than or
equal to the number of ranges present in the request, the server
SHOULD respond with the number of ranges equal to the number of
responses.
5. Security Considerations
This document does not introduce any security considerations beyond
those present in [RFC2616].
6. IANA Considerations
No IANA action is required by this document.
7. Conclusions
The existing structure of HTTP range requests and partial responses
can be used for delivering portions of a requested entity without
syntactical modification to the HTTP protocol.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Fall Expires April 18, 2013 [Page 5]
Internet-Draft Server Oriented Range Reponses October 2012
[RFC2616] Fielding, R. et al., "Hypertext Transfer Protocol -
HTTP/1.1", RFC 2616, June 1999
[RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for
Syntax Specifications: ABNF", RFC 2234, Internet Mail
Consortium and Demon Internet Ltd., November 1997.
8.2. Informative References
[IDrange] Fielding, R. et al., "Hypertext Transfer Protocol
(HTTP/1.1): Range Requests", draft-ietf-httpbis-p5-range, work in
progress, Oct 4, 2012
9. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
Fall Expires April 18, 2013 [Page 6]
Internet-Draft Server Oriented Range Reponses October 2012
Authors' Addresses
Kevin Fall
Qualcomm Technologies Inc.
5580 Morehouse Drive
San Diego, CA 92121
USA
Email: kfall@qti.qualcomm.com
Fall Expires April 18, 2013 [Page 7]
