idnits 2.17.1 draft-kfall-httpbis-server-ranges-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 15, 2012) is 4183 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2234' is defined on line 233, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Httpbis K. Fall 2 Internet Draft Qualcomm Technologies Inc. 3 Intended status: Standards Track October 15, 2012 4 Expires: April 18, 2013 6 Server Oriented Range Responses 7 draft-kfall-httpbis-server-ranges-00.txt 9 Status of this Memo 11 This Internet-Draft is submitted in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 This Internet-Draft is submitted in full conformance with the 15 provisions of BCP 78 and BCP 79. This document may not be modified, 16 and derivative works of it may not be created, except to publish it 17 as an RFC and to translate it into languages other than English. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 This Internet-Draft will expire on April 18, 2013. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. 49 Abstract 51 This document clarifies the semantics associated with the Content-Range 52 HTTP header and associated Partial Content (206) response code. 54 It specifically allows a server to produce a Content-Range response 55 whose range is a subrange of the corresponding range requested using a 56 previous Range request. The HTTP protocol syntax is not modified. 57 Instead, this document clarifies that a server responding to a client 58 requesting a range (x-y) may respond with a range ((x+e)-(y-f)) for 59 nonzero integers e,f such that (x+e) < (y-f). In addition, it clarifies 60 the semantics of Request ranges which contain only a starting value. 62 Table of Contents 64 1. Introduction...................................................2 65 2. Conventions used in this document..............................4 66 3. Server-Oriented Ranges.........................................4 67 4. Summary........................................................5 68 5. Security Considerations........................................5 69 6. IANA Considerations............................................5 70 7. Conclusions....................................................5 71 8. References.....................................................5 72 8.1. Normative References......................................5 73 8.2. Informative References....................................6 74 9. Acknowledgments................................................6 76 1. Introduction 78 The HTTP/1.1 specification [RFC2616] defines the concepts of range 79 requests, partial GET requests, and partial range responses. The 80 definitions of these and other related concepts have been updated in 81 [IDrange]. 83 As originally conceived, these concepts allow a client to selectively 84 ask for, and receive, portions of an entity. Quoting from [RFC2616], 85 the intention is to "reduce unnecessary network usage by allowing 86 partially-retrieved entities to be completed without transferring 87 data already held by the client." 89 We may consider this case to be "client-driven", in that the client 90 is best positioned to know what it has received and what it still 91 wishes to obtain. Client-driven range requests become possible when 92 a server indicates its support of range request processing using the 93 Accept-Ranges header (Section 14.5 of [RFC2616]). This header is 94 used to indicate the type of unit the server is willing to process. 95 Although various units could potentially be used, the only one 96 defined for use with HTTP/1.1 and in common use is bytes. Thus, we 97 shall assume a range refers to a byte range, and the notation (a-b) 98 indicates a range of bytes numbered a through b (inclusive). The 99 first byte of an entity is byte number zero. 101 A client wishing to make a partial GET request (i.e., a range 102 request) includes a Range header in its request (see Sections 9.3 and 103 14.35 of [RFC2616]). 105 This header may include one or more byte ranges. Although a byte 106 range may be expressed as (a-b), the value of b (called the last- 107 byte-pos) may be omitted in a byte range when it is not known by the 108 client. In this case, or in a case where b is larger than or equal 109 to the current length of the entity-body, the value of b is taken to 110 be is equal to one less than the current length of the entity-body in 111 bytes. 113 A server which supports the Range header and receives an appropriate 114 and satisfiable range request for an entity responds with status code 115 of 206 (Partial Content) to indicate success (instead of status code 116 206, which indicates OK). In addition, the response must include 117 either a Content-Range header or a multipart/byteranges Content-Type 118 including Content-Range fields for each part included in the 119 response. 121 Multiple byte ranges will only be used if the corresponding request's 122 Range header included multiple ranges. The presence of multiple 123 ranges in the request in effect indicates the client's ability to 124 process the multipart/byteranges Content-Type. 126 +------------------------------------------------+ 127 | | 128 | | 129 | A ---- B ==== C | 130 | | 131 | | 132 +------------------------------------------------+ 134 Figure 1 A simple network (A-B) is TCP/IP; (B=C) may not be. 136 2. Conventions used in this document 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in RFC-2119 [RFC2119]. 142 In this document, these words will appear with that interpretation 143 only when in ALL CAPS. Lower case uses of these words are not to be 144 interpreted as carrying RFC-2119 significance. 146 3. Server-Oriented Ranges 148 When range requests and responses are used successfully, the server 149 will typically respond to a byte range request with the contents of 150 the entire byte range(s) included in the Range header. 152 However, this behavior is not explicitly required by [RFC2616]. 153 Furthermore, there are interesting use cases where certain portions 154 of an entity may not be available at a server at a particular point 155 in time, but other portions of the same entity may be of immediate 156 use to a requesting client. Support for this case may be termed 157 "server-driven," as the knowledge of which ranges are available at 158 which times are determined more by the server than the client. 160 Consider the simple network depicted in Figure 1. The path between A 161 and B is a conventional TCP/IP network and the path between B and C 162 may be some other type of network (e.g., a lossy one directional link 163 from C to B). 165 Assume that a web proxy agent on B aggregates blocks of an entity 166 together and provides the re-aggregated portions to A as soon as they 167 become available. 169 For concreteness, imagine the data being transferred are samples of 170 continuous media such as streaming audio or video. In this case it 171 would be useful to allow A to obtain whatever continuous byte ranges 172 are available on B in as timely a manner as possible. 174 Using the existing framework for range requests, A can issue a 175 partial GET request for the range (0-), indicating a desire to obtain 176 whatever is available from B. 178 B is able to respond with a byte range indicated using the Content- 179 Range header in a Partial Content (status code 206) response. It 180 may, but is not require to, respond with a range of bytes starting 181 with byte number zero. 183 Continuing with the example, if A desires to obtain the missing parts 184 of the entity it is interested in, it may issue multiple range 185 requests of the form (a-b) and the server on B may respond with 186 ranges corresponding ranges (x-y). It is explicitly not required 187 that a=x or b=y. However, to be a legal byte range, a <= b and x &<= 188 y are both required. 190 4. Summary 192 This document specifies a normative behavior for range responses. 193 When a partial GET request contains a range (x-y), a response 194 utilizing the 206 response code MAY include a range other than (x-y). 195 However, if the entire range is available it SHOULD respond with the 196 requested range. 198 In addition, when a range request is of the form (x-), the server MAY 199 respond with a range response including an initial byte number y > x. 200 Finally, a response including multiple ranges is permitted so long as 201 the corresponding range request included multiple ranges. 203 If the number of ranges available at the server are greater than or 204 equal to the number of ranges present in the request, the server 205 SHOULD respond with the number of ranges equal to the number of 206 responses. 208 5. Security Considerations 210 This document does not introduce any security considerations beyond 211 those present in [RFC2616]. 213 6. IANA Considerations 215 No IANA action is required by this document. 217 7. Conclusions 219 The existing structure of HTTP range requests and partial responses 220 can be used for delivering portions of a requested entity without 221 syntactical modification to the HTTP protocol. 223 8. References 225 8.1. Normative References 227 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 228 Requirement Levels", BCP 14, RFC 2119, March 1997. 230 [RFC2616] Fielding, R. et al., "Hypertext Transfer Protocol - 231 HTTP/1.1", RFC 2616, June 1999 233 [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for 234 Syntax Specifications: ABNF", RFC 2234, Internet Mail 235 Consortium and Demon Internet Ltd., November 1997. 237 8.2. Informative References 239 [IDrange] Fielding, R. et al., "Hypertext Transfer Protocol 240 (HTTP/1.1): Range Requests", draft-ietf-httpbis-p5-range, work in 241 progress, Oct 4, 2012 243 9. Acknowledgments 245 This document was prepared using 2-Word-v2.0.template.dot. 247 Authors' Addresses 249 Kevin Fall 250 Qualcomm Technologies Inc. 251 5580 Morehouse Drive 252 San Diego, CA 92121 253 USA 255 Email: kfall@qti.qualcomm.com