source: draft-ietf-httpbis/01/draft-ietf-httpbis-p5-range-01.txt @ 166

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

generated draft 01

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