source: draft-ietf-httpbis/19/draft-ietf-httpbis-p5-range-19.xml @ 1592

Last change on this file since 1592 was 1592, checked in by julian.reschke@…, 8 years ago

-19

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