source: draft-ietf-httpbis/20/draft-ietf-httpbis-p5-range-20.txt

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

Remove mentions of "seven" parts.

  • Property svn:eol-style set to native
  • Property svn:executable set to *
File size: 45.9 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: January 17, 2013                                J. Reschke, Ed.
9                                                              greenbytes
10                                                           July 16, 2012
11
12
13                    HTTP/1.1, part 5: Range Requests
14                     draft-ietf-httpbis-p5-range-20
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.1.
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 January 17, 2013.
52
53
54
55Fielding, et al.        Expires January 17, 2013                [Page 1]
56
57Internet-Draft              HTTP/1.1, Part 5                   July 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 January 17, 2013                [Page 2]
112
113Internet-Draft              HTTP/1.1, Part 5                   July 2012
114
115
116Table of Contents
117
118   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
119     1.1.  Conformance and Error Handling . . . . . . . . . . . . . .  4
120     1.2.  Syntax Notation  . . . . . . . . . . . . . . . . . . . . .  5
121   2.  Range Units  . . . . . . . . . . . . . . . . . . . . . . . . .  5
122     2.1.  Range Specifier Registry . . . . . . . . . . . . . . . . .  6
123   3.  Status Code Definitions  . . . . . . . . . . . . . . . . . . .  6
124     3.1.  206 Partial Content  . . . . . . . . . . . . . . . . . . .  6
125     3.2.  416 Requested Range Not Satisfiable  . . . . . . . . . . .  7
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 . . . . . . . . . . . . . . . . . . . . .  8
129   5.  Header Field Definitions . . . . . . . . . . . . . . . . . . .  9
130     5.1.  Accept-Ranges  . . . . . . . . . . . . . . . . . . . . . .  9
131     5.2.  Content-Range  . . . . . . . . . . . . . . . . . . . . . . 10
132     5.3.  If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 11
133     5.4.  Range  . . . . . . . . . . . . . . . . . . . . . . . . . . 12
134       5.4.1.  Byte Ranges  . . . . . . . . . . . . . . . . . . . . . 12
135       5.4.2.  Range Retrieval Requests . . . . . . . . . . . . . . . 14
136   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
137     6.1.  Status Code Registration . . . . . . . . . . . . . . . . . 15
138     6.2.  Header Field Registration  . . . . . . . . . . . . . . . . 15
139     6.3.  Range Specifier Registration . . . . . . . . . . . . . . . 16
140   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
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 . . . . . . . . . . . . . . . . . . 17
146   Appendix A.  Internet Media Type multipart/byteranges  . . . . . . 18
147   Appendix B.  Changes from RFC 2616 . . . . . . . . . . . . . . . . 20
148   Appendix C.  Imported ABNF . . . . . . . . . . . . . . . . . . . . 20
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   Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
154
155
156
157
158
159
160
161
162
163
164
165
166
167Fielding, et al.        Expires January 17, 2013                [Page 3]
168
169Internet-Draft              HTTP/1.1, Part 5                   July 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   This specification targets conformance criteria according to the role
204   of a participant in HTTP communication.  Hence, HTTP requirements are
205   placed on senders, recipients, clients, servers, user agents,
206   intermediaries, origin servers, proxies, gateways, or caches,
207   depending on what behavior is being constrained by the requirement.
208   See Section 2 of [Part1] for definitions of these terms.
209
210   The verb "generate" is used instead of "send" where a requirement
211   differentiates between creating a protocol element and merely
212   forwarding a received element downstream.
213
214   An implementation is considered conformant if it complies with all of
215   the requirements associated with the roles it partakes in HTTP.  Note
216   that SHOULD-level requirements are relevant here, unless one of the
217   documented exceptions is applicable.
218
219   This document also uses ABNF to define valid protocol elements
220
221
222
223Fielding, et al.        Expires January 17, 2013                [Page 4]
224
225Internet-Draft              HTTP/1.1, Part 5                   July 2012
226
227
228   (Section 1.2).  In addition to the prose requirements placed upon
229   them, senders MUST NOT generate protocol elements that do not match
230   the grammar defined by the ABNF rules for those protocol elements
231   that are applicable to the sender's role.  If a received protocol
232   element is processed, the recipient MUST be able to parse any value
233   that would match the ABNF rules for that protocol element, excluding
234   only those rules not applicable to the recipient's role.
235
236   Unless noted otherwise, a recipient MAY attempt to recover a usable
237   protocol element from an invalid construct.  HTTP does not define
238   specific error handling mechanisms except when they have a direct
239   impact on security, since different applications of the protocol
240   require different error handling strategies.  For example, a Web
241   browser might wish to transparently recover from a response where the
242   Location header field doesn't parse according to the ABNF, whereas a
243   systems control client might consider any form of error recovery to
244   be dangerous.
245
2461.2.  Syntax Notation
247
248   This specification uses the Augmented Backus-Naur Form (ABNF)
249   notation of [RFC5234] with the list rule extension defined in Section
250   1.2 of [Part1].  Appendix C describes rules imported from other
251   documents.  Appendix D shows the collected ABNF with the list rule
252   expanded.
253
2542.  Range Units
255
256   HTTP/1.1 allows a client to request that only part (a range) of the
257   representation be included within the response.  HTTP/1.1 uses range
258   units in the Range (Section 5.4) and Content-Range (Section 5.2)
259   header fields.  A representation can be broken down into subranges
260   according to various structural units.
261
262     range-unit       = bytes-unit / other-range-unit
263     bytes-unit       = "bytes"
264     other-range-unit = token
265
266   HTTP/1.1 has been designed to allow implementations of applications
267   that do not depend on knowledge of ranges.  The only range unit
268   defined by HTTP/1.1 is "bytes".  Additional specifiers can be defined
269   as described in Section 2.1.
270
271   If a range unit is not understood in a request, a server MUST ignore
272   the whole Range header field (Section 5.4).  If a range unit is not
273   understood in a response, an intermediary SHOULD pass the response to
274   the client; a client MUST fail.
275
276
277
278
279Fielding, et al.        Expires January 17, 2013                [Page 5]
280
281Internet-Draft              HTTP/1.1, Part 5                   July 2012
282
283
2842.1.  Range Specifier Registry
285
286   The HTTP Range Specifier Registry defines the name space for the
287   range specifier names.
288
289   Registrations MUST include the following fields:
290
291   o  Name
292
293   o  Description
294
295   o  Pointer to specification text
296
297   Values to be added to this name space require IETF Review (see
298   [RFC5226], Section 4.1).
299
300   The registry itself is maintained at
301   <http://www.iana.org/assignments/http-range-specifiers>.
302
3033.  Status Code Definitions
304
3053.1.  206 Partial Content
306
307   The server has fulfilled the partial GET request for the resource.
308   The request MUST have included a Range header field (Section 5.4)
309   indicating the desired range, and MAY have included an If-Range
310   header field (Section 5.3) to make the request conditional.
311
312   The response MUST include the following header fields:
313
314   o  Either a Content-Range header field (Section 5.2) indicating the
315      range included with this response, or a multipart/byteranges
316      Content-Type including Content-Range fields for each part.  If a
317      Content-Length header field is present in the response, its value
318      MUST match the actual number of octets transmitted in the message
319      body.
320
321   o  Date
322
323   o  Cache-Control, ETag, Expires, Content-Location and/or Vary, if the
324      header field would have been sent in a 200 (OK) response to the
325      same request
326
327   If a 206 is sent in response to a request with an If-Range header
328   field, it SHOULD NOT include other representation header fields.
329   Otherwise, the response MUST include all of the representation header
330   fields that would have been returned with a 200 (OK) response to the
331   same request.
332
333
334
335Fielding, et al.        Expires January 17, 2013                [Page 6]
336
337Internet-Draft              HTTP/1.1, Part 5                   July 2012
338
339
340   Caches MAY use a heuristic (see Section 4.1.2 of [Part6]) to
341   determine freshness for 206 responses.
342
3433.2.  416 Requested Range Not Satisfiable
344
345   A server SHOULD return a response with this status code if a request
346   included a Range header field (Section 5.4), and none of the ranges-
347   specifier values in this field overlap the current extent of the
348   selected resource, and the request did not include an If-Range header
349   field (Section 5.3).  (For byte-ranges, this means that the first-
350   byte-pos of all of the byte-range-spec values were greater than the
351   current length of the selected resource.)
352
353   When this status code is returned for a byte-range request, the
354   response SHOULD include a Content-Range header field specifying the
355   current length of the representation (see Section 5.2).  This
356   response MUST NOT use the multipart/byteranges content-type.  For
357   example,
358
359     HTTP/1.1 416 Requested Range Not Satisfiable
360     Date: Mon, 20 Jan 2012 15:41:54 GMT
361     Content-Range: bytes */47022
362     Content-Type: image/gif
363
364      Note: Clients cannot depend on servers to send a 416 (Requested
365      Range Not Satisfiable) response instead of a 200 (OK) response for
366      an unsatisfiable Range header field, since not all servers
367      implement this header field.
368
3694.  Responses to a Range Request
370
3714.1.  Response to a Single and Multiple Ranges Request
372
373   When an HTTP message includes the content of a single range (for
374   example, a response to a request for a single range, or to a request
375   for a set of ranges that overlap without any holes), this content is
376   transmitted with a Content-Range header field, and a Content-Length
377   header field showing the number of bytes actually transferred.  For
378   example,
379
380     HTTP/1.1 206 Partial Content
381     Date: Wed, 15 Nov 1995 06:25:24 GMT
382     Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
383     Content-Range: bytes 21010-47021/47022
384     Content-Length: 26012
385     Content-Type: image/gif
386
387   When an HTTP message includes the content of multiple ranges (for
388
389
390
391Fielding, et al.        Expires January 17, 2013                [Page 7]
392
393Internet-Draft              HTTP/1.1, Part 5                   July 2012
394
395
396   example, a response to a request for multiple non-overlapping
397   ranges), these are transmitted as a multipart message.  The multipart
398   media type used for this purpose is "multipart/byteranges" as defined
399   in Appendix A.
400
401   A server MAY combine requested ranges when those ranges are
402   overlapping (see Section 7.1).
403
404   A response to a request for a single range MUST NOT be sent using the
405   multipart/byteranges media type.  A response to a request for
406   multiple ranges, whose result is a single range, MAY be sent as a
407   multipart/byteranges media type with one part.  A client that cannot
408   decode a multipart/byteranges message MUST NOT ask for multiple
409   ranges in a single request.
410
411   When a client asks for multiple ranges in one request, the server
412   SHOULD return them in the order that they appeared in the request.
413
4144.2.  Combining Ranges
415
416   A response might transfer only a subrange of a representation if the
417   connection closed prematurely or if the request used one or more
418   Range specifications.  After several such transfers, a client might
419   have received several ranges of the same representation.  These
420   ranges can only be safely combined if they all have in common the
421   same strong validator, where "strong validator" is defined to be
422   either an entity-tag that is not marked as weak (Section 2.3 of
423   [Part4]) or, if no entity-tag is provided, a Last-Modified value that
424   is strong in the sense defined by Section 2.2.2 of [Part4].
425
426   When a client receives an incomplete 200 (OK) or 206 (Partial
427   Content) response and already has one or more stored responses for
428   the same method and effective request URI, all of the stored
429   responses with the same strong validator MAY be combined with the
430   partial content in this new response.  If none of the stored
431   responses contain the same strong validator, then this new response
432   corresponds to a new representation and MUST NOT be combined with the
433   existing stored responses.
434
435   If the new response is an incomplete 200 (OK) response, then the
436   header fields of that new response are used for any combined response
437   and replace those of the matching stored responses.
438
439   If the new response is a 206 (Partial Content) response and at least
440   one of the matching stored responses is a 200 (OK), then the combined
441   response header fields consist of the most recent 200 response's
442   header fields.  If all of the matching stored responses are 206
443   responses, then the stored response with the most header fields is
444
445
446
447Fielding, et al.        Expires January 17, 2013                [Page 8]
448
449Internet-Draft              HTTP/1.1, Part 5                   July 2012
450
451
452   used as the source of header fields for the combined response, except
453   that the client MUST use other header fields provided in the new
454   response, aside from Content-Range, to replace all instances of the
455   corresponding header fields in the stored response.
456
457   The combined response message body consists of the union of partial
458   content ranges in the new response and each of the selected
459   responses.  If the union consists of the entire range of the
460   representation, then the combined response MUST be recorded as a
461   complete 200 (OK) response with a Content-Length header field that
462   reflects the complete length.  Otherwise, the combined response(s)
463   MUST include a Content-Range header field describing the included
464   range(s) and be recorded as incomplete.  If the union consists of a
465   discontinuous range of the representation, then the client MAY store
466   it as either a multipart range response or as multiple 206 responses
467   with one continuous range each.
468
4695.  Header Field Definitions
470
471   This section defines the syntax and semantics of HTTP/1.1 header
472   fields related to range requests and partial responses.
473
4745.1.  Accept-Ranges
475
476   The "Accept-Ranges" header field allows a resource to indicate its
477   acceptance of range requests.
478
479     Accept-Ranges     = acceptable-ranges
480     acceptable-ranges = 1#range-unit / "none"
481
482   Origin servers that accept byte-range requests MAY send
483
484     Accept-Ranges: bytes
485
486   but are not required to do so.  Clients MAY generate range requests
487   without having received this header field for the resource involved.
488   Range units are defined in Section 2.
489
490   Servers that do not accept any kind of range request for a resource
491   MAY send
492
493     Accept-Ranges: none
494
495   to advise the client not to attempt a range request.
496
497
498
499
500
501
502
503Fielding, et al.        Expires January 17, 2013                [Page 9]
504
505Internet-Draft              HTTP/1.1, Part 5                   July 2012
506
507
5085.2.  Content-Range
509
510   The "Content-Range" header field is sent with a partial
511   representation to specify where in the full representation the
512   payload body is intended to be applied.
513
514   Range units are defined in Section 2.
515
516     Content-Range           = byte-content-range-spec
517                             / other-content-range-spec
518
519     byte-content-range-spec = bytes-unit SP
520                               byte-range-resp-spec "/"
521                               ( instance-length / "*" )
522
523     byte-range-resp-spec    = (first-byte-pos "-" last-byte-pos)
524                             / "*"
525
526     instance-length         = 1*DIGIT
527
528     other-content-range-spec = other-range-unit SP
529                                other-range-resp-spec
530     other-range-resp-spec    = *CHAR
531
532   The header field SHOULD indicate the total length of the full
533   representation, unless this length is unknown or difficult to
534   determine.  The asterisk "*" character means that the instance-length
535   is unknown at the time when the response was generated.
536
537   Unlike byte-ranges-specifier values (see Section 5.4.1), a byte-
538   range-resp-spec MUST only specify one range, and MUST contain
539   absolute byte positions for both the first and last byte of the
540   range.
541
542   A byte-content-range-spec with a byte-range-resp-spec whose last-
543   byte-pos value is less than its first-byte-pos value, or whose
544   instance-length value is less than or equal to its last-byte-pos
545   value, is invalid.  The recipient of an invalid byte-content-range-
546   spec MUST ignore it and any content transferred along with it.
547
548   In the case of a byte range request: A server sending a response with
549   status code 416 (Requested Range Not Satisfiable) SHOULD include a
550   Content-Range field with a byte-range-resp-spec of "*".  The
551   instance-length specifies the current length of the selected
552   resource.  A response with status code 206 (Partial Content) MUST NOT
553   include a Content-Range field with a byte-range-resp-spec of "*".
554
555   The "Content-Range" header field has no meaning for status codes that
556
557
558
559Fielding, et al.        Expires January 17, 2013               [Page 10]
560
561Internet-Draft              HTTP/1.1, Part 5                   July 2012
562
563
564   do not explicitly describe its semantic.  Currently, only status
565   codes 206 (Partial Content) and 416 (Requested Range Not Satisfiable)
566   describe the meaning of this header field.
567
568   Examples of byte-content-range-spec values, assuming that the
569   representation contains a total of 1234 bytes:
570
571   o  The first 500 bytes:
572
573        bytes 0-499/1234
574
575   o  The second 500 bytes:
576
577        bytes 500-999/1234
578
579   o  All except for the first 500 bytes:
580
581        bytes 500-1233/1234
582
583   o  The last 500 bytes:
584
585        bytes 734-1233/1234
586
587   If the server ignores a byte-range-spec (for example if it is
588   syntactically invalid, or if it might be seen as a denial-of-service
589   attack), the server SHOULD treat the request as if the invalid Range
590   header field did not exist.  (Normally, this means return a 200 (OK)
591   response containing the full representation).
592
5935.3.  If-Range
594
595   If a client has a partial copy of a representation and wishes to have
596   an up-to-date copy of the entire representation, it could use the
597   Range header field with a conditional GET (using either or both of
598   If-Unmodified-Since and If-Match.)  However, if the condition fails
599   because the representation has been modified, the client would then
600   have to make a second request to obtain the entire current
601   representation.
602
603   The "If-Range" header field allows a client to "short-circuit" the
604   second request.  Informally, its meaning is "if the representation is
605   unchanged, send me the part(s) that I am missing; otherwise, send me
606   the entire new representation".
607
608     If-Range = entity-tag / HTTP-date
609
610   Clients MUST NOT use an entity-tag marked as weak in an If-Range
611   field value and MUST NOT use a Last-Modified date in an If-Range
612
613
614
615Fielding, et al.        Expires January 17, 2013               [Page 11]
616
617Internet-Draft              HTTP/1.1, Part 5                   July 2012
618
619
620   field value unless it has no entity-tag for the representation and
621   the Last-Modified date it does have for the representation is strong
622   in the sense defined by Section 2.2.2 of [Part4].
623
624   A server that evaluates a conditional range request that is
625   applicable to one of its representations MUST evaluate the condition
626   as false if the entity-tag used as a validator is marked as weak or,
627   when an HTTP-date is used as the validator, if the date value is not
628   strong in the sense defined by Section 2.2.2 of [Part4].  (A server
629   can distinguish between a valid HTTP-date and any form of entity-tag
630   by examining the first two characters.)
631
632   The If-Range header field SHOULD only be sent by clients together
633   with a Range header field.  The If-Range header field MUST be ignored
634   if it is received in a request that does not include a Range header
635   field.  The If-Range header field MUST be ignored by a server that
636   does not support the sub-range operation.
637
638   If the validator given in the If-Range header field matches the
639   current validator for the selected representation of the target
640   resource, then the server SHOULD send the specified sub-range of the
641   representation using a 206 (Partial Content) response.  If the
642   validator does not match, then the server SHOULD send the entire
643   representation using a 200 (OK) response.
644
6455.4.  Range
646
6475.4.1.  Byte Ranges
648
649   Since all HTTP representations are transferred as sequences of bytes,
650   the concept of a byte range is meaningful for any HTTP
651   representation.  (However, not all clients and servers need to
652   support byte-range operations.)
653
654   Byte range specifications in HTTP apply to the sequence of bytes in
655   the representation body (not necessarily the same as the message
656   body).
657
658   A byte range operation MAY specify a single range of bytes, or a set
659   of ranges within a single representation.
660
661     byte-ranges-specifier = bytes-unit "=" byte-range-set
662     byte-range-set  = 1#( byte-range-spec / suffix-byte-range-spec )
663     byte-range-spec = first-byte-pos "-" [ last-byte-pos ]
664     first-byte-pos  = 1*DIGIT
665     last-byte-pos   = 1*DIGIT
666
667   The first-byte-pos value in a byte-range-spec gives the byte-offset
668
669
670
671Fielding, et al.        Expires January 17, 2013               [Page 12]
672
673Internet-Draft              HTTP/1.1, Part 5                   July 2012
674
675
676   of the first byte in a range.  The last-byte-pos value gives the
677   byte-offset of the last byte in the range; that is, the byte
678   positions specified are inclusive.  Byte offsets start at zero.
679
680   If the last-byte-pos value is present, it MUST be greater than or
681   equal to the first-byte-pos in that byte-range-spec, or the byte-
682   range-spec is syntactically invalid.  The recipient of a byte-range-
683   set that includes one or more syntactically invalid byte-range-spec
684   values MUST ignore the header field that includes that byte-range-
685   set.
686
687   If the last-byte-pos value is absent, or if the value is greater than
688   or equal to the current length of the representation body, last-byte-
689   pos is taken to be equal to one less than the current length of the
690   representation in bytes.
691
692   By its choice of last-byte-pos, a client can limit the number of
693   bytes retrieved without knowing the size of the representation.
694
695     suffix-byte-range-spec = "-" suffix-length
696     suffix-length = 1*DIGIT
697
698   A suffix-byte-range-spec is used to specify the suffix of the
699   representation body, of a length given by the suffix-length value.
700   (That is, this form specifies the last N bytes of a representation.)
701   If the representation is shorter than the specified suffix-length,
702   the entire representation is used.
703
704   If a syntactically valid byte-range-set includes at least one byte-
705   range-spec whose first-byte-pos is less than the current length of
706   the representation, or at least one suffix-byte-range-spec with a
707   non-zero suffix-length, then the byte-range-set is satisfiable.
708   Otherwise, the byte-range-set is unsatisfiable.  If the byte-range-
709   set is unsatisfiable, the server SHOULD return a response with a 416
710   (Requested Range Not Satisfiable) status code.  Otherwise, the server
711   SHOULD return a response with a 206 (Partial Content) status code
712   containing the satisfiable ranges of the representation.
713
714   In the byte range syntax, first-byte-pos, last-byte-pos, and suffix-
715   length are expressed as decimal number of octets.  Since there is no
716   predefined limit to the length of an HTTP payload, recipients SHOULD
717   anticipate potentially large decimal numerals and prevent parsing
718   errors due to integer conversion overflows.
719
720   Examples of byte-ranges-specifier values (assuming a representation
721   of length 10000):
722
723
724
725
726
727Fielding, et al.        Expires January 17, 2013               [Page 13]
728
729Internet-Draft              HTTP/1.1, Part 5                   July 2012
730
731
732   o  The first 500 bytes (byte offsets 0-499, inclusive):
733
734        bytes=0-499
735
736   o  The second 500 bytes (byte offsets 500-999, inclusive):
737
738        bytes=500-999
739
740   o  The final 500 bytes (byte offsets 9500-9999, inclusive):
741
742        bytes=-500
743
744      Or:
745
746        bytes=9500-
747
748   o  The first and last bytes only (bytes 0 and 9999):
749
750        bytes=0-0,-1
751
752   o  Several legal but not canonical specifications of the second 500
753      bytes (byte offsets 500-999, inclusive):
754
755        bytes=500-600,601-999
756        bytes=500-700,601-999
757
7585.4.2.  Range Retrieval Requests
759
760   The "Range" header field defines the GET method (conditional or not)
761   to request one or more sub-ranges of the response representation
762   body, instead of the entire representation body.
763
764     Range = byte-ranges-specifier / other-ranges-specifier
765     other-ranges-specifier = other-range-unit "=" other-range-set
766     other-range-set = 1*CHAR
767
768   A server MAY ignore the Range header field.  However, origin servers
769   and intermediate caches ought to support byte ranges when possible,
770   since Range supports efficient recovery from partially failed
771   transfers, and supports efficient partial retrieval of large
772   representations.
773
774   If the server supports the Range header field and the specified range
775   or ranges are appropriate for the representation:
776
777   o  The presence of a Range header field in an unconditional GET
778      modifies what is returned if the GET is otherwise successful.  In
779      other words, the response carries a status code of 206 (Partial
780
781
782
783Fielding, et al.        Expires January 17, 2013               [Page 14]
784
785Internet-Draft              HTTP/1.1, Part 5                   July 2012
786
787
788      Content) instead of 200 (OK).
789
790   o  The presence of a Range header field in a conditional GET (a
791      request using one or both of If-Modified-Since and If-None-Match,
792      or one or both of If-Unmodified-Since and If-Match) modifies what
793      is returned if the GET is otherwise successful and the condition
794      is true.  It does not affect the 304 (Not Modified) response
795      returned if the conditional is false.
796
797   In some cases, it might be more appropriate to use the If-Range
798   header field (see Section 5.3) in addition to the Range header field.
799
800   If a proxy that supports ranges receives a Range request, forwards
801   the request to an inbound server, and receives an entire
802   representation in reply, it MAY only return the requested range to
803   its client.
804
8056.  IANA Considerations
806
8076.1.  Status Code Registration
808
809   The HTTP Status Code Registry located at
810   <http://www.iana.org/assignments/http-status-codes> shall be updated
811   with the registrations below:
812
813   +-------+---------------------------------+-------------+
814   | Value | Description                     | Reference   |
815   +-------+---------------------------------+-------------+
816   | 206   | Partial Content                 | Section 3.1 |
817   | 416   | Requested Range Not Satisfiable | Section 3.2 |
818   +-------+---------------------------------+-------------+
819
8206.2.  Header Field Registration
821
822   The Message Header Field Registry located at <http://www.iana.org/
823   assignments/message-headers/message-header-index.html> shall be
824   updated with the permanent registrations below (see [RFC3864]):
825
826   +-------------------+----------+----------+-------------+
827   | Header Field Name | Protocol | Status   | Reference   |
828   +-------------------+----------+----------+-------------+
829   | Accept-Ranges     | http     | standard | Section 5.1 |
830   | Content-Range     | http     | standard | Section 5.2 |
831   | If-Range          | http     | standard | Section 5.3 |
832   | Range             | http     | standard | Section 5.4 |
833   +-------------------+----------+----------+-------------+
834
835   The change controller is: "IETF (iesg@ietf.org) - Internet
836
837
838
839Fielding, et al.        Expires January 17, 2013               [Page 15]
840
841Internet-Draft              HTTP/1.1, Part 5                   July 2012
842
843
844   Engineering Task Force".
845
8466.3.  Range Specifier Registration
847
848   The registration procedure for HTTP Range Specifiers is defined by
849   Section 2.1 of this document.
850
851   The HTTP Range Specifier Registry shall be created at
852   <http://www.iana.org/assignments/http-range-specifiers> and be
853   populated with the registrations below:
854
855   +---------------+-------------------------------------+-------------+
856   | Range         | Description                         | Reference   |
857   | Specifier     |                                     |             |
858   | Name          |                                     |             |
859   +---------------+-------------------------------------+-------------+
860   | bytes         | a range of octets                   | Section 2   |
861   | none          | reserved as keyword, indicating no  | Section 5.1 |
862   |               | ranges are supported                |             |
863   +---------------+-------------------------------------+-------------+
864
865   The change controller is: "IETF (iesg@ietf.org) - Internet
866   Engineering Task Force".
867
8687.  Security Considerations
869
870   This section is meant to inform application developers, information
871   providers, and users of the security limitations in HTTP/1.1 as
872   described by this document.  The discussion does not include
873   definitive solutions to the problems revealed, though it does make
874   some suggestions for reducing security risks.
875
8767.1.  Overlapping Ranges
877
878   Range requests containing overlapping ranges can lead to the
879   situation where a server is sending far more data than the size of
880   the complete resource representation.
881
8828.  Acknowledgments
883
884   See Section 9 of [Part1].
885
8869.  References
887
8889.1.  Normative References
889
890   [Part1]    Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
891              "HTTP/1.1, part 1: Message Routing and Syntax"",
892
893
894
895Fielding, et al.        Expires January 17, 2013               [Page 16]
896
897Internet-Draft              HTTP/1.1, Part 5                   July 2012
898
899
900              draft-ietf-httpbis-p1-messaging-20 (work in progress),
901              July 2012.
902
903   [Part2]    Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
904              "HTTP/1.1, part 2: Semantics and Payloads",
905              draft-ietf-httpbis-p2-semantics-20 (work in progress),
906              July 2012.
907
908   [Part4]    Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
909              "HTTP/1.1, part 4: Conditional Requests",
910              draft-ietf-httpbis-p4-conditional-20 (work in progress),
911              July 2012.
912
913   [Part6]    Fielding, R., Ed., Lafon, Y., Ed., Nottingham, M., Ed.,
914              and J. Reschke, Ed., "HTTP/1.1, part 6: Caching",
915              draft-ietf-httpbis-p6-cache-20 (work in progress),
916              July 2012.
917
918   [RFC2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
919              Extensions (MIME) Part Two: Media Types", RFC 2046,
920              November 1996.
921
922   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
923              Requirement Levels", BCP 14, RFC 2119, March 1997.
924
925   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
926              Specifications: ABNF", STD 68, RFC 5234, January 2008.
927
9289.2.  Informative References
929
930   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
931              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
932              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
933
934   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
935              Procedures for Message Header Fields", BCP 90, RFC 3864,
936              September 2004.
937
938   [RFC4288]  Freed, N. and J. Klensin, "Media Type Specifications and
939              Registration Procedures", BCP 13, RFC 4288, December 2005.
940
941   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
942              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
943              May 2008.
944
945
946
947
948
949
950
951Fielding, et al.        Expires January 17, 2013               [Page 17]
952
953Internet-Draft              HTTP/1.1, Part 5                   July 2012
954
955
956Appendix A.  Internet Media Type multipart/byteranges
957
958   When an HTTP 206 (Partial Content) response message includes the
959   content of multiple ranges (a response to a request for multiple non-
960   overlapping ranges), these are transmitted as a multipart message
961   body ([RFC2046], Section 5.1).  The media type for this purpose is
962   called "multipart/byteranges".  The following is to be registered
963   with IANA [RFC4288].
964
965   The multipart/byteranges media type includes one or more parts, each
966   with its own Content-Type and Content-Range fields.  The required
967   boundary parameter specifies the boundary string used to separate
968   each body-part.
969
970   Type name:  multipart
971
972   Subtype name:  byteranges
973
974   Required parameters:  boundary
975
976   Optional parameters:  none
977
978   Encoding considerations:  only "7bit", "8bit", or "binary" are
979      permitted
980
981   Security considerations:  none
982
983   Interoperability considerations:  none
984
985   Published specification:  This specification (see Appendix A).
986
987   Applications that use this media type:  HTTP components supporting
988      multiple ranges in a single request.
989
990   Additional information:
991
992      Magic number(s):  none
993
994      File extension(s):  none
995
996      Macintosh file type code(s):  none
997
998   Person and email address to contact for further information:  See
999      Authors Section.
1000
1001
1002
1003
1004
1005
1006
1007Fielding, et al.        Expires January 17, 2013               [Page 18]
1008
1009Internet-Draft              HTTP/1.1, Part 5                   July 2012
1010
1011
1012   Intended usage:  COMMON
1013
1014   Restrictions on usage:  none
1015
1016   Author/Change controller:  IESG
1017
1018      Note: Despite the name "multipart/byteranges" is not limited to
1019      the byte ranges only.
1020
1021   For example:
1022
1023     HTTP/1.1 206 Partial Content
1024     Date: Wed, 15 Nov 1995 06:25:24 GMT
1025     Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
1026     Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
1027
1028     --THIS_STRING_SEPARATES
1029     Content-type: application/pdf
1030     Content-range: bytes 500-999/8000
1031
1032     ...the first range...
1033     --THIS_STRING_SEPARATES
1034     Content-type: application/pdf
1035     Content-range: bytes 7000-7999/8000
1036
1037     ...the second range
1038     --THIS_STRING_SEPARATES--
1039
1040   Another example, using the "exampleunit" range unit:
1041
1042     HTTP/1.1 206 Partial Content
1043     Date: Tue, 14 Nov 1995 06:25:24 GMT
1044     Last-Modified: Tue, 14 July 04:58:08 GMT
1045     Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
1046
1047     --THIS_STRING_SEPARATES
1048     Content-type: video/example
1049     Content-range: exampleunit 1.2-4.3/25
1050
1051     ...the first range...
1052     --THIS_STRING_SEPARATES
1053     Content-type: video/example
1054     Content-range: exampleunit 11.2-14.3/25
1055
1056     ...the second range
1057     --THIS_STRING_SEPARATES--
1058
1059   Notes:
1060
1061
1062
1063Fielding, et al.        Expires January 17, 2013               [Page 19]
1064
1065Internet-Draft              HTTP/1.1, Part 5                   July 2012
1066
1067
1068   1.  Additional CRLFs MAY precede the first boundary string in the
1069       body.
1070
1071   2.  Although [RFC2046] permits the boundary string to be quoted, some
1072       existing implementations handle a quoted boundary string
1073       incorrectly.
1074
1075   3.  A number of clients and servers were coded to an early draft of
1076       the byteranges specification to use a media type of multipart/
1077       x-byteranges, which is almost, but not quite compatible with the
1078       version documented in HTTP/1.1.
1079
1080Appendix B.  Changes from RFC 2616
1081
1082   Introduce Range Specifier Registry.  (Section 2.1)
1083
1084   Clarify that it is not ok to use a weak validator in a 206 response.
1085   (Section 3.1)
1086
1087   Change ABNF productions for header fields to only define the field
1088   value.  (Section 5)
1089
1090   Clarify that multipart/byteranges can consist of a single part.
1091   (Appendix A)
1092
1093Appendix C.  Imported ABNF
1094
1095   The following core rules are included by reference, as defined in
1096   Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return),
1097   CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double
1098   quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any
1099   8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII
1100   character).
1101
1102   Note that all rules derived from token are to be compared case-
1103   insensitively, like range-unit and acceptable-ranges.
1104
1105   The rules below are defined in [Part1]:
1106
1107     OWS        = <OWS, defined in [Part1], Section 3.2.1>
1108     token      = <token, defined in [Part1], Section 3.2.4>
1109
1110   The rules below are defined in other parts:
1111
1112     HTTP-date  = <HTTP-date, defined in [Part2], Section 5.1>
1113     entity-tag = <entity-tag, defined in [Part4], Section 2.3>
1114
1115
1116
1117
1118
1119Fielding, et al.        Expires January 17, 2013               [Page 20]
1120
1121Internet-Draft              HTTP/1.1, Part 5                   July 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 5.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 January 17, 2013               [Page 21]
1176
1177Internet-Draft              HTTP/1.1, Part 5                   July 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
1205Index
1206
1207   2
1208      206 Partial Content (status code)  6
1209
1210   4
1211      416 Requested Range Not Satisfiable (status code)  7
1212
1213   A
1214      Accept-Ranges header field  9
1215
1216   C
1217      Content-Range header field  10
1218
1219   G
1220      Grammar
1221         Accept-Ranges  9
1222         acceptable-ranges  9
1223         byte-content-range-spec  10
1224         byte-range-resp-spec  10
1225         byte-range-set  12
1226         byte-range-spec  12
1227         byte-ranges-specifier  12
1228
1229
1230
1231Fielding, et al.        Expires January 17, 2013               [Page 22]
1232
1233Internet-Draft              HTTP/1.1, Part 5                   July 2012
1234
1235
1236         bytes-unit  5
1237         Content-Range  10
1238         first-byte-pos  12
1239         If-Range  11
1240         instance-length  10
1241         last-byte-pos  12
1242         other-range-unit  5
1243         Range  14
1244         range-unit  5
1245         ranges-specifier  12
1246         suffix-byte-range-spec  13
1247         suffix-length  13
1248
1249   H
1250      Header Fields
1251         Accept-Ranges  9
1252         Content-Range  10
1253         If-Range  11
1254         Range  12
1255
1256   I
1257      If-Range header field  11
1258
1259   M
1260      Media Type
1261         multipart/byteranges  18
1262         multipart/x-byteranges  20
1263      multipart/byteranges Media Type  18
1264      multipart/x-byteranges Media Type  20
1265
1266   R
1267      Range header field  12
1268
1269   S
1270      Status Codes
1271         206 Partial Content  6
1272         416 Requested Range Not Satisfiable  7
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287Fielding, et al.        Expires January 17, 2013               [Page 23]
1288
1289Internet-Draft              HTTP/1.1, Part 5                   July 2012
1290
1291
1292Authors' Addresses
1293
1294   Roy T. Fielding (editor)
1295   Adobe Systems Incorporated
1296   345 Park Ave
1297   San Jose, CA  95110
1298   USA
1299
1300   EMail: fielding@gbiv.com
1301   URI:   http://roy.gbiv.com/
1302
1303
1304   Yves Lafon (editor)
1305   World Wide Web Consortium
1306   W3C / ERCIM
1307   2004, rte des Lucioles
1308   Sophia-Antipolis, AM  06902
1309   France
1310
1311   EMail: ylafon@w3.org
1312   URI:   http://www.raubacapeu.net/people/yves/
1313
1314
1315   Julian F. Reschke (editor)
1316   greenbytes GmbH
1317   Hafenweg 16
1318   Muenster, NW  48155
1319   Germany
1320
1321   EMail: julian.reschke@greenbytes.de
1322   URI:   http://greenbytes.de/tech/webdav/
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343Fielding, et al.        Expires January 17, 2013               [Page 24]
1344
Note: See TracBrowser for help on using the repository browser.