source: draft-ietf-httpbis/21/draft-ietf-httpbis-p5-range-21.xml @ 2211

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

prepare release of -21 drafts on Oct 4

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