source: draft-ietf-httpbis/16/draft-ietf-httpbis-p5-range-16.txt @ 1860

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

prepare for publication of -16 on Aug 24.

  • Property svn:eol-style set to native
  • Property svn:executable set to *
File size: 50.8 KB
Line 
1
2
3
4HTTPbis Working Group                                   R. Fielding, Ed.
5Internet-Draft                                                     Adobe
6Obsoletes: 2616 (if approved)                                  J. Gettys
7Intended status: Standards Track                          Alcatel-Lucent
8Expires: February 25, 2012                                      J. Mogul
9                                                                      HP
10                                                              H. Frystyk
11                                                               Microsoft
12                                                             L. Masinter
13                                                                   Adobe
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                                                         August 24, 2011
23
24
25         HTTP/1.1, part 5: Range Requests and Partial Responses
26                     draft-ietf-httpbis-p5-range-16
27
28Abstract
29
30   The Hypertext Transfer Protocol (HTTP) is an application-level
31   protocol for distributed, collaborative, hypertext information
32   systems.  HTTP has been in use by the World Wide Web global
33   information initiative since 1990.  This document is Part 5 of the
34   seven-part specification that defines the protocol referred to as
35   "HTTP/1.1" and, taken together, obsoletes RFC 2616.
36
37   Part 5 defines range-specific requests and the rules for constructing
38   and combining responses to those requests.
39
40Editorial Note (To be removed by RFC Editor)
41
42   Discussion of this draft should take place on the HTTPBIS working
43   group mailing list (ietf-http-wg@w3.org), which is archived at
44   <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
45
46   The current issues list is at
47   <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
48   documents (including fancy diffs) can be found at
49   <http://tools.ietf.org/wg/httpbis/>.
50
51   The changes in this draft are summarized in Appendix D.17.
52
53
54
55Fielding, et al.        Expires February 25, 2012               [Page 1]
56
57Internet-Draft              HTTP/1.1, Part 5                 August 2011
58
59
60Status of This Memo
61
62   This Internet-Draft is submitted in full conformance with the
63   provisions of BCP 78 and BCP 79.
64
65   Internet-Drafts are working documents of the Internet Engineering
66   Task Force (IETF).  Note that other groups may also distribute
67   working documents as Internet-Drafts.  The list of current Internet-
68   Drafts is at http://datatracker.ietf.org/drafts/current/.
69
70   Internet-Drafts are draft documents valid for a maximum of six months
71   and may be updated, replaced, or obsoleted by other documents at any
72   time.  It is inappropriate to use Internet-Drafts as reference
73   material or to cite them other than as "work in progress."
74
75   This Internet-Draft will expire on February 25, 2012.
76
77Copyright Notice
78
79   Copyright (c) 2011 IETF Trust and the persons identified as the
80   document authors.  All rights reserved.
81
82   This document is subject to BCP 78 and the IETF Trust's Legal
83   Provisions Relating to IETF Documents
84   (http://trustee.ietf.org/license-info) in effect on the date of
85   publication of this document.  Please review these documents
86   carefully, as they describe your rights and restrictions with respect
87   to this document.  Code Components extracted from this document must
88   include Simplified BSD License text as described in Section 4.e of
89   the Trust Legal Provisions and are provided without warranty as
90   described in the Simplified BSD License.
91
92   This document may contain material from IETF Documents or IETF
93   Contributions published or made publicly available before November
94   10, 2008.  The person(s) controlling the copyright in some of this
95   material may not have granted the IETF Trust the right to allow
96   modifications of such material outside the IETF Standards Process.
97   Without obtaining an adequate license from the person(s) controlling
98   the copyright in such materials, this document may not be modified
99   outside the IETF Standards Process, and derivative works of it may
100   not be created outside the IETF Standards Process, except to format
101   it for publication as an RFC or to translate it into languages other
102   than English.
103
104Table of Contents
105
106   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
107     1.1.  Requirements . . . . . . . . . . . . . . . . . . . . . . .  5
108
109
110
111Fielding, et al.        Expires February 25, 2012               [Page 2]
112
113Internet-Draft              HTTP/1.1, Part 5                 August 2011
114
115
116     1.2.  Syntax Notation  . . . . . . . . . . . . . . . . . . . . .  5
117       1.2.1.  Core Rules . . . . . . . . . . . . . . . . . . . . . .  6
118       1.2.2.  ABNF Rules defined in other Parts of the
119               Specification  . . . . . . . . . . . . . . . . . . . .  6
120   2.  Range Units  . . . . . . . . . . . . . . . . . . . . . . . . .  6
121     2.1.  Range Specifier Registry . . . . . . . . . . . . . . . . .  6
122   3.  Status Code Definitions  . . . . . . . . . . . . . . . . . . .  7
123     3.1.  206 Partial Content  . . . . . . . . . . . . . . . . . . .  7
124     3.2.  416 Requested Range Not Satisfiable  . . . . . . . . . . .  7
125   4.  Combining Ranges . . . . . . . . . . . . . . . . . . . . . . .  8
126   5.  Header Field Definitions . . . . . . . . . . . . . . . . . . .  9
127     5.1.  Accept-Ranges  . . . . . . . . . . . . . . . . . . . . . .  9
128     5.2.  Content-Range  . . . . . . . . . . . . . . . . . . . . . .  9
129     5.3.  If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 12
130     5.4.  Range  . . . . . . . . . . . . . . . . . . . . . . . . . . 13
131       5.4.1.  Byte Ranges  . . . . . . . . . . . . . . . . . . . . . 13
132       5.4.2.  Range Retrieval Requests . . . . . . . . . . . . . . . 15
133   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
134     6.1.  Status Code Registration . . . . . . . . . . . . . . . . . 15
135     6.2.  Header Field Registration  . . . . . . . . . . . . . . . . 16
136     6.3.  Range Specifier Registration . . . . . . . . . . . . . . . 16
137   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
138     7.1.  Overlapping Ranges . . . . . . . . . . . . . . . . . . . . 17
139   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 17
140   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
141     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 17
142     9.2.  Informative References . . . . . . . . . . . . . . . . . . 17
143   Appendix A.  Internet Media Type multipart/byteranges  . . . . . . 18
144   Appendix B.  Compatibility with Previous Versions  . . . . . . . . 20
145     B.1.  Changes from RFC 2616  . . . . . . . . . . . . . . . . . . 20
146   Appendix C.  Collected ABNF  . . . . . . . . . . . . . . . . . . . 21
147   Appendix D.  Change Log (to be removed by RFC Editor before
148                publication)  . . . . . . . . . . . . . . . . . . . . 22
149     D.1.  Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 22
150     D.2.  Since draft-ietf-httpbis-p5-range-00 . . . . . . . . . . . 22
151     D.3.  Since draft-ietf-httpbis-p5-range-01 . . . . . . . . . . . 22
152     D.4.  Since draft-ietf-httpbis-p5-range-02 . . . . . . . . . . . 22
153     D.5.  Since draft-ietf-httpbis-p5-range-03 . . . . . . . . . . . 23
154     D.6.  Since draft-ietf-httpbis-p5-range-04 . . . . . . . . . . . 23
155     D.7.  Since draft-ietf-httpbis-p5-range-05 . . . . . . . . . . . 23
156     D.8.  Since draft-ietf-httpbis-p5-range-06 . . . . . . . . . . . 23
157     D.9.  Since draft-ietf-httpbis-p5-range-07 . . . . . . . . . . . 24
158     D.10. Since draft-ietf-httpbis-p5-range-08 . . . . . . . . . . . 24
159     D.11. Since draft-ietf-httpbis-p5-range-09 . . . . . . . . . . . 24
160     D.12. Since draft-ietf-httpbis-p5-range-10 . . . . . . . . . . . 24
161     D.13. Since draft-ietf-httpbis-p5-range-11 . . . . . . . . . . . 24
162     D.14. Since draft-ietf-httpbis-p5-range-12 . . . . . . . . . . . 25
163     D.15. Since draft-ietf-httpbis-p5-range-13 . . . . . . . . . . . 25
164
165
166
167Fielding, et al.        Expires February 25, 2012               [Page 3]
168
169Internet-Draft              HTTP/1.1, Part 5                 August 2011
170
171
172     D.16. Since draft-ietf-httpbis-p5-range-14 . . . . . . . . . . . 25
173     D.17. Since draft-ietf-httpbis-p5-range-15 . . . . . . . . . . . 25
174   Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223Fielding, et al.        Expires February 25, 2012               [Page 4]
224
225Internet-Draft              HTTP/1.1, Part 5                 August 2011
226
227
2281.  Introduction
229
230   HTTP clients often encounter interrupted data transfers as a result
231   of cancelled requests or dropped connections.  When a client has
232   stored a partial representation, it is desirable to request the
233   remainder of that representation in a subsequent request rather than
234   transfer the entire representation.  There are also a number of Web
235   applications that benefit from being able to request only a subset of
236   a larger representation, such as a single page of a very large
237   document or only part of an image to be rendered by a device with
238   limited local storage.
239
240   This document defines HTTP/1.1 range requests, partial responses, and
241   the multipart/byteranges media type.  The protocol for range requests
242   is an OPTIONAL feature of HTTP, designed so resources or recipients
243   that do not implement this feature can respond as if it is a normal
244   GET request without impacting interoperability.  Partial responses
245   are indicated by a distinct status code to not be mistaken for full
246   responses by intermediate caches that might not implement the
247   feature.
248
249   Although the HTTP range request mechanism is designed to allow for
250   extensible range types, this specification only defines requests for
251   byte ranges.
252
2531.1.  Requirements
254
255   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
256   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
257   document are to be interpreted as described in [RFC2119].
258
259   An implementation is not compliant if it fails to satisfy one or more
260   of the "MUST" or "REQUIRED" level requirements for the protocols it
261   implements.  An implementation that satisfies all the "MUST" or
262   "REQUIRED" level and all the "SHOULD" level requirements for its
263   protocols is said to be "unconditionally compliant"; one that
264   satisfies all the "MUST" level requirements but not all the "SHOULD"
265   level requirements for its protocols is said to be "conditionally
266   compliant".
267
2681.2.  Syntax Notation
269
270   This specification uses the ABNF syntax defined in Section 1.2 of
271   [Part1] (which extends the syntax defined in [RFC5234] with a list
272   rule).  Appendix C shows the collected ABNF, with the list rule
273   expanded.
274
275   The following core rules are included by reference, as defined in
276
277
278
279Fielding, et al.        Expires February 25, 2012               [Page 5]
280
281Internet-Draft              HTTP/1.1, Part 5                 August 2011
282
283
284   [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
285   (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
286   HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit
287   sequence of data), SP (space), VCHAR (any visible USASCII character),
288   and WSP (whitespace).
289
2901.2.1.  Core Rules
291
292   The core rules below are defined in [Part1]:
293
294     OWS        = <OWS, defined in [Part1], Section 1.2.2>
295     token      = <token, defined in [Part1], Section 3.2.3>
296     HTTP-date  = <HTTP-date, defined in [Part1], Section 6.1>
297
2981.2.2.  ABNF Rules defined in other Parts of the Specification
299
300   The ABNF rules below are defined in other parts:
301
302     entity-tag = <entity-tag, defined in [Part4], Section 2.3>
303
3042.  Range Units
305
306   HTTP/1.1 allows a client to request that only part (a range) of the
307   representation be included within the response.  HTTP/1.1 uses range
308   units in the Range (Section 5.4) and Content-Range (Section 5.2)
309   header fields.  A representation can be broken down into subranges
310   according to various structural units.
311
312     range-unit       = bytes-unit / other-range-unit
313     bytes-unit       = "bytes"
314     other-range-unit = token
315
316   HTTP/1.1 has been designed to allow implementations of applications
317   that do not depend on knowledge of ranges.  The only range unit
318   defined by HTTP/1.1 is "bytes".  Additional specifiers can be defined
319   as described in Section 2.1.
320
321   If a range unit is not understood in a request, a server MUST ignore
322   the whole Range header field (Section 5.4).  If a range unit is not
323   understood in a response, an intermediary SHOULD pass the response to
324   the client; a client MUST fail.
325
3262.1.  Range Specifier Registry
327
328   The HTTP Range Specifier Registry defines the name space for the
329   range specifier names.
330
331   Registrations MUST include the following fields:
332
333
334
335Fielding, et al.        Expires February 25, 2012               [Page 6]
336
337Internet-Draft              HTTP/1.1, Part 5                 August 2011
338
339
340   o  Name
341
342   o  Description
343
344   o  Pointer to specification text
345
346   Values to be added to this name space are subject to IETF review
347   ([RFC5226], Section 4.1).
348
349   The registry itself is maintained at
350   <http://www.iana.org/assignments/http-range-specifiers>.
351
3523.  Status Code Definitions
353
3543.1.  206 Partial Content
355
356   The server has fulfilled the partial GET request for the resource.
357   The request MUST have included a Range header field (Section 5.4)
358   indicating the desired range, and MAY have included an If-Range
359   header field (Section 5.3) to make the request conditional.
360
361   The response MUST include the following header fields:
362
363   o  Either a Content-Range header field (Section 5.2) indicating the
364      range included with this response, or a multipart/byteranges
365      Content-Type including Content-Range fields for each part.  If a
366      Content-Length header field is present in the response, its value
367      MUST match the actual number of octets transmitted in the message-
368      body.
369
370   o  Date
371
372   o  Cache-Control, ETag, Expires, Content-Location, Last-Modified,
373      and/or Vary, if the header field would have been sent in a 200
374      response to the same request
375
376   If the 206 response is the result of an If-Range request, the
377   response SHOULD NOT include other representation header fields.
378   Otherwise, the response MUST include all of the representation header
379   fields that would have been returned with a 200 (OK) response to the
380   same request.
381
3823.2.  416 Requested Range Not Satisfiable
383
384   A server SHOULD return a response with this status code if a request
385   included a Range header field (Section 5.4), and none of the ranges-
386   specifier values in this field overlap the current extent of the
387   selected resource, and the request did not include an If-Range header
388
389
390
391Fielding, et al.        Expires February 25, 2012               [Page 7]
392
393Internet-Draft              HTTP/1.1, Part 5                 August 2011
394
395
396   field (Section 5.3).  (For byte-ranges, this means that the first-
397   byte-pos of all of the byte-range-spec values were greater than the
398   current length of the selected resource.)
399
400   When this status code is returned for a byte-range request, the
401   response SHOULD include a Content-Range header field specifying the
402   current length of the representation (see Section 5.2).  This
403   response MUST NOT use the multipart/byteranges content-type.
404
4054.  Combining Ranges
406
407   A response might transfer only a subrange of a representation if the
408   connection closed prematurely or if the request used one or more
409   Range specifications.  After several such transfers, a client might
410   have received several ranges of the same representation.  These
411   ranges can only be safely combined if they all have in common the
412   same strong validator, where "strong validator" is defined to be
413   either an entity-tag that is not marked as weak (Section 2.3 of
414   [Part4]) or, if no entity-tag is provided, a Last-Modified value that
415   is strong in the sense defined by Section 2.2.2 of [Part4].
416
417   When a client receives an incomplete 200 (OK) or 206 (Partial
418   Content) response and already has one or more stored responses for
419   the same method and effective request URI, all of the stored
420   responses with the same strong validator MAY be combined with the
421   partial content in this new response.  If none of the stored
422   responses contain the same strong validator, then this new response
423   corresponds to a new representation and MUST NOT be combined with the
424   existing stored responses.
425
426   If the new response is an incomplete 200 (OK) response, then the
427   header fields of that new response are used for any combined response
428   and replace those of the matching stored responses.
429
430   If the new response is a 206 (Partial Content) response and at least
431   one of the matching stored responses is a 200 (OK), then the combined
432   response header fields consist of the most recent 200 response's
433   header fields.  If all of the matching stored responses are 206
434   responses, then the stored response with the most header fields is
435   used as the source of header fields for the combined response, except
436   that the client MUST use other header fields provided in the new
437   response, aside from Content-Range, to replace all instances of the
438   corresponding header fields in the stored response.
439
440   The combined response message-body consists of the union of partial
441   content ranges in the new response and each of the selected
442   responses.  If the union consists of the entire range of the
443   representation, then the combined response MUST be recorded as a
444
445
446
447Fielding, et al.        Expires February 25, 2012               [Page 8]
448
449Internet-Draft              HTTP/1.1, Part 5                 August 2011
450
451
452   complete 200 (OK) response with a Content-Length header field that
453   reflects the complete length.  Otherwise, the combined response(s)
454   MUST include a Content-Range header field describing the included
455   range(s) and be recorded as incomplete.  If the union consists of a
456   discontinuous range of the representation, then the client MAY store
457   it as either a multipart range response or as multiple 206 responses
458   with one continuous range each.
459
4605.  Header Field Definitions
461
462   This section defines the syntax and semantics of HTTP/1.1 header
463   fields related to range requests and partial responses.
464
4655.1.  Accept-Ranges
466
467   The "Accept-Ranges" header field allows a resource to indicate its
468   acceptance of range requests.
469
470     Accept-Ranges     = acceptable-ranges
471     acceptable-ranges = 1#range-unit / "none"
472
473   Origin servers that accept byte-range requests MAY send
474
475     Accept-Ranges: bytes
476
477   but are not required to do so.  Clients MAY generate range requests
478   without having received this header field for the resource involved.
479   Range units are defined in Section 2.
480
481   Servers that do not accept any kind of range request for a resource
482   MAY send
483
484     Accept-Ranges: none
485
486   to advise the client not to attempt a range request.
487
4885.2.  Content-Range
489
490   The "Content-Range" header field is sent with a partial
491   representation to specify where in the full representation the
492   payload body is intended to be applied.
493
494   Range units are defined in Section 2.
495
496
497
498
499
500
501
502
503Fielding, et al.        Expires February 25, 2012               [Page 9]
504
505Internet-Draft              HTTP/1.1, Part 5                 August 2011
506
507
508     Content-Range           = byte-content-range-spec
509                             / other-content-range-spec
510
511     byte-content-range-spec = bytes-unit SP
512                               byte-range-resp-spec "/"
513                               ( instance-length / "*" )
514
515     byte-range-resp-spec    = (first-byte-pos "-" last-byte-pos)
516                             / "*"
517
518     instance-length         = 1*DIGIT
519
520     other-content-range-spec = other-range-unit SP
521                                other-range-resp-spec
522     other-range-resp-spec    = *CHAR
523
524   The header field SHOULD indicate the total length of the full
525   representation, unless this length is unknown or difficult to
526   determine.  The asterisk "*" character means that the instance-length
527   is unknown at the time when the response was generated.
528
529   Unlike byte-ranges-specifier values (see Section 5.4.1), a byte-
530   range-resp-spec MUST only specify one range, and MUST contain
531   absolute byte positions for both the first and last byte of the
532   range.
533
534   A byte-content-range-spec with a byte-range-resp-spec whose last-
535   byte-pos value is less than its first-byte-pos value, or whose
536   instance-length value is less than or equal to its last-byte-pos
537   value, is invalid.  The recipient of an invalid byte-content-range-
538   spec MUST ignore it and any content transferred along with it.
539
540   In the case of a byte range request: A server sending a response with
541   status code 416 (Requested range not satisfiable) SHOULD include a
542   Content-Range field with a byte-range-resp-spec of "*".  The
543   instance-length specifies the current length of the selected
544   resource.  A response with status code 206 (Partial Content) MUST NOT
545   include a Content-Range field with a byte-range-resp-spec of "*".
546
547   Examples of byte-content-range-spec values, assuming that the
548   representation contains a total of 1234 bytes:
549
550   o  The first 500 bytes:
551
552        bytes 0-499/1234
553
554
555
556
557
558
559Fielding, et al.        Expires February 25, 2012              [Page 10]
560
561Internet-Draft              HTTP/1.1, Part 5                 August 2011
562
563
564   o  The second 500 bytes:
565
566        bytes 500-999/1234
567
568   o  All except for the first 500 bytes:
569
570        bytes 500-1233/1234
571
572   o  The last 500 bytes:
573
574        bytes 734-1233/1234
575
576   When an HTTP message includes the content of a single range (for
577   example, a response to a request for a single range, or to a request
578   for a set of ranges that overlap without any holes), this content is
579   transmitted with a Content-Range header field, and a Content-Length
580   header field showing the number of bytes actually transferred.  For
581   example,
582
583     HTTP/1.1 206 Partial Content
584     Date: Wed, 15 Nov 1995 06:25:24 GMT
585     Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
586     Content-Range: bytes 21010-47021/47022
587     Content-Length: 26012
588     Content-Type: image/gif
589
590   When an HTTP message includes the content of multiple ranges (for
591   example, a response to a request for multiple non-overlapping
592   ranges), these are transmitted as a multipart message.  The multipart
593   media type used for this purpose is "multipart/byteranges" as defined
594   in Appendix A.
595
596   A response to a request for a single range MUST NOT be sent using the
597   multipart/byteranges media type.  A response to a request for
598   multiple ranges, whose result is a single range, MAY be sent as a
599   multipart/byteranges media type with one part.  A client that cannot
600   decode a multipart/byteranges message MUST NOT ask for multiple
601   ranges in a single request.
602
603   When a client requests multiple ranges in one request, the server
604   SHOULD return them in the order that they appeared in the request.
605
606   If the server ignores a byte-range-spec because it is syntactically
607   invalid, the server SHOULD treat the request as if the invalid Range
608   header field did not exist.  (Normally, this means return a 200
609   response containing the full representation).
610
611   If the server receives a request (other than one including an If-
612
613
614
615Fielding, et al.        Expires February 25, 2012              [Page 11]
616
617Internet-Draft              HTTP/1.1, Part 5                 August 2011
618
619
620   Range header field) with an unsatisfiable Range header field (that
621   is, all of whose byte-range-spec values have a first-byte-pos value
622   greater than the current length of the selected resource), it SHOULD
623   return a response code of 416 (Requested range not satisfiable)
624   (Section 3.2).
625
626      Note: Clients cannot depend on servers to send a 416 (Requested
627      range not satisfiable) response instead of a 200 (OK) response for
628      an unsatisfiable Range header field, since not all servers
629      implement this header field.
630
6315.3.  If-Range
632
633   If a client has a partial copy of a representation and wishes to have
634   an up-to-date copy of the entire representation, it could use the
635   Range header field with a conditional GET (using either or both of
636   If-Unmodified-Since and If-Match.)  However, if the condition fails
637   because the representation has been modified, the client would then
638   have to make a second request to obtain the entire current
639   representation.
640
641   The "If-Range" header field allows a client to "short-circuit" the
642   second request.  Informally, its meaning is "if the representation is
643   unchanged, send me the part(s) that I am missing; otherwise, send me
644   the entire new representation".
645
646     If-Range = entity-tag / HTTP-date
647
648   Clients MUST NOT use an entity-tag marked as weak in an If-Range
649   field value and MUST NOT use a Last-Modified date in an If-Range
650   field value unless it has no entity-tag for the representation and
651   the Last-Modified date it does have for the representation is strong
652   in the sense defined by Section 2.2.2 of [Part4].
653
654   A server that evaluates a conditional range request that is
655   applicable to one of its representations MUST evaluate the condition
656   as false if the entity-tag used as a validator is marked as weak or,
657   when an HTTP-date is used as the validator, if the date value is not
658   strong in the sense defined by Section 2.2.2 of [Part4].  (A server
659   can distinguish between a valid HTTP-date and any form of entity-tag
660   by examining the first two characters.)
661
662   The If-Range header field SHOULD only be sent by clients together
663   with a Range header field.  The If-Range header field MUST be ignored
664   if it is received in a request that does not include a Range header
665   field.  The If-Range header field MUST be ignored by a server that
666   does not support the sub-range operation.
667
668
669
670
671Fielding, et al.        Expires February 25, 2012              [Page 12]
672
673Internet-Draft              HTTP/1.1, Part 5                 August 2011
674
675
676   If the validator given in the If-Range header field matches the
677   current validator for the selected representation of the target
678   resource, then the server SHOULD send the specified sub-range of the
679   representation using a 206 (Partial Content) response.  If the
680   validator does not match, then the server SHOULD send the entire
681   representation using a 200 (OK) response.
682
6835.4.  Range
684
6855.4.1.  Byte Ranges
686
687   Since all HTTP representations are transferred as sequences of bytes,
688   the concept of a byte range is meaningful for any HTTP
689   representation.  (However, not all clients and servers need to
690   support byte-range operations.)
691
692   Byte range specifications in HTTP apply to the sequence of bytes in
693   the representation body (not necessarily the same as the message-
694   body).
695
696   A byte range operation MAY specify a single range of bytes, or a set
697   of ranges within a single representation.
698
699     byte-ranges-specifier = bytes-unit "=" byte-range-set
700     byte-range-set  = 1#( byte-range-spec / suffix-byte-range-spec )
701     byte-range-spec = first-byte-pos "-" [ last-byte-pos ]
702     first-byte-pos  = 1*DIGIT
703     last-byte-pos   = 1*DIGIT
704
705   The first-byte-pos value in a byte-range-spec gives the byte-offset
706   of the first byte in a range.  The last-byte-pos value gives the
707   byte-offset of the last byte in the range; that is, the byte
708   positions specified are inclusive.  Byte offsets start at zero.
709
710   If the last-byte-pos value is present, it MUST be greater than or
711   equal to the first-byte-pos in that byte-range-spec, or the byte-
712   range-spec is syntactically invalid.  The recipient of a byte-range-
713   set that includes one or more syntactically invalid byte-range-spec
714   values MUST ignore the header field that includes that byte-range-
715   set.
716
717   If the last-byte-pos value is absent, or if the value is greater than
718   or equal to the current length of the representation body, last-byte-
719   pos is taken to be equal to one less than the current length of the
720   representation in bytes.
721
722   By its choice of last-byte-pos, a client can limit the number of
723   bytes retrieved without knowing the size of the representation.
724
725
726
727Fielding, et al.        Expires February 25, 2012              [Page 13]
728
729Internet-Draft              HTTP/1.1, Part 5                 August 2011
730
731
732     suffix-byte-range-spec = "-" suffix-length
733     suffix-length = 1*DIGIT
734
735   A suffix-byte-range-spec is used to specify the suffix of the
736   representation body, of a length given by the suffix-length value.
737   (That is, this form specifies the last N bytes of a representation.)
738   If the representation is shorter than the specified suffix-length,
739   the entire representation is used.
740
741   If a syntactically valid byte-range-set includes at least one byte-
742   range-spec whose first-byte-pos is less than the current length of
743   the representation, or at least one suffix-byte-range-spec with a
744   non-zero suffix-length, then the byte-range-set is satisfiable.
745   Otherwise, the byte-range-set is unsatisfiable.  If the byte-range-
746   set is unsatisfiable, the server SHOULD return a response with a 416
747   (Requested range not satisfiable) status code.  Otherwise, the server
748   SHOULD return a response with a 206 (Partial Content) status code
749   containing the satisfiable ranges of the representation.
750
751   Examples of byte-ranges-specifier values (assuming a representation
752   of length 10000):
753
754   o  The first 500 bytes (byte offsets 0-499, inclusive):
755
756        bytes=0-499
757
758   o  The second 500 bytes (byte offsets 500-999, inclusive):
759
760        bytes=500-999
761
762   o  The final 500 bytes (byte offsets 9500-9999, inclusive):
763
764        bytes=-500
765
766      Or:
767
768        bytes=9500-
769
770   o  The first and last bytes only (bytes 0 and 9999):
771
772        bytes=0-0,-1
773
774   o  Several legal but not canonical specifications of the second 500
775      bytes (byte offsets 500-999, inclusive):
776
777        bytes=500-600,601-999
778        bytes=500-700,601-999
779
780
781
782
783Fielding, et al.        Expires February 25, 2012              [Page 14]
784
785Internet-Draft              HTTP/1.1, Part 5                 August 2011
786
787
7885.4.2.  Range Retrieval Requests
789
790   The "Range" header field defines the GET method (conditional or not)
791   to request one or more sub-ranges of the response representation
792   body, instead of the entire representation body.
793
794     Range = byte-ranges-specifier / other-ranges-specifier
795     other-ranges-specifier = other-range-unit "=" other-range-set
796     other-range-set = 1*CHAR
797
798   A server MAY ignore the Range header field.  However, origin servers
799   and intermediate caches ought to support byte ranges when possible,
800   since Range supports efficient recovery from partially failed
801   transfers, and supports efficient partial retrieval of large
802   representations.
803
804   If the server supports the Range header field and the specified range
805   or ranges are appropriate for the representation:
806
807   o  The presence of a Range header field in an unconditional GET
808      modifies what is returned if the GET is otherwise successful.  In
809      other words, the response carries a status code of 206 (Partial
810      Content) instead of 200 (OK).
811
812   o  The presence of a Range header field in a conditional GET (a
813      request using one or both of If-Modified-Since and If-None-Match,
814      or one or both of If-Unmodified-Since and If-Match) modifies what
815      is returned if the GET is otherwise successful and the condition
816      is true.  It does not affect the 304 (Not Modified) response
817      returned if the conditional is false.
818
819   In some cases, it might be more appropriate to use the If-Range
820   header field (see Section 5.3) in addition to the Range header field.
821
822   If a proxy that supports ranges receives a Range request, forwards
823   the request to an inbound server, and receives an entire
824   representation in reply, it MAY only return the requested range to
825   its client.
826
8276.  IANA Considerations
828
8296.1.  Status Code Registration
830
831   The HTTP Status Code Registry located at
832   <http://www.iana.org/assignments/http-status-codes> shall be updated
833   with the registrations below:
834
835
836
837
838
839Fielding, et al.        Expires February 25, 2012              [Page 15]
840
841Internet-Draft              HTTP/1.1, Part 5                 August 2011
842
843
844   +-------+---------------------------------+-------------+
845   | Value | Description                     | Reference   |
846   +-------+---------------------------------+-------------+
847   | 206   | Partial Content                 | Section 3.1 |
848   | 416   | Requested Range Not Satisfiable | Section 3.2 |
849   +-------+---------------------------------+-------------+
850
8516.2.  Header Field Registration
852
853   The Message Header Field Registry located at <http://www.iana.org/
854   assignments/message-headers/message-header-index.html> shall be
855   updated with the permanent registrations below (see [RFC3864]):
856
857   +-------------------+----------+----------+-------------+
858   | Header Field Name | Protocol | Status   | Reference   |
859   +-------------------+----------+----------+-------------+
860   | Accept-Ranges     | http     | standard | Section 5.1 |
861   | Content-Range     | http     | standard | Section 5.2 |
862   | If-Range          | http     | standard | Section 5.3 |
863   | Range             | http     | standard | Section 5.4 |
864   +-------------------+----------+----------+-------------+
865
866   The change controller is: "IETF (iesg@ietf.org) - Internet
867   Engineering Task Force".
868
8696.3.  Range Specifier Registration
870
871   The registration procedure for HTTP Range Specifiers is defined by
872   Section 2.1 of this document.
873
874   The HTTP Range Specifier Registry shall be created at
875   <http://www.iana.org/assignments/http-range-specifiers> and be
876   populated with the registrations below:
877
878   +----------------------+-------------------+----------------------+
879   | Range Specifier Name | Description       | Reference            |
880   +----------------------+-------------------+----------------------+
881   | bytes                | a range of octets | (this specification) |
882   +----------------------+-------------------+----------------------+
883
884   The change controller is: "IETF (iesg@ietf.org) - Internet
885   Engineering Task Force".
886
8877.  Security Considerations
888
889   This section is meant to inform application developers, information
890   providers, and users of the security limitations in HTTP/1.1 as
891   described by this document.  The discussion does not include
892
893
894
895Fielding, et al.        Expires February 25, 2012              [Page 16]
896
897Internet-Draft              HTTP/1.1, Part 5                 August 2011
898
899
900   definitive solutions to the problems revealed, though it does make
901   some suggestions for reducing security risks.
902
9037.1.  Overlapping Ranges
904
905   Range requests containing overlapping ranges may lead to the
906   situation where a server is sending far more data than the size of
907   the complete resource representation.
908
9098.  Acknowledgments
910
911   See Section 12 of [Part1].
912
9139.  References
914
9159.1.  Normative References
916
917   [Part1]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
918              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
919              and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
920              and Message Parsing", draft-ietf-httpbis-p1-messaging-16
921              (work in progress), August 2011.
922
923   [Part4]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
924              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
925              and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional
926              Requests", draft-ietf-httpbis-p4-conditional-16 (work in
927              progress), August 2011.
928
929   [RFC2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
930              Extensions (MIME) Part Two: Media Types", RFC 2046,
931              November 1996.
932
933   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
934              Requirement Levels", BCP 14, RFC 2119, March 1997.
935
936   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
937              Specifications: ABNF", STD 68, RFC 5234, January 2008.
938
9399.2.  Informative References
940
941   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
942              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
943              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
944
945   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
946              Procedures for Message Header Fields", BCP 90, RFC 3864,
947              September 2004.
948
949
950
951Fielding, et al.        Expires February 25, 2012              [Page 17]
952
953Internet-Draft              HTTP/1.1, Part 5                 August 2011
954
955
956   [RFC4288]  Freed, N. and J. Klensin, "Media Type Specifications and
957              Registration Procedures", BCP 13, RFC 4288, December 2005.
958
959   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
960              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
961              May 2008.
962
963Appendix A.  Internet Media Type multipart/byteranges
964
965   When an HTTP 206 (Partial Content) response message includes the
966   content of multiple ranges (a response to a request for multiple non-
967   overlapping ranges), these are transmitted as a multipart message-
968   body ([RFC2046], Section 5.1).  The media type for this purpose is
969   called "multipart/byteranges".  The following is to be registered
970   with IANA [RFC4288].
971
972      Note: Despite the name "multipart/byteranges" is not limited to
973      the byte ranges only.
974
975   The multipart/byteranges media type includes one or more parts, each
976   with its own Content-Type and Content-Range fields.  The required
977   boundary parameter specifies the boundary string used to separate
978   each body-part.
979
980   Type name:  multipart
981
982   Subtype name:  byteranges
983
984   Required parameters:  boundary
985
986   Optional parameters:  none
987
988   Encoding considerations:  only "7bit", "8bit", or "binary" are
989      permitted
990
991   Security considerations:  none
992
993   Interoperability considerations:  none
994
995   Published specification:  This specification (see Appendix A).
996
997   Applications that use this media type:
998
999   Additional information:
1000
1001
1002
1003
1004
1005
1006
1007Fielding, et al.        Expires February 25, 2012              [Page 18]
1008
1009Internet-Draft              HTTP/1.1, Part 5                 August 2011
1010
1011
1012      Magic number(s):  none
1013
1014      File extension(s):  none
1015
1016      Macintosh file type code(s):  none
1017
1018   Person and email address to contact for further information:  See
1019      Authors Section.
1020
1021   Intended usage:  COMMON
1022
1023   Restrictions on usage:  none
1024
1025   Author/Change controller:  IESG
1026
1027   For example:
1028
1029     HTTP/1.1 206 Partial Content
1030     Date: Wed, 15 Nov 1995 06:25:24 GMT
1031     Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
1032     Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
1033
1034     --THIS_STRING_SEPARATES
1035     Content-type: application/pdf
1036     Content-range: bytes 500-999/8000
1037
1038     ...the first range...
1039     --THIS_STRING_SEPARATES
1040     Content-type: application/pdf
1041     Content-range: bytes 7000-7999/8000
1042
1043     ...the second range
1044     --THIS_STRING_SEPARATES--
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063Fielding, et al.        Expires February 25, 2012              [Page 19]
1064
1065Internet-Draft              HTTP/1.1, Part 5                 August 2011
1066
1067
1068   Other example:
1069
1070     HTTP/1.1 206 Partial Content
1071     Date: Tue, 14 Nov 1995 06:25:24 GMT
1072     Last-Modified: Tue, 14 July 04:58:08 GMT
1073     Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
1074
1075     --THIS_STRING_SEPARATES
1076     Content-type: video/example
1077     Content-range: exampleunit 1.2-4.3/25
1078
1079     ...the first range...
1080     --THIS_STRING_SEPARATES
1081     Content-type: video/example
1082     Content-range: exampleunit 11.2-14.3/25
1083
1084     ...the second range
1085     --THIS_STRING_SEPARATES--
1086
1087   Notes:
1088
1089   1.  Additional CRLFs MAY precede the first boundary string in the
1090       body.
1091
1092   2.  Although [RFC2046] permits the boundary string to be quoted, some
1093       existing implementations handle a quoted boundary string
1094       incorrectly.
1095
1096   3.  A number of browsers and servers were coded to an early draft of
1097       the byteranges specification to use a media type of multipart/
1098       x-byteranges, which is almost, but not quite compatible with the
1099       version documented in HTTP/1.1.
1100
1101Appendix B.  Compatibility with Previous Versions
1102
1103B.1.  Changes from RFC 2616
1104
1105   Clarify that it is not ok to use a weak validator in a 206 response.
1106   (Section 3.1)
1107
1108   Change ABNF productions for header fields to only define the field
1109   value.  (Section 5)
1110
1111   Clarify that multipart/byteranges can consist of a single part.
1112   (Appendix A)
1113
1114
1115
1116
1117
1118
1119Fielding, et al.        Expires February 25, 2012              [Page 20]
1120
1121Internet-Draft              HTTP/1.1, Part 5                 August 2011
1122
1123
1124Appendix C.  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 [Part1], Section 6.1>
1131
1132   If-Range = entity-tag / HTTP-date
1133
1134   OWS = <OWS, defined in [Part1], Section 1.2.2>
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.3>
1171
1172
1173
1174
1175Fielding, et al.        Expires February 25, 2012              [Page 21]
1176
1177Internet-Draft              HTTP/1.1, Part 5                 August 2011
1178
1179
1180   ABNF diagnostics:
1181
1182   ; Accept-Ranges defined but not used
1183   ; Content-Range defined but not used
1184   ; If-Range defined but not used
1185   ; Range defined but not used
1186
1187Appendix D.  Change Log (to be removed by RFC Editor before publication)
1188
1189D.1.  Since RFC 2616
1190
1191   Extracted relevant partitions from [RFC2616].
1192
1193D.2.  Since draft-ietf-httpbis-p5-range-00
1194
1195   Closed issues:
1196
1197   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/18>: "Cache
1198      validators in 206 responses"
1199      (<http://purl.org/NET/http-errata#ifrange206>)
1200
1201   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and
1202      Informative references"
1203
1204   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/86>: "Normative up-
1205      to-date references"
1206
1207D.3.  Since draft-ietf-httpbis-p5-range-01
1208
1209   Closed issues:
1210
1211   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/55>: "Updating to
1212      RFC4288"
1213
1214   Ongoing work on ABNF conversion
1215   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
1216
1217   o  Add explicit references to BNF syntax and rules imported from
1218      other parts of the specification.
1219
1220D.4.  Since draft-ietf-httpbis-p5-range-02
1221
1222   Ongoing work on IANA Message Header Field Registration
1223   (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>):
1224
1225   o  Reference RFC 3984, and update header field registrations for
1226      headers defined in this document.
1227
1228
1229
1230
1231Fielding, et al.        Expires February 25, 2012              [Page 22]
1232
1233Internet-Draft              HTTP/1.1, Part 5                 August 2011
1234
1235
1236D.5.  Since draft-ietf-httpbis-p5-range-03
1237
1238   None.
1239
1240D.6.  Since draft-ietf-httpbis-p5-range-04
1241
1242   Closed issues:
1243
1244   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/133>: "multipart/
1245      byteranges minimum number of parts"
1246
1247   Ongoing work on ABNF conversion
1248   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
1249
1250   o  Use "/" instead of "|" for alternatives.
1251
1252   o  Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
1253      whitespace ("OWS") and required whitespace ("RWS").
1254
1255   o  Rewrite ABNFs to spell out whitespace rules, factor out header
1256      field value format definitions.
1257
1258D.7.  Since draft-ietf-httpbis-p5-range-05
1259
1260   Closed issues:
1261
1262   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/142>: "State base
1263      for *-byte-pos and suffix-length"
1264
1265   Ongoing work on Custom Ranges
1266   (<http://tools.ietf.org/wg/httpbis/trac/ticket/85>):
1267
1268   o  Remove bias in favor of byte ranges; allow custom ranges in ABNF.
1269
1270   Final work on ABNF conversion
1271   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
1272
1273   o  Add appendix containing collected and expanded ABNF, reorganize
1274      ABNF introduction.
1275
1276D.8.  Since draft-ietf-httpbis-p5-range-06
1277
1278   Closed issues:
1279
1280   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/161>: "base for
1281      numeric protocol elements"
1282
1283
1284
1285
1286
1287Fielding, et al.        Expires February 25, 2012              [Page 23]
1288
1289Internet-Draft              HTTP/1.1, Part 5                 August 2011
1290
1291
1292D.9.  Since draft-ietf-httpbis-p5-range-07
1293
1294   Closed issues:
1295
1296   o  Fixed discrepancy in the If-Range definition about allowed
1297      validators.
1298
1299   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/150>: "multipart/
1300      byteranges for custom range units"
1301
1302   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/151>: "range unit
1303      missing from other-ranges-specifier in Range header"
1304
1305   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/198>: "move IANA
1306      registrations for optional status codes"
1307
1308D.10.  Since draft-ietf-httpbis-p5-range-08
1309
1310   No significant changes.
1311
1312D.11.  Since draft-ietf-httpbis-p5-range-09
1313
1314   No significant changes.
1315
1316D.12.  Since draft-ietf-httpbis-p5-range-10
1317
1318   Closed issues:
1319
1320   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/69>: "Clarify
1321      'Requested Variant'"
1322
1323   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/109>: "Clarify
1324      entity / representation / variant terminology"
1325
1326   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider
1327      removing the 'changes from 2068' sections"
1328
1329   Ongoing work on Custom Ranges
1330   (<http://tools.ietf.org/wg/httpbis/trac/ticket/85>):
1331
1332   o  Add IANA registry.
1333
1334D.13.  Since draft-ietf-httpbis-p5-range-11
1335
1336   Closed issues:
1337
1338   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/217>: "Caches can't
1339      be required to serve ranges"
1340
1341
1342
1343Fielding, et al.        Expires February 25, 2012              [Page 24]
1344
1345Internet-Draft              HTTP/1.1, Part 5                 August 2011
1346
1347
1348D.14.  Since draft-ietf-httpbis-p5-range-12
1349
1350   Closed issues:
1351
1352   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/224>: "Header
1353      Classification"
1354
1355D.15.  Since draft-ietf-httpbis-p5-range-13
1356
1357   Closed issues:
1358
1359   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle
1360      ABNFs for header fields"
1361
1362D.16.  Since draft-ietf-httpbis-p5-range-14
1363
1364   None.
1365
1366D.17.  Since draft-ietf-httpbis-p5-range-15
1367
1368   Closed issues:
1369
1370   o  <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/175>: "Security
1371      consideration: range flooding"
1372
1373Index
1374
1375   2
1376      206 Partial Content (status code)  7
1377
1378   4
1379      416 Requested Range Not Satisfiable (status code)  7
1380
1381   A
1382      Accept-Ranges header field  9
1383
1384   C
1385      Content-Range header field  9
1386
1387   G
1388      Grammar
1389         Accept-Ranges  9
1390         acceptable-ranges  9
1391         byte-content-range-spec  10
1392         byte-range-resp-spec  10
1393         byte-range-set  13
1394         byte-range-spec  13
1395         byte-ranges-specifier  13
1396
1397
1398
1399Fielding, et al.        Expires February 25, 2012              [Page 25]
1400
1401Internet-Draft              HTTP/1.1, Part 5                 August 2011
1402
1403
1404         bytes-unit  6
1405         Content-Range  10
1406         first-byte-pos  13
1407         If-Range  12
1408         instance-length  10
1409         last-byte-pos  13
1410         other-range-unit  6
1411         Range  15
1412         range-unit  6
1413         ranges-specifier  13
1414         suffix-byte-range-spec  14
1415         suffix-length  14
1416
1417   H
1418      Header Fields
1419         Accept-Ranges  9
1420         Content-Range  9
1421         If-Range  12
1422         Range  13
1423
1424   I
1425      If-Range header field  12
1426
1427   M
1428      Media Type
1429         multipart/byteranges  18
1430         multipart/x-byteranges  20
1431      multipart/byteranges Media Type  18
1432      multipart/x-byteranges Media Type  20
1433
1434   R
1435      Range header field  13
1436
1437   S
1438      Status Codes
1439         206 Partial Content  7
1440         416 Requested Range Not Satisfiable  7
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455Fielding, et al.        Expires February 25, 2012              [Page 26]
1456
1457Internet-Draft              HTTP/1.1, Part 5                 August 2011
1458
1459
1460Authors' Addresses
1461
1462   Roy T. Fielding (editor)
1463   Adobe Systems Incorporated
1464   345 Park Ave
1465   San Jose, CA  95110
1466   USA
1467
1468   EMail: fielding@gbiv.com
1469   URI:   http://roy.gbiv.com/
1470
1471
1472   Jim Gettys
1473   Alcatel-Lucent Bell Labs
1474   21 Oak Knoll Road
1475   Carlisle, MA  01741
1476   USA
1477
1478   EMail: jg@freedesktop.org
1479   URI:   http://gettys.wordpress.com/
1480
1481
1482   Jeffrey C. Mogul
1483   Hewlett-Packard Company
1484   HP Labs, Large Scale Systems Group
1485   1501 Page Mill Road, MS 1177
1486   Palo Alto, CA  94304
1487   USA
1488
1489   EMail: JeffMogul@acm.org
1490
1491
1492   Henrik Frystyk Nielsen
1493   Microsoft Corporation
1494   1 Microsoft Way
1495   Redmond, WA  98052
1496   USA
1497
1498   EMail: henrikn@microsoft.com
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511Fielding, et al.        Expires February 25, 2012              [Page 27]
1512
1513Internet-Draft              HTTP/1.1, Part 5                 August 2011
1514
1515
1516   Larry Masinter
1517   Adobe Systems Incorporated
1518   345 Park Ave
1519   San Jose, CA  95110
1520   USA
1521
1522   EMail: LMM@acm.org
1523   URI:   http://larry.masinter.net/
1524
1525
1526   Paul J. Leach
1527   Microsoft Corporation
1528   1 Microsoft Way
1529   Redmond, WA  98052
1530
1531   EMail: paulle@microsoft.com
1532
1533
1534   Tim Berners-Lee
1535   World Wide Web Consortium
1536   MIT Computer Science and Artificial Intelligence Laboratory
1537   The Stata Center, Building 32
1538   32 Vassar Street
1539   Cambridge, MA  02139
1540   USA
1541
1542   EMail: timbl@w3.org
1543   URI:   http://www.w3.org/People/Berners-Lee/
1544
1545
1546   Yves Lafon (editor)
1547   World Wide Web Consortium
1548   W3C / ERCIM
1549   2004, rte des Lucioles
1550   Sophia-Antipolis, AM  06902
1551   France
1552
1553   EMail: ylafon@w3.org
1554   URI:   http://www.raubacapeu.net/people/yves/
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567Fielding, et al.        Expires February 25, 2012              [Page 28]
1568
1569Internet-Draft              HTTP/1.1, Part 5                 August 2011
1570
1571
1572   Julian F. Reschke (editor)
1573   greenbytes GmbH
1574   Hafenweg 16
1575   Muenster, NW  48155
1576   Germany
1577
1578   Phone: +49 251 2807760
1579   Fax:   +49 251 2807761
1580   EMail: julian.reschke@greenbytes.de
1581   URI:   http://greenbytes.de/tech/webdav/
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623Fielding, et al.        Expires February 25, 2012              [Page 29]
1624
Note: See TracBrowser for help on using the repository browser.