[29] | 1 | <?xml version="1.0" encoding="utf-8"?> |
---|
[101] | 2 | <?xml-stylesheet type='text/xsl' href='../myxml2rfc.xslt'?> |
---|
[8] | 3 | <!DOCTYPE rfc [ |
---|
| 4 | <!ENTITY MAY "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MAY</bcp14>"> |
---|
| 5 | <!ENTITY MUST "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MUST</bcp14>"> |
---|
| 6 | <!ENTITY MUST-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MUST NOT</bcp14>"> |
---|
| 7 | <!ENTITY OPTIONAL "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>OPTIONAL</bcp14>"> |
---|
| 8 | <!ENTITY RECOMMENDED "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>RECOMMENDED</bcp14>"> |
---|
| 9 | <!ENTITY REQUIRED "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>REQUIRED</bcp14>"> |
---|
| 10 | <!ENTITY SHALL "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHALL</bcp14>"> |
---|
| 11 | <!ENTITY SHALL-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHALL NOT</bcp14>"> |
---|
| 12 | <!ENTITY SHOULD "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD</bcp14>"> |
---|
| 13 | <!ENTITY SHOULD-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD NOT</bcp14>"> |
---|
[29] | 14 | <!ENTITY ID-VERSION "latest"> |
---|
[439] | 15 | <!ENTITY ID-MONTH "January"> |
---|
| 16 | <!ENTITY ID-YEAR "2009"> |
---|
[424] | 17 | <!ENTITY notation "<xref target='Part1' x:rel='#notation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
[205] | 18 | <!ENTITY notation-abnf "<xref target='Part1' x:rel='#notation.abnf' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 19 | <!ENTITY basic-rules "<xref target='Part1' x:rel='#basic.rules' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 20 | <!ENTITY full-date "<xref target='Part1' x:rel='#full.date' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
[31] | 21 | <!ENTITY messaging "<xref target='Part1' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
[205] | 22 | <!ENTITY entity-tags "<xref target='Part4' x:rel='#entity.tags' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
[31] | 23 | <!ENTITY weak-and-strong-validators "<xref target='Part4' x:rel='#weak.and.strong.validators' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
[8] | 24 | ]> |
---|
| 25 | <?rfc toc="yes" ?> |
---|
[29] | 26 | <?rfc symrefs="yes" ?> |
---|
| 27 | <?rfc sortrefs="yes" ?> |
---|
[8] | 28 | <?rfc compact="yes"?> |
---|
| 29 | <?rfc subcompact="no" ?> |
---|
| 30 | <?rfc linkmailto="no" ?> |
---|
| 31 | <?rfc editing="no" ?> |
---|
[203] | 32 | <?rfc comments="yes"?> |
---|
| 33 | <?rfc inline="yes"?> |
---|
[8] | 34 | <?rfc-ext allow-markup-in-artwork="yes" ?> |
---|
| 35 | <?rfc-ext include-references-in-index="yes" ?> |
---|
[308] | 36 | <rfc obsoletes="2616" category="std" x:maturity-level="draft" |
---|
[29] | 37 | ipr="full3978" docName="draft-ietf-httpbis-p5-range-&ID-VERSION;" |
---|
[153] | 38 | xmlns:x='http://purl.org/net/xml2rfc/ext'> |
---|
[8] | 39 | <front> |
---|
| 40 | |
---|
[120] | 41 | <title abbrev="HTTP/1.1, Part 5">HTTP/1.1, part 5: Range Requests and Partial Responses</title> |
---|
[8] | 42 | |
---|
[29] | 43 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> |
---|
| 44 | <organization abbrev="Day Software">Day Software</organization> |
---|
[8] | 45 | <address> |
---|
| 46 | <postal> |
---|
[29] | 47 | <street>23 Corporate Plaza DR, Suite 280</street> |
---|
| 48 | <city>Newport Beach</city> |
---|
[8] | 49 | <region>CA</region> |
---|
[29] | 50 | <code>92660</code> |
---|
| 51 | <country>USA</country> |
---|
[8] | 52 | </postal> |
---|
[29] | 53 | <phone>+1-949-706-5300</phone> |
---|
| 54 | <facsimile>+1-949-706-5305</facsimile> |
---|
| 55 | <email>fielding@gbiv.com</email> |
---|
| 56 | <uri>http://roy.gbiv.com/</uri> |
---|
[8] | 57 | </address> |
---|
| 58 | </author> |
---|
| 59 | |
---|
[29] | 60 | <author initials="J." surname="Gettys" fullname="Jim Gettys"> |
---|
| 61 | <organization>One Laptop per Child</organization> |
---|
[8] | 62 | <address> |
---|
| 63 | <postal> |
---|
[29] | 64 | <street>21 Oak Knoll Road</street> |
---|
| 65 | <city>Carlisle</city> |
---|
[8] | 66 | <region>MA</region> |
---|
[29] | 67 | <code>01741</code> |
---|
| 68 | <country>USA</country> |
---|
[8] | 69 | </postal> |
---|
[29] | 70 | <email>jg@laptop.org</email> |
---|
| 71 | <uri>http://www.laptop.org/</uri> |
---|
[8] | 72 | </address> |
---|
| 73 | </author> |
---|
| 74 | |
---|
| 75 | <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul"> |
---|
[29] | 76 | <organization abbrev="HP">Hewlett-Packard Company</organization> |
---|
[8] | 77 | <address> |
---|
| 78 | <postal> |
---|
[29] | 79 | <street>HP Labs, Large Scale Systems Group</street> |
---|
| 80 | <street>1501 Page Mill Road, MS 1177</street> |
---|
[8] | 81 | <city>Palo Alto</city> |
---|
| 82 | <region>CA</region> |
---|
[29] | 83 | <code>94304</code> |
---|
| 84 | <country>USA</country> |
---|
[8] | 85 | </postal> |
---|
[29] | 86 | <email>JeffMogul@acm.org</email> |
---|
[8] | 87 | </address> |
---|
| 88 | </author> |
---|
| 89 | |
---|
| 90 | <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen"> |
---|
[29] | 91 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
[8] | 92 | <address> |
---|
| 93 | <postal> |
---|
[29] | 94 | <street>1 Microsoft Way</street> |
---|
| 95 | <city>Redmond</city> |
---|
| 96 | <region>WA</region> |
---|
| 97 | <code>98052</code> |
---|
| 98 | <country>USA</country> |
---|
[8] | 99 | </postal> |
---|
[29] | 100 | <email>henrikn@microsoft.com</email> |
---|
[8] | 101 | </address> |
---|
| 102 | </author> |
---|
| 103 | |
---|
| 104 | <author initials="L." surname="Masinter" fullname="Larry Masinter"> |
---|
[29] | 105 | <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization> |
---|
[8] | 106 | <address> |
---|
| 107 | <postal> |
---|
[29] | 108 | <street>345 Park Ave</street> |
---|
| 109 | <city>San Jose</city> |
---|
[8] | 110 | <region>CA</region> |
---|
[29] | 111 | <code>95110</code> |
---|
| 112 | <country>USA</country> |
---|
[8] | 113 | </postal> |
---|
[29] | 114 | <email>LMM@acm.org</email> |
---|
| 115 | <uri>http://larry.masinter.net/</uri> |
---|
[8] | 116 | </address> |
---|
| 117 | </author> |
---|
| 118 | |
---|
| 119 | <author initials="P." surname="Leach" fullname="Paul J. Leach"> |
---|
| 120 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
| 121 | <address> |
---|
| 122 | <postal> |
---|
| 123 | <street>1 Microsoft Way</street> |
---|
| 124 | <city>Redmond</city> |
---|
| 125 | <region>WA</region> |
---|
| 126 | <code>98052</code> |
---|
| 127 | </postal> |
---|
| 128 | <email>paulle@microsoft.com</email> |
---|
| 129 | </address> |
---|
| 130 | </author> |
---|
| 131 | |
---|
| 132 | <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> |
---|
| 133 | <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> |
---|
| 134 | <address> |
---|
| 135 | <postal> |
---|
[34] | 136 | <street>MIT Computer Science and Artificial Intelligence Laboratory</street> |
---|
| 137 | <street>The Stata Center, Building 32</street> |
---|
| 138 | <street>32 Vassar Street</street> |
---|
[8] | 139 | <city>Cambridge</city> |
---|
| 140 | <region>MA</region> |
---|
| 141 | <code>02139</code> |
---|
[29] | 142 | <country>USA</country> |
---|
[8] | 143 | </postal> |
---|
| 144 | <email>timbl@w3.org</email> |
---|
[34] | 145 | <uri>http://www.w3.org/People/Berners-Lee/</uri> |
---|
[8] | 146 | </address> |
---|
| 147 | </author> |
---|
| 148 | |
---|
[95] | 149 | <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor"> |
---|
[94] | 150 | <organization abbrev="W3C">World Wide Web Consortium</organization> |
---|
| 151 | <address> |
---|
| 152 | <postal> |
---|
| 153 | <street>W3C / ERCIM</street> |
---|
| 154 | <street>2004, rte des Lucioles</street> |
---|
| 155 | <city>Sophia-Antipolis</city> |
---|
| 156 | <region>AM</region> |
---|
| 157 | <code>06902</code> |
---|
| 158 | <country>France</country> |
---|
| 159 | </postal> |
---|
| 160 | <email>ylafon@w3.org</email> |
---|
| 161 | <uri>http://www.raubacapeu.net/people/yves/</uri> |
---|
| 162 | </address> |
---|
| 163 | </author> |
---|
| 164 | |
---|
[95] | 165 | <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor"> |
---|
| 166 | <organization abbrev="greenbytes">greenbytes GmbH</organization> |
---|
| 167 | <address> |
---|
| 168 | <postal> |
---|
| 169 | <street>Hafenweg 16</street> |
---|
| 170 | <city>Muenster</city><region>NW</region><code>48155</code> |
---|
| 171 | <country>Germany</country> |
---|
| 172 | </postal> |
---|
| 173 | <phone>+49 251 2807760</phone> |
---|
| 174 | <facsimile>+49 251 2807761</facsimile> |
---|
| 175 | <email>julian.reschke@greenbytes.de</email> |
---|
| 176 | <uri>http://greenbytes.de/tech/webdav/</uri> |
---|
| 177 | </address> |
---|
| 178 | </author> |
---|
| 179 | |
---|
[31] | 180 | <date month="&ID-MONTH;" year="&ID-YEAR;"/> |
---|
[8] | 181 | |
---|
| 182 | <abstract> |
---|
| 183 | <t> |
---|
| 184 | The Hypertext Transfer Protocol (HTTP) is an application-level |
---|
| 185 | protocol for distributed, collaborative, hypermedia information |
---|
[29] | 186 | systems. HTTP has been in use by the World Wide Web global information |
---|
[35] | 187 | initiative since 1990. This document is Part 5 of the seven-part specification |
---|
[29] | 188 | that defines the protocol referred to as "HTTP/1.1" and, taken together, |
---|
[42] | 189 | obsoletes RFC 2616. Part 5 defines range-specific requests and |
---|
[29] | 190 | the rules for constructing and combining responses to those requests. |
---|
[8] | 191 | </t> |
---|
| 192 | </abstract> |
---|
[36] | 193 | |
---|
| 194 | <note title="Editorial Note (To be removed by RFC Editor)"> |
---|
| 195 | <t> |
---|
| 196 | Discussion of this draft should take place on the HTTPBIS working group |
---|
| 197 | mailing list (ietf-http-wg@w3.org). The current issues list is |
---|
[324] | 198 | at <eref target="http://tools.ietf.org/wg/httpbis/trac/report/11"/> |
---|
[36] | 199 | and related documents (including fancy diffs) can be found at |
---|
[324] | 200 | <eref target="http://tools.ietf.org/wg/httpbis/"/>. |
---|
[36] | 201 | </t> |
---|
[153] | 202 | <t> |
---|
[382] | 203 | The changes in this draft are summarized in <xref target="changes.since.05"/>. |
---|
[153] | 204 | </t> |
---|
[36] | 205 | </note> |
---|
[8] | 206 | </front> |
---|
| 207 | <middle> |
---|
| 208 | <section title="Introduction" anchor="introduction"> |
---|
| 209 | <t> |
---|
[158] | 210 | HTTP clients often encounter interrupted data transfers as a result |
---|
| 211 | of cancelled requests or dropped connections. When a cache has stored |
---|
| 212 | a partial representation, it is desirable to request the remainder |
---|
| 213 | of that representation in a subsequent request rather than transfer |
---|
| 214 | the entire representation. |
---|
| 215 | There are also a number of Web applications that benefit from being |
---|
| 216 | able to request only a subset of a larger representation, such as a |
---|
| 217 | single page of a very large document or only part of an image to be |
---|
| 218 | rendered by a device with limited local storage. |
---|
[8] | 219 | </t> |
---|
[158] | 220 | <t> |
---|
[163] | 221 | This document defines HTTP/1.1 range requests, |
---|
[158] | 222 | partial responses, and the multipart/byteranges media type. |
---|
[163] | 223 | The protocol for range requests is an &OPTIONAL; feature of HTTP, |
---|
[158] | 224 | designed so resources or recipients that do not implement this feature |
---|
| 225 | can respond as if it is a normal GET request without impacting |
---|
| 226 | interoperability. Partial responses are indicated by a distinct status |
---|
| 227 | code to not be mistaken for full responses by intermediate caches |
---|
| 228 | that might not implement the feature. |
---|
| 229 | </t> |
---|
| 230 | <t> |
---|
[163] | 231 | Although the HTTP range request mechanism is designed to allow for |
---|
[158] | 232 | extensible range types, this specification only defines requests for |
---|
| 233 | byte ranges. |
---|
| 234 | </t> |
---|
[96] | 235 | |
---|
| 236 | <section title="Requirements" anchor="intro.requirements"> |
---|
| 237 | <t> |
---|
| 238 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |
---|
| 239 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |
---|
| 240 | document are to be interpreted as described in <xref target="RFC2119"/>. |
---|
| 241 | </t> |
---|
| 242 | <t> |
---|
| 243 | An implementation is not compliant if it fails to satisfy one or more |
---|
| 244 | of the &MUST; or &REQUIRED; level requirements for the protocols it |
---|
| 245 | implements. An implementation that satisfies all the &MUST; or &REQUIRED; |
---|
| 246 | level and all the &SHOULD; level requirements for its protocols is said |
---|
| 247 | to be "unconditionally compliant"; one that satisfies all the &MUST; |
---|
| 248 | level requirements but not all the &SHOULD; level requirements for its |
---|
| 249 | protocols is said to be "conditionally compliant." |
---|
| 250 | </t> |
---|
[8] | 251 | </section> |
---|
| 252 | |
---|
[424] | 253 | <section title="Syntax Notation" anchor="notation"> |
---|
[425] | 254 | <x:anchor-alias value="ALPHA"/> |
---|
| 255 | <x:anchor-alias value="CHAR"/> |
---|
| 256 | <x:anchor-alias value="CR"/> |
---|
| 257 | <x:anchor-alias value="DIGIT"/> |
---|
| 258 | <x:anchor-alias value="LF"/> |
---|
| 259 | <x:anchor-alias value="OCTET"/> |
---|
| 260 | <x:anchor-alias value="SP"/> |
---|
| 261 | <x:anchor-alias value="VCHAR"/> |
---|
| 262 | <x:anchor-alias value="WSP"/> |
---|
[424] | 263 | <t> |
---|
| 264 | This specification uses the ABNF syntax defined in ¬ation;. |
---|
[425] | 265 | The following core rules are included by |
---|
| 266 | reference, as defined in <xref target="RFC5234" x:fmt="," x:sec="B.1"/>: |
---|
| 267 | ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), |
---|
| 268 | DIGIT (decimal 0-9), DQUOTE (double quote), |
---|
| 269 | HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), |
---|
| 270 | OCTET (any 8-bit sequence of data), SP (space), |
---|
| 271 | VCHAR (any visible USASCII character), |
---|
| 272 | and WSP (whitespace). |
---|
[424] | 273 | </t> |
---|
| 274 | |
---|
| 275 | <section title="Core Rules" anchor="core.rules"> |
---|
[229] | 276 | <x:anchor-alias value="token"/> |
---|
[363] | 277 | <x:anchor-alias value="OWS"/> |
---|
[205] | 278 | <t> |
---|
[424] | 279 | The core rules below are defined in &basic-rules;: |
---|
[205] | 280 | </t> |
---|
| 281 | <figure><artwork type="abnf2616"> |
---|
[229] | 282 | <x:ref>token</x:ref> = <token, defined in &basic-rules;> |
---|
[363] | 283 | <x:ref>OWS</x:ref> = <OWS, defined in &basic-rules;> |
---|
[205] | 284 | </artwork></figure> |
---|
[424] | 285 | </section> |
---|
| 286 | |
---|
| 287 | <section title="ABNF Rules defined in other Parts of the Specification" anchor="abnf.dependencies"> |
---|
[229] | 288 | <x:anchor-alias value="entity-tag"/> |
---|
| 289 | <x:anchor-alias value="HTTP-date"/> |
---|
[424] | 290 | <t> |
---|
[205] | 291 | The ABNF rules below are defined in other parts: |
---|
| 292 | </t> |
---|
[207] | 293 | <figure><!--Part1--><artwork type="abnf2616"> |
---|
[229] | 294 | <x:ref>HTTP-date</x:ref> = <HTTP-date, defined in &full-date;> |
---|
[205] | 295 | </artwork></figure> |
---|
[207] | 296 | <figure><!--Part4--><artwork type="abnf2616"> |
---|
[229] | 297 | <x:ref>entity-tag</x:ref> = <entity-tag, defined in &entity-tags;> |
---|
[205] | 298 | </artwork></figure> |
---|
| 299 | </section> |
---|
| 300 | |
---|
[424] | 301 | </section> |
---|
| 302 | |
---|
| 303 | </section> |
---|
| 304 | |
---|
| 305 | |
---|
[8] | 306 | <section title="Range Units" anchor="range.units"> |
---|
[229] | 307 | <x:anchor-alias value="bytes-unit"/> |
---|
| 308 | <x:anchor-alias value="other-range-unit"/> |
---|
| 309 | <x:anchor-alias value="range-unit"/> |
---|
[8] | 310 | <t> |
---|
| 311 | HTTP/1.1 allows a client to request that only part (a range of) the |
---|
| 312 | response entity be included within the response. HTTP/1.1 uses range |
---|
| 313 | units in the Range (<xref target="header.range"/>) and Content-Range (<xref target="header.content-range"/>) |
---|
| 314 | header fields. An entity can be broken down into subranges according |
---|
| 315 | to various structural units. |
---|
| 316 | </t> |
---|
| 317 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="range-unit"/><iref primary="true" item="Grammar" subitem="bytes-unit"/><iref primary="true" item="Grammar" subitem="other-range-unit"/> |
---|
[334] | 318 | <x:ref>range-unit</x:ref> = <x:ref>bytes-unit</x:ref> / <x:ref>other-range-unit</x:ref> |
---|
[229] | 319 | <x:ref>bytes-unit</x:ref> = "bytes" |
---|
| 320 | <x:ref>other-range-unit</x:ref> = <x:ref>token</x:ref> |
---|
[8] | 321 | </artwork></figure> |
---|
| 322 | <t> |
---|
[393] | 323 | HTTP/1.1 has been designed to allow implementations of applications |
---|
| 324 | that do not depend on knowledge of ranges. The only range unit defined |
---|
| 325 | by HTTP/1.1 is "bytes". |
---|
[8] | 326 | </t> |
---|
| 327 | <t> |
---|
[393] | 328 | If a range unit is not understood in a request, a server &MUST; ignore |
---|
| 329 | the whole Range header (<xref target="header.range" />). |
---|
| 330 | If a range unit is not understood in a response, an intermediary |
---|
| 331 | &SHOULD; pass the response to the client; a client &MUST; fail. |
---|
[8] | 332 | </t> |
---|
| 333 | </section> |
---|
| 334 | |
---|
[39] | 335 | <section title="Status Code Definitions"> |
---|
[8] | 336 | <section title="206 Partial Content" anchor="status.206"> |
---|
| 337 | <iref primary="true" item="206 Partial Content (status code)" x:for-anchor=""/> |
---|
| 338 | <iref primary="true" item="Status Codes" subitem="206 Partial Content" x:for-anchor=""/> |
---|
| 339 | <t> |
---|
| 340 | The server has fulfilled the partial GET request for the resource. |
---|
| 341 | The request &MUST; have included a Range header field (<xref target="header.range"/>) |
---|
| 342 | indicating the desired range, and &MAY; have included an If-Range |
---|
| 343 | header field (<xref target="header.if-range"/>) to make the request conditional. |
---|
| 344 | </t> |
---|
| 345 | <t> |
---|
| 346 | The response &MUST; include the following header fields: |
---|
| 347 | <list style="symbols"> |
---|
| 348 | <t> |
---|
| 349 | Either a Content-Range header field (<xref target="header.content-range"/>) indicating |
---|
| 350 | the range included with this response, or a multipart/byteranges |
---|
| 351 | Content-Type including Content-Range fields for each part. If a |
---|
| 352 | Content-Length header field is present in the response, its |
---|
| 353 | value &MUST; match the actual number of OCTETs transmitted in the |
---|
| 354 | message-body. |
---|
| 355 | </t> |
---|
| 356 | <t> |
---|
| 357 | Date |
---|
| 358 | </t> |
---|
| 359 | <t> |
---|
| 360 | ETag and/or Content-Location, if the header would have been sent |
---|
| 361 | in a 200 response to the same request |
---|
| 362 | </t> |
---|
| 363 | <t> |
---|
| 364 | Expires, Cache-Control, and/or Vary, if the field-value might |
---|
| 365 | differ from that sent in any previous response for the same |
---|
| 366 | variant |
---|
| 367 | </t> |
---|
| 368 | </list> |
---|
| 369 | </t> |
---|
| 370 | <t> |
---|
[79] | 371 | If the 206 response is the result of an If-Range request, the response |
---|
| 372 | &SHOULD-NOT; include other entity-headers. Otherwise, the response |
---|
[8] | 373 | &MUST; include all of the entity-headers that would have been returned |
---|
| 374 | with a 200 (OK) response to the same request. |
---|
| 375 | </t> |
---|
| 376 | <t> |
---|
| 377 | A cache &MUST-NOT; combine a 206 response with other previously cached |
---|
| 378 | content if the ETag or Last-Modified headers do not match exactly, |
---|
[141] | 379 | see <xref target="combining.byte.ranges"/>. |
---|
[8] | 380 | </t> |
---|
| 381 | <t> |
---|
| 382 | A cache that does not support the Range and Content-Range headers |
---|
[393] | 383 | &MUST-NOT; cache 206 (Partial Content) responses. Furthermore, |
---|
| 384 | if a response uses a range unit that is not understood by the cache, |
---|
| 385 | then it &MUST-NOT; be cached either. |
---|
[8] | 386 | </t> |
---|
| 387 | </section> |
---|
| 388 | |
---|
| 389 | <section title="416 Requested Range Not Satisfiable" anchor="status.416"> |
---|
| 390 | <iref primary="true" item="416 Requested Range Not Satisfiable (status code)" x:for-anchor=""/> |
---|
| 391 | <iref primary="true" item="Status Codes" subitem="416 Requested Range Not Satisfiable" x:for-anchor=""/> |
---|
| 392 | <t> |
---|
| 393 | A server &SHOULD; return a response with this status code if a request |
---|
| 394 | included a Range request-header field (<xref target="header.range"/>), and none of |
---|
[359] | 395 | the ranges-specifier values in this field overlap the current extent |
---|
[8] | 396 | of the selected resource, and the request did not include an If-Range |
---|
| 397 | request-header field. (For byte-ranges, this means that the first-byte-pos |
---|
| 398 | of all of the byte-range-spec values were greater than the |
---|
| 399 | current length of the selected resource.) |
---|
| 400 | </t> |
---|
| 401 | <t> |
---|
| 402 | When this status code is returned for a byte-range request, the |
---|
| 403 | response &SHOULD; include a Content-Range entity-header field |
---|
| 404 | specifying the current length of the selected resource (see <xref target="header.content-range"/>). |
---|
| 405 | This response &MUST-NOT; use the multipart/byteranges content-type. |
---|
| 406 | </t> |
---|
| 407 | </section> |
---|
[39] | 408 | </section> |
---|
[8] | 409 | |
---|
[393] | 410 | <section title="Combining Ranges" anchor="combining.byte.ranges"> |
---|
[8] | 411 | <t> |
---|
[393] | 412 | A response might transfer only a subrange of an entity-body, either |
---|
| 413 | the request included one or more Range specifications, or because |
---|
| 414 | a connection was broken prematurely. |
---|
| 415 | After several such transfers, a cache might have received several |
---|
| 416 | ranges of the same entity-body. |
---|
[8] | 417 | </t> |
---|
| 418 | <t> |
---|
| 419 | If a cache has a stored non-empty set of subranges for an entity, and |
---|
| 420 | an incoming response transfers another subrange, the cache &MAY; |
---|
| 421 | combine the new subrange with the existing set if both the following |
---|
| 422 | conditions are met: |
---|
| 423 | <list style="symbols"> |
---|
| 424 | <t>Both the incoming response and the cache entry have a cache |
---|
| 425 | validator.</t> |
---|
| 426 | <t>The two cache validators match using the strong comparison |
---|
[29] | 427 | function (see &weak-and-strong-validators;).</t> |
---|
[8] | 428 | </list> |
---|
| 429 | </t> |
---|
| 430 | <t> |
---|
| 431 | If either requirement is not met, the cache &MUST; use only the most |
---|
| 432 | recent partial response (based on the Date values transmitted with |
---|
| 433 | every response, and using the incoming response if these values are |
---|
| 434 | equal or missing), and &MUST; discard the other partial information. |
---|
| 435 | </t> |
---|
| 436 | </section> |
---|
| 437 | |
---|
| 438 | <section title="Header Field Definitions" anchor="header.fields"> |
---|
| 439 | <t> |
---|
[117] | 440 | This section defines the syntax and semantics of HTTP/1.1 header fields |
---|
| 441 | related to range requests and partial responses. |
---|
[8] | 442 | </t> |
---|
[117] | 443 | <t> |
---|
| 444 | For entity-header fields, both sender and recipient refer to either the |
---|
| 445 | client or the server, depending on who sends and who receives the entity. |
---|
| 446 | </t> |
---|
| 447 | |
---|
[8] | 448 | <section title="Accept-Ranges" anchor="header.accept-ranges"> |
---|
| 449 | <iref primary="true" item="Accept-Ranges header" x:for-anchor=""/> |
---|
| 450 | <iref primary="true" item="Headers" subitem="Accept-Ranges" x:for-anchor=""/> |
---|
[229] | 451 | <x:anchor-alias value="Accept-Ranges"/> |
---|
[363] | 452 | <x:anchor-alias value="Accept-Ranges-v"/> |
---|
[229] | 453 | <x:anchor-alias value="acceptable-ranges"/> |
---|
[8] | 454 | <t> |
---|
[363] | 455 | The response-header "Accept-Ranges" field allows the server to |
---|
[8] | 456 | indicate its acceptance of range requests for a resource: |
---|
| 457 | </t> |
---|
[363] | 458 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept-Ranges"/><iref primary="true" item="Grammar" subitem="Accept-Ranges-v"/><iref primary="true" item="Grammar" subitem="acceptable-ranges"/> |
---|
[366] | 459 | <x:ref>Accept-Ranges</x:ref> = "Accept-Ranges" ":" <x:ref>OWS</x:ref> <x:ref>Accept-Ranges-v</x:ref> |
---|
[363] | 460 | <x:ref>Accept-Ranges-v</x:ref> = <x:ref>acceptable-ranges</x:ref> |
---|
[334] | 461 | <x:ref>acceptable-ranges</x:ref> = 1#<x:ref>range-unit</x:ref> / "none" |
---|
[8] | 462 | </artwork></figure> |
---|
| 463 | <t> |
---|
| 464 | Origin servers that accept byte-range requests &MAY; send |
---|
| 465 | </t> |
---|
| 466 | <figure><artwork type="example"> |
---|
[363] | 467 | Accept-Ranges: bytes |
---|
[8] | 468 | </artwork></figure> |
---|
| 469 | <t> |
---|
[393] | 470 | but are not required to do so. Clients &MAY; generate range |
---|
[8] | 471 | requests without having received this header for the resource |
---|
| 472 | involved. Range units are defined in <xref target="range.units"/>. |
---|
| 473 | </t> |
---|
| 474 | <t> |
---|
| 475 | Servers that do not accept any kind of range request for a |
---|
| 476 | resource &MAY; send |
---|
| 477 | </t> |
---|
| 478 | <figure><artwork type="example"> |
---|
[363] | 479 | Accept-Ranges: none |
---|
[8] | 480 | </artwork></figure> |
---|
| 481 | <t> |
---|
| 482 | to advise the client not to attempt a range request. |
---|
| 483 | </t> |
---|
| 484 | </section> |
---|
| 485 | |
---|
| 486 | <section title="Content-Range" anchor="header.content-range"> |
---|
| 487 | <iref primary="true" item="Content-Range header" x:for-anchor=""/> |
---|
| 488 | <iref primary="true" item="Headers" subitem="Content-Range" x:for-anchor=""/> |
---|
[229] | 489 | <x:anchor-alias value="byte-content-range-spec"/> |
---|
| 490 | <x:anchor-alias value="byte-range-resp-spec"/> |
---|
| 491 | <x:anchor-alias value="Content-Range"/> |
---|
[363] | 492 | <x:anchor-alias value="Content-Range-v"/> |
---|
[229] | 493 | <x:anchor-alias value="content-range-spec"/> |
---|
| 494 | <x:anchor-alias value="instance-length"/> |
---|
[393] | 495 | <x:anchor-alias value="other-content-range-spec"/> |
---|
| 496 | <x:anchor-alias value="other-range-resp-spec"/> |
---|
[8] | 497 | <t> |
---|
[363] | 498 | The entity-header "Content-Range" is sent with a partial entity-body to |
---|
[8] | 499 | specify where in the full entity-body the partial body should be |
---|
| 500 | applied. Range units are defined in <xref target="range.units"/>. |
---|
| 501 | </t> |
---|
[363] | 502 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Range"/><iref primary="true" item="Grammar" subitem="Content-Range-v"/><iref primary="true" item="Grammar" subitem="content-range-spec"/><iref primary="true" item="Grammar" subitem="byte-content-range-spec"/><iref primary="true" item="Grammar" subitem="byte-range-resp-spec"/><iref primary="true" item="Grammar" subitem="instance-length"/> |
---|
[366] | 503 | <x:ref>Content-Range</x:ref> = "Content-Range" ":" <x:ref>OWS</x:ref> <x:ref>Content-Range-v</x:ref> |
---|
[363] | 504 | <x:ref>Content-Range-v</x:ref> = <x:ref>content-range-spec</x:ref> |
---|
[135] | 505 | |
---|
[229] | 506 | <x:ref>content-range-spec</x:ref> = <x:ref>byte-content-range-spec</x:ref> |
---|
[434] | 507 | / <x:ref>other-content-range-spec</x:ref> |
---|
[229] | 508 | <x:ref>byte-content-range-spec</x:ref> = <x:ref>bytes-unit</x:ref> <x:ref>SP</x:ref> |
---|
| 509 | <x:ref>byte-range-resp-spec</x:ref> "/" |
---|
[334] | 510 | ( <x:ref>instance-length</x:ref> / "*" ) |
---|
[135] | 511 | |
---|
[304] | 512 | <x:ref>byte-range-resp-spec</x:ref> = (<x:ref>first-byte-pos</x:ref> "-" <x:ref>last-byte-pos</x:ref>) |
---|
[334] | 513 | / "*" |
---|
[304] | 514 | |
---|
| 515 | <x:ref>instance-length</x:ref> = 1*<x:ref>DIGIT</x:ref> |
---|
[393] | 516 | |
---|
| 517 | <x:ref>other-content-range-spec</x:ref> = <x:ref>other-range-unit</x:ref> <x:ref>SP</x:ref> |
---|
| 518 | <x:ref>other-range-resp-spec</x:ref> |
---|
| 519 | <x:ref>other-range-resp-spec</x:ref> = *<x:ref>CHAR</x:ref> |
---|
[8] | 520 | </artwork></figure> |
---|
| 521 | <t> |
---|
| 522 | The header &SHOULD; indicate the total length of the full entity-body, |
---|
| 523 | unless this length is unknown or difficult to determine. The asterisk |
---|
| 524 | "*" character means that the instance-length is unknown at the time |
---|
| 525 | when the response was generated. |
---|
| 526 | </t> |
---|
| 527 | <t> |
---|
| 528 | Unlike byte-ranges-specifier values (see <xref target="byte.ranges"/>), a byte-range-resp-spec |
---|
| 529 | &MUST; only specify one range, and &MUST; contain |
---|
| 530 | absolute byte positions for both the first and last byte of the |
---|
| 531 | range. |
---|
| 532 | </t> |
---|
| 533 | <t> |
---|
| 534 | A byte-content-range-spec with a byte-range-resp-spec whose last-byte-pos |
---|
| 535 | value is less than its first-byte-pos value, or whose |
---|
| 536 | instance-length value is less than or equal to its last-byte-pos |
---|
| 537 | value, is invalid. The recipient of an invalid byte-content-range-spec |
---|
| 538 | &MUST; ignore it and any content transferred along with it. |
---|
| 539 | </t> |
---|
| 540 | <t> |
---|
[393] | 541 | In the case of a byte range request: |
---|
[8] | 542 | A server sending a response with status code 416 (Requested range not |
---|
| 543 | satisfiable) &SHOULD; include a Content-Range field with a byte-range-resp-spec |
---|
| 544 | of "*". The instance-length specifies the current length of |
---|
[438] | 545 | the selected resource as a decimal number. A response with status code 206 (Partial |
---|
[8] | 546 | Content) &MUST-NOT; include a Content-Range field with a byte-range-resp-spec of "*". |
---|
| 547 | </t> |
---|
| 548 | <t> |
---|
| 549 | Examples of byte-content-range-spec values, assuming that the entity |
---|
| 550 | contains a total of 1234 bytes: |
---|
| 551 | <list style="symbols"> |
---|
| 552 | <t> |
---|
| 553 | The first 500 bytes: |
---|
| 554 | <figure><artwork type="text/plain"> |
---|
| 555 | bytes 0-499/1234 |
---|
| 556 | </artwork></figure> |
---|
| 557 | </t> |
---|
| 558 | <t> |
---|
| 559 | The second 500 bytes: |
---|
| 560 | <figure><artwork type="text/plain"> |
---|
| 561 | bytes 500-999/1234 |
---|
| 562 | </artwork></figure> |
---|
| 563 | </t> |
---|
| 564 | <t> |
---|
| 565 | All except for the first 500 bytes: |
---|
| 566 | <figure><artwork type="text/plain"> |
---|
| 567 | bytes 500-1233/1234 |
---|
| 568 | </artwork></figure> |
---|
| 569 | </t> |
---|
| 570 | <t> |
---|
| 571 | The last 500 bytes: |
---|
| 572 | <figure><artwork type="text/plain"> |
---|
| 573 | bytes 734-1233/1234 |
---|
| 574 | </artwork></figure> |
---|
| 575 | </t> |
---|
| 576 | </list> |
---|
| 577 | </t> |
---|
| 578 | <t> |
---|
| 579 | When an HTTP message includes the content of a single range (for |
---|
| 580 | example, a response to a request for a single range, or to a request |
---|
| 581 | for a set of ranges that overlap without any holes), this content is |
---|
| 582 | transmitted with a Content-Range header, and a Content-Length header |
---|
| 583 | showing the number of bytes actually transferred. For example, |
---|
| 584 | </t> |
---|
| 585 | <figure><artwork type="example"> |
---|
[363] | 586 | HTTP/1.1 206 Partial Content |
---|
| 587 | Date: Wed, 15 Nov 1995 06:25:24 GMT |
---|
| 588 | Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT |
---|
| 589 | Content-Range: bytes 21010-47021/47022 |
---|
| 590 | Content-Length: 26012 |
---|
| 591 | Content-Type: image/gif |
---|
[8] | 592 | </artwork></figure> |
---|
| 593 | <t> |
---|
| 594 | When an HTTP message includes the content of multiple ranges (for |
---|
| 595 | example, a response to a request for multiple non-overlapping |
---|
| 596 | ranges), these are transmitted as a multipart message. The multipart |
---|
| 597 | media type used for this purpose is "multipart/byteranges" as defined |
---|
| 598 | in <xref target="internet.media.type.multipart.byteranges"/>. See <xref target="changes.from.rfc.2068"/> for a compatibility issue. |
---|
| 599 | </t> |
---|
| 600 | <t> |
---|
| 601 | A response to a request for a single range &MUST-NOT; be sent using the |
---|
| 602 | multipart/byteranges media type. A response to a request for |
---|
| 603 | multiple ranges, whose result is a single range, &MAY; be sent as a |
---|
| 604 | multipart/byteranges media type with one part. A client that cannot |
---|
| 605 | decode a multipart/byteranges message &MUST-NOT; ask for multiple |
---|
[393] | 606 | ranges in a single request. |
---|
[8] | 607 | </t> |
---|
| 608 | <t> |
---|
| 609 | When a client requests multiple byte-ranges in one request, the |
---|
| 610 | server &SHOULD; return them in the order that they appeared in the |
---|
| 611 | request. |
---|
| 612 | </t> |
---|
| 613 | <t> |
---|
| 614 | If the server ignores a byte-range-spec because it is syntactically |
---|
| 615 | invalid, the server &SHOULD; treat the request as if the invalid Range |
---|
| 616 | header field did not exist. (Normally, this means return a 200 |
---|
| 617 | response containing the full entity). |
---|
| 618 | </t> |
---|
| 619 | <t> |
---|
| 620 | If the server receives a request (other than one including an If-Range |
---|
| 621 | request-header field) with an unsatisfiable Range request-header |
---|
| 622 | field (that is, all of whose byte-range-spec values have a |
---|
| 623 | first-byte-pos value greater than the current length of the selected |
---|
| 624 | resource), it &SHOULD; return a response code of 416 (Requested range |
---|
| 625 | not satisfiable) (<xref target="status.416"/>). |
---|
| 626 | <list><t> |
---|
| 627 | <x:h>Note:</x:h> clients cannot depend on servers to send a 416 (Requested |
---|
| 628 | range not satisfiable) response instead of a 200 (OK) response for |
---|
| 629 | an unsatisfiable Range request-header, since not all servers |
---|
| 630 | implement this request-header. |
---|
| 631 | </t></list> |
---|
| 632 | </t> |
---|
| 633 | </section> |
---|
| 634 | |
---|
| 635 | <section title="If-Range" anchor="header.if-range"> |
---|
| 636 | <iref primary="true" item="If-Range header" x:for-anchor=""/> |
---|
| 637 | <iref primary="true" item="Headers" subitem="If-Range" x:for-anchor=""/> |
---|
[229] | 638 | <x:anchor-alias value="If-Range"/> |
---|
[363] | 639 | <x:anchor-alias value="If-Range-v"/> |
---|
[8] | 640 | <t> |
---|
| 641 | If a client has a partial copy of an entity in its cache, and wishes |
---|
| 642 | to have an up-to-date copy of the entire entity in its cache, it |
---|
| 643 | could use the Range request-header with a conditional GET (using |
---|
| 644 | either or both of If-Unmodified-Since and If-Match.) However, if the |
---|
| 645 | condition fails because the entity has been modified, the client |
---|
| 646 | would then have to make a second request to obtain the entire current |
---|
| 647 | entity-body. |
---|
| 648 | </t> |
---|
| 649 | <t> |
---|
[363] | 650 | The request header "If-Range" allows a client to "short-circuit" the second |
---|
[8] | 651 | request. Informally, its meaning is `if the entity is unchanged, send |
---|
| 652 | me the part(s) that I am missing; otherwise, send me the entire new |
---|
| 653 | entity'. |
---|
| 654 | </t> |
---|
[363] | 655 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-Range"/><iref primary="true" item="Grammar" subitem="If-Range-v"/> |
---|
[366] | 656 | <x:ref>If-Range</x:ref> = "If-Range" ":" <x:ref>OWS</x:ref> <x:ref>If-Range-v</x:ref> |
---|
[363] | 657 | <x:ref>If-Range-v</x:ref> = <x:ref>entity-tag</x:ref> / <x:ref>HTTP-date</x:ref> |
---|
[8] | 658 | </artwork></figure> |
---|
| 659 | <t> |
---|
| 660 | If the client has no entity tag for an entity, but does have a Last-Modified |
---|
| 661 | date, it &MAY; use that date in an If-Range header. (The |
---|
| 662 | server can distinguish between a valid HTTP-date and any form of |
---|
| 663 | entity-tag by examining no more than two characters.) The If-Range |
---|
| 664 | header &SHOULD; only be used together with a Range header, and &MUST; be |
---|
| 665 | ignored if the request does not include a Range header, or if the |
---|
| 666 | server does not support the sub-range operation. |
---|
| 667 | </t> |
---|
| 668 | <t> |
---|
| 669 | If the entity tag given in the If-Range header matches the current |
---|
| 670 | entity tag for the entity, then the server &SHOULD; provide the |
---|
[137] | 671 | specified sub-range of the entity using a 206 (Partial Content) |
---|
[8] | 672 | response. If the entity tag does not match, then the server &SHOULD; |
---|
| 673 | return the entire entity using a 200 (OK) response. |
---|
| 674 | </t> |
---|
| 675 | </section> |
---|
| 676 | |
---|
| 677 | <section title="Range" anchor="header.range"> |
---|
| 678 | <iref primary="true" item="Range header" x:for-anchor=""/> |
---|
| 679 | <iref primary="true" item="Headers" subitem="Range" x:for-anchor=""/> |
---|
| 680 | |
---|
| 681 | <section title="Byte Ranges" anchor="byte.ranges"> |
---|
| 682 | <t> |
---|
| 683 | Since all HTTP entities are represented in HTTP messages as sequences |
---|
| 684 | of bytes, the concept of a byte range is meaningful for any HTTP |
---|
| 685 | entity. (However, not all clients and servers need to support byte-range |
---|
| 686 | operations.) |
---|
| 687 | </t> |
---|
| 688 | <t> |
---|
| 689 | Byte range specifications in HTTP apply to the sequence of bytes in |
---|
| 690 | the entity-body (not necessarily the same as the message-body). |
---|
| 691 | </t> |
---|
[229] | 692 | <t anchor="rule.ranges-specifier"> |
---|
| 693 | <x:anchor-alias value="byte-range-set"/> |
---|
| 694 | <x:anchor-alias value="byte-range-spec"/> |
---|
| 695 | <x:anchor-alias value="byte-ranges-specifier"/> |
---|
| 696 | <x:anchor-alias value="first-byte-pos"/> |
---|
| 697 | <x:anchor-alias value="last-byte-pos"/> |
---|
| 698 | <x:anchor-alias value="ranges-specifier"/> |
---|
| 699 | <x:anchor-alias value="suffix-byte-range-spec"/> |
---|
| 700 | <x:anchor-alias value="suffix-length"/> |
---|
[393] | 701 | <x:anchor-alias value="other-ranges-specifier"/> |
---|
| 702 | |
---|
[8] | 703 | A byte range operation &MAY; specify a single range of bytes, or a set |
---|
| 704 | of ranges within a single entity. |
---|
| 705 | </t> |
---|
| 706 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="ranges-specifier"/><iref primary="true" item="Grammar" subitem="byte-ranges-specifier"/><iref primary="true" item="Grammar" subitem="byte-range-set"/><iref primary="true" item="Grammar" subitem="byte-range-spec"/><iref primary="true" item="Grammar" subitem="first-byte-pos"/><iref primary="true" item="Grammar" subitem="last-byte-pos"/> |
---|
[229] | 707 | <x:ref>byte-ranges-specifier</x:ref> = <x:ref>bytes-unit</x:ref> "=" <x:ref>byte-range-set</x:ref> |
---|
[334] | 708 | <x:ref>byte-range-set</x:ref> = 1#( <x:ref>byte-range-spec</x:ref> / <x:ref>suffix-byte-range-spec</x:ref> ) |
---|
[434] | 709 | <x:ref>byte-range-spec</x:ref> = <x:ref>first-byte-pos</x:ref> "-" [ <x:ref>last-byte-pos</x:ref> ] |
---|
[229] | 710 | <x:ref>first-byte-pos</x:ref> = 1*<x:ref>DIGIT</x:ref> |
---|
| 711 | <x:ref>last-byte-pos</x:ref> = 1*<x:ref>DIGIT</x:ref> |
---|
[8] | 712 | </artwork></figure> |
---|
| 713 | <t> |
---|
| 714 | The first-byte-pos value in a byte-range-spec gives the byte-offset |
---|
| 715 | of the first byte in a range. The last-byte-pos value gives the |
---|
| 716 | byte-offset of the last byte in the range; that is, the byte |
---|
[438] | 717 | positions specified are inclusive. Byte offsets are decimal and start at zero. |
---|
[8] | 718 | </t> |
---|
| 719 | <t> |
---|
| 720 | If the last-byte-pos value is present, it &MUST; be greater than or |
---|
| 721 | equal to the first-byte-pos in that byte-range-spec, or the byte-range-spec |
---|
| 722 | is syntactically invalid. The recipient of a byte-range-set |
---|
| 723 | that includes one or more syntactically invalid byte-range-spec |
---|
| 724 | values &MUST; ignore the header field that includes that byte-range-set. |
---|
| 725 | </t> |
---|
| 726 | <t> |
---|
| 727 | If the last-byte-pos value is absent, or if the value is greater than |
---|
| 728 | or equal to the current length of the entity-body, last-byte-pos is |
---|
| 729 | taken to be equal to one less than the current length of the entity-body |
---|
| 730 | in bytes. |
---|
| 731 | </t> |
---|
| 732 | <t> |
---|
| 733 | By its choice of last-byte-pos, a client can limit the number of |
---|
| 734 | bytes retrieved without knowing the size of the entity. |
---|
| 735 | </t> |
---|
| 736 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="suffix-byte-range-spec"/><iref primary="true" item="Grammar" subitem="suffix-length"/> |
---|
[229] | 737 | <x:ref>suffix-byte-range-spec</x:ref> = "-" <x:ref>suffix-length</x:ref> |
---|
| 738 | <x:ref>suffix-length</x:ref> = 1*<x:ref>DIGIT</x:ref> |
---|
[8] | 739 | </artwork></figure> |
---|
| 740 | <t> |
---|
| 741 | A suffix-byte-range-spec is used to specify the suffix of the |
---|
[438] | 742 | entity-body, of a length given by the decimal suffix-length value. (That is, |
---|
[8] | 743 | this form specifies the last N bytes of an entity-body.) If the |
---|
| 744 | entity is shorter than the specified suffix-length, the entire |
---|
| 745 | entity-body is used. |
---|
| 746 | </t> |
---|
| 747 | <t> |
---|
| 748 | If a syntactically valid byte-range-set includes at least one byte-range-spec |
---|
| 749 | whose first-byte-pos is less than the current length of |
---|
| 750 | the entity-body, or at least one suffix-byte-range-spec with a non-zero |
---|
| 751 | suffix-length, then the byte-range-set is satisfiable. |
---|
| 752 | Otherwise, the byte-range-set is unsatisfiable. If the byte-range-set |
---|
| 753 | is unsatisfiable, the server &SHOULD; return a response with a status |
---|
| 754 | of 416 (Requested range not satisfiable). Otherwise, the server |
---|
| 755 | &SHOULD; return a response with a status of 206 (Partial Content) |
---|
| 756 | containing the satisfiable ranges of the entity-body. |
---|
| 757 | </t> |
---|
| 758 | <t> |
---|
| 759 | Examples of byte-ranges-specifier values (assuming an entity-body of |
---|
| 760 | length 10000): |
---|
| 761 | <list style="symbols"> |
---|
| 762 | <t>The first 500 bytes (byte offsets 0-499, inclusive): bytes=0-499</t> |
---|
| 763 | |
---|
| 764 | <t>The second 500 bytes (byte offsets 500-999, inclusive): |
---|
| 765 | bytes=500-999</t> |
---|
| 766 | |
---|
| 767 | <t>The final 500 bytes (byte offsets 9500-9999, inclusive): |
---|
| 768 | bytes=-500</t> |
---|
| 769 | |
---|
| 770 | <t>Or bytes=9500-</t> |
---|
| 771 | |
---|
| 772 | <t>The first and last bytes only (bytes 0 and 9999): bytes=0-0,-1</t> |
---|
| 773 | |
---|
| 774 | <t>Several legal but not canonical specifications of the second 500 |
---|
| 775 | bytes (byte offsets 500-999, inclusive): |
---|
| 776 | <vspace/> |
---|
| 777 | bytes=500-600,601-999<vspace/> |
---|
| 778 | bytes=500-700,601-999</t> |
---|
| 779 | </list> |
---|
| 780 | </t> |
---|
| 781 | </section> |
---|
| 782 | |
---|
| 783 | <section title="Range Retrieval Requests" anchor="range.retrieval.requests"> |
---|
[229] | 784 | <x:anchor-alias value="Range"/> |
---|
[363] | 785 | <x:anchor-alias value="Range-v"/> |
---|
[8] | 786 | <t> |
---|
| 787 | HTTP retrieval requests using conditional or unconditional GET |
---|
| 788 | methods &MAY; request one or more sub-ranges of the entity, instead of |
---|
| 789 | the entire entity, using the Range request header, which applies to |
---|
| 790 | the entity returned as the result of the request: |
---|
| 791 | </t> |
---|
[393] | 792 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Range"/> |
---|
[434] | 793 | <x:ref>Range</x:ref> = "Range" ":" <x:ref>OWS</x:ref> <x:ref>Range-v</x:ref> |
---|
| 794 | <x:ref>Range-v</x:ref> = <x:ref>byte-ranges-specifier</x:ref> |
---|
| 795 | / <x:ref>other-ranges-specifier</x:ref> |
---|
[393] | 796 | <x:ref>other-ranges-specifier</x:ref> = 1*<x:ref>CHAR</x:ref> |
---|
[8] | 797 | </artwork></figure> |
---|
| 798 | <t> |
---|
| 799 | A server &MAY; ignore the Range header. However, HTTP/1.1 origin |
---|
| 800 | servers and intermediate caches ought to support byte ranges when |
---|
| 801 | possible, since Range supports efficient recovery from partially |
---|
| 802 | failed transfers, and supports efficient partial retrieval of large |
---|
| 803 | entities. |
---|
| 804 | </t> |
---|
| 805 | <t> |
---|
| 806 | If the server supports the Range header and the specified range or |
---|
| 807 | ranges are appropriate for the entity: |
---|
| 808 | <list style="symbols"> |
---|
| 809 | <t>The presence of a Range header in an unconditional GET modifies |
---|
| 810 | what is returned if the GET is otherwise successful. In other |
---|
| 811 | words, the response carries a status code of 206 (Partial |
---|
| 812 | Content) instead of 200 (OK).</t> |
---|
| 813 | |
---|
| 814 | <t>The presence of a Range header in a conditional GET (a request |
---|
| 815 | using one or both of If-Modified-Since and If-None-Match, or |
---|
| 816 | one or both of If-Unmodified-Since and If-Match) modifies what |
---|
| 817 | is returned if the GET is otherwise successful and the |
---|
| 818 | condition is true. It does not affect the 304 (Not Modified) |
---|
| 819 | response returned if the conditional is false.</t> |
---|
| 820 | </list> |
---|
| 821 | </t> |
---|
| 822 | <t> |
---|
| 823 | In some cases, it might be more appropriate to use the If-Range |
---|
| 824 | header (see <xref target="header.if-range"/>) in addition to the Range header. |
---|
| 825 | </t> |
---|
| 826 | <t> |
---|
| 827 | If a proxy that supports ranges receives a Range request, forwards |
---|
| 828 | the request to an inbound server, and receives an entire entity in |
---|
| 829 | reply, it &SHOULD; only return the requested range to its client. It |
---|
| 830 | &SHOULD; store the entire received response in its cache if that is |
---|
| 831 | consistent with its cache allocation policies. |
---|
| 832 | </t> |
---|
| 833 | </section> |
---|
| 834 | </section> |
---|
| 835 | </section> |
---|
| 836 | |
---|
[29] | 837 | <section title="IANA Considerations" anchor="IANA.considerations"> |
---|
[253] | 838 | <section title="Message Header Registration" anchor="message.header.registration"> |
---|
[290] | 839 | <t> |
---|
| 840 | The Message Header Registry located at <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/> should be updated |
---|
| 841 | with the permanent registrations below (see <xref target="RFC3864"/>): |
---|
| 842 | </t> |
---|
[253] | 843 | <!--AUTOGENERATED FROM extract-header-defs.xslt, do not edit manually--> |
---|
[290] | 844 | <texttable align="left" suppress-title="true" anchor="iana.header.registration.table"> |
---|
[253] | 845 | <ttcol>Header Field Name</ttcol> |
---|
| 846 | <ttcol>Protocol</ttcol> |
---|
| 847 | <ttcol>Status</ttcol> |
---|
| 848 | <ttcol>Reference</ttcol> |
---|
| 849 | |
---|
| 850 | <c>Accept-Ranges</c> |
---|
| 851 | <c>http</c> |
---|
| 852 | <c>standard</c> |
---|
| 853 | <c> |
---|
| 854 | <xref target="header.accept-ranges"/> |
---|
| 855 | </c> |
---|
| 856 | <c>Content-Range</c> |
---|
| 857 | <c>http</c> |
---|
| 858 | <c>standard</c> |
---|
| 859 | <c> |
---|
| 860 | <xref target="header.content-range"/> |
---|
| 861 | </c> |
---|
| 862 | <c>If-Range</c> |
---|
| 863 | <c>http</c> |
---|
| 864 | <c>standard</c> |
---|
| 865 | <c> |
---|
| 866 | <xref target="header.if-range"/> |
---|
| 867 | </c> |
---|
| 868 | <c>Range</c> |
---|
| 869 | <c>http</c> |
---|
| 870 | <c>standard</c> |
---|
| 871 | <c> |
---|
| 872 | <xref target="header.range"/> |
---|
| 873 | </c> |
---|
| 874 | </texttable> |
---|
[290] | 875 | <!--(END)--> |
---|
[253] | 876 | <t> |
---|
[290] | 877 | The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force". |
---|
| 878 | </t> |
---|
[8] | 879 | </section> |
---|
[253] | 880 | </section> |
---|
[8] | 881 | |
---|
| 882 | <section title="Security Considerations" anchor="security.considerations"> |
---|
| 883 | <t> |
---|
[29] | 884 | No additional security considerations have been identified beyond |
---|
| 885 | those applicable to HTTP in general &messaging;. |
---|
[8] | 886 | </t> |
---|
| 887 | </section> |
---|
| 888 | |
---|
| 889 | <section title="Acknowledgments" anchor="ack"> |
---|
| 890 | <t> |
---|
| 891 | Most of the specification of ranges is based on work originally done |
---|
| 892 | by Ari Luotonen and John Franks, with additional input from Steve |
---|
[159] | 893 | Zilles, Daniel W. Connolly, Roy T. Fielding, Jim Gettys, Martin Hamilton, |
---|
| 894 | Koen Holtman, Shel Kaplan, Paul Leach, Alex Lopez-Ortiz, Larry Masinter, |
---|
| 895 | Jeff Mogul, Lou Montulli, David W. Morris, Luigi Rizzo, and Bill Weihl. |
---|
[8] | 896 | </t> |
---|
| 897 | </section> |
---|
| 898 | </middle> |
---|
| 899 | <back> |
---|
| 900 | |
---|
[119] | 901 | <references title="Normative References"> |
---|
| 902 | |
---|
[31] | 903 | <reference anchor="Part1"> |
---|
[119] | 904 | <front> |
---|
| 905 | <title abbrev="HTTP/1.1">HTTP/1.1, part 1: URIs, Connections, and Message Parsing</title> |
---|
| 906 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> |
---|
| 907 | <organization abbrev="Day Software">Day Software</organization> |
---|
| 908 | <address><email>fielding@gbiv.com</email></address> |
---|
| 909 | </author> |
---|
| 910 | <author initials="J." surname="Gettys" fullname="Jim Gettys"> |
---|
| 911 | <organization>One Laptop per Child</organization> |
---|
| 912 | <address><email>jg@laptop.org</email></address> |
---|
| 913 | </author> |
---|
| 914 | <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul"> |
---|
| 915 | <organization abbrev="HP">Hewlett-Packard Company</organization> |
---|
| 916 | <address><email>JeffMogul@acm.org</email></address> |
---|
| 917 | </author> |
---|
| 918 | <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen"> |
---|
| 919 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
| 920 | <address><email>henrikn@microsoft.com</email></address> |
---|
| 921 | </author> |
---|
| 922 | <author initials="L." surname="Masinter" fullname="Larry Masinter"> |
---|
| 923 | <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization> |
---|
| 924 | <address><email>LMM@acm.org</email></address> |
---|
| 925 | </author> |
---|
| 926 | <author initials="P." surname="Leach" fullname="Paul J. Leach"> |
---|
| 927 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
| 928 | <address><email>paulle@microsoft.com</email></address> |
---|
| 929 | </author> |
---|
| 930 | <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> |
---|
| 931 | <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> |
---|
| 932 | <address><email>timbl@w3.org</email></address> |
---|
| 933 | </author> |
---|
| 934 | <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor"> |
---|
| 935 | <organization abbrev="W3C">World Wide Web Consortium</organization> |
---|
| 936 | <address><email>ylafon@w3.org</email></address> |
---|
| 937 | </author> |
---|
| 938 | <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor"> |
---|
| 939 | <organization abbrev="greenbytes">greenbytes GmbH</organization> |
---|
| 940 | <address><email>julian.reschke@greenbytes.de</email></address> |
---|
| 941 | </author> |
---|
| 942 | <date month="&ID-MONTH;" year="&ID-YEAR;"/> |
---|
| 943 | </front> |
---|
| 944 | <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p1-messaging-&ID-VERSION;"/> |
---|
| 945 | <x:source href="p1-messaging.xml" basename="p1-messaging"/> |
---|
[31] | 946 | </reference> |
---|
| 947 | |
---|
[138] | 948 | <reference anchor="Part3"> |
---|
| 949 | <front> |
---|
| 950 | <title abbrev="HTTP/1.1">HTTP/1.1, part 3: Message Payload and Content Negotiation</title> |
---|
| 951 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> |
---|
| 952 | <organization abbrev="Day Software">Day Software</organization> |
---|
| 953 | <address><email>fielding@gbiv.com</email></address> |
---|
| 954 | </author> |
---|
| 955 | <author initials="J." surname="Gettys" fullname="Jim Gettys"> |
---|
| 956 | <organization>One Laptop per Child</organization> |
---|
| 957 | <address><email>jg@laptop.org</email></address> |
---|
| 958 | </author> |
---|
| 959 | <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul"> |
---|
| 960 | <organization abbrev="HP">Hewlett-Packard Company</organization> |
---|
| 961 | <address><email>JeffMogul@acm.org</email></address> |
---|
| 962 | </author> |
---|
| 963 | <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen"> |
---|
| 964 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
| 965 | <address><email>henrikn@microsoft.com</email></address> |
---|
| 966 | </author> |
---|
| 967 | <author initials="L." surname="Masinter" fullname="Larry Masinter"> |
---|
| 968 | <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization> |
---|
| 969 | <address><email>LMM@acm.org</email></address> |
---|
| 970 | </author> |
---|
| 971 | <author initials="P." surname="Leach" fullname="Paul J. Leach"> |
---|
| 972 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
| 973 | <address><email>paulle@microsoft.com</email></address> |
---|
| 974 | </author> |
---|
| 975 | <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> |
---|
| 976 | <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> |
---|
| 977 | <address><email>timbl@w3.org</email></address> |
---|
| 978 | </author> |
---|
| 979 | <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor"> |
---|
| 980 | <organization abbrev="W3C">World Wide Web Consortium</organization> |
---|
| 981 | <address><email>ylafon@w3.org</email></address> |
---|
| 982 | </author> |
---|
| 983 | <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor"> |
---|
| 984 | <organization abbrev="greenbytes">greenbytes GmbH</organization> |
---|
| 985 | <address><email>julian.reschke@greenbytes.de</email></address> |
---|
| 986 | </author> |
---|
| 987 | <date month="&ID-MONTH;" year="&ID-YEAR;"/> |
---|
| 988 | </front> |
---|
| 989 | <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p3-payload-&ID-VERSION;"/> |
---|
| 990 | <x:source href="p3-payload.xml" basename="p3-payload"/> |
---|
| 991 | </reference> |
---|
| 992 | |
---|
[31] | 993 | <reference anchor="Part4"> |
---|
[119] | 994 | <front> |
---|
| 995 | <title abbrev="HTTP/1.1">HTTP/1.1, part 4: Conditional Requests</title> |
---|
| 996 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> |
---|
| 997 | <organization abbrev="Day Software">Day Software</organization> |
---|
| 998 | <address><email>fielding@gbiv.com</email></address> |
---|
| 999 | </author> |
---|
| 1000 | <author initials="J." surname="Gettys" fullname="Jim Gettys"> |
---|
| 1001 | <organization>One Laptop per Child</organization> |
---|
| 1002 | <address><email>jg@laptop.org</email></address> |
---|
| 1003 | </author> |
---|
| 1004 | <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul"> |
---|
| 1005 | <organization abbrev="HP">Hewlett-Packard Company</organization> |
---|
| 1006 | <address><email>JeffMogul@acm.org</email></address> |
---|
| 1007 | </author> |
---|
| 1008 | <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen"> |
---|
| 1009 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
| 1010 | <address><email>henrikn@microsoft.com</email></address> |
---|
| 1011 | </author> |
---|
| 1012 | <author initials="L." surname="Masinter" fullname="Larry Masinter"> |
---|
| 1013 | <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization> |
---|
| 1014 | <address><email>LMM@acm.org</email></address> |
---|
| 1015 | </author> |
---|
| 1016 | <author initials="P." surname="Leach" fullname="Paul J. Leach"> |
---|
| 1017 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
| 1018 | <address><email>paulle@microsoft.com</email></address> |
---|
| 1019 | </author> |
---|
| 1020 | <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> |
---|
| 1021 | <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> |
---|
| 1022 | <address><email>timbl@w3.org</email></address> |
---|
| 1023 | </author> |
---|
| 1024 | <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor"> |
---|
| 1025 | <organization abbrev="W3C">World Wide Web Consortium</organization> |
---|
| 1026 | <address><email>ylafon@w3.org</email></address> |
---|
| 1027 | </author> |
---|
| 1028 | <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor"> |
---|
| 1029 | <organization abbrev="greenbytes">greenbytes GmbH</organization> |
---|
| 1030 | <address><email>julian.reschke@greenbytes.de</email></address> |
---|
| 1031 | </author> |
---|
| 1032 | <date month="&ID-MONTH;" year="&ID-YEAR;"/> |
---|
| 1033 | </front> |
---|
| 1034 | <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p4-conditional-&ID-VERSION;"/> |
---|
| 1035 | <x:source href="p4-conditional.xml" basename="p4-conditional"/> |
---|
[31] | 1036 | </reference> |
---|
| 1037 | |
---|
[138] | 1038 | <reference anchor="Part6"> |
---|
| 1039 | <front> |
---|
| 1040 | <title abbrev="HTTP/1.1">HTTP/1.1, part 6: Caching</title> |
---|
| 1041 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> |
---|
| 1042 | <organization abbrev="Day Software">Day Software</organization> |
---|
| 1043 | <address><email>fielding@gbiv.com</email></address> |
---|
| 1044 | </author> |
---|
| 1045 | <author initials="J." surname="Gettys" fullname="Jim Gettys"> |
---|
| 1046 | <organization>One Laptop per Child</organization> |
---|
| 1047 | <address><email>jg@laptop.org</email></address> |
---|
| 1048 | </author> |
---|
| 1049 | <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul"> |
---|
| 1050 | <organization abbrev="HP">Hewlett-Packard Company</organization> |
---|
| 1051 | <address><email>JeffMogul@acm.org</email></address> |
---|
| 1052 | </author> |
---|
| 1053 | <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen"> |
---|
| 1054 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
| 1055 | <address><email>henrikn@microsoft.com</email></address> |
---|
| 1056 | </author> |
---|
| 1057 | <author initials="L." surname="Masinter" fullname="Larry Masinter"> |
---|
| 1058 | <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization> |
---|
| 1059 | <address><email>LMM@acm.org</email></address> |
---|
| 1060 | </author> |
---|
| 1061 | <author initials="P." surname="Leach" fullname="Paul J. Leach"> |
---|
| 1062 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
| 1063 | <address><email>paulle@microsoft.com</email></address> |
---|
| 1064 | </author> |
---|
| 1065 | <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> |
---|
| 1066 | <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> |
---|
| 1067 | <address><email>timbl@w3.org</email></address> |
---|
| 1068 | </author> |
---|
| 1069 | <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor"> |
---|
| 1070 | <organization abbrev="W3C">World Wide Web Consortium</organization> |
---|
| 1071 | <address><email>ylafon@w3.org</email></address> |
---|
| 1072 | </author> |
---|
| 1073 | <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor"> |
---|
| 1074 | <organization abbrev="greenbytes">greenbytes GmbH</organization> |
---|
| 1075 | <address><email>julian.reschke@greenbytes.de</email></address> |
---|
| 1076 | </author> |
---|
| 1077 | <date month="&ID-MONTH;" year="&ID-YEAR;"/> |
---|
| 1078 | </front> |
---|
| 1079 | <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p6-cache-&ID-VERSION;"/> |
---|
| 1080 | <x:source href="p6-cache.xml" basename="p6-cache"/> |
---|
| 1081 | </reference> |
---|
| 1082 | |
---|
[131] | 1083 | <reference anchor="RFC2046"> |
---|
| 1084 | <front> |
---|
| 1085 | <title abbrev="Media Types">Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types</title> |
---|
| 1086 | <author initials="N." surname="Freed" fullname="Ned Freed"> |
---|
| 1087 | <organization>Innosoft International, Inc.</organization> |
---|
| 1088 | <address><email>ned@innosoft.com</email></address> |
---|
| 1089 | </author> |
---|
| 1090 | <author initials="N." surname="Borenstein" fullname="Nathaniel S. Borenstein"> |
---|
| 1091 | <organization>First Virtual Holdings</organization> |
---|
| 1092 | <address><email>nsb@nsb.fv.com</email></address> |
---|
| 1093 | </author> |
---|
| 1094 | <date month="November" year="1996"/> |
---|
| 1095 | </front> |
---|
| 1096 | <seriesInfo name="RFC" value="2046"/> |
---|
| 1097 | </reference> |
---|
| 1098 | |
---|
[119] | 1099 | <reference anchor="RFC2119"> |
---|
| 1100 | <front> |
---|
| 1101 | <title>Key words for use in RFCs to Indicate Requirement Levels</title> |
---|
| 1102 | <author initials="S." surname="Bradner" fullname="Scott Bradner"> |
---|
| 1103 | <organization>Harvard University</organization> |
---|
| 1104 | <address><email>sob@harvard.edu</email></address> |
---|
| 1105 | </author> |
---|
| 1106 | <date month="March" year="1997"/> |
---|
| 1107 | </front> |
---|
| 1108 | <seriesInfo name="BCP" value="14"/> |
---|
| 1109 | <seriesInfo name="RFC" value="2119"/> |
---|
| 1110 | </reference> |
---|
| 1111 | |
---|
[425] | 1112 | <reference anchor="RFC5234"> |
---|
| 1113 | <front> |
---|
| 1114 | <title abbrev="ABNF for Syntax Specifications">Augmented BNF for Syntax Specifications: ABNF</title> |
---|
| 1115 | <author initials="D." surname="Crocker" fullname="Dave Crocker" role="editor"> |
---|
| 1116 | <organization>Brandenburg InternetWorking</organization> |
---|
| 1117 | <address> |
---|
| 1118 | <postal> |
---|
| 1119 | <street>675 Spruce Dr.</street> |
---|
| 1120 | <city>Sunnyvale</city> |
---|
| 1121 | <region>CA</region> |
---|
| 1122 | <code>94086</code> |
---|
| 1123 | <country>US</country></postal> |
---|
| 1124 | <phone>+1.408.246.8253</phone> |
---|
| 1125 | <email>dcrocker@bbiw.net</email></address> |
---|
| 1126 | </author> |
---|
| 1127 | <author initials="P." surname="Overell" fullname="Paul Overell"> |
---|
| 1128 | <organization>THUS plc.</organization> |
---|
| 1129 | <address> |
---|
| 1130 | <postal> |
---|
| 1131 | <street>1/2 Berkeley Square</street> |
---|
| 1132 | <street>99 Berkely Street</street> |
---|
| 1133 | <city>Glasgow</city> |
---|
| 1134 | <code>G3 7HR</code> |
---|
| 1135 | <country>UK</country></postal> |
---|
| 1136 | <email>paul.overell@thus.net</email></address> |
---|
| 1137 | </author> |
---|
| 1138 | <date month="January" year="2008"/> |
---|
| 1139 | </front> |
---|
| 1140 | <seriesInfo name="STD" value="68"/> |
---|
| 1141 | <seriesInfo name="RFC" value="5234"/> |
---|
| 1142 | </reference> |
---|
| 1143 | |
---|
[119] | 1144 | </references> |
---|
| 1145 | |
---|
| 1146 | <references title="Informative References"> |
---|
| 1147 | |
---|
[36] | 1148 | <reference anchor="RFC2616"> |
---|
[119] | 1149 | <front> |
---|
| 1150 | <title>Hypertext Transfer Protocol -- HTTP/1.1</title> |
---|
| 1151 | <author initials="R." surname="Fielding" fullname="R. Fielding"> |
---|
| 1152 | <organization>University of California, Irvine</organization> |
---|
| 1153 | <address><email>fielding@ics.uci.edu</email></address> |
---|
| 1154 | </author> |
---|
| 1155 | <author initials="J." surname="Gettys" fullname="J. Gettys"> |
---|
| 1156 | <organization>W3C</organization> |
---|
| 1157 | <address><email>jg@w3.org</email></address> |
---|
| 1158 | </author> |
---|
| 1159 | <author initials="J." surname="Mogul" fullname="J. Mogul"> |
---|
| 1160 | <organization>Compaq Computer Corporation</organization> |
---|
| 1161 | <address><email>mogul@wrl.dec.com</email></address> |
---|
| 1162 | </author> |
---|
| 1163 | <author initials="H." surname="Frystyk" fullname="H. Frystyk"> |
---|
| 1164 | <organization>MIT Laboratory for Computer Science</organization> |
---|
| 1165 | <address><email>frystyk@w3.org</email></address> |
---|
| 1166 | </author> |
---|
| 1167 | <author initials="L." surname="Masinter" fullname="L. Masinter"> |
---|
| 1168 | <organization>Xerox Corporation</organization> |
---|
| 1169 | <address><email>masinter@parc.xerox.com</email></address> |
---|
| 1170 | </author> |
---|
| 1171 | <author initials="P." surname="Leach" fullname="P. Leach"> |
---|
| 1172 | <organization>Microsoft Corporation</organization> |
---|
| 1173 | <address><email>paulle@microsoft.com</email></address> |
---|
| 1174 | </author> |
---|
| 1175 | <author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee"> |
---|
| 1176 | <organization>W3C</organization> |
---|
| 1177 | <address><email>timbl@w3.org</email></address> |
---|
| 1178 | </author> |
---|
| 1179 | <date month="June" year="1999"/> |
---|
| 1180 | </front> |
---|
| 1181 | <seriesInfo name="RFC" value="2616"/> |
---|
[36] | 1182 | </reference> |
---|
| 1183 | |
---|
[253] | 1184 | <reference anchor='RFC3864'> |
---|
| 1185 | <front> |
---|
| 1186 | <title>Registration Procedures for Message Header Fields</title> |
---|
| 1187 | <author initials='G.' surname='Klyne' fullname='G. Klyne'> |
---|
| 1188 | <organization>Nine by Nine</organization> |
---|
| 1189 | <address><email>GK-IETF@ninebynine.org</email></address> |
---|
| 1190 | </author> |
---|
| 1191 | <author initials='M.' surname='Nottingham' fullname='M. Nottingham'> |
---|
| 1192 | <organization>BEA Systems</organization> |
---|
| 1193 | <address><email>mnot@pobox.com</email></address> |
---|
| 1194 | </author> |
---|
| 1195 | <author initials='J.' surname='Mogul' fullname='J. Mogul'> |
---|
| 1196 | <organization>HP Labs</organization> |
---|
| 1197 | <address><email>JeffMogul@acm.org</email></address> |
---|
| 1198 | </author> |
---|
| 1199 | <date year='2004' month='September' /> |
---|
| 1200 | </front> |
---|
| 1201 | <seriesInfo name='BCP' value='90' /> |
---|
| 1202 | <seriesInfo name='RFC' value='3864' /> |
---|
| 1203 | </reference> |
---|
| 1204 | |
---|
[196] | 1205 | <reference anchor="RFC4288"> |
---|
| 1206 | <front> |
---|
| 1207 | <title>Media Type Specifications and Registration Procedures</title> |
---|
| 1208 | <author initials="N." surname="Freed" fullname="N. Freed"> |
---|
| 1209 | <organization>Sun Microsystems</organization> |
---|
| 1210 | <address> |
---|
| 1211 | <email>ned.freed@mrochek.com</email> |
---|
| 1212 | </address> |
---|
| 1213 | </author> |
---|
| 1214 | <author initials="J." surname="Klensin" fullname="J. Klensin"> |
---|
| 1215 | <organization/> |
---|
| 1216 | <address> |
---|
| 1217 | <email>klensin+ietf@jck.com</email> |
---|
| 1218 | </address> |
---|
| 1219 | </author> |
---|
| 1220 | <date year="2005" month="December"/> |
---|
| 1221 | </front> |
---|
| 1222 | <seriesInfo name="BCP" value="13"/> |
---|
| 1223 | <seriesInfo name="RFC" value="4288"/> |
---|
| 1224 | </reference> |
---|
| 1225 | |
---|
[119] | 1226 | </references> |
---|
| 1227 | |
---|
[8] | 1228 | <section title="Internet Media Type multipart/byteranges" anchor="internet.media.type.multipart.byteranges"> |
---|
| 1229 | <iref item="Media Type" subitem="multipart/byteranges" primary="true"/> |
---|
| 1230 | <iref item="multipart/byteranges Media Type" primary="true"/> |
---|
| 1231 | <t> |
---|
| 1232 | When an HTTP 206 (Partial Content) response message includes the |
---|
| 1233 | content of multiple ranges (a response to a request for multiple |
---|
| 1234 | non-overlapping ranges), these are transmitted as a multipart |
---|
[328] | 1235 | message-body (<xref target="RFC2046" x:fmt="," x:sec="5.1"/>). The media type for this purpose is called |
---|
[196] | 1236 | "multipart/byteranges". The following is to be registered with IANA <xref target="RFC4288"/>. |
---|
[8] | 1237 | </t><t> |
---|
[332] | 1238 | The multipart/byteranges media type includes one or more parts, each |
---|
[8] | 1239 | with its own Content-Type and Content-Range fields. The required |
---|
| 1240 | boundary parameter specifies the boundary string used to separate |
---|
| 1241 | each body-part. |
---|
| 1242 | </t> |
---|
| 1243 | <t> |
---|
| 1244 | <list style="hanging" x:indent="12em"> |
---|
[196] | 1245 | <t hangText="Type name:"> |
---|
[8] | 1246 | multipart |
---|
| 1247 | </t> |
---|
[196] | 1248 | <t hangText="Subtype name:"> |
---|
[8] | 1249 | byteranges |
---|
| 1250 | </t> |
---|
| 1251 | <t hangText="Required parameters:"> |
---|
| 1252 | boundary |
---|
| 1253 | </t> |
---|
| 1254 | <t hangText="Optional parameters:"> |
---|
| 1255 | none |
---|
| 1256 | </t> |
---|
| 1257 | <t hangText="Encoding considerations:"> |
---|
| 1258 | only "7bit", "8bit", or "binary" are permitted |
---|
| 1259 | </t> |
---|
| 1260 | <t hangText="Security considerations:"> |
---|
| 1261 | none |
---|
| 1262 | </t> |
---|
[196] | 1263 | <t hangText="Interoperability considerations:"> |
---|
| 1264 | none |
---|
| 1265 | </t> |
---|
| 1266 | <t hangText="Published specification:"> |
---|
| 1267 | This specification (see <xref target="internet.media.type.multipart.byteranges"/>). |
---|
| 1268 | </t> |
---|
| 1269 | <t hangText="Applications that use this media type:"> |
---|
| 1270 | </t> |
---|
| 1271 | <t hangText="Additional information:"> |
---|
| 1272 | <list style="hanging"> |
---|
| 1273 | <t hangText="Magic number(s):">none</t> |
---|
| 1274 | <t hangText="File extension(s):">none</t> |
---|
| 1275 | <t hangText="Macintosh file type code(s):">none</t> |
---|
| 1276 | </list> |
---|
| 1277 | </t> |
---|
| 1278 | <t hangText="Person and email address to contact for further information:"> |
---|
| 1279 | See Authors Section. |
---|
| 1280 | </t> |
---|
| 1281 | <t hangText="Intended usage:"> |
---|
| 1282 | COMMON |
---|
| 1283 | </t> |
---|
| 1284 | <t hangText="Restrictions on usage:"> |
---|
| 1285 | none |
---|
| 1286 | </t> |
---|
| 1287 | <t hangText="Author/Change controller:"> |
---|
| 1288 | IESG |
---|
| 1289 | </t> |
---|
[8] | 1290 | </list> |
---|
| 1291 | </t> |
---|
| 1292 | <figure><preamble> |
---|
| 1293 | For example: |
---|
| 1294 | </preamble><artwork type="example"> |
---|
[435] | 1295 | HTTP/1.1 206 Partial Content |
---|
| 1296 | Date: Wed, 15 Nov 1995 06:25:24 GMT |
---|
| 1297 | Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT |
---|
| 1298 | Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES |
---|
| 1299 | |
---|
| 1300 | --THIS_STRING_SEPARATES |
---|
| 1301 | Content-type: application/pdf |
---|
| 1302 | Content-range: bytes 500-999/8000 |
---|
| 1303 | |
---|
| 1304 | ...the first range... |
---|
| 1305 | --THIS_STRING_SEPARATES |
---|
| 1306 | Content-type: application/pdf |
---|
| 1307 | Content-range: bytes 7000-7999/8000 |
---|
| 1308 | |
---|
| 1309 | ...the second range |
---|
| 1310 | --THIS_STRING_SEPARATES-- |
---|
[8] | 1311 | </artwork></figure> |
---|
| 1312 | <t> |
---|
| 1313 | Notes: |
---|
| 1314 | <list style="numbers"> |
---|
| 1315 | <t>Additional CRLFs may precede the first boundary string in the |
---|
| 1316 | entity.</t> |
---|
| 1317 | |
---|
[97] | 1318 | <t>Although <xref target="RFC2046"/> permits the boundary string to be |
---|
[8] | 1319 | quoted, some existing implementations handle a quoted boundary |
---|
| 1320 | string incorrectly.</t> |
---|
| 1321 | |
---|
| 1322 | <t>A number of browsers and servers were coded to an early draft |
---|
| 1323 | of the byteranges specification to use a media type of |
---|
| 1324 | multipart/x-byteranges<iref item="multipart/x-byteranges Media Type"/><iref item="Media Type" subitem="multipart/x-byteranges"/>, which is almost, but not quite |
---|
| 1325 | compatible with the version documented in HTTP/1.1.</t> |
---|
| 1326 | </list> |
---|
| 1327 | </t> |
---|
| 1328 | </section> |
---|
| 1329 | |
---|
[99] | 1330 | <section title="Compatibility with Previous Versions" anchor="compatibility"> |
---|
[8] | 1331 | <section title="Changes from RFC 2068" anchor="changes.from.rfc.2068"> |
---|
| 1332 | <t> |
---|
[138] | 1333 | Transfer-coding and message lengths all interact in ways that |
---|
| 1334 | required fixing exactly when chunked encoding is used (to allow for |
---|
| 1335 | transfer encoding that may not be self delimiting); it was important |
---|
| 1336 | to straighten out exactly how message lengths are computed. |
---|
| 1337 | (<xref target="header.content-range"/>, |
---|
| 1338 | see also <xref target="Part1"/>, <xref target="Part3"/> and <xref target="Part6"/>) |
---|
| 1339 | </t> |
---|
| 1340 | <t> |
---|
[8] | 1341 | There are situations where a server (especially a proxy) does not |
---|
| 1342 | know the full length of a response but is capable of serving a |
---|
| 1343 | byterange request. We therefore need a mechanism to allow byteranges |
---|
| 1344 | with a content-range not indicating the full length of the message. |
---|
| 1345 | (<xref target="header.content-range"/>) |
---|
| 1346 | </t> |
---|
| 1347 | <t> |
---|
| 1348 | Range request responses would become very verbose if all meta-data |
---|
| 1349 | were always returned; by allowing the server to only send needed |
---|
[29] | 1350 | headers in a 206 response, this problem can be avoided. |
---|
[142] | 1351 | (Section <xref target="status.206" format="counter"/> |
---|
| 1352 | and <xref target="header.if-range" format="counter"/>) |
---|
[8] | 1353 | </t> |
---|
| 1354 | <t> |
---|
| 1355 | Fix problem with unsatisfiable range requests; there are two cases: |
---|
| 1356 | syntactic problems, and range doesn't exist in the document. The 416 |
---|
| 1357 | status code was needed to resolve this ambiguity needed to indicate |
---|
| 1358 | an error for a byte range request that falls outside of the actual |
---|
| 1359 | contents of a document. (Section <xref target="status.416" format="counter"/>, <xref target="header.content-range" format="counter"/>) |
---|
| 1360 | </t> |
---|
| 1361 | </section> |
---|
| 1362 | |
---|
[99] | 1363 | <section title="Changes from RFC 2616" anchor="changes.from.rfc.2616"> |
---|
[105] | 1364 | <t> |
---|
| 1365 | Clarify that it is not ok to use a weak cache validator in a 206 response. |
---|
| 1366 | (<xref target="status.206"/>) |
---|
| 1367 | </t> |
---|
[332] | 1368 | <t> |
---|
| 1369 | Clarify that multipart/byteranges can consist of a single part. |
---|
| 1370 | (<xref target="internet.media.type.multipart.byteranges"/>) |
---|
| 1371 | </t> |
---|
| 1372 | |
---|
[99] | 1373 | </section> |
---|
| 1374 | |
---|
| 1375 | </section> |
---|
| 1376 | |
---|
[427] | 1377 | <section xmlns:x="http://purl.org/net/xml2rfc/ext" title="Collected ABNF" anchor="collected.abnf"> |
---|
| 1378 | <figure> |
---|
| 1379 | <artwork type="abnf" name="p5-range.parsed-abnf"> |
---|
| 1380 | <x:ref>Accept-Ranges</x:ref> = "Accept-Ranges:" OWS Accept-Ranges-v |
---|
| 1381 | <x:ref>Accept-Ranges-v</x:ref> = acceptable-ranges |
---|
| 1382 | |
---|
| 1383 | <x:ref>Content-Range</x:ref> = "Content-Range:" OWS Content-Range-v |
---|
| 1384 | <x:ref>Content-Range-v</x:ref> = content-range-spec |
---|
| 1385 | |
---|
| 1386 | <x:ref>HTTP-date</x:ref> = <HTTP-date, defined in [Part1], Section 3.2.1> |
---|
| 1387 | |
---|
| 1388 | <x:ref>If-Range</x:ref> = "If-Range:" OWS If-Range-v |
---|
| 1389 | <x:ref>If-Range-v</x:ref> = entity-tag / HTTP-date |
---|
| 1390 | |
---|
| 1391 | <x:ref>OWS</x:ref> = <OWS, defined in [Part1], Section 1.2.2> |
---|
| 1392 | |
---|
[434] | 1393 | <x:ref>Range</x:ref> = "Range:" OWS Range-v |
---|
| 1394 | <x:ref>Range-v</x:ref> = byte-ranges-specifier / other-ranges-specifier |
---|
[427] | 1395 | |
---|
| 1396 | <x:ref>acceptable-ranges</x:ref> = ( *( "," OWS ) range-unit *( OWS "," [ OWS |
---|
[425] | 1397 | range-unit ] ) ) / "none" |
---|
[428] | 1398 | |
---|
[427] | 1399 | <x:ref>byte-content-range-spec</x:ref> = bytes-unit SP byte-range-resp-spec "/" ( |
---|
[425] | 1400 | instance-length / "*" ) |
---|
[427] | 1401 | <x:ref>byte-range-resp-spec</x:ref> = ( first-byte-pos "-" last-byte-pos ) / "*" |
---|
| 1402 | <x:ref>byte-range-set</x:ref> = ( *( "," OWS ) byte-range-spec ) / ( |
---|
[425] | 1403 | suffix-byte-range-spec *( OWS "," [ ( OWS byte-range-spec ) / |
---|
| 1404 | suffix-byte-range-spec ] ) ) |
---|
[427] | 1405 | <x:ref>byte-range-spec</x:ref> = first-byte-pos "-" [ last-byte-pos ] |
---|
| 1406 | <x:ref>byte-ranges-specifier</x:ref> = bytes-unit "=" byte-range-set |
---|
| 1407 | <x:ref>bytes-unit</x:ref> = "bytes" |
---|
| 1408 | |
---|
| 1409 | <x:ref>content-range-spec</x:ref> = byte-content-range-spec / |
---|
[425] | 1410 | other-content-range-spec |
---|
[428] | 1411 | |
---|
[427] | 1412 | <x:ref>entity-tag</x:ref> = <entity-tag, defined in [Part4], Section 2> |
---|
| 1413 | |
---|
| 1414 | <x:ref>first-byte-pos</x:ref> = 1*DIGIT |
---|
| 1415 | |
---|
| 1416 | <x:ref>instance-length</x:ref> = 1*DIGIT |
---|
| 1417 | |
---|
| 1418 | <x:ref>last-byte-pos</x:ref> = 1*DIGIT |
---|
| 1419 | |
---|
| 1420 | <x:ref>other-content-range-spec</x:ref> = other-range-unit SP other-range-resp-spec |
---|
| 1421 | <x:ref>other-range-resp-spec</x:ref> = *CHAR |
---|
| 1422 | <x:ref>other-range-unit</x:ref> = token |
---|
| 1423 | <x:ref>other-ranges-specifier</x:ref> = 1*CHAR |
---|
| 1424 | |
---|
| 1425 | <x:ref>range-unit</x:ref> = bytes-unit / other-range-unit |
---|
| 1426 | |
---|
| 1427 | <x:ref>suffix-byte-range-spec</x:ref> = "-" suffix-length |
---|
| 1428 | <x:ref>suffix-length</x:ref> = 1*DIGIT |
---|
| 1429 | |
---|
| 1430 | <x:ref>token</x:ref> = <token, defined in [Part1], Section 1.2.2> |
---|
| 1431 | |
---|
[425] | 1432 | ; Accept-Ranges defined but not used |
---|
| 1433 | ; Content-Range defined but not used |
---|
| 1434 | ; If-Range defined but not used |
---|
| 1435 | ; Range defined but not used |
---|
[427] | 1436 | |
---|
| 1437 | |
---|
[421] | 1438 | </artwork> |
---|
[427] | 1439 | </figure> |
---|
[421] | 1440 | </section> |
---|
| 1441 | |
---|
[434] | 1442 | |
---|
[252] | 1443 | <section title="Change Log (to be removed by RFC Editor before publication)" anchor="change.log"> |
---|
[99] | 1444 | |
---|
[115] | 1445 | <section title="Since RFC2616"> |
---|
| 1446 | <t> |
---|
| 1447 | Extracted relevant partitions from <xref target="RFC2616"/>. |
---|
| 1448 | </t> |
---|
| 1449 | </section> |
---|
| 1450 | |
---|
| 1451 | <section title="Since draft-ietf-httpbis-p5-range-00"> |
---|
| 1452 | <t> |
---|
[116] | 1453 | Closed issues: |
---|
| 1454 | <list style="symbols"> |
---|
| 1455 | <t> |
---|
[324] | 1456 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/18"/>: |
---|
[116] | 1457 | "Cache validators in 206 responses" |
---|
| 1458 | (<eref target="http://purl.org/NET/http-errata#ifrange206"/>) |
---|
| 1459 | </t> |
---|
[131] | 1460 | <t> |
---|
[324] | 1461 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/35"/>: |
---|
[152] | 1462 | "Normative and Informative references" |
---|
| 1463 | </t> |
---|
| 1464 | <t> |
---|
[324] | 1465 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/86"/>: |
---|
[131] | 1466 | "Normative up-to-date references" |
---|
| 1467 | </t> |
---|
[116] | 1468 | </list> |
---|
[115] | 1469 | </t> |
---|
| 1470 | </section> |
---|
| 1471 | |
---|
[170] | 1472 | <section title="Since draft-ietf-httpbis-p5-range-01"> |
---|
| 1473 | <t> |
---|
[200] | 1474 | Closed issues: |
---|
| 1475 | <list style="symbols"> |
---|
| 1476 | <t> |
---|
[324] | 1477 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/55"/>: |
---|
[200] | 1478 | "Updating to RFC4288" |
---|
| 1479 | </t> |
---|
| 1480 | </list> |
---|
[170] | 1481 | </t> |
---|
[205] | 1482 | <t> |
---|
[324] | 1483 | Ongoing work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>): |
---|
[205] | 1484 | <list style="symbols"> |
---|
| 1485 | <t> |
---|
| 1486 | Add explicit references to BNF syntax and rules imported from other parts of the specification. |
---|
| 1487 | </t> |
---|
| 1488 | </list> |
---|
| 1489 | </t> |
---|
[115] | 1490 | </section> |
---|
| 1491 | |
---|
[252] | 1492 | <section title="Since draft-ietf-httpbis-p5-range-02" anchor="changes.since.02"> |
---|
[228] | 1493 | <t> |
---|
[324] | 1494 | Ongoing work on IANA Message Header Registration (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/40"/>): |
---|
[253] | 1495 | <list style="symbols"> |
---|
| 1496 | <t> |
---|
| 1497 | Reference RFC 3984, and update header registrations for headers defined |
---|
| 1498 | in this document. |
---|
| 1499 | </t> |
---|
| 1500 | </list> |
---|
[228] | 1501 | </t> |
---|
[170] | 1502 | </section> |
---|
| 1503 | |
---|
[267] | 1504 | <section title="Since draft-ietf-httpbis-p5-range-03" anchor="changes.since.03"> |
---|
| 1505 | <t> |
---|
| 1506 | </t> |
---|
[228] | 1507 | </section> |
---|
| 1508 | |
---|
[323] | 1509 | <section title="Since draft-ietf-httpbis-p5-range-04" anchor="changes.since.04"> |
---|
| 1510 | <t> |
---|
[332] | 1511 | Closed issues: |
---|
| 1512 | <list style="symbols"> |
---|
| 1513 | <t> |
---|
| 1514 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/133"/>: |
---|
| 1515 | "multipart/byteranges minimum number of parts" |
---|
| 1516 | </t> |
---|
| 1517 | </list> |
---|
[323] | 1518 | </t> |
---|
[334] | 1519 | <t> |
---|
| 1520 | Ongoing work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>): |
---|
| 1521 | <list style="symbols"> |
---|
| 1522 | <t> |
---|
| 1523 | Use "/" instead of "|" for alternatives. |
---|
| 1524 | </t> |
---|
[363] | 1525 | <t> |
---|
| 1526 | Introduce new ABNF rules for "bad" whitespace ("BWS"), optional |
---|
| 1527 | whitespace ("OWS") and required whitespace ("RWS"). |
---|
| 1528 | </t> |
---|
| 1529 | <t> |
---|
| 1530 | Rewrite ABNFs to spell out whitespace rules, factor out |
---|
| 1531 | header value format definitions. |
---|
| 1532 | </t> |
---|
[334] | 1533 | </list> |
---|
| 1534 | </t> |
---|
[267] | 1535 | </section> |
---|
| 1536 | |
---|
[382] | 1537 | <section title="Since draft-ietf-httpbis-p5-range-05" anchor="changes.since.05"> |
---|
| 1538 | <t> |
---|
[438] | 1539 | Closed issues: |
---|
| 1540 | <list style="symbols"> |
---|
| 1541 | <t> |
---|
| 1542 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/142"/>: |
---|
| 1543 | "State base for *-byte-pos and suffix-length" |
---|
| 1544 | </t> |
---|
| 1545 | </list> |
---|
| 1546 | </t> |
---|
| 1547 | <t> |
---|
[393] | 1548 | Ongoing work on Custom Ranges (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/85"/>): |
---|
| 1549 | <list style="symbols"> |
---|
| 1550 | <t> |
---|
| 1551 | Remove bias in favor of byte ranges; allow custom ranges in ABNF. |
---|
| 1552 | </t> |
---|
| 1553 | </list> |
---|
[382] | 1554 | </t> |
---|
[421] | 1555 | <t> |
---|
| 1556 | Ongoing work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>): |
---|
| 1557 | <list style="symbols"> |
---|
| 1558 | <t> |
---|
[424] | 1559 | Add appendix containing collected and expanded ABNF, reorganize ABNF introduction. |
---|
[421] | 1560 | </t> |
---|
| 1561 | </list> |
---|
| 1562 | </t> |
---|
[323] | 1563 | </section> |
---|
| 1564 | |
---|
[382] | 1565 | </section> |
---|
| 1566 | |
---|
[8] | 1567 | </back> |
---|
| 1568 | </rfc> |
---|