source: draft-ietf-httpbis/18/draft-ietf-httpbis-p5-range-18.txt @ 1840

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

prepare for publication of -18 on Jan 04.

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