source: draft-ietf-httpbis/latest/auth48/p5-range.unpg.txt @ 2705

Last change on this file since 2705 was 2702, checked in by julian.reschke@…, 6 years ago

Consistently say "Authors .. section" (#553)

  • Property svn:eol-style set to native
File size: 46.6 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: November 29, 2014                               J. Reschke, Ed.
9                                                              greenbytes
10                                                            May 28, 2014
11
12
13         Hypertext Transfer Protocol (HTTP/1.1): Range Requests
14                   draft-ietf-httpbis-p5-range-latest
15
16Abstract
17
18   The Hypertext Transfer Protocol (HTTP) is a stateless application-
19   level 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   _This is a temporary document for the purpose of tracking the
35   editorial changes made during the AUTH48 (RFC publication) phase._
36
37Status of This Memo
38
39   This Internet-Draft is submitted in full conformance with the
40   provisions of BCP 78 and BCP 79.
41
42   Internet-Drafts are working documents of the Internet Engineering
43   Task Force (IETF).  Note that other groups may also distribute
44   working documents as Internet-Drafts.  The list of current Internet-
45   Drafts is at http://datatracker.ietf.org/drafts/current/.
46
47   Internet-Drafts are draft documents valid for a maximum of six months
48   and may be updated, replaced, or obsoleted by other documents at any
49   time.  It is inappropriate to use Internet-Drafts as reference
50   material or to cite them other than as "work in progress."
51
52
53
54
55Fielding, et al.        Expires November 29, 2014               [Page 1]
56
57Internet-Draft           HTTP/1.1 Range Requests                May 2014
58
59
60   This Internet-Draft will expire on November 29, 2014.
61
62Copyright Notice
63
64   Copyright (c) 2014 IETF Trust and the persons identified as the
65   document authors.  All rights reserved.
66
67   This document is subject to BCP 78 and the IETF Trust's Legal
68   Provisions Relating to IETF Documents
69   (http://trustee.ietf.org/license-info) in effect on the date of
70   publication of this document.  Please review these documents
71   carefully, as they describe your rights and restrictions with respect
72   to this document.  Code Components extracted from this document must
73   include Simplified BSD License text as described in Section 4.e of
74   the Trust Legal Provisions and are provided without warranty as
75   described in the Simplified BSD License.
76
77   This document may contain material from IETF Documents or IETF
78   Contributions published or made publicly available before November
79   10, 2008.  The person(s) controlling the copyright in some of this
80   material may not have granted the IETF Trust the right to allow
81   modifications of such material outside the IETF Standards Process.
82   Without obtaining an adequate license from the person(s) controlling
83   the copyright in such materials, this document may not be modified
84   outside the IETF Standards Process, and derivative works of it may
85   not be created outside the IETF Standards Process, except to format
86   it for publication as an RFC or to translate it into languages other
87   than English.
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 November 29, 2014               [Page 2]
112
113Internet-Draft           HTTP/1.1 Range Requests                May 2014
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.  Byte Ranges  . . . . . . . . . . . . . . . . . . . . . . .  5
123     2.2.  Other Range Units  . . . . . . . . . . . . . . . . . . . .  7
124     2.3.  Accept-Ranges  . . . . . . . . . . . . . . . . . . . . . .  7
125   3.  Range Requests . . . . . . . . . . . . . . . . . . . . . . . .  7
126     3.1.  Range  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
127     3.2.  If-Range . . . . . . . . . . . . . . . . . . . . . . . . .  9
128   4.  Responses to a Range Request . . . . . . . . . . . . . . . . . 10
129     4.1.  206 Partial Content  . . . . . . . . . . . . . . . . . . . 10
130     4.2.  Content-Range  . . . . . . . . . . . . . . . . . . . . . . 12
131     4.3.  Combining Ranges . . . . . . . . . . . . . . . . . . . . . 14
132     4.4.  416 Range Not Satisfiable  . . . . . . . . . . . . . . . . 15
133   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
134     5.1.  Range Unit Registry  . . . . . . . . . . . . . . . . . . . 15
135       5.1.1.  Procedure  . . . . . . . . . . . . . . . . . . . . . . 15
136       5.1.2.  Registrations  . . . . . . . . . . . . . . . . . . . . 16
137     5.2.  Status Code Registration . . . . . . . . . . . . . . . . . 16
138     5.3.  Header Field Registration  . . . . . . . . . . . . . . . . 16
139     5.4.  Internet Media Type Registration . . . . . . . . . . . . . 17
140       5.4.1.  Internet Media Type multipart/byteranges . . . . . . . 17
141   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
142     6.1.  Denial-of-Service Attacks Using Range  . . . . . . . . . . 18
143   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 18
144   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
145     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 19
146     8.2.  Informative References . . . . . . . . . . . . . . . . . . 19
147   Appendix A.  Internet Media Type multipart/byteranges  . . . . . . 20
148   Appendix B.  Changes from RFC 2616 . . . . . . . . . . . . . . . . 21
149   Appendix C.  Imported ABNF . . . . . . . . . . . . . . . . . . . . 21
150   Appendix D.  Collected ABNF  . . . . . . . . . . . . . . . . . . . 21
151   Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167Fielding, et al.        Expires November 29, 2014               [Page 3]
168
169Internet-Draft           HTTP/1.1 Range Requests                May 2014
170
171
1721.  Introduction
173
174   Hypertext Transfer Protocol (HTTP) clients often encounter
175   interrupted data transfers as a result of canceled requests or
176   dropped connections.  When a client has stored a partial
177   representation, it is desirable to request the remainder of that
178   representation in a subsequent request rather than transfer the
179   entire representation.  Likewise, devices with limited local storage
180   might benefit from being able to request only a subset of a larger
181   representation, such as a single page of a very large document, or
182   the dimensions of an embedded image.
183
184   This document defines HTTP/1.1 range requests, partial responses, and
185   the multipart/byteranges media type.  Range requests are an OPTIONAL
186   feature of HTTP, designed so that recipients not implementing this
187   feature (or not supporting it for the target resource) can respond as
188   if it is a normal GET request without impacting interoperability.
189   Partial responses are indicated by a distinct status code to not be
190   mistaken for full responses by caches that might not implement the
191   feature.
192
193   Although the 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 [RFC7230].
205
2061.2.  Syntax Notation
207
208   This specification uses the Augmented Backus-Naur Form (ABNF)
209   notation of [RFC5234] with a list extension, defined in Section 7 of
210   [RFC7230], that allows for compact definition of comma-separated
211   lists using a '#' operator (similar to how the '*' operator indicates
212   repetition).  Appendix C describes rules imported from other
213   documents.  Appendix D shows the collected grammar with all list
214   operators expanded to standard ABNF notation.
215
2162.  Range Units
217
218   A representation can be partitioned into subranges according to
219   various structural units, depending on the structure inherent in the
220
221
222
223Fielding, et al.        Expires November 29, 2014               [Page 4]
224
225Internet-Draft           HTTP/1.1 Range Requests                May 2014
226
227
228   representation's media type.  This "range unit" is used in the
229   Accept-Ranges (Section 2.3) response header field to advertise
230   support for range requests, the Range (Section 3.1) request header
231   field to delineate the parts of a representation that are requested,
232   and the Content-Range (Section 4.2) payload header field to describe
233   which part of a representation is being transferred.
234
235     range-unit       = bytes-unit / other-range-unit
236
2372.1.  Byte Ranges
238
239   Since representation data is transferred in payloads as a sequence of
240   octets, a byte range is a meaningful substructure for any
241   representation transferable over HTTP (Section 3 of [RFC7231]).  The
242   "bytes" range unit is defined for expressing subranges of the data's
243   octet sequence.
244
245     bytes-unit       = "bytes"
246
247   A byte-range request can specify a single range of bytes or a set of
248   ranges within a single representation.
249
250     byte-ranges-specifier = bytes-unit "=" byte-range-set
251     byte-range-set  = 1#( byte-range-spec / suffix-byte-range-spec )
252     byte-range-spec = first-byte-pos "-" [ last-byte-pos ]
253     first-byte-pos  = 1*DIGIT
254     last-byte-pos   = 1*DIGIT
255
256   The first-byte-pos value in a byte-range-spec gives the byte-offset
257   of the first byte in a range.  The last-byte-pos value gives the
258   byte-offset of the last byte in the range; that is, the byte
259   positions specified are inclusive.  Byte offsets start at zero.
260
261   Examples of byte-ranges-specifier values:
262
263   o  The first 500 bytes (byte offsets 0-499, inclusive):
264
265        bytes=0-499
266
267   o  The second 500 bytes (byte offsets 500-999, inclusive):
268
269        bytes=500-999
270
271   A byte-range-spec is invalid if the last-byte-pos value is present
272   and less than the first-byte-pos.
273
274   A client can limit the number of bytes requested without knowing the
275   size of the selected representation.  If the last-byte-pos value is
276
277
278
279Fielding, et al.        Expires November 29, 2014               [Page 5]
280
281Internet-Draft           HTTP/1.1 Range Requests                May 2014
282
283
284   absent, or if the value is greater than or equal to the current
285   length of the representation data, the byte range is interpreted as
286   the remainder of the representation (i.e., the server replaces the
287   value of last-byte-pos with a value that is one less than the current
288   length of the selected representation).
289
290   A client can request the last N bytes of the selected representation
291   using a suffix-byte-range-spec.
292
293     suffix-byte-range-spec = "-" suffix-length
294     suffix-length = 1*DIGIT
295
296   If the selected representation is shorter than the specified suffix-
297   length, the entire representation is used.
298
299   Additional examples, assuming a representation of length 10000:
300
301   o  The final 500 bytes (byte offsets 9500-9999, inclusive):
302
303        bytes=-500
304
305      Or:
306
307        bytes=9500-
308
309   o  The first and last bytes only (bytes 0 and 9999):
310
311        bytes=0-0,-1
312
313   o  Other valid (but not canonical) specifications of the second 500
314      bytes (byte offsets 500-999, inclusive):
315
316        bytes=500-600,601-999
317        bytes=500-700,601-999
318
319   If a valid byte-range-set includes at least one byte-range-spec with
320   a first-byte-pos that is less than the current length of the
321   representation, or at least one suffix-byte-range-spec with a non-
322   zero suffix-length, then the byte-range-set is satisfiable.
323   Otherwise, the byte-range-set is unsatisfiable.
324
325   In the byte-range syntax, first-byte-pos, last-byte-pos, and suffix-
326   length are expressed as decimal number of octets.  Since there is no
327   predefined limit to the length of a payload, recipients MUST
328   anticipate potentially large decimal numerals and prevent parsing
329   errors due to integer conversion overflows.
330
331
332
333
334
335Fielding, et al.        Expires November 29, 2014               [Page 6]
336
337Internet-Draft           HTTP/1.1 Range Requests                May 2014
338
339
3402.2.  Other Range Units
341
342   Range units are intended to be extensible.  New range units ought to
343   be registered with IANA, as defined in Section 5.1.
344
345     other-range-unit = token
346
3472.3.  Accept-Ranges
348
349   The "Accept-Ranges" header field allows a server to indicate that it
350   supports range requests for the target resource.
351
352     Accept-Ranges     = acceptable-ranges
353     acceptable-ranges = 1#range-unit / "none"
354
355   An origin server that supports byte-range requests for a given target
356   resource MAY send
357
358     Accept-Ranges: bytes
359
360   to indicate what range units are supported.  A client MAY generate
361   range requests without having received this header field for the
362   resource involved.  Range units are defined in Section 2.
363
364   A server that does not support any kind of range request for the
365   target resource MAY send
366
367     Accept-Ranges: none
368
369   to advise the client not to attempt a range request.
370
3713.  Range Requests
372
3733.1.  Range
374
375   The "Range" header field on a GET request modifies the method
376   semantics to request transfer of only one or more subranges of the
377   selected representation data, rather than the entire selected
378   representation data.
379
380     Range = byte-ranges-specifier / other-ranges-specifier
381     other-ranges-specifier = other-range-unit "=" other-range-set
382     other-range-set = 1*VCHAR
383
384   A server MAY ignore the Range header field.  However, origin servers
385   and intermediate caches ought to support byte ranges when possible,
386   since Range supports efficient recovery from partially failed
387   transfers and partial retrieval of large representations.  A server
388
389
390
391Fielding, et al.        Expires November 29, 2014               [Page 7]
392
393Internet-Draft           HTTP/1.1 Range Requests                May 2014
394
395
396   MUST ignore a Range header field received with a request method other
397   than GET.
398
399   An origin server MUST ignore a Range header field that contains a
400   range unit it does not understand.  A proxy MAY discard a Range
401   header field that contains a range unit it does not understand.
402
403   A server that supports range requests MAY ignore or reject a Range
404   header field that consists of more than two overlapping ranges, or a
405   set of many small ranges that are not listed in ascending order,
406   since both are indications of either a broken client or a deliberate
407   denial-of-service attack (Section 6.1).  A client SHOULD NOT request
408   multiple ranges that are inherently less efficient to process and
409   transfer than a single range that encompasses the same data.
410
411   A client that is requesting multiple ranges SHOULD list those ranges
412   in ascending order (the order in which they would typically be
413   received in a complete representation) unless there is a specific
414   need to request a later part earlier.  For example, a user agent
415   processing a large representation with an internal catalog of parts
416   might need to request later parts first, particularly if the
417   representation consists of pages stored in reverse order and the user
418   agent wishes to transfer one page at a time.
419
420   The Range header field is evaluated after evaluating the precondition
421   header fields defined in [RFC7232], and only if the result in absence
422   of the Range header field would be a 200 (OK) response.  In other
423   words, Range is ignored when a conditional GET would result in a 304
424   (Not Modified) response.
425
426   The If-Range header field (Section 3.2) can be used as a precondition
427   to applying the Range header field.
428
429   If all of the preconditions are true, the server supports the Range
430   header field for the target resource, and the specified range(s) are
431   valid and satisfiable (as defined in Section 2.1), the server SHOULD
432   send a 206 (Partial Content) response with a payload containing one
433   or more partial representations that correspond to the satisfiable
434   ranges requested, as defined in Section 4.
435
436   If all of the preconditions are true, the server supports the Range
437   header field for the target resource, and the specified range(s) are
438   invalid or unsatisfiable, the server SHOULD send a 416 (Range Not
439   Satisfiable) response.
440
441
442
443
444
445
446
447Fielding, et al.        Expires November 29, 2014               [Page 8]
448
449Internet-Draft           HTTP/1.1 Range Requests                May 2014
450
451
4523.2.  If-Range
453
454   If a client has a partial copy of a representation and wishes to have
455   an up-to-date copy of the entire representation, it could use the
456   Range header field with a conditional GET (using either or both of
457   If-Unmodified-Since and If-Match.)  However, if the precondition
458   fails because the representation has been modified, the client would
459   then have to make a second request to obtain the entire current
460   representation.
461
462   The "If-Range" header field allows a client to "short-circuit" the
463   second request.  Informally, its meaning is as follows: if the
464   representation is unchanged, send me the part(s) that I am requesting
465   in Range; otherwise, send me the entire representation.
466
467     If-Range = entity-tag / HTTP-date
468
469   A client MUST NOT generate an If-Range header field in a request that
470   does not contain a Range header field.  A server MUST ignore an If-
471   Range header field received in a request that does not contain a
472   Range header field.  An origin server MUST ignore an If-Range header
473   field received in a request for a target resource that does not
474   support Range requests.
475
476   A client MUST NOT generate an If-Range header field containing an
477   entity-tag that is marked as weak.  A client MUST NOT generate an If-
478   Range header field containing an HTTP-date unless the client has no
479   entity-tag for the corresponding representation and the date is a
480   strong validator in the sense defined by Section 2.2.2 of [RFC7232].
481
482   A server that evaluates an If-Range precondition MUST use the strong
483   comparison function when comparing entity-tags (Section 2.3.2 of
484   [RFC7232]) and MUST evaluate the condition as false if an HTTP-date
485   validator is provided that is not a strong validator in the sense
486   defined by Section 2.2.2 of [RFC7232].  A valid entity-tag can be
487   distinguished from a valid HTTP-date by examining the first two
488   characters for a DQUOTE.
489
490   If the validator given in the If-Range header field matches the
491   current validator for the selected representation of the target
492   resource, then the server SHOULD process the Range header field as
493   requested.  If the validator does not match, the server MUST ignore
494   the Range header field.  Note that this comparison by exact match,
495   including when the validator is an HTTP-date, differs from the
496   "earlier than or equal to" comparison used when evaluating an If-
497   Unmodified-Since conditional.
498
499
500
501
502
503Fielding, et al.        Expires November 29, 2014               [Page 9]
504
505Internet-Draft           HTTP/1.1 Range Requests                May 2014
506
507
5084.  Responses to a Range Request
509
5104.1.  206 Partial Content
511
512   The 206 (Partial Content) status code indicates that the server is
513   successfully fulfilling a range request for the target resource by
514   transferring one or more parts of the selected representation that
515   correspond to the satisfiable ranges found in the request's Range
516   header field (Section 3.1).
517
518   If a single part is being transferred, the server generating the 206
519   response MUST generate a Content-Range header field, describing what
520   range of the selected representation is enclosed, and a payload
521   consisting of the range.  For example:
522
523     HTTP/1.1 206 Partial Content
524     Date: Wed, 15 Nov 1995 06:25:24 GMT
525     Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
526     Content-Range: bytes 21010-47021/47022
527     Content-Length: 26012
528     Content-Type: image/gif
529
530     ... 26012 bytes of partial image data ...
531
532   If multiple parts are being transferred, the server generating the
533   206 response MUST generate a "multipart/byteranges" payload, as
534   defined in Appendix A, and a Content-Type header field containing the
535   multipart/byteranges media type and its required boundary parameter.
536   To avoid confusion with single-part responses, a server MUST NOT
537   generate a Content-Range header field in the HTTP header section of a
538   multiple part response (this field will be sent in each part
539   instead).
540
541   Within the header area of each body part in the multipart payload,
542   the server MUST generate a Content-Range header field corresponding
543   to the range being enclosed in that body part.  If the selected
544   representation would have had a Content-Type header field in a 200
545   (OK) response, the server SHOULD generate that same Content-Type
546   field in the header area of each body part.  For example:
547
548
549
550
551
552
553
554
555
556
557
558
559Fielding, et al.        Expires November 29, 2014              [Page 10]
560
561Internet-Draft           HTTP/1.1 Range Requests                May 2014
562
563
564     HTTP/1.1 206 Partial Content
565     Date: Wed, 15 Nov 1995 06:25:24 GMT
566     Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
567     Content-Length: 1741
568     Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
569
570     --THIS_STRING_SEPARATES
571     Content-Type: application/pdf
572     Content-Range: bytes 500-999/8000
573
574     ...the first range...
575     --THIS_STRING_SEPARATES
576     Content-Type: application/pdf
577     Content-Range: bytes 7000-7999/8000
578
579     ...the second range
580     --THIS_STRING_SEPARATES--
581
582   When multiple ranges are requested, a server MAY coalesce any of the
583   ranges that overlap, or that are separated by a gap that is smaller
584   than the overhead of sending multiple parts, regardless of the order
585   in which the corresponding byte-range-spec appeared in the received
586   Range header field.  Since the typical overhead between parts of a
587   multipart/byteranges payload is around 80 bytes, depending on the
588   selected representation's media type and the chosen boundary
589   parameter length, it can be less efficient to transfer many small
590   disjoint parts than it is to transfer the entire selected
591   representation.
592
593   A server MUST NOT generate a multipart response to a request for a
594   single range, since a client that does not request multiple parts
595   might not support multipart responses.  However, a server MAY
596   generate a multipart/byteranges payload with only a single body part
597   if multiple ranges were requested and only one range was found to be
598   satisfiable or only one range remained after coalescing.  A client
599   that cannot process a multipart/byteranges response MUST NOT generate
600   a request that asks for multiple ranges.
601
602   When a multipart response payload is generated, the server SHOULD
603   send the parts in the same order that the corresponding byte-range-
604   spec appeared in the received Range header field, excluding those
605   ranges that were deemed unsatisfiable or that were coalesced into
606   other ranges.  A client that receives a multipart response MUST
607   inspect the Content-Range header field present in each body part in
608   order to determine which range is contained in that body part; a
609   client cannot rely on receiving the same ranges that it requested,
610   nor the same order that it requested.
611
612
613
614
615Fielding, et al.        Expires November 29, 2014              [Page 11]
616
617Internet-Draft           HTTP/1.1 Range Requests                May 2014
618
619
620   When a 206 response is generated, the server MUST generate the
621   following header fields, in addition to those required above, if the
622   field would have been sent in a 200 (OK) response to the same
623   request: Date, Cache-Control, ETag, Expires, Content-Location, and
624   Vary.
625
626   If a 206 is generated in response to a request with an If-Range
627   header field, the sender SHOULD NOT generate other representation
628   header fields beyond those required above, because the client is
629   understood to already have a prior response containing those header
630   fields.  Otherwise, the sender MUST generate all of the
631   representation header fields that would have been sent in a 200 (OK)
632   response to the same request.
633
634   A 206 response is cacheable by default; i.e., unless otherwise
635   indicated by explicit cache controls (see Section 4.2.2 of
636   [RFC7234]).
637
6384.2.  Content-Range
639
640   The "Content-Range" header field is sent in a single part 206
641   (Partial Content) response to indicate the partial range of the
642   selected representation enclosed as the message payload, sent in each
643   part of a multipart 206 response to indicate the range enclosed
644   within each body part, and sent in 416 (Range Not Satisfiable)
645   responses to provide information about the selected representation.
646
647     Content-Range       = byte-content-range
648                         / other-content-range
649
650     byte-content-range  = bytes-unit SP
651                           ( byte-range-resp / unsatisfied-range )
652
653     byte-range-resp     = byte-range "/" ( complete-length / "*" )
654     byte-range          = first-byte-pos "-" last-byte-pos
655     unsatisfied-range   = "*/" complete-length
656
657     complete-length     = 1*DIGIT
658
659     other-content-range = other-range-unit SP other-range-resp
660     other-range-resp    = *CHAR
661
662   If a 206 (Partial Content) response contains a Content-Range header
663   field with a range unit (Section 2) that the recipient does not
664   understand, the recipient MUST NOT attempt to recombine it with a
665   stored representation.  A proxy that receives such a message SHOULD
666   forward it downstream.
667
668
669
670
671Fielding, et al.        Expires November 29, 2014              [Page 12]
672
673Internet-Draft           HTTP/1.1 Range Requests                May 2014
674
675
676   For byte ranges, a sender SHOULD indicate the complete length of the
677   representation from which the range has been extracted, unless the
678   complete length is unknown or difficult to determine.  An asterisk
679   character ("*") in place of the complete-length indicates that the
680   representation length was unknown when the header field was
681   generated.
682
683   The following example illustrates when the complete length of the
684   selected representation is known by the sender to be 1234 bytes:
685
686     Content-Range: bytes 42-1233/1234
687
688   and this second example illustrates when the complete length is
689   unknown:
690
691     Content-Range: bytes 42-1233/*
692
693   A Content-Range field value is invalid if it contains a byte-range-
694   resp that has a last-byte-pos value less than its first-byte-pos
695   value, or a complete-length value less than or equal to its last-
696   byte-pos value.  The recipient of an invalid Content-Range MUST NOT
697   attempt to recombine the received content with a stored
698   representation.
699
700   A server generating a 416 (Range Not Satisfiable) response to a byte-
701   range request SHOULD send a Content-Range header field with an
702   unsatisfied-range value, as in the following example:
703
704     Content-Range: bytes */1234
705
706   The complete-length in a 416 response indicates the current length of
707   the selected representation.
708
709   The Content-Range header field has no meaning for status codes that
710   do not explicitly describe its semantic.  For this specification,
711   only the 206 (Partial Content) and 416 (Range Not Satisfiable) status
712   codes describe a meaning for Content-Range.
713
714   The following are examples of Content-Range values in which the
715   selected representation contains a total of 1234 bytes:
716
717   o  The first 500 bytes:
718
719        Content-Range: bytes 0-499/1234
720
721   o  The second 500 bytes:
722
723        Content-Range: bytes 500-999/1234
724
725
726
727Fielding, et al.        Expires November 29, 2014              [Page 13]
728
729Internet-Draft           HTTP/1.1 Range Requests                May 2014
730
731
732   o  All except for the first 500 bytes:
733
734        Content-Range: bytes 500-1233/1234
735
736   o  The last 500 bytes:
737
738        Content-Range: bytes 734-1233/1234
739
7404.3.  Combining Ranges
741
742   A response might transfer only a subrange of a representation if the
743   connection closed prematurely or if the request used one or more
744   Range specifications.  After several such transfers, a client might
745   have received several ranges of the same representation.  These
746   ranges can only be safely combined if they all have in common the
747   same strong validator (Section 2.1 of [RFC7232]).
748
749   A client that has received multiple partial responses to GET requests
750   on a target resource MAY combine those responses into a larger
751   continuous range if they share the same strong validator.
752
753   If the most recent response is an incomplete 200 (OK) response, then
754   the header fields of that response are used for any combined response
755   and replace those of the matching stored responses.
756
757   If the most recent response is a 206 (Partial Content) response and
758   at least one of the matching stored responses is a 200 (OK), then the
759   combined response header fields consist of the most recent 200
760   response's header fields.  If all of the matching stored responses
761   are 206 responses, then the stored response with the most recent
762   header fields is used as the source of header fields for the combined
763   response, except that the client MUST use other header fields
764   provided in the new response, aside from Content-Range, to replace
765   all instances of the corresponding header fields in the stored
766   response.
767
768   The combined response message body consists of the union of partial
769   content ranges in the new response and each of the selected
770   responses.  If the union consists of the entire range of the
771   representation, then the client MUST process the combined response as
772   if it were a complete 200 (OK) response, including a Content-Length
773   header field that reflects the complete length.  Otherwise, the
774   client MUST process the set of continuous ranges as one of the
775   following: an incomplete 200 (OK) response if the combined response
776   is a prefix of the representation, a single 206 (Partial Content)
777   response containing a multipart/byteranges body, or multiple 206
778   (Partial Content) responses, each with one continuous range that is
779   indicated by a Content-Range header field.
780
781
782
783Fielding, et al.        Expires November 29, 2014              [Page 14]
784
785Internet-Draft           HTTP/1.1 Range Requests                May 2014
786
787
7884.4.  416 Range Not Satisfiable
789
790   The 416 (Range Not Satisfiable) status code indicates that none of
791   the ranges in the request's Range header field (Section 3.1) overlap
792   the current extent of the selected resource or that the set of ranges
793   requested has been rejected due to invalid ranges or an excessive
794   request of small or overlapping ranges.
795
796   For byte ranges, failing to overlap the current extent means that the
797   first-byte-pos of all of the byte-range-spec values were greater than
798   the current length of the selected representation.  When this status
799   code is generated in response to a byte-range request, the sender
800   SHOULD generate a Content-Range header field specifying the current
801   length of the selected representation (Section 4.2).
802
803   For example:
804
805     HTTP/1.1 416 Range Not Satisfiable
806     Date: Fri, 20 Jan 2012 15:41:54 GMT
807     Content-Range: bytes */47022
808
809      Note: Because servers are free to ignore Range, many
810      implementations will simply respond with the entire selected
811      representation in a 200 (OK) response.  That is partly because
812      most clients are prepared to receive a 200 (OK) to complete the
813      task (albeit less efficiently) and partly because clients might
814      not stop making an invalid partial request until they have
815      received a complete representation.  Thus, clients cannot depend
816      on receiving a 416 (Range Not Satisfiable) response even when it
817      is most appropriate.
818
8195.  IANA Considerations
820
8215.1.  Range Unit Registry
822
823   The "HTTP Range Unit Registry" defines the namespace for the range
824   unit names and refers to their corresponding specifications.  The
825   registry has been created and is now maintained at
826   <http://www.iana.org/assignments/http-parameters>.
827
8285.1.1.  Procedure
829
830   Registration of an HTTP Range Unit MUST include the following fields:
831
832   o  Name
833
834   o  Description
835
836
837
838
839Fielding, et al.        Expires November 29, 2014              [Page 15]
840
841Internet-Draft           HTTP/1.1 Range Requests                May 2014
842
843
844   o  Pointer to specification text
845
846   Values to be added to this namespace require IETF Review (see
847   [RFC5226], Section 4.1).
848
8495.1.2.  Registrations
850
851   The initial range unit registry contains the registrations below:
852
853   +-------------+---------------------------------------+-------------+
854   | Range Unit  | Description                           | Reference   |
855   | Name        |                                       |             |
856   +-------------+---------------------------------------+-------------+
857   | bytes       | a range of octets                     | Section 2.1 |
858   | none        | reserved as keyword, indicating no    | Section 2.3 |
859   |             | ranges are supported                  |             |
860   +-------------+---------------------------------------+-------------+
861
862   The change controller is: "IETF (iesg@ietf.org) - Internet
863   Engineering Task Force".
864
8655.2.  Status Code Registration
866
867   The "Hypertext Transfer Protocol (HTTP) Status Code Registry" located
868   at <http://www.iana.org/assignments/http-status-codes> has been
869   updated to include the registrations below:
870
871   +-------+-----------------------+-------------+
872   | Value | Description           | Reference   |
873   +-------+-----------------------+-------------+
874   | 206   | Partial Content       | Section 4.1 |
875   | 416   | Range Not Satisfiable | Section 4.4 |
876   +-------+-----------------------+-------------+
877
8785.3.  Header Field Registration
879
880   HTTP header fields are registered within the "Message Headers"
881   registry maintained at
882   <http://www.iana.org/assignments/message-headers/>.
883
884   This document defines the following HTTP header fields, so their
885   associated registry entries have been updated according to the
886   permanent registrations below (see [BCP90]):
887
888
889
890
891
892
893
894
895Fielding, et al.        Expires November 29, 2014              [Page 16]
896
897Internet-Draft           HTTP/1.1 Range Requests                May 2014
898
899
900   +-------------------+----------+----------+-------------+
901   | Header Field Name | Protocol | Status   | Reference   |
902   +-------------------+----------+----------+-------------+
903   | Accept-Ranges     | http     | standard | Section 2.3 |
904   | Content-Range     | http     | standard | Section 4.2 |
905   | If-Range          | http     | standard | Section 3.2 |
906   | Range             | http     | standard | Section 3.1 |
907   +-------------------+----------+----------+-------------+
908
909   The change controller is: "IETF (iesg@ietf.org) - Internet
910   Engineering Task Force".
911
9125.4.  Internet Media Type Registration
913
914   IANA maintains the registry of Internet media types [BCP13] at
915   <http://www.iana.org/assignments/media-types>.
916
917   This document serves as the specification for the Internet media type
918   "multipart/byteranges".  The following has been registered with IANA.
919
9205.4.1.  Internet Media Type multipart/byteranges
921
922   Type name:  multipart
923
924   Subtype name:  byteranges
925
926   Required parameters:  boundary
927
928   Optional parameters:  N/A
929
930   Encoding considerations:  only "7bit", "8bit", or "binary" are
931      permitted
932
933   Security considerations:  see Section 6
934
935   Interoperability considerations:  N/A
936
937   Published specification:  This specification (see Appendix A).
938
939   Applications that use this media type:  HTTP components supporting
940      multiple ranges in a single request.
941
942   Fragment identifier considerations:  N/A
943
944   Additional information:
945
946
947
948
949
950
951Fielding, et al.        Expires November 29, 2014              [Page 17]
952
953Internet-Draft           HTTP/1.1 Range Requests                May 2014
954
955
956      Deprecated alias names for this type:  N/A
957
958      Magic number(s):  N/A
959
960      File extension(s):  N/A
961
962      Macintosh file type code(s):  N/A
963
964   Person and email address to contact for further information:  See
965      Authors' Addresses section.
966
967   Intended usage:  COMMON
968
969   Restrictions on usage:  N/A
970
971   Author:  See Authors' Addresses section.
972
973   Change controller:  IESG
974
9756.  Security Considerations
976
977   This section is meant to inform developers, information providers,
978   and users of known security concerns specific to the HTTP range
979   request mechanisms.  More general security considerations are
980   addressed in HTTP messaging [RFC7230] and semantics [RFC7231].
981
9826.1.  Denial-of-Service Attacks Using Range
983
984   Unconstrained multiple range requests are susceptible to denial-of-
985   service attacks because the effort required to request many
986   overlapping ranges of the same data is tiny compared to the time,
987   memory, and bandwidth consumed by attempting to serve the requested
988   data in many parts.  Servers ought to ignore, coalesce, or reject
989   egregious range requests, such as requests for more than two
990   overlapping ranges or for many small ranges in a single set,
991   particularly when the ranges are requested out of order for no
992   apparent reason.  Multipart range requests are not designed to
993   support random access.
994
9957.  Acknowledgments
996
997   See Section 10 of [RFC7230].
998
9998.  References
1000
1001
1002
1003
1004
1005
1006
1007Fielding, et al.        Expires November 29, 2014              [Page 18]
1008
1009Internet-Draft           HTTP/1.1 Range Requests                May 2014
1010
1011
10128.1.  Normative References
1013
1014   [RFC2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
1015              Extensions (MIME) Part Two: Media Types", RFC 2046,
1016              November 1996.
1017
1018   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
1019              Requirement Levels", BCP 14, RFC 2119, March 1997.
1020
1021   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
1022              Specifications: ABNF", STD 68, RFC 5234, January 2008.
1023
1024   [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1025              Protocol (HTTP/1.1): Message Syntax and Routing",
1026              draft-ietf-httpbis-p1-messaging-latest (work in progress),
1027              May 2014.
1028
1029   [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1030              Protocol (HTTP/1.1): Semantics and Content",
1031              draft-ietf-httpbis-p2-semantics-latest (work in progress),
1032              May 2014.
1033
1034   [RFC7232]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1035              Protocol (HTTP/1.1): Conditional Requests",
1036              draft-ietf-httpbis-p4-conditional-latest (work in
1037              progress), May 2014.
1038
1039   [RFC7234]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
1040              Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
1041              draft-ietf-httpbis-p6-cache-latest (work in progress),
1042              May 2014.
1043
10448.2.  Informative References
1045
1046   [BCP13]    Freed, N., Klensin, J., and T. Hansen, "Media Type
1047              Specifications and Registration Procedures", BCP 13,
1048              RFC 6838, January 2013.
1049
1050   [BCP90]    Klyne, G., Nottingham, M., and J. Mogul, "Registration
1051              Procedures for Message Header Fields", BCP 90, RFC 3864,
1052              September 2004.
1053
1054   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
1055              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
1056              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
1057
1058   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
1059              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
1060
1061
1062
1063Fielding, et al.        Expires November 29, 2014              [Page 19]
1064
1065Internet-Draft           HTTP/1.1 Range Requests                May 2014
1066
1067
1068              May 2008.
1069
1070Appendix A.  Internet Media Type multipart/byteranges
1071
1072   When a 206 (Partial Content) response message includes the content of
1073   multiple ranges, they are transmitted as body parts in a multipart
1074   message body ([RFC2046], Section 5.1) with the media type of
1075   "multipart/byteranges".
1076
1077   The multipart/byteranges media type includes one or more body parts,
1078   each with its own Content-Type and Content-Range fields.  The
1079   required boundary parameter specifies the boundary string used to
1080   separate each body part.
1081
1082   Implementation Notes:
1083
1084   1.  Additional CRLFs might precede the first boundary string in the
1085       body.
1086
1087   2.  Although [RFC2046] permits the boundary string to be quoted, some
1088       existing implementations handle a quoted boundary string
1089       incorrectly.
1090
1091   3.  A number of clients and servers were coded to an early draft of
1092       the byteranges specification that used a media type of multipart/
1093       x-byteranges, which is almost (but not quite) compatible with
1094       this type.
1095
1096   Despite the name, the "multipart/byteranges" media type is not
1097   limited to byte ranges.  The following example uses an "exampleunit"
1098   range unit:
1099
1100     HTTP/1.1 206 Partial Content
1101     Date: Tue, 14 Nov 1995 06:25:24 GMT
1102     Last-Modified: Tue, 14 July 04:58:08 GMT
1103     Content-Length: 2331785
1104     Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
1105
1106     --THIS_STRING_SEPARATES
1107     Content-Type: video/example
1108     Content-Range: exampleunit 1.2-4.3/25
1109
1110     ...the first range...
1111     --THIS_STRING_SEPARATES
1112     Content-Type: video/example
1113     Content-Range: exampleunit 11.2-14.3/25
1114
1115     ...the second range
1116
1117
1118
1119Fielding, et al.        Expires November 29, 2014              [Page 20]
1120
1121Internet-Draft           HTTP/1.1 Range Requests                May 2014
1122
1123
1124     --THIS_STRING_SEPARATES--
1125
1126Appendix B.  Changes from RFC 2616
1127
1128   Servers are given more leeway in how they respond to a range request,
1129   in order to mitigate abuse by malicious (or just greedy) clients.
1130   (Section 3.1)
1131
1132   A weak validator cannot be used in a 206 response.  (Section 4.1)
1133
1134   The Content-Range header field only has meaning when the status code
1135   explicitly defines its use.  (Section 4.2)
1136
1137   This specification introduces a Range Unit Registry.  (Section 5.1)
1138
1139   multipart/byteranges can consist of a single part.  (Appendix A)
1140
1141Appendix C.  Imported ABNF
1142
1143   The following core rules are included by reference, as defined in
1144   Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return),
1145   CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double
1146   quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any
1147   8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII
1148   character).
1149
1150   Note that all rules derived from token are to be compared case-
1151   insensitively, like range-unit and acceptable-ranges.
1152
1153   The rules below are defined in [RFC7230]:
1154
1155     OWS        = <OWS, see [RFC7230], Section 3.2.3>
1156     token      = <token, see [RFC7230], Section 3.2.6>
1157
1158   The rules below are defined in other parts:
1159
1160     HTTP-date  = <HTTP-date, see [RFC7231], Section 7.1.1.1>
1161     entity-tag = <entity-tag, see [RFC7232], Section 2.3>
1162
1163Appendix D.  Collected ABNF
1164
1165   In the collected ABNF below, list rules are expanded as per Section
1166   1.2 of [RFC7230].
1167
1168
1169
1170
1171
1172
1173
1174
1175Fielding, et al.        Expires November 29, 2014              [Page 21]
1176
1177Internet-Draft           HTTP/1.1 Range Requests                May 2014
1178
1179
1180   Accept-Ranges = acceptable-ranges
1181
1182   Content-Range = byte-content-range / other-content-range
1183
1184   HTTP-date = <HTTP-date, see [RFC7231], Section 7.1.1.1>
1185
1186   If-Range = entity-tag / HTTP-date
1187
1188   OWS = <OWS, see [RFC7230], Section 3.2.3>
1189
1190   Range = byte-ranges-specifier / other-ranges-specifier
1191
1192   acceptable-ranges = ( *( "," OWS ) range-unit *( OWS "," [ OWS
1193    range-unit ] ) ) / "none"
1194
1195   byte-content-range = bytes-unit SP ( byte-range-resp /
1196    unsatisfied-range )
1197   byte-range = first-byte-pos "-" last-byte-pos
1198   byte-range-resp = byte-range "/" ( complete-length / "*" )
1199   byte-range-set = *( "," OWS ) ( byte-range-spec /
1200    suffix-byte-range-spec ) *( OWS "," [ OWS ( byte-range-spec /
1201    suffix-byte-range-spec ) ] )
1202   byte-range-spec = first-byte-pos "-" [ last-byte-pos ]
1203   byte-ranges-specifier = bytes-unit "=" byte-range-set
1204   bytes-unit = "bytes"
1205
1206   complete-length = 1*DIGIT
1207
1208   entity-tag = <entity-tag, see [RFC7232], Section 2.3>
1209
1210   first-byte-pos = 1*DIGIT
1211
1212   last-byte-pos = 1*DIGIT
1213
1214   other-content-range = other-range-unit SP other-range-resp
1215   other-range-resp = *CHAR
1216   other-range-set = 1*VCHAR
1217   other-range-unit = token
1218   other-ranges-specifier = other-range-unit "=" other-range-set
1219
1220   range-unit = bytes-unit / other-range-unit
1221
1222   suffix-byte-range-spec = "-" suffix-length
1223   suffix-length = 1*DIGIT
1224
1225   token = <token, see [RFC7230], Section 3.2.6>
1226
1227   unsatisfied-range = "*/" complete-length
1228
1229
1230
1231Fielding, et al.        Expires November 29, 2014              [Page 22]
1232
1233Internet-Draft           HTTP/1.1 Range Requests                May 2014
1234
1235
1236Index
1237
1238   2
1239      206 Partial Content (status code)  10
1240
1241   4
1242      416 Range Not Satisfiable (status code)  15
1243
1244   A
1245      Accept-Ranges header field  7
1246
1247   C
1248      Content-Range header field  12
1249
1250   G
1251      Grammar
1252         Accept-Ranges  7
1253         acceptable-ranges  7
1254         byte-content-range  12
1255         byte-range  12
1256         byte-range-resp  12
1257         byte-range-set  5
1258         byte-range-spec  5
1259         byte-ranges-specifier  5
1260         bytes-unit  5
1261         complete-length  12
1262         Content-Range  12
1263         first-byte-pos  5
1264         If-Range  9
1265         last-byte-pos  5
1266         other-content-range  12
1267         other-range-resp  12
1268         other-range-unit  5, 7
1269         Range  7
1270         range-unit  5
1271         ranges-specifier  5
1272         suffix-byte-range-spec  6
1273         suffix-length  6
1274         unsatisfied-range  12
1275
1276   I
1277      If-Range header field  9
1278
1279   M
1280      Media Type
1281         multipart/byteranges  17, 20
1282         multipart/x-byteranges  20
1283      multipart/byteranges Media Type  17, 20
1284
1285
1286
1287Fielding, et al.        Expires November 29, 2014              [Page 23]
1288
1289Internet-Draft           HTTP/1.1 Range Requests                May 2014
1290
1291
1292      multipart/x-byteranges Media Type  20
1293
1294   R
1295      Range header field  7
1296
1297Authors' Addresses
1298
1299   Roy T. Fielding (editor)
1300   Adobe Systems Incorporated
1301   345 Park Ave
1302   San Jose, CA  95110
1303   USA
1304
1305   EMail: fielding@gbiv.com
1306   URI:   http://roy.gbiv.com/
1307
1308
1309   Yves Lafon (editor)
1310   World Wide Web Consortium
1311   W3C / ERCIM
1312   2004, rte des Lucioles
1313   Sophia-Antipolis, AM  06902
1314   France
1315
1316   EMail: ylafon@w3.org
1317   URI:   http://www.raubacapeu.net/people/yves/
1318
1319
1320   Julian F. Reschke (editor)
1321   greenbytes GmbH
1322   Hafenweg 16
1323   Muenster, NW  48155
1324   Germany
1325
1326   EMail: julian.reschke@greenbytes.de
1327   URI:   http://greenbytes.de/tech/webdav/
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343Fielding, et al.        Expires November 29, 2014              [Page 24]
1344
Note: See TracBrowser for help on using the repository browser.