source: draft-ietf-httpbis/20/draft-ietf-httpbis-p5-range-20.xml @ 1807

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

Prepare release of -20 drafts

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