source: draft-ietf-httpbis/05/draft-ietf-httpbis-p5-range-05.txt @ 559

Last change on this file since 559 was 559, checked in by fielding@…, 11 years ago

remove executable and set eol-style for earlier drafts

  • Property svn:eol-style set to native
File size: 42.0 KB
Line 
1
2
3
4Network Working Group                                   R. Fielding, Ed.
5Internet-Draft                                              Day Software
6Obsoletes: 2616 (if approved)                                  J. Gettys
7Intended status: Standards Track                    One Laptop per Child
8Expires: May 20, 2009                                           J. Mogul
9                                                                      HP
10                                                              H. Frystyk
11                                                               Microsoft
12                                                             L. Masinter
13                                                           Adobe Systems
14                                                                P. Leach
15                                                               Microsoft
16                                                          T. Berners-Lee
17                                                                 W3C/MIT
18                                                           Y. Lafon, Ed.
19                                                                     W3C
20                                                         J. Reschke, Ed.
21                                                              greenbytes
22                                                       November 16, 2008
23
24
25         HTTP/1.1, part 5: Range Requests and Partial Responses
26                     draft-ietf-httpbis-p5-range-05
27
28Status of this Memo
29
30   By submitting this Internet-Draft, each author represents that any
31   applicable patent or other IPR claims of which he or she is aware
32   have been or will be disclosed, and any of which he or she becomes
33   aware will be disclosed, in accordance with Section 6 of BCP 79.
34
35   Internet-Drafts are working documents of the Internet Engineering
36   Task Force (IETF), its areas, and its working groups.  Note that
37   other groups may also distribute working documents as Internet-
38   Drafts.
39
40   Internet-Drafts are draft documents valid for a maximum of six months
41   and may be updated, replaced, or obsoleted by other documents at any
42   time.  It is inappropriate to use Internet-Drafts as reference
43   material or to cite them other than as "work in progress."
44
45   The list of current Internet-Drafts can be accessed at
46   http://www.ietf.org/ietf/1id-abstracts.txt.
47
48   The list of Internet-Draft Shadow Directories can be accessed at
49   http://www.ietf.org/shadow.html.
50
51   This Internet-Draft will expire on May 20, 2009.
52
53
54
55Fielding, et al.          Expires May 20, 2009                  [Page 1]
56
57Internet-Draft              HTTP/1.1, Part 5               November 2008
58
59
60Abstract
61
62   The Hypertext Transfer Protocol (HTTP) is an application-level
63   protocol for distributed, collaborative, hypermedia information
64   systems.  HTTP has been in use by the World Wide Web global
65   information initiative since 1990.  This document is Part 5 of the
66   seven-part specification that defines the protocol referred to as
67   "HTTP/1.1" and, taken together, obsoletes RFC 2616.  Part 5 defines
68   range-specific requests and the rules for constructing and combining
69   responses to those requests.
70
71Editorial Note (To be removed by RFC Editor)
72
73   Discussion of this draft should take place on the HTTPBIS working
74   group mailing list (ietf-http-wg@w3.org).  The current issues list is
75   at <http://tools.ietf.org/wg/httpbis/trac/report/11> and related
76   documents (including fancy diffs) can be found at
77   <http://tools.ietf.org/wg/httpbis/>.
78
79   The changes in this draft are summarized in Appendix C.6.
80
81
82
83
84
85
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 May 20, 2009                  [Page 2]
112
113Internet-Draft              HTTP/1.1, Part 5               November 2008
114
115
116Table of Contents
117
118   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
119     1.1.  Requirements . . . . . . . . . . . . . . . . . . . . . . .  4
120   2.  Notational Conventions and Generic Grammar . . . . . . . . . .  4
121   3.  Range Units  . . . . . . . . . . . . . . . . . . . . . . . . .  5
122   4.  Status Code Definitions  . . . . . . . . . . . . . . . . . . .  5
123     4.1.  206 Partial Content  . . . . . . . . . . . . . . . . . . .  5
124     4.2.  416 Requested Range Not Satisfiable  . . . . . . . . . . .  6
125   5.  Combining Byte Ranges  . . . . . . . . . . . . . . . . . . . .  6
126   6.  Header Field Definitions . . . . . . . . . . . . . . . . . . .  7
127     6.1.  Accept-Ranges  . . . . . . . . . . . . . . . . . . . . . .  7
128     6.2.  Content-Range  . . . . . . . . . . . . . . . . . . . . . .  8
129     6.3.  If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 10
130     6.4.  Range  . . . . . . . . . . . . . . . . . . . . . . . . . . 10
131       6.4.1.  Byte Ranges  . . . . . . . . . . . . . . . . . . . . . 11
132       6.4.2.  Range Retrieval Requests . . . . . . . . . . . . . . . 12
133   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
134     7.1.  Message Header Registration  . . . . . . . . . . . . . . . 13
135   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
136   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 14
137   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
138     10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
139     10.2. Informative References . . . . . . . . . . . . . . . . . . 15
140   Appendix A.  Internet Media Type multipart/byteranges  . . . . . . 15
141   Appendix B.  Compatibility with Previous Versions  . . . . . . . . 17
142     B.1.  Changes from RFC 2068  . . . . . . . . . . . . . . . . . . 17
143     B.2.  Changes from RFC 2616  . . . . . . . . . . . . . . . . . . 17
144   Appendix C.  Change Log (to be removed by RFC Editor before
145                publication)  . . . . . . . . . . . . . . . . . . . . 17
146     C.1.  Since RFC2616  . . . . . . . . . . . . . . . . . . . . . . 17
147     C.2.  Since draft-ietf-httpbis-p5-range-00 . . . . . . . . . . . 18
148     C.3.  Since draft-ietf-httpbis-p5-range-01 . . . . . . . . . . . 18
149     C.4.  Since draft-ietf-httpbis-p5-range-02 . . . . . . . . . . . 18
150     C.5.  Since draft-ietf-httpbis-p5-range-03 . . . . . . . . . . . 18
151     C.6.  Since draft-ietf-httpbis-p5-range-04 . . . . . . . . . . . 18
152   Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
153   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
154   Intellectual Property and Copyright Statements . . . . . . . . . . 23
155
156
157
158
159
160
161
162
163
164
165
166
167Fielding, et al.          Expires May 20, 2009                  [Page 3]
168
169Internet-Draft              HTTP/1.1, Part 5               November 2008
170
171
1721.  Introduction
173
174   HTTP clients often encounter interrupted data transfers as a result
175   of cancelled requests or dropped connections.  When a cache 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.  Requirements
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   An implementation is not compliant if it fails to satisfy one or more
204   of the MUST or REQUIRED level requirements for the protocols it
205   implements.  An implementation that satisfies all the MUST or
206   REQUIRED level and all the SHOULD level requirements for its
207   protocols is said to be "unconditionally compliant"; one that
208   satisfies all the MUST level requirements but not all the SHOULD
209   level requirements for its protocols is said to be "conditionally
210   compliant."
211
212
2132.  Notational Conventions and Generic Grammar
214
215   This specification uses the ABNF syntax defined in Section 2.1 of
216   [Part1] and the core rules defined in Section 2.2 of [Part1]:
217
218     DIGIT      = <DIGIT, defined in [Part1], Section 2.2>
219     SP         = <SP, defined in [Part1], Section 2.2>
220
221
222
223Fielding, et al.          Expires May 20, 2009                  [Page 4]
224
225Internet-Draft              HTTP/1.1, Part 5               November 2008
226
227
228     token      = <token, defined in [Part1], Section 2.2>
229     OWS        = <OWS, defined in [Part1], Section 2.2>
230
231   The ABNF rules below are defined in other parts:
232
233     HTTP-date  = <HTTP-date, defined in [Part1], Section 3.3.1>
234
235
236     entity-tag = <entity-tag, defined in [Part4], Section 3>
237
238
2393.  Range Units
240
241   HTTP/1.1 allows a client to request that only part (a range of) the
242   response entity be included within the response.  HTTP/1.1 uses range
243   units in the Range (Section 6.4) and Content-Range (Section 6.2)
244   header fields.  An entity can be broken down into subranges according
245   to various structural units.
246
247     range-unit       = bytes-unit / other-range-unit
248     bytes-unit       = "bytes"
249     other-range-unit = token
250
251   The only range unit defined by HTTP/1.1 is "bytes".  HTTP/1.1
252   implementations MAY ignore ranges specified using other units.
253
254   HTTP/1.1 has been designed to allow implementations of applications
255   that do not depend on knowledge of ranges.
256
257
2584.  Status Code Definitions
259
2604.1.  206 Partial Content
261
262   The server has fulfilled the partial GET request for the resource.
263   The request MUST have included a Range header field (Section 6.4)
264   indicating the desired range, and MAY have included an If-Range
265   header field (Section 6.3) to make the request conditional.
266
267   The response MUST include the following header fields:
268
269   o  Either a Content-Range header field (Section 6.2) indicating the
270      range included with this response, or a multipart/byteranges
271      Content-Type including Content-Range fields for each part.  If a
272      Content-Length header field is present in the response, its value
273      MUST match the actual number of OCTETs transmitted in the message-
274      body.
275
276
277
278
279Fielding, et al.          Expires May 20, 2009                  [Page 5]
280
281Internet-Draft              HTTP/1.1, Part 5               November 2008
282
283
284   o  Date
285
286   o  ETag and/or Content-Location, if the header would have been sent
287      in a 200 response to the same request
288
289   o  Expires, Cache-Control, and/or Vary, if the field-value might
290      differ from that sent in any previous response for the same
291      variant
292
293   If the 206 response is the result of an If-Range request, the
294   response SHOULD NOT include other entity-headers.  Otherwise, the
295   response MUST include all of the entity-headers that would have been
296   returned with a 200 (OK) response to the same request.
297
298   A cache MUST NOT combine a 206 response with other previously cached
299   content if the ETag or Last-Modified headers do not match exactly,
300   see Section 5.
301
302   A cache that does not support the Range and Content-Range headers
303   MUST NOT cache 206 (Partial Content) responses.
304
3054.2.  416 Requested Range Not Satisfiable
306
307   A server SHOULD return a response with this status code if a request
308   included a Range request-header field (Section 6.4), and none of the
309   ranges-specifier values in this field overlap the current extent of
310   the selected resource, and the request did not include an If-Range
311   request-header field.  (For byte-ranges, this means that the first-
312   byte-pos of all of the byte-range-spec values were greater than the
313   current length of the selected resource.)
314
315   When this status code is returned for a byte-range request, the
316   response SHOULD include a Content-Range entity-header field
317   specifying the current length of the selected resource (see
318   Section 6.2).  This response MUST NOT use the multipart/byteranges
319   content-type.
320
321
3225.  Combining Byte Ranges
323
324   A response might transfer only a subrange of the bytes of an entity-
325   body, either because the request included one or more Range
326   specifications, or because a connection was broken prematurely.
327   After several such transfers, a cache might have received several
328   ranges of the same entity-body.
329
330   If a cache has a stored non-empty set of subranges for an entity, and
331   an incoming response transfers another subrange, the cache MAY
332
333
334
335Fielding, et al.          Expires May 20, 2009                  [Page 6]
336
337Internet-Draft              HTTP/1.1, Part 5               November 2008
338
339
340   combine the new subrange with the existing set if both the following
341   conditions are met:
342
343   o  Both the incoming response and the cache entry have a cache
344      validator.
345
346   o  The two cache validators match using the strong comparison
347      function (see Section 5 of [Part4]).
348
349   If either requirement is not met, the cache MUST use only the most
350   recent partial response (based on the Date values transmitted with
351   every response, and using the incoming response if these values are
352   equal or missing), and MUST discard the other partial information.
353
354
3556.  Header Field Definitions
356
357   This section defines the syntax and semantics of HTTP/1.1 header
358   fields related to range requests and partial responses.
359
360   For entity-header fields, both sender and recipient refer to either
361   the client or the server, depending on who sends and who receives the
362   entity.
363
3646.1.  Accept-Ranges
365
366   The response-header "Accept-Ranges" field allows the server to
367   indicate its acceptance of range requests for a resource:
368
369     Accept-Ranges     = "Accept-Ranges" ":" OWS Accept-Ranges-v
370     Accept-Ranges-v   = acceptable-ranges
371     acceptable-ranges = 1#range-unit / "none"
372
373   Origin servers that accept byte-range requests MAY send
374
375     Accept-Ranges: bytes
376
377   but are not required to do so.  Clients MAY generate byte-range
378   requests without having received this header for the resource
379   involved.  Range units are defined in Section 3.
380
381   Servers that do not accept any kind of range request for a resource
382   MAY send
383
384     Accept-Ranges: none
385
386   to advise the client not to attempt a range request.
387
388
389
390
391Fielding, et al.          Expires May 20, 2009                  [Page 7]
392
393Internet-Draft              HTTP/1.1, Part 5               November 2008
394
395
3966.2.  Content-Range
397
398   The entity-header "Content-Range" is sent with a partial entity-body
399   to specify where in the full entity-body the partial body should be
400   applied.  Range units are defined in Section 3.
401
402     Content-Range = "Content-Range" ":" OWS Content-Range-v
403     Content-Range-v = content-range-spec
404
405     content-range-spec      = byte-content-range-spec
406     byte-content-range-spec = bytes-unit SP
407                               byte-range-resp-spec "/"
408                               ( instance-length / "*" )
409
410     byte-range-resp-spec    = (first-byte-pos "-" last-byte-pos)
411                             / "*"
412
413     instance-length         = 1*DIGIT
414
415   The header SHOULD indicate the total length of the full entity-body,
416   unless this length is unknown or difficult to determine.  The
417   asterisk "*" character means that the instance-length is unknown at
418   the time when the response was generated.
419
420   Unlike byte-ranges-specifier values (see Section 6.4.1), a byte-
421   range-resp-spec MUST only specify one range, and MUST contain
422   absolute byte positions for both the first and last byte of the
423   range.
424
425   A byte-content-range-spec with a byte-range-resp-spec whose last-
426   byte-pos value is less than its first-byte-pos value, or whose
427   instance-length value is less than or equal to its last-byte-pos
428   value, is invalid.  The recipient of an invalid byte-content-range-
429   spec MUST ignore it and any content transferred along with it.
430
431   A server sending a response with status code 416 (Requested range not
432   satisfiable) SHOULD include a Content-Range field with a byte-range-
433   resp-spec of "*".  The instance-length specifies the current length
434   of the selected resource.  A response with status code 206 (Partial
435   Content) MUST NOT include a Content-Range field with a byte-range-
436   resp-spec of "*".
437
438   Examples of byte-content-range-spec values, assuming that the entity
439   contains a total of 1234 bytes:
440
441   o  The first 500 bytes:
442
443      bytes 0-499/1234
444
445
446
447Fielding, et al.          Expires May 20, 2009                  [Page 8]
448
449Internet-Draft              HTTP/1.1, Part 5               November 2008
450
451
452   o  The second 500 bytes:
453
454      bytes 500-999/1234
455
456   o  All except for the first 500 bytes:
457
458      bytes 500-1233/1234
459
460   o  The last 500 bytes:
461
462      bytes 734-1233/1234
463
464   When an HTTP message includes the content of a single range (for
465   example, a response to a request for a single range, or to a request
466   for a set of ranges that overlap without any holes), this content is
467   transmitted with a Content-Range header, and a Content-Length header
468   showing the number of bytes actually transferred.  For example,
469
470     HTTP/1.1 206 Partial Content
471     Date: Wed, 15 Nov 1995 06:25:24 GMT
472     Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
473     Content-Range: bytes 21010-47021/47022
474     Content-Length: 26012
475     Content-Type: image/gif
476
477   When an HTTP message includes the content of multiple ranges (for
478   example, a response to a request for multiple non-overlapping
479   ranges), these are transmitted as a multipart message.  The multipart
480   media type used for this purpose is "multipart/byteranges" as defined
481   in Appendix A.  See Appendix B.1 for a compatibility issue.
482
483   A response to a request for a single range MUST NOT be sent using the
484   multipart/byteranges media type.  A response to a request for
485   multiple ranges, whose result is a single range, MAY be sent as a
486   multipart/byteranges media type with one part.  A client that cannot
487   decode a multipart/byteranges message MUST NOT ask for multiple byte-
488   ranges in a single request.
489
490   When a client requests multiple byte-ranges in one request, the
491   server SHOULD return them in the order that they appeared in the
492   request.
493
494   If the server ignores a byte-range-spec because it is syntactically
495   invalid, the server SHOULD treat the request as if the invalid Range
496   header field did not exist.  (Normally, this means return a 200
497   response containing the full entity).
498
499   If the server receives a request (other than one including an If-
500
501
502
503Fielding, et al.          Expires May 20, 2009                  [Page 9]
504
505Internet-Draft              HTTP/1.1, Part 5               November 2008
506
507
508   Range request-header field) with an unsatisfiable Range request-
509   header field (that is, all of whose byte-range-spec values have a
510   first-byte-pos value greater than the current length of the selected
511   resource), it SHOULD return a response code of 416 (Requested range
512   not satisfiable) (Section 4.2).
513
514      Note: clients cannot depend on servers to send a 416 (Requested
515      range not satisfiable) response instead of a 200 (OK) response for
516      an unsatisfiable Range request-header, since not all servers
517      implement this request-header.
518
5196.3.  If-Range
520
521   If a client has a partial copy of an entity in its cache, and wishes
522   to have an up-to-date copy of the entire entity in its cache, it
523   could use the Range request-header with a conditional GET (using
524   either or both of If-Unmodified-Since and If-Match.)  However, if the
525   condition fails because the entity has been modified, the client
526   would then have to make a second request to obtain the entire current
527   entity-body.
528
529   The request header "If-Range" allows a client to "short-circuit" the
530   second request.  Informally, its meaning is `if the entity is
531   unchanged, send me the part(s) that I am missing; otherwise, send me
532   the entire new entity'.
533
534     If-Range   = "If-Range" ":" OWS If-Range-v
535     If-Range-v = entity-tag / HTTP-date
536
537   If the client has no entity tag for an entity, but does have a Last-
538   Modified date, it MAY use that date in an If-Range header.  (The
539   server can distinguish between a valid HTTP-date and any form of
540   entity-tag by examining no more than two characters.)  The If-Range
541   header SHOULD only be used together with a Range header, and MUST be
542   ignored if the request does not include a Range header, or if the
543   server does not support the sub-range operation.
544
545   If the entity tag given in the If-Range header matches the current
546   entity tag for the entity, then the server SHOULD provide the
547   specified sub-range of the entity using a 206 (Partial Content)
548   response.  If the entity tag does not match, then the server SHOULD
549   return the entire entity using a 200 (OK) response.
550
5516.4.  Range
552
553
554
555
556
557
558
559Fielding, et al.          Expires May 20, 2009                 [Page 10]
560
561Internet-Draft              HTTP/1.1, Part 5               November 2008
562
563
5646.4.1.  Byte Ranges
565
566   Since all HTTP entities are represented in HTTP messages as sequences
567   of bytes, the concept of a byte range is meaningful for any HTTP
568   entity.  (However, not all clients and servers need to support byte-
569   range operations.)
570
571   Byte range specifications in HTTP apply to the sequence of bytes in
572   the entity-body (not necessarily the same as the message-body).
573
574   A byte range operation MAY specify a single range of bytes, or a set
575   of ranges within a single entity.
576
577     ranges-specifier = byte-ranges-specifier
578     byte-ranges-specifier = bytes-unit "=" byte-range-set
579     byte-range-set  = 1#( byte-range-spec / suffix-byte-range-spec )
580     byte-range-spec = first-byte-pos "-" [last-byte-pos]
581     first-byte-pos  = 1*DIGIT
582     last-byte-pos   = 1*DIGIT
583
584   The first-byte-pos value in a byte-range-spec gives the byte-offset
585   of the first byte in a range.  The last-byte-pos value gives the
586   byte-offset of the last byte in the range; that is, the byte
587   positions specified are inclusive.  Byte offsets start at zero.
588
589   If the last-byte-pos value is present, it MUST be greater than or
590   equal to the first-byte-pos in that byte-range-spec, or the byte-
591   range-spec is syntactically invalid.  The recipient of a byte-range-
592   set that includes one or more syntactically invalid byte-range-spec
593   values MUST ignore the header field that includes that byte-range-
594   set.
595
596   If the last-byte-pos value is absent, or if the value is greater than
597   or equal to the current length of the entity-body, last-byte-pos is
598   taken to be equal to one less than the current length of the entity-
599   body in bytes.
600
601   By its choice of last-byte-pos, a client can limit the number of
602   bytes retrieved without knowing the size of the entity.
603
604     suffix-byte-range-spec = "-" suffix-length
605     suffix-length = 1*DIGIT
606
607   A suffix-byte-range-spec is used to specify the suffix of the entity-
608   body, of a length given by the suffix-length value.  (That is, this
609   form specifies the last N bytes of an entity-body.)  If the entity is
610   shorter than the specified suffix-length, the entire entity-body is
611   used.
612
613
614
615Fielding, et al.          Expires May 20, 2009                 [Page 11]
616
617Internet-Draft              HTTP/1.1, Part 5               November 2008
618
619
620   If a syntactically valid byte-range-set includes at least one byte-
621   range-spec whose first-byte-pos is less than the current length of
622   the entity-body, or at least one suffix-byte-range-spec with a non-
623   zero suffix-length, then the byte-range-set is satisfiable.
624   Otherwise, the byte-range-set is unsatisfiable.  If the byte-range-
625   set is unsatisfiable, the server SHOULD return a response with a
626   status of 416 (Requested range not satisfiable).  Otherwise, the
627   server SHOULD return a response with a status of 206 (Partial
628   Content) containing the satisfiable ranges of the entity-body.
629
630   Examples of byte-ranges-specifier values (assuming an entity-body of
631   length 10000):
632
633   o  The first 500 bytes (byte offsets 0-499, inclusive): bytes=0-499
634
635   o  The second 500 bytes (byte offsets 500-999, inclusive): bytes=500-
636      999
637
638   o  The final 500 bytes (byte offsets 9500-9999, inclusive): bytes=-
639      500
640
641   o  Or bytes=9500-
642
643   o  The first and last bytes only (bytes 0 and 9999): bytes=0-0,-1
644
645   o  Several legal but not canonical specifications of the second 500
646      bytes (byte offsets 500-999, inclusive):
647      bytes=500-600,601-999
648      bytes=500-700,601-999
649
6506.4.2.  Range Retrieval Requests
651
652   HTTP retrieval requests using conditional or unconditional GET
653   methods MAY request one or more sub-ranges of the entity, instead of
654   the entire entity, using the Range request header, which applies to
655   the entity returned as the result of the request:
656
657     Range   = "Range" ":" OWS Range-v
658     Range-v = ranges-specifier
659
660   A server MAY ignore the Range header.  However, HTTP/1.1 origin
661   servers and intermediate caches ought to support byte ranges when
662   possible, since Range supports efficient recovery from partially
663   failed transfers, and supports efficient partial retrieval of large
664   entities.
665
666   If the server supports the Range header and the specified range or
667   ranges are appropriate for the entity:
668
669
670
671Fielding, et al.          Expires May 20, 2009                 [Page 12]
672
673Internet-Draft              HTTP/1.1, Part 5               November 2008
674
675
676   o  The presence of a Range header in an unconditional GET modifies
677      what is returned if the GET is otherwise successful.  In other
678      words, the response carries a status code of 206 (Partial Content)
679      instead of 200 (OK).
680
681   o  The presence of a Range header in a conditional GET (a request
682      using one or both of If-Modified-Since and If-None-Match, or one
683      or both of If-Unmodified-Since and If-Match) modifies what is
684      returned if the GET is otherwise successful and the condition is
685      true.  It does not affect the 304 (Not Modified) response returned
686      if the conditional is false.
687
688   In some cases, it might be more appropriate to use the If-Range
689   header (see Section 6.3) in addition to the Range header.
690
691   If a proxy that supports ranges receives a Range request, forwards
692   the request to an inbound server, and receives an entire entity in
693   reply, it SHOULD only return the requested range to its client.  It
694   SHOULD store the entire received response in its cache if that is
695   consistent with its cache allocation policies.
696
697
6987.  IANA Considerations
699
7007.1.  Message Header Registration
701
702   The Message Header Registry located at <http://www.iana.org/
703   assignments/message-headers/message-header-index.html> should be
704   updated with the permanent registrations below (see [RFC3864]):
705
706   +-------------------+----------+----------+-------------+
707   | Header Field Name | Protocol | Status   | Reference   |
708   +-------------------+----------+----------+-------------+
709   | Accept-Ranges     | http     | standard | Section 6.1 |
710   | Content-Range     | http     | standard | Section 6.2 |
711   | If-Range          | http     | standard | Section 6.3 |
712   | Range             | http     | standard | Section 6.4 |
713   +-------------------+----------+----------+-------------+
714
715   The change controller is: "IETF (iesg@ietf.org) - Internet
716   Engineering Task Force".
717
718
7198.  Security Considerations
720
721   No additional security considerations have been identified beyond
722   those applicable to HTTP in general [Part1].
723
724
725
726
727Fielding, et al.          Expires May 20, 2009                 [Page 13]
728
729Internet-Draft              HTTP/1.1, Part 5               November 2008
730
731
7329.  Acknowledgments
733
734   Most of the specification of ranges is based on work originally done
735   by Ari Luotonen and John Franks, with additional input from Steve
736   Zilles, Daniel W. Connolly, Roy T. Fielding, Jim Gettys, Martin
737   Hamilton, Koen Holtman, Shel Kaplan, Paul Leach, Alex Lopez-Ortiz,
738   Larry Masinter, Jeff Mogul, Lou Montulli, David W. Morris, Luigi
739   Rizzo, and Bill Weihl.
740
741
74210.  References
743
74410.1.  Normative References
745
746   [Part1]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
747              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
748              and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
749              and Message Parsing", draft-ietf-httpbis-p1-messaging-05
750              (work in progress), November 2008.
751
752   [Part3]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
753              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
754              and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload
755              and Content Negotiation", draft-ietf-httpbis-p3-payload-05
756              (work in progress), November 2008.
757
758   [Part4]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
759              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
760              and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional
761              Requests", draft-ietf-httpbis-p4-conditional-05 (work in
762              progress), November 2008.
763
764   [Part6]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
765              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
766              and J. Reschke, Ed., "HTTP/1.1, part 6: Caching",
767              draft-ietf-httpbis-p6-cache-05 (work in progress),
768              November 2008.
769
770   [RFC2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
771              Extensions (MIME) Part Two: Media Types", RFC 2046,
772              November 1996.
773
774   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
775              Requirement Levels", BCP 14, RFC 2119, March 1997.
776
777
778
779
780
781
782
783Fielding, et al.          Expires May 20, 2009                 [Page 14]
784
785Internet-Draft              HTTP/1.1, Part 5               November 2008
786
787
78810.2.  Informative References
789
790   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
791              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
792              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
793
794   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
795              Procedures for Message Header Fields", BCP 90, RFC 3864,
796              September 2004.
797
798   [RFC4288]  Freed, N. and J. Klensin, "Media Type Specifications and
799              Registration Procedures", BCP 13, RFC 4288, December 2005.
800
801
802Appendix A.  Internet Media Type multipart/byteranges
803
804   When an HTTP 206 (Partial Content) response message includes the
805   content of multiple ranges (a response to a request for multiple non-
806   overlapping ranges), these are transmitted as a multipart message-
807   body ([RFC2046], Section 5.1).  The media type for this purpose is
808   called "multipart/byteranges".  The following is to be registered
809   with IANA [RFC4288].
810
811   The multipart/byteranges media type includes one or more parts, each
812   with its own Content-Type and Content-Range fields.  The required
813   boundary parameter specifies the boundary string used to separate
814   each body-part.
815
816   Type name:  multipart
817
818   Subtype name:  byteranges
819
820   Required parameters:  boundary
821
822   Optional parameters:  none
823
824   Encoding considerations:  only "7bit", "8bit", or "binary" are
825      permitted
826
827   Security considerations:  none
828
829   Interoperability considerations:  none
830
831   Published specification:  This specification (see Appendix A).
832
833
834
835
836
837
838
839Fielding, et al.          Expires May 20, 2009                 [Page 15]
840
841Internet-Draft              HTTP/1.1, Part 5               November 2008
842
843
844   Applications that use this media type:
845
846   Additional information:
847
848      Magic number(s):  none
849
850      File extension(s):  none
851
852      Macintosh file type code(s):  none
853
854   Person and email address to contact for further information:  See
855      Authors Section.
856
857   Intended usage:  COMMON
858
859   Restrictions on usage:  none
860
861   Author/Change controller:  IESG
862
863   For example:
864
865      HTTP/1.1 206 Partial Content
866      Date: Wed, 15 Nov 1995 06:25:24 GMT
867      Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
868      Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
869
870      --THIS_STRING_SEPARATES
871      Content-type: application/pdf
872      Content-range: bytes 500-999/8000
873
874      ...the first range...
875      --THIS_STRING_SEPARATES
876      Content-type: application/pdf
877      Content-range: bytes 7000-7999/8000
878
879      ...the second range
880      --THIS_STRING_SEPARATES--
881
882   Notes:
883
884   1.  Additional CRLFs may precede the first boundary string in the
885       entity.
886
887   2.  Although [RFC2046] permits the boundary string to be quoted, some
888       existing implementations handle a quoted boundary string
889       incorrectly.
890
891
892
893
894
895Fielding, et al.          Expires May 20, 2009                 [Page 16]
896
897Internet-Draft              HTTP/1.1, Part 5               November 2008
898
899
900   3.  A number of browsers and servers were coded to an early draft of
901       the byteranges specification to use a media type of multipart/
902       x-byteranges, which is almost, but not quite compatible with the
903       version documented in HTTP/1.1.
904
905
906Appendix B.  Compatibility with Previous Versions
907
908B.1.  Changes from RFC 2068
909
910   Transfer-coding and message lengths all interact in ways that
911   required fixing exactly when chunked encoding is used (to allow for
912   transfer encoding that may not be self delimiting); it was important
913   to straighten out exactly how message lengths are computed.
914   (Section 6.2, see also [Part1], [Part3] and [Part6])
915
916   There are situations where a server (especially a proxy) does not
917   know the full length of a response but is capable of serving a
918   byterange request.  We therefore need a mechanism to allow byteranges
919   with a content-range not indicating the full length of the message.
920   (Section 6.2)
921
922   Range request responses would become very verbose if all meta-data
923   were always returned; by allowing the server to only send needed
924   headers in a 206 response, this problem can be avoided.  (Section 4.1
925   and 6.3)
926
927   Fix problem with unsatisfiable range requests; there are two cases:
928   syntactic problems, and range doesn't exist in the document.  The 416
929   status code was needed to resolve this ambiguity needed to indicate
930   an error for a byte range request that falls outside of the actual
931   contents of a document.  (Section 4.2, 6.2)
932
933B.2.  Changes from RFC 2616
934
935   Clarify that it is not ok to use a weak cache validator in a 206
936   response.  (Section 4.1)
937
938   Clarify that multipart/byteranges can consist of a single part.
939   (Appendix A)
940
941
942Appendix C.  Change Log (to be removed by RFC Editor before publication)
943
944C.1.  Since RFC2616
945
946   Extracted relevant partitions from [RFC2616].
947
948
949
950
951Fielding, et al.          Expires May 20, 2009                 [Page 17]
952
953Internet-Draft              HTTP/1.1, Part 5               November 2008
954
955
956C.2.  Since draft-ietf-httpbis-p5-range-00
957
958   Closed issues:
959
960   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/18>: "Cache
961      validators in 206 responses"
962      (<http://purl.org/NET/http-errata#ifrange206>)
963
964   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and
965      Informative references"
966
967   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/86>: "Normative up-
968      to-date references"
969
970C.3.  Since draft-ietf-httpbis-p5-range-01
971
972   Closed issues:
973
974   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/55>: "Updating to
975      RFC4288"
976
977   Ongoing work on ABNF conversion
978   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
979
980   o  Add explicit references to BNF syntax and rules imported from
981      other parts of the specification.
982
983C.4.  Since draft-ietf-httpbis-p5-range-02
984
985   Ongoing work on IANA Message Header Registration
986   (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>):
987
988   o  Reference RFC 3984, and update header registrations for headers
989      defined in this document.
990
991C.5.  Since draft-ietf-httpbis-p5-range-03
992
993C.6.  Since draft-ietf-httpbis-p5-range-04
994
995   Closed issues:
996
997   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/133>: "multipart/
998      byteranges minimum number of parts"
999
1000   Ongoing work on ABNF conversion
1001   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
1002
1003
1004
1005
1006
1007Fielding, et al.          Expires May 20, 2009                 [Page 18]
1008
1009Internet-Draft              HTTP/1.1, Part 5               November 2008
1010
1011
1012   o  Use "/" instead of "|" for alternatives.
1013
1014   o  Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
1015      whitespace ("OWS") and required whitespace ("RWS").
1016
1017   o  Rewrite ABNFs to spell out whitespace rules, factor out header
1018      value format definitions.
1019
1020
1021Index
1022
1023   2
1024      206 Partial Content (status code)  5
1025
1026   4
1027      416 Requested Range Not Satisfiable (status code)  6
1028
1029   A
1030      Accept-Ranges header  7
1031
1032   C
1033      Content-Range header  8
1034
1035   G
1036      Grammar
1037         Accept-Ranges  7
1038         Accept-Ranges-v  7
1039         acceptable-ranges  7
1040         byte-content-range-spec  8
1041         byte-range-resp-spec  8
1042         byte-range-set  11
1043         byte-range-spec  11
1044         byte-ranges-specifier  11
1045         bytes-unit  5
1046         Content-Range  8
1047         content-range-spec  8
1048         Content-Range-v  8
1049         first-byte-pos  11
1050         If-Range  10
1051         If-Range-v  10
1052         instance-length  8
1053         last-byte-pos  11
1054         other-range-unit  5
1055         Range  12
1056         range-unit  5
1057         Range-v  12
1058         ranges-specifier  11
1059         suffix-byte-range-spec  11
1060
1061
1062
1063Fielding, et al.          Expires May 20, 2009                 [Page 19]
1064
1065Internet-Draft              HTTP/1.1, Part 5               November 2008
1066
1067
1068         suffix-length  11
1069
1070   H
1071      Headers
1072         Accept-Ranges  7
1073         Content-Range  8
1074         If-Range  10
1075         Range  10
1076
1077   I
1078      If-Range header  10
1079
1080   M
1081      Media Type
1082         multipart/byteranges  15
1083         multipart/x-byteranges  17
1084      multipart/byteranges Media Type  15
1085      multipart/x-byteranges Media Type  17
1086
1087   R
1088      Range header  10
1089
1090   S
1091      Status Codes
1092         206 Partial Content  5
1093         416 Requested Range Not Satisfiable  6
1094
1095
1096Authors' Addresses
1097
1098   Roy T. Fielding (editor)
1099   Day Software
1100   23 Corporate Plaza DR, Suite 280
1101   Newport Beach, CA  92660
1102   USA
1103
1104   Phone: +1-949-706-5300
1105   Fax:   +1-949-706-5305
1106   Email: fielding@gbiv.com
1107   URI:   http://roy.gbiv.com/
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119Fielding, et al.          Expires May 20, 2009                 [Page 20]
1120
1121Internet-Draft              HTTP/1.1, Part 5               November 2008
1122
1123
1124   Jim Gettys
1125   One Laptop per Child
1126   21 Oak Knoll Road
1127   Carlisle, MA  01741
1128   USA
1129
1130   Email: jg@laptop.org
1131   URI:   http://www.laptop.org/
1132
1133
1134   Jeffrey C. Mogul
1135   Hewlett-Packard Company
1136   HP Labs, Large Scale Systems Group
1137   1501 Page Mill Road, MS 1177
1138   Palo Alto, CA  94304
1139   USA
1140
1141   Email: JeffMogul@acm.org
1142
1143
1144   Henrik Frystyk Nielsen
1145   Microsoft Corporation
1146   1 Microsoft Way
1147   Redmond, WA  98052
1148   USA
1149
1150   Email: henrikn@microsoft.com
1151
1152
1153   Larry Masinter
1154   Adobe Systems, Incorporated
1155   345 Park Ave
1156   San Jose, CA  95110
1157   USA
1158
1159   Email: LMM@acm.org
1160   URI:   http://larry.masinter.net/
1161
1162
1163   Paul J. Leach
1164   Microsoft Corporation
1165   1 Microsoft Way
1166   Redmond, WA  98052
1167
1168   Email: paulle@microsoft.com
1169
1170
1171
1172
1173
1174
1175Fielding, et al.          Expires May 20, 2009                 [Page 21]
1176
1177Internet-Draft              HTTP/1.1, Part 5               November 2008
1178
1179
1180   Tim Berners-Lee
1181   World Wide Web Consortium
1182   MIT Computer Science and Artificial Intelligence Laboratory
1183   The Stata Center, Building 32
1184   32 Vassar Street
1185   Cambridge, MA  02139
1186   USA
1187
1188   Email: timbl@w3.org
1189   URI:   http://www.w3.org/People/Berners-Lee/
1190
1191
1192   Yves Lafon (editor)
1193   World Wide Web Consortium
1194   W3C / ERCIM
1195   2004, rte des Lucioles
1196   Sophia-Antipolis, AM  06902
1197   France
1198
1199   Email: ylafon@w3.org
1200   URI:   http://www.raubacapeu.net/people/yves/
1201
1202
1203   Julian F. Reschke (editor)
1204   greenbytes GmbH
1205   Hafenweg 16
1206   Muenster, NW  48155
1207   Germany
1208
1209   Phone: +49 251 2807760
1210   Fax:   +49 251 2807761
1211   Email: julian.reschke@greenbytes.de
1212   URI:   http://greenbytes.de/tech/webdav/
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231Fielding, et al.          Expires May 20, 2009                 [Page 22]
1232
1233Internet-Draft              HTTP/1.1, Part 5               November 2008
1234
1235
1236Full Copyright Statement
1237
1238   Copyright (C) The IETF Trust (2008).
1239
1240   This document is subject to the rights, licenses and restrictions
1241   contained in BCP 78, and except as set forth therein, the authors
1242   retain all their rights.
1243
1244   This document and the information contained herein are provided on an
1245   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1246   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
1247   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
1248   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
1249   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1250   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1251
1252
1253Intellectual Property
1254
1255   The IETF takes no position regarding the validity or scope of any
1256   Intellectual Property Rights or other rights that might be claimed to
1257   pertain to the implementation or use of the technology described in
1258   this document or the extent to which any license under such rights
1259   might or might not be available; nor does it represent that it has
1260   made any independent effort to identify any such rights.  Information
1261   on the procedures with respect to rights in RFC documents can be
1262   found in BCP 78 and BCP 79.
1263
1264   Copies of IPR disclosures made to the IETF Secretariat and any
1265   assurances of licenses to be made available, or the result of an
1266   attempt made to obtain a general license or permission for the use of
1267   such proprietary rights by implementers or users of this
1268   specification can be obtained from the IETF on-line IPR repository at
1269   http://www.ietf.org/ipr.
1270
1271   The IETF invites any interested party to bring to its attention any
1272   copyrights, patents or patent applications, or other proprietary
1273   rights that may cover technology that may be required to implement
1274   this standard.  Please address the information to the IETF at
1275   ietf-ipr@ietf.org.
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287Fielding, et al.          Expires May 20, 2009                 [Page 23]
1288
Note: See TracBrowser for help on using the repository browser.