source: draft-ietf-httpbis/21/draft-ietf-httpbis-p5-range-21.txt @ 2650

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