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]