source: draft-ietf-httpbis/15/draft-ietf-httpbis-p5-range-15.txt @ 2082

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

Fix "none yet" entries in -15 change log entries, update -latest accordingly.

  • Property svn:eol-style set to native
  • Property svn:executable set to *
File size: 49.2 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: January 12, 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                                                           July 11, 2011
23
24
25         HTTP/1.1, part 5: Range Requests and Partial Responses
26                     draft-ietf-httpbis-p5-range-15
27
28Abstract
29
30   The Hypertext Transfer Protocol (HTTP) is an application-level
31   protocol for distributed, collaborative, hypermedia 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.  Part 5 defines
36   range-specific requests and the rules for constructing and combining
37   responses to those requests.
38
39Editorial Note (To be removed by RFC Editor)
40
41   Discussion of this draft should take place on the HTTPBIS working
42   group mailing list (ietf-http-wg@w3.org), which is archived at
43   <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
44
45   The current issues list is at
46   <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
47   documents (including fancy diffs) can be found at
48   <http://tools.ietf.org/wg/httpbis/>.
49
50   The changes in this draft are summarized in Appendix D.16.
51
52
53
54
55Fielding, et al.        Expires January 12, 2012                [Page 1]
56
57Internet-Draft              HTTP/1.1, Part 5                   July 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 January 12, 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 January 12, 2012                [Page 2]
112
113Internet-Draft              HTTP/1.1, Part 5                   July 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  . . . . . . . . . . .  8
125   4.  Combining Ranges . . . . . . . . . . . . . . . . . . . . . . .  8
126   5.  Header Field Definitions . . . . . . . . . . . . . . . . . . .  8
127     5.1.  Accept-Ranges  . . . . . . . . . . . . . . . . . . . . . .  9
128     5.2.  Content-Range  . . . . . . . . . . . . . . . . . . . . . .  9
129     5.3.  If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 11
130     5.4.  Range  . . . . . . . . . . . . . . . . . . . . . . . . . . 12
131       5.4.1.  Byte Ranges  . . . . . . . . . . . . . . . . . . . . . 12
132       5.4.2.  Range Retrieval Requests . . . . . . . . . . . . . . . 14
133   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
134     6.1.  Status Code Registration . . . . . . . . . . . . . . . . . 15
135     6.2.  Header Field Registration  . . . . . . . . . . . . . . . . 15
136     6.3.  Range Specifier Registration . . . . . . . . . . . . . . . 16
137   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
138   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 16
139   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
140     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 17
141     9.2.  Informative References . . . . . . . . . . . . . . . . . . 17
142   Appendix A.  Internet Media Type multipart/byteranges  . . . . . . 17
143   Appendix B.  Compatibility with Previous Versions  . . . . . . . . 20
144     B.1.  Changes from RFC 2616  . . . . . . . . . . . . . . . . . . 20
145   Appendix C.  Collected ABNF  . . . . . . . . . . . . . . . . . . . 20
146   Appendix D.  Change Log (to be removed by RFC Editor before
147                publication)  . . . . . . . . . . . . . . . . . . . . 22
148     D.1.  Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 22
149     D.2.  Since draft-ietf-httpbis-p5-range-00 . . . . . . . . . . . 22
150     D.3.  Since draft-ietf-httpbis-p5-range-01 . . . . . . . . . . . 22
151     D.4.  Since draft-ietf-httpbis-p5-range-02 . . . . . . . . . . . 22
152     D.5.  Since draft-ietf-httpbis-p5-range-03 . . . . . . . . . . . 23
153     D.6.  Since draft-ietf-httpbis-p5-range-04 . . . . . . . . . . . 23
154     D.7.  Since draft-ietf-httpbis-p5-range-05 . . . . . . . . . . . 23
155     D.8.  Since draft-ietf-httpbis-p5-range-06 . . . . . . . . . . . 23
156     D.9.  Since draft-ietf-httpbis-p5-range-07 . . . . . . . . . . . 24
157     D.10. Since draft-ietf-httpbis-p5-range-08 . . . . . . . . . . . 24
158     D.11. Since draft-ietf-httpbis-p5-range-09 . . . . . . . . . . . 24
159     D.12. Since draft-ietf-httpbis-p5-range-10 . . . . . . . . . . . 24
160     D.13. Since draft-ietf-httpbis-p5-range-11 . . . . . . . . . . . 24
161     D.14. Since draft-ietf-httpbis-p5-range-12 . . . . . . . . . . . 25
162     D.15. Since draft-ietf-httpbis-p5-range-13 . . . . . . . . . . . 25
163     D.16. Since draft-ietf-httpbis-p5-range-14 . . . . . . . . . . . 25
164
165
166
167Fielding, et al.        Expires January 12, 2012                [Page 3]
168
169Internet-Draft              HTTP/1.1, Part 5                   July 2011
170
171
172   Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
173
174
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 January 12, 2012                [Page 4]
224
225Internet-Draft              HTTP/1.1, Part 5                   July 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 cache 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 January 12, 2012                [Page 5]
280
281Internet-Draft              HTTP/1.1, Part 5                   July 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 Section 1.2.2 of [Part1]:
293
294     token      = <token, defined in [Part1], Section 1.2.2>
295     OWS        = <OWS, defined in [Part1], Section 1.2.2>
296
2971.2.2.  ABNF Rules defined in other Parts of the Specification
298
299   The ABNF rules below are defined in other parts:
300
301     HTTP-date  = <HTTP-date, defined in [Part1], Section 6.1>
302
303
304     entity-tag = <entity-tag, defined in [Part4], Section 2.2>
305
3062.  Range Units
307
308   HTTP/1.1 allows a client to request that only part (a range) of the
309   representation be included within the response.  HTTP/1.1 uses range
310   units in the Range (Section 5.4) and Content-Range (Section 5.2)
311   header fields.  A representation can be broken down into subranges
312   according to various structural units.
313
314     range-unit       = bytes-unit / other-range-unit
315     bytes-unit       = "bytes"
316     other-range-unit = token
317
318   HTTP/1.1 has been designed to allow implementations of applications
319   that do not depend on knowledge of ranges.  The only range unit
320   defined by HTTP/1.1 is "bytes".  Additional specifiers can be defined
321   as described in Section 2.1.
322
323   If a range unit is not understood in a request, a server MUST ignore
324   the whole Range header field (Section 5.4).  If a range unit is not
325   understood in a response, an intermediary SHOULD pass the response to
326   the client; a client MUST fail.
327
3282.1.  Range Specifier Registry
329
330   The HTTP Range Specifier Registry defines the name space for the
331   range specifier names.
332
333
334
335Fielding, et al.        Expires January 12, 2012                [Page 6]
336
337Internet-Draft              HTTP/1.1, Part 5                   July 2011
338
339
340   Registrations MUST include the following fields:
341
342   o  Name
343
344   o  Description
345
346   o  Pointer to specification text
347
348   Values to be added to this name space are subject to IETF review
349   ([RFC5226], Section 4.1).
350
351   The registry itself is maintained at
352   <http://www.iana.org/assignments/http-range-specifiers>.
353
3543.  Status Code Definitions
355
3563.1.  206 Partial Content
357
358   The server has fulfilled the partial GET request for the resource.
359   The request MUST have included a Range header field (Section 5.4)
360   indicating the desired range, and MAY have included an If-Range
361   header field (Section 5.3) to make the request conditional.
362
363   The response MUST include the following header fields:
364
365   o  Either a Content-Range header field (Section 5.2) indicating the
366      range included with this response, or a multipart/byteranges
367      Content-Type including Content-Range fields for each part.  If a
368      Content-Length header field is present in the response, its value
369      MUST match the actual number of octets transmitted in the message-
370      body.
371
372   o  Date
373
374   o  Cache-Control, ETag, Expires, Content-Location, Last-Modified,
375      and/or Vary, if the header field would have been sent in a 200
376      response to the same request
377
378   If the 206 response is the result of an If-Range request, the
379   response SHOULD NOT include other representation header fields.
380   Otherwise, the response MUST include all of the representation header
381   fields that would have been returned with a 200 (OK) response to the
382   same request.
383
384   A cache MUST NOT combine a 206 response with other previously cached
385   content if the ETag or Last-Modified header fields do not match
386   exactly, see Section 4.
387
388
389
390
391Fielding, et al.        Expires January 12, 2012                [Page 7]
392
393Internet-Draft              HTTP/1.1, Part 5                   July 2011
394
395
396   A cache that does not support the Range and Content-Range header
397   fields MUST NOT cache 206 (Partial Content) responses.  Furthermore,
398   if a response uses a range unit that is not understood by the cache,
399   then it MUST NOT be cached either.
400
4013.2.  416 Requested Range Not Satisfiable
402
403   A server SHOULD return a response with this status code if a request
404   included a Range header field (Section 5.4), and none of the ranges-
405   specifier values in this field overlap the current extent of the
406   selected resource, and the request did not include an If-Range header
407   field (Section 5.3).  (For byte-ranges, this means that the first-
408   byte-pos of all of the byte-range-spec values were greater than the
409   current length of the selected resource.)
410
411   When this status code is returned for a byte-range request, the
412   response SHOULD include a Content-Range header field specifying the
413   current length of the representation (see Section 5.2).  This
414   response MUST NOT use the multipart/byteranges content-type.
415
4164.  Combining Ranges
417
418   A response might transfer only a subrange of a representation, either
419   because the request included one or more Range specifications, or
420   because a connection closed prematurely.  After several such
421   transfers, a cache might have received several ranges of the same
422   representation.
423
424   If a cache has a stored non-empty set of subranges for a
425   representation, and an incoming response transfers another subrange,
426   the cache MAY combine the new subrange with the existing set if both
427   the following conditions are met:
428
429   o  Both the incoming response and the cache entry have a cache
430      validator.
431
432   o  The two cache validators match using the strong comparison
433      function (see Section 2.2.2 of [Part4]).
434
435   If either requirement is not met, the cache MUST use only the most
436   recent partial response (based on the Date values transmitted with
437   every response, and using the incoming response if these values are
438   equal or missing), and MUST discard the other partial information.
439
4405.  Header Field Definitions
441
442   This section defines the syntax and semantics of HTTP/1.1 header
443   fields related to range requests and partial responses.
444
445
446
447Fielding, et al.        Expires January 12, 2012                [Page 8]
448
449Internet-Draft              HTTP/1.1, Part 5                   July 2011
450
451
4525.1.  Accept-Ranges
453
454   The "Accept-Ranges" header field allows a resource to indicate its
455   acceptance of range requests.
456
457     Accept-Ranges     = acceptable-ranges
458     acceptable-ranges = 1#range-unit / "none"
459
460   Origin servers that accept byte-range requests MAY send
461
462     Accept-Ranges: bytes
463
464   but are not required to do so.  Clients MAY generate range requests
465   without having received this header field for the resource involved.
466   Range units are defined in Section 2.
467
468   Servers that do not accept any kind of range request for a resource
469   MAY send
470
471     Accept-Ranges: none
472
473   to advise the client not to attempt a range request.
474
4755.2.  Content-Range
476
477   The "Content-Range" header field is sent with a partial
478   representation to specify where in the full representation the
479   payload body is intended to be applied.
480
481   Range units are defined in Section 2.
482
483     Content-Range = content-range-spec
484
485     content-range-spec      = byte-content-range-spec
486                             / other-content-range-spec
487     byte-content-range-spec = bytes-unit SP
488                               byte-range-resp-spec "/"
489                               ( instance-length / "*" )
490
491     byte-range-resp-spec    = (first-byte-pos "-" last-byte-pos)
492                             / "*"
493
494     instance-length         = 1*DIGIT
495
496     other-content-range-spec = other-range-unit SP
497                                other-range-resp-spec
498     other-range-resp-spec    = *CHAR
499
500
501
502
503Fielding, et al.        Expires January 12, 2012                [Page 9]
504
505Internet-Draft              HTTP/1.1, Part 5                   July 2011
506
507
508   The header field SHOULD indicate the total length of the full
509   representation, unless this length is unknown or difficult to
510   determine.  The asterisk "*" character means that the instance-length
511   is unknown at the time when the response was generated.
512
513   Unlike byte-ranges-specifier values (see Section 5.4.1), a byte-
514   range-resp-spec MUST only specify one range, and MUST contain
515   absolute byte positions for both the first and last byte of the
516   range.
517
518   A byte-content-range-spec with a byte-range-resp-spec whose last-
519   byte-pos value is less than its first-byte-pos value, or whose
520   instance-length value is less than or equal to its last-byte-pos
521   value, is invalid.  The recipient of an invalid byte-content-range-
522   spec MUST ignore it and any content transferred along with it.
523
524   In the case of a byte range request: A server sending a response with
525   status code 416 (Requested range not satisfiable) SHOULD include a
526   Content-Range field with a byte-range-resp-spec of "*".  The
527   instance-length specifies the current length of the selected
528   resource.  A response with status code 206 (Partial Content) MUST NOT
529   include a Content-Range field with a byte-range-resp-spec of "*".
530
531   Examples of byte-content-range-spec values, assuming that the
532   representation contains a total of 1234 bytes:
533
534   o  The first 500 bytes:
535
536        bytes 0-499/1234
537
538   o  The second 500 bytes:
539
540        bytes 500-999/1234
541
542   o  All except for the first 500 bytes:
543
544        bytes 500-1233/1234
545
546   o  The last 500 bytes:
547
548        bytes 734-1233/1234
549
550   When an HTTP message includes the content of a single range (for
551   example, a response to a request for a single range, or to a request
552   for a set of ranges that overlap without any holes), this content is
553   transmitted with a Content-Range header field, and a Content-Length
554   header field showing the number of bytes actually transferred.  For
555   example,
556
557
558
559Fielding, et al.        Expires January 12, 2012               [Page 10]
560
561Internet-Draft              HTTP/1.1, Part 5                   July 2011
562
563
564     HTTP/1.1 206 Partial Content
565     Date: Wed, 15 Nov 1995 06:25:24 GMT
566     Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
567     Content-Range: bytes 21010-47021/47022
568     Content-Length: 26012
569     Content-Type: image/gif
570
571   When an HTTP message includes the content of multiple ranges (for
572   example, a response to a request for multiple non-overlapping
573   ranges), these are transmitted as a multipart message.  The multipart
574   media type used for this purpose is "multipart/byteranges" as defined
575   in Appendix A.
576
577   A response to a request for a single range MUST NOT be sent using the
578   multipart/byteranges media type.  A response to a request for
579   multiple ranges, whose result is a single range, MAY be sent as a
580   multipart/byteranges media type with one part.  A client that cannot
581   decode a multipart/byteranges message MUST NOT ask for multiple
582   ranges in a single request.
583
584   When a client requests multiple ranges in one request, the server
585   SHOULD return them in the order that they appeared in the request.
586
587   If the server ignores a byte-range-spec because it is syntactically
588   invalid, the server SHOULD treat the request as if the invalid Range
589   header field did not exist.  (Normally, this means return a 200
590   response containing the full representation).
591
592   If the server receives a request (other than one including an If-
593   Range header field) with an unsatisfiable Range header field (that
594   is, all of whose byte-range-spec values have a first-byte-pos value
595   greater than the current length of the selected resource), it SHOULD
596   return a response code of 416 (Requested range not satisfiable)
597   (Section 3.2).
598
599      Note: Clients cannot depend on servers to send a 416 (Requested
600      range not satisfiable) response instead of a 200 (OK) response for
601      an unsatisfiable Range header field, since not all servers
602      implement this header field.
603
6045.3.  If-Range
605
606   If a client has a partial copy of a representation in its cache, and
607   wishes to have an up-to-date copy of the entire representation in its
608   cache, it could use the Range header field with a conditional GET
609   (using either or both of If-Unmodified-Since and If-Match.)  However,
610   if the condition fails because the representation has been modified,
611   the client would then have to make a second request to obtain the
612
613
614
615Fielding, et al.        Expires January 12, 2012               [Page 11]
616
617Internet-Draft              HTTP/1.1, Part 5                   July 2011
618
619
620   entire current representation.
621
622   The "If-Range" header field allows a client to "short-circuit" the
623   second request.  Informally, its meaning is "if the representation is
624   unchanged, send me the part(s) that I am missing; otherwise, send me
625   the entire new representation".
626
627     If-Range = entity-tag / HTTP-date
628
629   Only a strong validator (Section 2.2.2 of [Part4]) is usable for
630   range retrieval, since otherwise the client might end up with an
631   internally inconsistent representation.  Clients MUST NOT use weak
632   validators in range requests.  A cache or origin server receiving a
633   conditional range request MUST use the strong comparison function to
634   evaluate the condition.
635
636   If the client has no entity-tag for a representation, but does have a
637   Last-Modified date, it MAY use that date in an If-Range header field.
638   (The server can distinguish between a valid HTTP-date and any form of
639   entity-tag by examining no more than two characters.)  The If-Range
640   header field SHOULD only be used together with a Range header field,
641   and MUST be ignored if the request does not include a Range header
642   field, or if the server does not support the sub-range operation.
643
644   If a client wishes to perform a sub-range retrieval on a value for
645   which it has only a Last-Modified time and no opaque validator, it
646   MAY do this only if the Last-Modified time is strong in the sense
647   described in Section 2.1.2 of [Part4].
648
649   If the entity-tag given in the If-Range header field matches the
650   current cache validator for the representation, then the server
651   SHOULD provide the specified sub-range of the representation using a
652   206 (Partial Content) response.  If the cache validator does not
653   match, then the server SHOULD return the entire representation using
654   a 200 (OK) response.
655
6565.4.  Range
657
6585.4.1.  Byte Ranges
659
660   Since all HTTP representations are transferred as sequences of bytes,
661   the concept of a byte range is meaningful for any HTTP
662   representation.  (However, not all clients and servers need to
663   support byte-range operations.)
664
665   Byte range specifications in HTTP apply to the sequence of bytes in
666   the representation body (not necessarily the same as the message-
667   body).
668
669
670
671Fielding, et al.        Expires January 12, 2012               [Page 12]
672
673Internet-Draft              HTTP/1.1, Part 5                   July 2011
674
675
676   A byte range operation MAY specify a single range of bytes, or a set
677   of ranges within a single representation.
678
679     byte-ranges-specifier = bytes-unit "=" byte-range-set
680     byte-range-set  = 1#( byte-range-spec / suffix-byte-range-spec )
681     byte-range-spec = first-byte-pos "-" [ last-byte-pos ]
682     first-byte-pos  = 1*DIGIT
683     last-byte-pos   = 1*DIGIT
684
685   The first-byte-pos value in a byte-range-spec gives the byte-offset
686   of the first byte in a range.  The last-byte-pos value gives the
687   byte-offset of the last byte in the range; that is, the byte
688   positions specified are inclusive.  Byte offsets start at zero.
689
690   If the last-byte-pos value is present, it MUST be greater than or
691   equal to the first-byte-pos in that byte-range-spec, or the byte-
692   range-spec is syntactically invalid.  The recipient of a byte-range-
693   set that includes one or more syntactically invalid byte-range-spec
694   values MUST ignore the header field that includes that byte-range-
695   set.
696
697   If the last-byte-pos value is absent, or if the value is greater than
698   or equal to the current length of the representation body, last-byte-
699   pos is taken to be equal to one less than the current length of the
700   representation in bytes.
701
702   By its choice of last-byte-pos, a client can limit the number of
703   bytes retrieved without knowing the size of the representation.
704
705     suffix-byte-range-spec = "-" suffix-length
706     suffix-length = 1*DIGIT
707
708   A suffix-byte-range-spec is used to specify the suffix of the
709   representation body, of a length given by the suffix-length value.
710   (That is, this form specifies the last N bytes of a representation.)
711   If the representation is shorter than the specified suffix-length,
712   the entire representation is used.
713
714   If a syntactically valid byte-range-set includes at least one byte-
715   range-spec whose first-byte-pos is less than the current length of
716   the representation, or at least one suffix-byte-range-spec with a
717   non-zero suffix-length, then the byte-range-set is satisfiable.
718   Otherwise, the byte-range-set is unsatisfiable.  If the byte-range-
719   set is unsatisfiable, the server SHOULD return a response with a 416
720   (Requested range not satisfiable) status code.  Otherwise, the server
721   SHOULD return a response with a 206 (Partial Content) status code
722   containing the satisfiable ranges of the representation.
723
724
725
726
727Fielding, et al.        Expires January 12, 2012               [Page 13]
728
729Internet-Draft              HTTP/1.1, Part 5                   July 2011
730
731
732   Examples of byte-ranges-specifier values (assuming a representation
733   of length 10000):
734
735   o  The first 500 bytes (byte offsets 0-499, inclusive):
736
737        bytes=0-499
738
739   o  The second 500 bytes (byte offsets 500-999, inclusive):
740
741        bytes=500-999
742
743   o  The final 500 bytes (byte offsets 9500-9999, inclusive):
744
745        bytes=-500
746
747      Or:
748
749        bytes=9500-
750
751   o  The first and last bytes only (bytes 0 and 9999):
752
753        bytes=0-0,-1
754
755   o  Several legal but not canonical specifications of the second 500
756      bytes (byte offsets 500-999, inclusive):
757
758        bytes=500-600,601-999
759        bytes=500-700,601-999
760
7615.4.2.  Range Retrieval Requests
762
763   The "Range" header field defines the GET method (conditional or not)
764   to request one or more sub-ranges of the response representation
765   body, instead of the entire representation body.
766
767     Range = byte-ranges-specifier / other-ranges-specifier
768     other-ranges-specifier = other-range-unit "=" other-range-set
769     other-range-set = 1*CHAR
770
771   A server MAY ignore the Range header field.  However, HTTP/1.1 origin
772   servers and intermediate caches ought to support byte ranges when
773   possible, since Range supports efficient recovery from partially
774   failed transfers, and supports efficient partial retrieval of large
775   representations.
776
777   If the server supports the Range header field and the specified range
778   or ranges are appropriate for the representation:
779
780
781
782
783Fielding, et al.        Expires January 12, 2012               [Page 14]
784
785Internet-Draft              HTTP/1.1, Part 5                   July 2011
786
787
788   o  The presence of a Range header field in an unconditional GET
789      modifies what is returned if the GET is otherwise successful.  In
790      other words, the response carries a status code of 206 (Partial
791      Content) instead of 200 (OK).
792
793   o  The presence of a Range header field in a conditional GET (a
794      request using one or both of If-Modified-Since and If-None-Match,
795      or one or both of If-Unmodified-Since and If-Match) modifies what
796      is returned if the GET is otherwise successful and the condition
797      is true.  It does not affect the 304 (Not Modified) response
798      returned if the conditional is false.
799
800   In some cases, it might be more appropriate to use the If-Range
801   header field (see Section 5.3) in addition to the Range header field.
802
803   If a proxy that supports ranges receives a Range request, forwards
804   the request to an inbound server, and receives an entire
805   representation in reply, it MAY only return the requested range to
806   its client.
807
8086.  IANA Considerations
809
8106.1.  Status Code Registration
811
812   The HTTP Status Code Registry located at
813   <http://www.iana.org/assignments/http-status-codes> shall be updated
814   with the registrations below:
815
816   +-------+---------------------------------+-------------+
817   | Value | Description                     | Reference   |
818   +-------+---------------------------------+-------------+
819   | 206   | Partial Content                 | Section 3.1 |
820   | 416   | Requested Range Not Satisfiable | Section 3.2 |
821   +-------+---------------------------------+-------------+
822
8236.2.  Header Field Registration
824
825   The Message Header Field Registry located at <http://www.iana.org/
826   assignments/message-headers/message-header-index.html> shall be
827   updated with the permanent registrations below (see [RFC3864]):
828
829
830
831
832
833
834
835
836
837
838
839Fielding, et al.        Expires January 12, 2012               [Page 15]
840
841Internet-Draft              HTTP/1.1, Part 5                   July 2011
842
843
844   +-------------------+----------+----------+-------------+
845   | Header Field Name | Protocol | Status   | Reference   |
846   +-------------------+----------+----------+-------------+
847   | Accept-Ranges     | http     | standard | Section 5.1 |
848   | Content-Range     | http     | standard | Section 5.2 |
849   | If-Range          | http     | standard | Section 5.3 |
850   | Range             | http     | standard | Section 5.4 |
851   +-------------------+----------+----------+-------------+
852
853   The change controller is: "IETF (iesg@ietf.org) - Internet
854   Engineering Task Force".
855
8566.3.  Range Specifier Registration
857
858   The registration procedure for HTTP Range Specifiers is defined by
859   Section 2.1 of this document.
860
861   The HTTP Range Specifier Registry shall be created at
862   <http://www.iana.org/assignments/http-range-specifiers> and be
863   populated with the registrations below:
864
865   +----------------------+-------------------+----------------------+
866   | Range Specifier Name | Description       | Reference            |
867   +----------------------+-------------------+----------------------+
868   | bytes                | a range of octets | (this specification) |
869   +----------------------+-------------------+----------------------+
870
871   The change controller is: "IETF (iesg@ietf.org) - Internet
872   Engineering Task Force".
873
8747.  Security Considerations
875
876   No additional security considerations have been identified beyond
877   those applicable to HTTP in general [Part1].
878
8798.  Acknowledgments
880
881   Most of the specification of ranges is based on work originally done
882   by Ari Luotonen and John Franks, with additional input from Steve
883   Zilles, Daniel W. Connolly, Roy T. Fielding, Jim Gettys, Martin
884   Hamilton, Koen Holtman, Shel Kaplan, Paul Leach, Alex Lopez-Ortiz,
885   Larry Masinter, Jeff Mogul, Lou Montulli, David W. Morris, Luigi
886   Rizzo, and Bill Weihl.
887
8889.  References
889
890
891
892
893
894
895Fielding, et al.        Expires January 12, 2012               [Page 16]
896
897Internet-Draft              HTTP/1.1, Part 5                   July 2011
898
899
9009.1.  Normative References
901
902   [Part1]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
903              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
904              and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
905              and Message Parsing", draft-ietf-httpbis-p1-messaging-15
906              (work in progress), July 2011.
907
908   [Part4]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
909              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
910              and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional
911              Requests", draft-ietf-httpbis-p4-conditional-15 (work in
912              progress), July 2011.
913
914   [RFC2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
915              Extensions (MIME) Part Two: Media Types", RFC 2046,
916              November 1996.
917
918   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
919              Requirement Levels", BCP 14, RFC 2119, March 1997.
920
921   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
922              Specifications: ABNF", STD 68, RFC 5234, January 2008.
923
9249.2.  Informative References
925
926   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
927              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
928              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
929
930   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
931              Procedures for Message Header Fields", BCP 90, RFC 3864,
932              September 2004.
933
934   [RFC4288]  Freed, N. and J. Klensin, "Media Type Specifications and
935              Registration Procedures", BCP 13, RFC 4288, December 2005.
936
937   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
938              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
939              May 2008.
940
941Appendix A.  Internet Media Type multipart/byteranges
942
943   When an HTTP 206 (Partial Content) response message includes the
944   content of multiple ranges (a response to a request for multiple non-
945   overlapping ranges), these are transmitted as a multipart message-
946   body ([RFC2046], Section 5.1).  The media type for this purpose is
947   called "multipart/byteranges".  The following is to be registered
948
949
950
951Fielding, et al.        Expires January 12, 2012               [Page 17]
952
953Internet-Draft              HTTP/1.1, Part 5                   July 2011
954
955
956   with IANA [RFC4288].
957
958      Note: Despite the name "multipart/byteranges" is not limited to
959      the byte ranges only.
960
961   The multipart/byteranges media type includes one or more parts, each
962   with its own Content-Type and Content-Range fields.  The required
963   boundary parameter specifies the boundary string used to separate
964   each body-part.
965
966   Type name:  multipart
967
968   Subtype name:  byteranges
969
970   Required parameters:  boundary
971
972   Optional parameters:  none
973
974   Encoding considerations:  only "7bit", "8bit", or "binary" are
975      permitted
976
977   Security considerations:  none
978
979   Interoperability considerations:  none
980
981   Published specification:  This specification (see Appendix A).
982
983   Applications that use this media type:
984
985   Additional information:
986
987      Magic number(s):  none
988
989      File extension(s):  none
990
991      Macintosh file type code(s):  none
992
993   Person and email address to contact for further information:  See
994      Authors Section.
995
996   Intended usage:  COMMON
997
998   Restrictions on usage:  none
999
1000   Author/Change controller:  IESG
1001
1002
1003
1004
1005
1006
1007Fielding, et al.        Expires January 12, 2012               [Page 18]
1008
1009Internet-Draft              HTTP/1.1, Part 5                   July 2011
1010
1011
1012   For example:
1013
1014     HTTP/1.1 206 Partial Content
1015     Date: Wed, 15 Nov 1995 06:25:24 GMT
1016     Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
1017     Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
1018
1019     --THIS_STRING_SEPARATES
1020     Content-type: application/pdf
1021     Content-range: bytes 500-999/8000
1022
1023     ...the first range...
1024     --THIS_STRING_SEPARATES
1025     Content-type: application/pdf
1026     Content-range: bytes 7000-7999/8000
1027
1028     ...the second range
1029     --THIS_STRING_SEPARATES--
1030
1031   Other example:
1032
1033     HTTP/1.1 206 Partial Content
1034     Date: Tue, 14 Nov 1995 06:25:24 GMT
1035     Last-Modified: Tue, 14 July 04:58:08 GMT
1036     Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
1037
1038     --THIS_STRING_SEPARATES
1039     Content-type: video/example
1040     Content-range: exampleunit 1.2-4.3/25
1041
1042     ...the first range...
1043     --THIS_STRING_SEPARATES
1044     Content-type: video/example
1045     Content-range: exampleunit 11.2-14.3/25
1046
1047     ...the second range
1048     --THIS_STRING_SEPARATES--
1049
1050   Notes:
1051
1052   1.  Additional CRLFs MAY precede the first boundary string in the
1053       body.
1054
1055   2.  Although [RFC2046] permits the boundary string to be quoted, some
1056       existing implementations handle a quoted boundary string
1057       incorrectly.
1058
1059
1060
1061
1062
1063Fielding, et al.        Expires January 12, 2012               [Page 19]
1064
1065Internet-Draft              HTTP/1.1, Part 5                   July 2011
1066
1067
1068   3.  A number of browsers and servers were coded to an early draft of
1069       the byteranges specification to use a media type of multipart/
1070       x-byteranges, which is almost, but not quite compatible with the
1071       version documented in HTTP/1.1.
1072
1073Appendix B.  Compatibility with Previous Versions
1074
1075B.1.  Changes from RFC 2616
1076
1077   Clarify that it is not ok to use a weak cache validator in a 206
1078   response.  (Section 3.1)
1079
1080   Change ABNF productions for header fields to only define the field
1081   value.  (Section 5)
1082
1083   Clarify that multipart/byteranges can consist of a single part.
1084   (Appendix A)
1085
1086Appendix C.  Collected ABNF
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 January 12, 2012               [Page 20]
1120
1121Internet-Draft              HTTP/1.1, Part 5                   July 2011
1122
1123
1124   Accept-Ranges = acceptable-ranges
1125
1126   Content-Range = content-range-spec
1127
1128   HTTP-date = <HTTP-date, defined in [Part1], Section 6.1>
1129
1130   If-Range = entity-tag / HTTP-date
1131
1132   OWS = <OWS, defined in [Part1], Section 1.2.2>
1133
1134   Range = byte-ranges-specifier / other-ranges-specifier
1135
1136   acceptable-ranges = ( *( "," OWS ) range-unit *( OWS "," [ OWS
1137    range-unit ] ) ) / "none"
1138
1139   byte-content-range-spec = bytes-unit SP byte-range-resp-spec "/" (
1140    instance-length / "*" )
1141   byte-range-resp-spec = ( first-byte-pos "-" last-byte-pos ) / "*"
1142   byte-range-set = ( *( "," OWS ) byte-range-spec ) / (
1143    suffix-byte-range-spec *( OWS "," [ ( OWS byte-range-spec ) /
1144    suffix-byte-range-spec ] ) )
1145   byte-range-spec = first-byte-pos "-" [ last-byte-pos ]
1146   byte-ranges-specifier = bytes-unit "=" byte-range-set
1147   bytes-unit = "bytes"
1148
1149   content-range-spec = byte-content-range-spec /
1150    other-content-range-spec
1151
1152   entity-tag = <entity-tag, defined in [Part4], Section 2.2>
1153
1154   first-byte-pos = 1*DIGIT
1155
1156   instance-length = 1*DIGIT
1157
1158   last-byte-pos = 1*DIGIT
1159
1160   other-content-range-spec = other-range-unit SP other-range-resp-spec
1161   other-range-resp-spec = *CHAR
1162   other-range-set = 1*CHAR
1163   other-range-unit = token
1164   other-ranges-specifier = other-range-unit "=" other-range-set
1165
1166   range-unit = bytes-unit / other-range-unit
1167
1168   suffix-byte-range-spec = "-" suffix-length
1169   suffix-length = 1*DIGIT
1170
1171   token = <token, defined in [Part1], Section 1.2.2>
1172
1173
1174
1175Fielding, et al.        Expires January 12, 2012               [Page 21]
1176
1177Internet-Draft              HTTP/1.1, Part 5                   July 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 January 12, 2012               [Page 22]
1232
1233Internet-Draft              HTTP/1.1, Part 5                   July 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 January 12, 2012               [Page 23]
1288
1289Internet-Draft              HTTP/1.1, Part 5                   July 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 January 12, 2012               [Page 24]
1344
1345Internet-Draft              HTTP/1.1, Part 5                   July 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
1366Index
1367
1368   2
1369      206 Partial Content (status code)  7
1370
1371   4
1372      416 Requested Range Not Satisfiable (status code)  8
1373
1374   A
1375      Accept-Ranges header field  9
1376
1377   C
1378      Content-Range header field  9
1379
1380   G
1381      Grammar
1382         Accept-Ranges  9
1383         acceptable-ranges  9
1384         byte-content-range-spec  9
1385         byte-range-resp-spec  9
1386         byte-range-set  13
1387         byte-range-spec  13
1388         byte-ranges-specifier  13
1389         bytes-unit  6
1390         Content-Range  9
1391         content-range-spec  9
1392         first-byte-pos  13
1393         If-Range  12
1394         instance-length  9
1395         last-byte-pos  13
1396
1397
1398
1399Fielding, et al.        Expires January 12, 2012               [Page 25]
1400
1401Internet-Draft              HTTP/1.1, Part 5                   July 2011
1402
1403
1404         other-range-unit  6
1405         Range  14
1406         range-unit  6
1407         ranges-specifier  13
1408         suffix-byte-range-spec  13
1409         suffix-length  13
1410
1411   H
1412      Header Fields
1413         Accept-Ranges  9
1414         Content-Range  9
1415         If-Range  11
1416         Range  12
1417
1418   I
1419      If-Range header field  11
1420
1421   M
1422      Media Type
1423         multipart/byteranges  17
1424         multipart/x-byteranges  20
1425      multipart/byteranges Media Type  17
1426      multipart/x-byteranges Media Type  20
1427
1428   R
1429      Range header field  12
1430
1431   S
1432      Status Codes
1433         206 Partial Content  7
1434         416 Requested Range Not Satisfiable  8
1435
1436Authors' Addresses
1437
1438   Roy T. Fielding (editor)
1439   Adobe Systems Incorporated
1440   345 Park Ave
1441   San Jose, CA  95110
1442   USA
1443
1444   EMail: fielding@gbiv.com
1445   URI:   http://roy.gbiv.com/
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455Fielding, et al.        Expires January 12, 2012               [Page 26]
1456
1457Internet-Draft              HTTP/1.1, Part 5                   July 2011
1458
1459
1460   Jim Gettys
1461   Alcatel-Lucent Bell Labs
1462   21 Oak Knoll Road
1463   Carlisle, MA  01741
1464   USA
1465
1466   EMail: jg@freedesktop.org
1467   URI:   http://gettys.wordpress.com/
1468
1469
1470   Jeffrey C. Mogul
1471   Hewlett-Packard Company
1472   HP Labs, Large Scale Systems Group
1473   1501 Page Mill Road, MS 1177
1474   Palo Alto, CA  94304
1475   USA
1476
1477   EMail: JeffMogul@acm.org
1478
1479
1480   Henrik Frystyk Nielsen
1481   Microsoft Corporation
1482   1 Microsoft Way
1483   Redmond, WA  98052
1484   USA
1485
1486   EMail: henrikn@microsoft.com
1487
1488
1489   Larry Masinter
1490   Adobe Systems Incorporated
1491   345 Park Ave
1492   San Jose, CA  95110
1493   USA
1494
1495   EMail: LMM@acm.org
1496   URI:   http://larry.masinter.net/
1497
1498
1499   Paul J. Leach
1500   Microsoft Corporation
1501   1 Microsoft Way
1502   Redmond, WA  98052
1503
1504   EMail: paulle@microsoft.com
1505
1506
1507
1508
1509
1510
1511Fielding, et al.        Expires January 12, 2012               [Page 27]
1512
1513Internet-Draft              HTTP/1.1, Part 5                   July 2011
1514
1515
1516   Tim Berners-Lee
1517   World Wide Web Consortium
1518   MIT Computer Science and Artificial Intelligence Laboratory
1519   The Stata Center, Building 32
1520   32 Vassar Street
1521   Cambridge, MA  02139
1522   USA
1523
1524   EMail: timbl@w3.org
1525   URI:   http://www.w3.org/People/Berners-Lee/
1526
1527
1528   Yves Lafon (editor)
1529   World Wide Web Consortium
1530   W3C / ERCIM
1531   2004, rte des Lucioles
1532   Sophia-Antipolis, AM  06902
1533   France
1534
1535   EMail: ylafon@w3.org
1536   URI:   http://www.raubacapeu.net/people/yves/
1537
1538
1539   Julian F. Reschke (editor)
1540   greenbytes GmbH
1541   Hafenweg 16
1542   Muenster, NW  48155
1543   Germany
1544
1545   Phone: +49 251 2807760
1546   Fax:   +49 251 2807761
1547   EMail: julian.reschke@greenbytes.de
1548   URI:   http://greenbytes.de/tech/webdav/
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567Fielding, et al.        Expires January 12, 2012               [Page 28]
1568
Note: See TracBrowser for help on using the repository browser.