idnits 2.17.1 draft-combs-http-indeterminate-range-02.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 (Using the creation date from RFC7233, updated by this document, for RFC5378 checks: 2007-12-21) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 21, 2015) is 3133 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 7233 (Obsoleted by RFC 9110) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. R. Combs, Ed. 2 Internet-Draft Plex 3 Updates: 7233 September 21, 2015 4 (if approved) 5 Intended status: Standards Track 6 Expires: March 24, 2016 8 HTTP/1.1: Range Responses of Indeterminate Length 9 draft-combs-http-indeterminate-range-02 11 Status of this Memo 13 This Internet-Draft is submitted in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF). Note that other groups may also distribute 18 working documents as Internet-Drafts. The list of current Internet- 19 Drafts is at http://datatracker.ietf.org/drafts/current/. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 This Internet-Draft will expire on March 24, 2016. 28 Copyright Notice 30 Copyright (c) 2015 IETF Trust and the persons identified as the 31 document authors. All rights reserved. 33 This document is subject to BCP 78 and the IETF Trust's Legal 34 Provisions Relating to IETF Documents 35 (http://trustee.ietf.org/license-info) in effect on the date of 36 publication of this document. Please review these documents 37 carefully, as they describe your rights and restrictions with respect 38 to this document. 40 Abstract 42 The Hypertext Transfer Protocol (HTTP) is an application-level 43 protocol for distributed, collaborative, hypermedia information 44 systems. HTTP has been in use by the World Wide Web global 45 information initiative since 1990. This document updates RFC 7233, 46 Part 5 of the eight-part specification that defines the protocol 47 referred to as "HTTP/1.1". Part 5 defines range-specific requests and 48 the rules for constructing and combining responses to those requests. 49 This document improves support for responding to range requests for 50 resources of indeterminate size. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Header Field Definitions . . . . . . . . . . . . . . . . . . . 3 56 2.1. Accept-Indefinite-Ranges . . . . . . . . . . . . . . . . . 3 57 2.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Security Considerations . . . . . . . . . . . . . . . . . . . 5 59 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 60 4.1. Header Field Registration . . . . . . . . . . . . . . . . 5 61 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 62 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 6.1. Normative References . . . . . . . . . . . . . . . . . . . 6 64 6.2. Informative References . . . . . . . . . . . . . . . . . . 6 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 67 1. Introduction 69 This document will define changes to [RFC7233] HTTP/1.1 designed to 70 allow range requests to be used to retrieve parts of resources whose 71 lengths are unknown at the time of the first request. 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 74 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 75 "OPTIONAL" in this document are to be interpreted as described in 76 [RFC2119]. 78 2. Header Field Definitions 80 This section defines the syntax and semantics of all standard 81 HTTP/1.1 header fields. For entity-header fields, both sender and 82 recipient refer to either the client or the server, depending on who 83 sends and who receives the entity. 85 2.1. Accept-Indefinite-Ranges 87 The Accept-Indefinite-Ranges request-header field allows the client 88 to indicate its acceptance of indefinite-sized range requests for a 89 resource: 91 Accept-Indefinite-Ranges = "Accept-Indefinite-Ranges" ":" "1" 93 Servers MUST NOT generate indefinite-sized byte-range replies without 94 having received this header, with the value "1", for the resource 95 involved. 97 2.2. Content-Range 99 The Content-Range entity-header is sent with a partial entity-body to 100 specify where in the full entity-body the partial body should be 101 applied. This section updates Section 4.2 of [RFC7233]. 103 Content-Range = byte-content-range 104 / other-content-range 106 byte-content-range = bytes-unit SP 107 ( byte-range-resp / unsatisfied-range ) 109 byte-range-resp = byte-range "/" ( complete-length / "*" ) 110 byte-range = first-byte-pos "-" (last-byte-pos / "*" ) 111 unsatisfied-range = "*/" ( complete-length / "*" ) 113 complete-length = 1*DIGIT 115 other-content-range = other-range-unit SP other-range-resp 116 other-range-resp = *CHAR 118 For byte ranges, a sender SHOULD indicate the complete length of the 119 representation from which the range has been extracted, unless the 120 complete length is unknown or difficult to determine. An asterisk 121 character ("*") in place of the complete-length indicates that the 122 representation length was unknown when the header field was 123 generated. 125 An asterisk character in place of the last-byte-pos indicates that 126 the response length was unknown when the header was generated, and 127 that the entire requested range of the resource will be sent. An 128 asterisk character may be used in place of the last-byte-pos ONLY 129 if the Accept-Indefinite-Ranges header was sent, and requires use 130 of the RFC 7230 Chunked Transfer-Encoding 132 The following example illustrates when the complete length of the 133 selected representation is known by the sender to be 1234 bytes: 135 Content-Range: bytes 42-1233/1234 137 and this second example illustrates when the complete length is 138 unknown: 140 Content-Range: bytes 42-1233/* 141 OR 142 Content-Range: bytes 42-*/* 143 (if the Accept-Indefinite-Ranges request header was sent) 145 Request and response range values for an example use-case, in which 146 a growing media file is streamed to the client: 148 Client requests the whole stream: 149 Range: 0- 151 Server begins a response of unknown size: 152 bytes 0-*/* 154 User seeks in the stream; client closes previous connection and 155 requests the seek offset (possibly repeating multiple times to 156 find the desired offset): 157 Range: 32768- 159 Server begins a response of unknown size, at the requested offset: 160 bytes 32768-*/* 162 3. Security Considerations 164 No additional security considerations have been identified beyond 165 those applicable to HTTP range requests in general [RFC7233]. 167 4. IANA Considerations 169 4.1. Header Field Registration 171 HTTP header fields are registered within the "Message Headers" 172 registry maintained at 173 . 175 This document defines or updates the following HTTP header fields, so 176 their associated registry entries shall be updated according to the 177 permanent registrations below (see [BCP90]): 179 +--------------------------+----------+----------+-------------+ 180 | Header Field Name | Protocol | Status | Reference | 181 +--------------------------+----------+----------+-------------+ 182 | Accept-Indefinite-Ranges | http | standard | Section 2.1 | 183 | Content-Range | http | standard | Section 2.2 | 184 +--------------------------+----------+----------+-------------+ 186 The change controller is: "IETF (iesg@ietf.org) - Internet 187 Engineering Task Force". 189 5. Acknowledgments 191 Parts of this document are based on [RFC7233] and its drafts. 193 6. References 195 6.1. Normative References 197 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 198 Requirement Levels", BCP 14, RFC 2119, March 1997. 200 [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., 201 "Hypertext Transfer Protocol (HTTP/1.1): Range 202 Requests", RFC 7233, June 2014. 204 6.2. Informative References 206 [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration 207 Procedures for Message Header Fields", BCP 90, RFC 3864, 208 September 2004. 210 Authors' Addresses 212 J. Rodger Combs (editor) 213 Plex, Inc. 215 Email: rodger@plex.tv