source: draft-ietf-httpbis/19/draft-ietf-httpbis-p5-range-19.txt @ 2673

Last change on this file since 2673 was 1596, checked in by fielding@…, 8 years ago

remove executable bit

  • Property svn:eol-style set to native
File size: 51.2 KB
Line 
1
2
3
4HTTPbis Working Group                                   R. Fielding, Ed.
5Internet-Draft                                                     Adobe
6Obsoletes: 2616 (if approved)                              Y. Lafon, Ed.
7Intended status: Standards Track                                     W3C
8Expires: September 13, 2012                              J. Reschke, Ed.
9                                                              greenbytes
10                                                          March 12, 2012
11
12
13         HTTP/1.1, part 5: Range Requests and Partial Responses
14                     draft-ietf-httpbis-p5-range-19
15
16Abstract
17
18   The Hypertext Transfer Protocol (HTTP) is an application-level
19   protocol for distributed, collaborative, hypertext information
20   systems.  HTTP has been in use by the World Wide Web global
21   information initiative since 1990.  This document is Part 5 of the
22   seven-part specification that defines the protocol referred to as
23   "HTTP/1.1" and, taken together, obsoletes RFC 2616.
24
25   Part 5 defines range-specific requests and the rules for constructing
26   and combining responses to those requests.
27
28Editorial Note (To be removed by RFC Editor)
29
30   Discussion of this draft should take place on the HTTPBIS working
31   group mailing list (ietf-http-wg@w3.org), which is archived at
32   <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
33
34   The current issues list is at
35   <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
36   documents (including fancy diffs) can be found at
37   <http://tools.ietf.org/wg/httpbis/>.
38
39   The changes in this draft are summarized in Appendix D.20.
40
41Status of This Memo
42
43   This Internet-Draft is submitted in full conformance with the
44   provisions of BCP 78 and BCP 79.
45
46   Internet-Drafts are working documents of the Internet Engineering
47   Task Force (IETF).  Note that other groups may also distribute
48   working documents as Internet-Drafts.  The list of current Internet-
49   Drafts is at http://datatracker.ietf.org/drafts/current/.
50
51   Internet-Drafts are draft documents valid for a maximum of six months
52
53
54
55Fielding, et al.       Expires September 13, 2012               [Page 1]
56
57Internet-Draft              HTTP/1.1, Part 5                  March 2012
58
59
60   and may be updated, replaced, or obsoleted by other documents at any
61   time.  It is inappropriate to use Internet-Drafts as reference
62   material or to cite them other than as "work in progress."
63
64   This Internet-Draft will expire on September 13, 2012.
65
66Copyright Notice
67
68   Copyright (c) 2012 IETF Trust and the persons identified as the
69   document authors.  All rights reserved.
70
71   This document is subject to BCP 78 and the IETF Trust's Legal
72   Provisions Relating to IETF Documents
73   (http://trustee.ietf.org/license-info) in effect on the date of
74   publication of this document.  Please review these documents
75   carefully, as they describe your rights and restrictions with respect
76   to this document.  Code Components extracted from this document must
77   include Simplified BSD License text as described in Section 4.e of
78   the Trust Legal Provisions and are provided without warranty as
79   described in the Simplified BSD License.
80
81   This document may contain material from IETF Documents or IETF
82   Contributions published or made publicly available before November
83   10, 2008.  The person(s) controlling the copyright in some of this
84   material may not have granted the IETF Trust the right to allow
85   modifications of such material outside the IETF Standards Process.
86   Without obtaining an adequate license from the person(s) controlling
87   the copyright in such materials, this document may not be modified
88   outside the IETF Standards Process, and derivative works of it may
89   not be created outside the IETF Standards Process, except to format
90   it for publication as an RFC or to translate it into languages other
91   than English.
92
93Table of Contents
94
95   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
96     1.1.  Conformance and Error Handling . . . . . . . . . . . . . .  4
97     1.2.  Syntax Notation  . . . . . . . . . . . . . . . . . . . . .  5
98       1.2.1.  Core Rules . . . . . . . . . . . . . . . . . . . . . .  5
99       1.2.2.  ABNF Rules defined in other Parts of the
100               Specification  . . . . . . . . . . . . . . . . . . . .  5
101   2.  Range Units  . . . . . . . . . . . . . . . . . . . . . . . . .  5
102     2.1.  Range Specifier Registry . . . . . . . . . . . . . . . . .  6
103   3.  Status Code Definitions  . . . . . . . . . . . . . . . . . . .  6
104     3.1.  206 Partial Content  . . . . . . . . . . . . . . . . . . .  6
105     3.2.  416 Requested Range Not Satisfiable  . . . . . . . . . . .  7
106   4.  Responses to a Range Request . . . . . . . . . . . . . . . . .  7
107     4.1.  Response to a Single and Multiple Ranges Request . . . . .  7
108
109
110
111Fielding, et al.       Expires September 13, 2012               [Page 2]
112
113Internet-Draft              HTTP/1.1, Part 5                  March 2012
114
115
116     4.2.  Combining Ranges . . . . . . . . . . . . . . . . . . . . .  8
117   5.  Header Field Definitions . . . . . . . . . . . . . . . . . . .  9
118     5.1.  Accept-Ranges  . . . . . . . . . . . . . . . . . . . . . .  9
119     5.2.  Content-Range  . . . . . . . . . . . . . . . . . . . . . . 10
120     5.3.  If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 11
121     5.4.  Range  . . . . . . . . . . . . . . . . . . . . . . . . . . 12
122       5.4.1.  Byte Ranges  . . . . . . . . . . . . . . . . . . . . . 12
123       5.4.2.  Range Retrieval Requests . . . . . . . . . . . . . . . 14
124   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
125     6.1.  Status Code Registration . . . . . . . . . . . . . . . . . 15
126     6.2.  Header Field Registration  . . . . . . . . . . . . . . . . 15
127     6.3.  Range Specifier Registration . . . . . . . . . . . . . . . 16
128   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
129     7.1.  Overlapping Ranges . . . . . . . . . . . . . . . . . . . . 16
130   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 16
131   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
132     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 16
133     9.2.  Informative References . . . . . . . . . . . . . . . . . . 17
134   Appendix A.  Internet Media Type multipart/byteranges  . . . . . . 17
135   Appendix B.  Changes from RFC 2616 . . . . . . . . . . . . . . . . 20
136   Appendix C.  Collected ABNF  . . . . . . . . . . . . . . . . . . . 21
137   Appendix D.  Change Log (to be removed by RFC Editor before
138                publication)  . . . . . . . . . . . . . . . . . . . . 22
139     D.1.  Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 22
140     D.2.  Since draft-ietf-httpbis-p5-range-00 . . . . . . . . . . . 22
141     D.3.  Since draft-ietf-httpbis-p5-range-01 . . . . . . . . . . . 22
142     D.4.  Since draft-ietf-httpbis-p5-range-02 . . . . . . . . . . . 22
143     D.5.  Since draft-ietf-httpbis-p5-range-03 . . . . . . . . . . . 23
144     D.6.  Since draft-ietf-httpbis-p5-range-04 . . . . . . . . . . . 23
145     D.7.  Since draft-ietf-httpbis-p5-range-05 . . . . . . . . . . . 23
146     D.8.  Since draft-ietf-httpbis-p5-range-06 . . . . . . . . . . . 23
147     D.9.  Since draft-ietf-httpbis-p5-range-07 . . . . . . . . . . . 24
148     D.10. Since draft-ietf-httpbis-p5-range-08 . . . . . . . . . . . 24
149     D.11. Since draft-ietf-httpbis-p5-range-09 . . . . . . . . . . . 24
150     D.12. Since draft-ietf-httpbis-p5-range-10 . . . . . . . . . . . 24
151     D.13. Since draft-ietf-httpbis-p5-range-11 . . . . . . . . . . . 24
152     D.14. Since draft-ietf-httpbis-p5-range-12 . . . . . . . . . . . 25
153     D.15. Since draft-ietf-httpbis-p5-range-13 . . . . . . . . . . . 25
154     D.16. Since draft-ietf-httpbis-p5-range-14 . . . . . . . . . . . 25
155     D.17. Since draft-ietf-httpbis-p5-range-15 . . . . . . . . . . . 25
156     D.18. Since draft-ietf-httpbis-p5-range-16 . . . . . . . . . . . 25
157     D.19. Since draft-ietf-httpbis-p5-range-17 . . . . . . . . . . . 25
158     D.20. Since draft-ietf-httpbis-p5-range-18 . . . . . . . . . . . 25
159   Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
160
161
162
163
164
165
166
167Fielding, et al.       Expires September 13, 2012               [Page 3]
168
169Internet-Draft              HTTP/1.1, Part 5                  March 2012
170
171
1721.  Introduction
173
174   HTTP clients often encounter interrupted data transfers as a result
175   of cancelled requests or dropped connections.  When a client has
176   stored a partial representation, it is desirable to request the
177   remainder of that representation in a subsequent request rather than
178   transfer the entire representation.  There are also a number of Web
179   applications that benefit from being able to request only a subset of
180   a larger representation, such as a single page of a very large
181   document or only part of an image to be rendered by a device with
182   limited local storage.
183
184   This document defines HTTP/1.1 range requests, partial responses, and
185   the multipart/byteranges media type.  The protocol for range requests
186   is an OPTIONAL feature of HTTP, designed so resources or recipients
187   that do not implement this feature can respond as if it is a normal
188   GET request without impacting interoperability.  Partial responses
189   are indicated by a distinct status code to not be mistaken for full
190   responses by intermediate caches that might not implement the
191   feature.
192
193   Although the HTTP range request mechanism is designed to allow for
194   extensible range types, this specification only defines requests for
195   byte ranges.
196
1971.1.  Conformance and Error Handling
198
199   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
200   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
201   document are to be interpreted as described in [RFC2119].
202
203   This document defines conformance criteria for several roles in HTTP
204   communication, including Senders, Recipients, Clients, Servers, User-
205   Agents, Origin Servers, Intermediaries, Proxies and Gateways.  See
206   Section 2 of [Part1] for definitions of these terms.
207
208   An implementation is considered conformant if it complies with all of
209   the requirements associated with its role(s).  Note that SHOULD-level
210   requirements are relevant here, unless one of the documented
211   exceptions is applicable.
212
213   This document also uses ABNF to define valid protocol elements
214   (Section 1.2).  In addition to the prose requirements placed upon
215   them, Senders MUST NOT generate protocol elements that are invalid.
216
217   Unless noted otherwise, Recipients MAY take steps to recover a usable
218   protocol element from an invalid construct.  However, HTTP does not
219   define specific error handling mechanisms, except in cases where it
220
221
222
223Fielding, et al.       Expires September 13, 2012               [Page 4]
224
225Internet-Draft              HTTP/1.1, Part 5                  March 2012
226
227
228   has direct impact on security.  This is because different uses of the
229   protocol require different error handling strategies; for example, a
230   Web browser may wish to transparently recover from a response where
231   the Location header field doesn't parse according to the ABNF,
232   whereby in a systems control protocol using HTTP, this type of error
233   recovery could lead to dangerous consequences.
234
2351.2.  Syntax Notation
236
237   This specification uses the Augmented Backus-Naur Form (ABNF)
238   notation of [RFC5234] with the list rule extension defined in Section
239   1.2 of [Part1].  Appendix C shows the collected ABNF with the list
240   rule expanded.
241
242   The following core rules are included by reference, as defined in
243   [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
244   (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
245   HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit
246   sequence of data), SP (space), and VCHAR (any visible US-ASCII
247   character).
248
249   Note that all rules derived from token are to be compared case-
250   insensitively, like range-unit and acceptable-ranges.
251
2521.2.1.  Core Rules
253
254   The core rules below are defined in [Part1] and [Part2]:
255
256     OWS        = <OWS, defined in [Part1], Section 3.2.1>
257     token      = <token, defined in [Part1], Section 3.2.4>
258     HTTP-date  = <HTTP-date, defined in [Part2], Section 8>
259
2601.2.2.  ABNF Rules defined in other Parts of the Specification
261
262   The ABNF rules below are defined in other parts:
263
264     entity-tag = <entity-tag, defined in [Part4], Section 2.3>
265
2662.  Range Units
267
268   HTTP/1.1 allows a client to request that only part (a range) of the
269   representation be included within the response.  HTTP/1.1 uses range
270   units in the Range (Section 5.4) and Content-Range (Section 5.2)
271   header fields.  A representation can be broken down into subranges
272   according to various structural units.
273
274     range-unit       = bytes-unit / other-range-unit
275     bytes-unit       = "bytes"
276
277
278
279Fielding, et al.       Expires September 13, 2012               [Page 5]
280
281Internet-Draft              HTTP/1.1, Part 5                  March 2012
282
283
284     other-range-unit = token
285
286   HTTP/1.1 has been designed to allow implementations of applications
287   that do not depend on knowledge of ranges.  The only range unit
288   defined by HTTP/1.1 is "bytes".  Additional specifiers can be defined
289   as described in Section 2.1.
290
291   If a range unit is not understood in a request, a server MUST ignore
292   the whole Range header field (Section 5.4).  If a range unit is not
293   understood in a response, an intermediary SHOULD pass the response to
294   the client; a client MUST fail.
295
2962.1.  Range Specifier Registry
297
298   The HTTP Range Specifier Registry defines the name space for the
299   range specifier names.
300
301   Registrations MUST include the following fields:
302
303   o  Name
304
305   o  Description
306
307   o  Pointer to specification text
308
309   Values to be added to this name space require IETF Review (see
310   [RFC5226], Section 4.1).
311
312   The registry itself is maintained at
313   <http://www.iana.org/assignments/http-range-specifiers>.
314
3153.  Status Code Definitions
316
3173.1.  206 Partial Content
318
319   The server has fulfilled the partial GET request for the resource.
320   The request MUST have included a Range header field (Section 5.4)
321   indicating the desired range, and MAY have included an If-Range
322   header field (Section 5.3) to make the request conditional.
323
324   The response MUST include the following header fields:
325
326   o  Either a Content-Range header field (Section 5.2) indicating the
327      range included with this response, or a multipart/byteranges
328      Content-Type including Content-Range fields for each part.  If a
329      Content-Length header field is present in the response, its value
330      MUST match the actual number of octets transmitted in the message
331      body.
332
333
334
335Fielding, et al.       Expires September 13, 2012               [Page 6]
336
337Internet-Draft              HTTP/1.1, Part 5                  March 2012
338
339
340   o  Date
341
342   o  Cache-Control, ETag, Expires, Content-Location, Last-Modified,
343      and/or Vary, if the header field would have been sent in a 200
344      response to the same request
345
346   If the 206 response is the result of an If-Range request, the
347   response SHOULD NOT include other representation header fields.
348   Otherwise, the response MUST include all of the representation header
349   fields that would have been returned with a 200 (OK) response to the
350   same request.
351
352   Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to
353   determine freshness for 206 responses.
354
3553.2.  416 Requested Range Not Satisfiable
356
357   A server SHOULD return a response with this status code if a request
358   included a Range header field (Section 5.4), and none of the ranges-
359   specifier values in this field overlap the current extent of the
360   selected resource, and the request did not include an If-Range header
361   field (Section 5.3).  (For byte-ranges, this means that the first-
362   byte-pos of all of the byte-range-spec values were greater than the
363   current length of the selected resource.)
364
365   When this status code is returned for a byte-range request, the
366   response SHOULD include a Content-Range header field specifying the
367   current length of the representation (see Section 5.2).  This
368   response MUST NOT use the multipart/byteranges content-type.  For
369   example,
370
371     HTTP/1.1 416 Requested Range Not Satisfiable
372     Date: Mon, 20 Jan 2012 15:41:54 GMT
373     Content-Range: bytes */47022
374     Content-Type: image/gif
375
376      Note: Clients cannot depend on servers to send a 416 (Requested
377      range not satisfiable) response instead of a 200 (OK) response for
378      an unsatisfiable Range header field, since not all servers
379      implement this header field.
380
3814.  Responses to a Range Request
382
3834.1.  Response to a Single and Multiple Ranges Request
384
385   When an HTTP message includes the content of a single range (for
386   example, a response to a request for a single range, or to a request
387   for a set of ranges that overlap without any holes), this content is
388
389
390
391Fielding, et al.       Expires September 13, 2012               [Page 7]
392
393Internet-Draft              HTTP/1.1, Part 5                  March 2012
394
395
396   transmitted with a Content-Range header field, and a Content-Length
397   header field showing the number of bytes actually transferred.  For
398   example,
399
400     HTTP/1.1 206 Partial Content
401     Date: Wed, 15 Nov 1995 06:25:24 GMT
402     Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
403     Content-Range: bytes 21010-47021/47022
404     Content-Length: 26012
405     Content-Type: image/gif
406
407   When an HTTP message includes the content of multiple ranges (for
408   example, a response to a request for multiple non-overlapping
409   ranges), these are transmitted as a multipart message.  The multipart
410   media type used for this purpose is "multipart/byteranges" as defined
411   in Appendix A.
412
413   A server MAY combine requested ranges when those ranges are
414   overlapping (see Section 7).
415
416   A response to a request for a single range MUST NOT be sent using the
417   multipart/byteranges media type.  A response to a request for
418   multiple ranges, whose result is a single range, MAY be sent as a
419   multipart/byteranges media type with one part.  A client that cannot
420   decode a multipart/byteranges message MUST NOT ask for multiple
421   ranges in a single request.
422
423   When a client requests multiple ranges in one request, the server
424   SHOULD return them in the order that they appeared in the request.
425
4264.2.  Combining Ranges
427
428   A response might transfer only a subrange of a representation if the
429   connection closed prematurely or if the request used one or more
430   Range specifications.  After several such transfers, a client might
431   have received several ranges of the same representation.  These
432   ranges can only be safely combined if they all have in common the
433   same strong validator, where "strong validator" is defined to be
434   either an entity-tag that is not marked as weak (Section 2.3 of
435   [Part4]) or, if no entity-tag is provided, a Last-Modified value that
436   is strong in the sense defined by Section 2.2.2 of [Part4].
437
438   When a client receives an incomplete 200 (OK) or 206 (Partial
439   Content) response and already has one or more stored responses for
440   the same method and effective request URI, all of the stored
441   responses with the same strong validator MAY be combined with the
442   partial content in this new response.  If none of the stored
443   responses contain the same strong validator, then this new response
444
445
446
447Fielding, et al.       Expires September 13, 2012               [Page 8]
448
449Internet-Draft              HTTP/1.1, Part 5                  March 2012
450
451
452   corresponds to a new representation and MUST NOT be combined with the
453   existing stored responses.
454
455   If the new response is an incomplete 200 (OK) response, then the
456   header fields of that new response are used for any combined response
457   and replace those of the matching stored responses.
458
459   If the new response is a 206 (Partial Content) response and at least
460   one of the matching stored responses is a 200 (OK), then the combined
461   response header fields consist of the most recent 200 response's
462   header fields.  If all of the matching stored responses are 206
463   responses, then the stored response with the most header fields is
464   used as the source of header fields for the combined response, except
465   that the client MUST use other header fields provided in the new
466   response, aside from Content-Range, to replace all instances of the
467   corresponding header fields in the stored response.
468
469   The combined response message body consists of the union of partial
470   content ranges in the new response and each of the selected
471   responses.  If the union consists of the entire range of the
472   representation, then the combined response MUST be recorded as a
473   complete 200 (OK) response with a Content-Length header field that
474   reflects the complete length.  Otherwise, the combined response(s)
475   MUST include a Content-Range header field describing the included
476   range(s) and be recorded as incomplete.  If the union consists of a
477   discontinuous range of the representation, then the client MAY store
478   it as either a multipart range response or as multiple 206 responses
479   with one continuous range each.
480
4815.  Header Field Definitions
482
483   This section defines the syntax and semantics of HTTP/1.1 header
484   fields related to range requests and partial responses.
485
4865.1.  Accept-Ranges
487
488   The "Accept-Ranges" header field allows a resource to indicate its
489   acceptance of range requests.
490
491     Accept-Ranges     = acceptable-ranges
492     acceptable-ranges = 1#range-unit / "none"
493
494   Origin servers that accept byte-range requests MAY send
495
496     Accept-Ranges: bytes
497
498   but are not required to do so.  Clients MAY generate range requests
499   without having received this header field for the resource involved.
500
501
502
503Fielding, et al.       Expires September 13, 2012               [Page 9]
504
505Internet-Draft              HTTP/1.1, Part 5                  March 2012
506
507
508   Range units are defined in Section 2.
509
510   Servers that do not accept any kind of range request for a resource
511   MAY send
512
513     Accept-Ranges: none
514
515   to advise the client not to attempt a range request.
516
5175.2.  Content-Range
518
519   The "Content-Range" header field is sent with a partial
520   representation to specify where in the full representation the
521   payload body is intended to be applied.
522
523   Range units are defined in Section 2.
524
525     Content-Range           = byte-content-range-spec
526                             / other-content-range-spec
527
528     byte-content-range-spec = bytes-unit SP
529                               byte-range-resp-spec "/"
530                               ( instance-length / "*" )
531
532     byte-range-resp-spec    = (first-byte-pos "-" last-byte-pos)
533                             / "*"
534
535     instance-length         = 1*DIGIT
536
537     other-content-range-spec = other-range-unit SP
538                                other-range-resp-spec
539     other-range-resp-spec    = *CHAR
540
541   The header field SHOULD indicate the total length of the full
542   representation, unless this length is unknown or difficult to
543   determine.  The asterisk "*" character means that the instance-length
544   is unknown at the time when the response was generated.
545
546   Unlike byte-ranges-specifier values (see Section 5.4.1), a byte-
547   range-resp-spec MUST only specify one range, and MUST contain
548   absolute byte positions for both the first and last byte of the
549   range.
550
551   A byte-content-range-spec with a byte-range-resp-spec whose last-
552   byte-pos value is less than its first-byte-pos value, or whose
553   instance-length value is less than or equal to its last-byte-pos
554   value, is invalid.  The recipient of an invalid byte-content-range-
555   spec MUST ignore it and any content transferred along with it.
556
557
558
559Fielding, et al.       Expires September 13, 2012              [Page 10]
560
561Internet-Draft              HTTP/1.1, Part 5                  March 2012
562
563
564   In the case of a byte range request: A server sending a response with
565   status code 416 (Requested range not satisfiable) SHOULD include a
566   Content-Range field with a byte-range-resp-spec of "*".  The
567   instance-length specifies the current length of the selected
568   resource.  A response with status code 206 (Partial Content) MUST NOT
569   include a Content-Range field with a byte-range-resp-spec of "*".
570
571   The "Content-Range" header field has no meaning for status codes that
572   do not explicitly describe its semantic.  Currently, only status
573   codes 206 (Partial Content) and 416 (Requested range not satisfiable)
574   describe the meaning of this header field.
575
576   Examples of byte-content-range-spec values, assuming that the
577   representation contains a total of 1234 bytes:
578
579   o  The first 500 bytes:
580
581        bytes 0-499/1234
582
583   o  The second 500 bytes:
584
585        bytes 500-999/1234
586
587   o  All except for the first 500 bytes:
588
589        bytes 500-1233/1234
590
591   o  The last 500 bytes:
592
593        bytes 734-1233/1234
594
595   If the server ignores a byte-range-spec (for example if it is
596   syntactically invalid, or if it may be seen as a denial-of-service
597   attack), the server SHOULD treat the request as if the invalid Range
598   header field did not exist.  (Normally, this means return a 200
599   response containing the full representation).
600
6015.3.  If-Range
602
603   If a client has a partial copy of a representation and wishes to have
604   an up-to-date copy of the entire representation, it could use the
605   Range header field with a conditional GET (using either or both of
606   If-Unmodified-Since and If-Match.)  However, if the condition fails
607   because the representation has been modified, the client would then
608   have to make a second request to obtain the entire current
609   representation.
610
611   The "If-Range" header field allows a client to "short-circuit" the
612
613
614
615Fielding, et al.       Expires September 13, 2012              [Page 11]
616
617Internet-Draft              HTTP/1.1, Part 5                  March 2012
618
619
620   second request.  Informally, its meaning is "if the representation is
621   unchanged, send me the part(s) that I am missing; otherwise, send me
622   the entire new representation".
623
624     If-Range = entity-tag / HTTP-date
625
626   Clients MUST NOT use an entity-tag marked as weak in an If-Range
627   field value and MUST NOT use a Last-Modified date in an If-Range
628   field value unless it has no entity-tag for the representation and
629   the Last-Modified date it does have for the representation is strong
630   in the sense defined by Section 2.2.2 of [Part4].
631
632   A server that evaluates a conditional range request that is
633   applicable to one of its representations MUST evaluate the condition
634   as false if the entity-tag used as a validator is marked as weak or,
635   when an HTTP-date is used as the validator, if the date value is not
636   strong in the sense defined by Section 2.2.2 of [Part4].  (A server
637   can distinguish between a valid HTTP-date and any form of entity-tag
638   by examining the first two characters.)
639
640   The If-Range header field SHOULD only be sent by clients together
641   with a Range header field.  The If-Range header field MUST be ignored
642   if it is received in a request that does not include a Range header
643   field.  The If-Range header field MUST be ignored by a server that
644   does not support the sub-range operation.
645
646   If the validator given in the If-Range header field matches the
647   current validator for the selected representation of the target
648   resource, then the server SHOULD send the specified sub-range of the
649   representation using a 206 (Partial Content) response.  If the
650   validator does not match, then the server SHOULD send the entire
651   representation using a 200 (OK) response.
652
6535.4.  Range
654
6555.4.1.  Byte Ranges
656
657   Since all HTTP representations are transferred as sequences of bytes,
658   the concept of a byte range is meaningful for any HTTP
659   representation.  (However, not all clients and servers need to
660   support byte-range operations.)
661
662   Byte range specifications in HTTP apply to the sequence of bytes in
663   the representation body (not necessarily the same as the message
664   body).
665
666   A byte range operation MAY specify a single range of bytes, or a set
667   of ranges within a single representation.
668
669
670
671Fielding, et al.       Expires September 13, 2012              [Page 12]
672
673Internet-Draft              HTTP/1.1, Part 5                  March 2012
674
675
676     byte-ranges-specifier = bytes-unit "=" byte-range-set
677     byte-range-set  = 1#( byte-range-spec / suffix-byte-range-spec )
678     byte-range-spec = first-byte-pos "-" [ last-byte-pos ]
679     first-byte-pos  = 1*DIGIT
680     last-byte-pos   = 1*DIGIT
681
682   The first-byte-pos value in a byte-range-spec gives the byte-offset
683   of the first byte in a range.  The last-byte-pos value gives the
684   byte-offset of the last byte in the range; that is, the byte
685   positions specified are inclusive.  Byte offsets start at zero.
686
687   If the last-byte-pos value is present, it MUST be greater than or
688   equal to the first-byte-pos in that byte-range-spec, or the byte-
689   range-spec is syntactically invalid.  The recipient of a byte-range-
690   set that includes one or more syntactically invalid byte-range-spec
691   values MUST ignore the header field that includes that byte-range-
692   set.
693
694   If the last-byte-pos value is absent, or if the value is greater than
695   or equal to the current length of the representation body, last-byte-
696   pos is taken to be equal to one less than the current length of the
697   representation in bytes.
698
699   By its choice of last-byte-pos, a client can limit the number of
700   bytes retrieved without knowing the size of the representation.
701
702     suffix-byte-range-spec = "-" suffix-length
703     suffix-length = 1*DIGIT
704
705   A suffix-byte-range-spec is used to specify the suffix of the
706   representation body, of a length given by the suffix-length value.
707   (That is, this form specifies the last N bytes of a representation.)
708   If the representation is shorter than the specified suffix-length,
709   the entire representation is used.
710
711   If a syntactically valid byte-range-set includes at least one byte-
712   range-spec whose first-byte-pos is less than the current length of
713   the representation, or at least one suffix-byte-range-spec with a
714   non-zero suffix-length, then the byte-range-set is satisfiable.
715   Otherwise, the byte-range-set is unsatisfiable.  If the byte-range-
716   set is unsatisfiable, the server SHOULD return a response with a 416
717   (Requested range not satisfiable) status code.  Otherwise, the server
718   SHOULD return a response with a 206 (Partial Content) status code
719   containing the satisfiable ranges of the representation.
720
721   Examples of byte-ranges-specifier values (assuming a representation
722   of length 10000):
723
724
725
726
727Fielding, et al.       Expires September 13, 2012              [Page 13]
728
729Internet-Draft              HTTP/1.1, Part 5                  March 2012
730
731
732   o  The first 500 bytes (byte offsets 0-499, inclusive):
733
734        bytes=0-499
735
736   o  The second 500 bytes (byte offsets 500-999, inclusive):
737
738        bytes=500-999
739
740   o  The final 500 bytes (byte offsets 9500-9999, inclusive):
741
742        bytes=-500
743
744      Or:
745
746        bytes=9500-
747
748   o  The first and last bytes only (bytes 0 and 9999):
749
750        bytes=0-0,-1
751
752   o  Several legal but not canonical specifications of the second 500
753      bytes (byte offsets 500-999, inclusive):
754
755        bytes=500-600,601-999
756        bytes=500-700,601-999
757
7585.4.2.  Range Retrieval Requests
759
760   The "Range" header field defines the GET method (conditional or not)
761   to request one or more sub-ranges of the response representation
762   body, instead of the entire representation body.
763
764     Range = byte-ranges-specifier / other-ranges-specifier
765     other-ranges-specifier = other-range-unit "=" other-range-set
766     other-range-set = 1*CHAR
767
768   A server MAY ignore the Range header field.  However, origin servers
769   and intermediate caches ought to support byte ranges when possible,
770   since Range supports efficient recovery from partially failed
771   transfers, and supports efficient partial retrieval of large
772   representations.
773
774   If the server supports the Range header field and the specified range
775   or ranges are appropriate for the representation:
776
777   o  The presence of a Range header field in an unconditional GET
778      modifies what is returned if the GET is otherwise successful.  In
779      other words, the response carries a status code of 206 (Partial
780
781
782
783Fielding, et al.       Expires September 13, 2012              [Page 14]
784
785Internet-Draft              HTTP/1.1, Part 5                  March 2012
786
787
788      Content) instead of 200 (OK).
789
790   o  The presence of a Range header field in a conditional GET (a
791      request using one or both of If-Modified-Since and If-None-Match,
792      or one or both of If-Unmodified-Since and If-Match) modifies what
793      is returned if the GET is otherwise successful and the condition
794      is true.  It does not affect the 304 (Not Modified) response
795      returned if the conditional is false.
796
797   In some cases, it might be more appropriate to use the If-Range
798   header field (see Section 5.3) in addition to the Range header field.
799
800   If a proxy that supports ranges receives a Range request, forwards
801   the request to an inbound server, and receives an entire
802   representation in reply, it MAY only return the requested range to
803   its client.
804
8056.  IANA Considerations
806
8076.1.  Status Code Registration
808
809   The HTTP Status Code Registry located at
810   <http://www.iana.org/assignments/http-status-codes> shall be updated
811   with the registrations below:
812
813   +-------+---------------------------------+-------------+
814   | Value | Description                     | Reference   |
815   +-------+---------------------------------+-------------+
816   | 206   | Partial Content                 | Section 3.1 |
817   | 416   | Requested Range Not Satisfiable | Section 3.2 |
818   +-------+---------------------------------+-------------+
819
8206.2.  Header Field Registration
821
822   The Message Header Field Registry located at <http://www.iana.org/
823   assignments/message-headers/message-header-index.html> shall be
824   updated with the permanent registrations below (see [RFC3864]):
825
826   +-------------------+----------+----------+-------------+
827   | Header Field Name | Protocol | Status   | Reference   |
828   +-------------------+----------+----------+-------------+
829   | Accept-Ranges     | http     | standard | Section 5.1 |
830   | Content-Range     | http     | standard | Section 5.2 |
831   | If-Range          | http     | standard | Section 5.3 |
832   | Range             | http     | standard | Section 5.4 |
833   +-------------------+----------+----------+-------------+
834
835   The change controller is: "IETF (iesg@ietf.org) - Internet
836
837
838
839Fielding, et al.       Expires September 13, 2012              [Page 15]
840
841Internet-Draft              HTTP/1.1, Part 5                  March 2012
842
843
844   Engineering Task Force".
845
8466.3.  Range Specifier Registration
847
848   The registration procedure for HTTP Range Specifiers is defined by
849   Section 2.1 of this document.
850
851   The HTTP Range Specifier Registry shall be created at
852   <http://www.iana.org/assignments/http-range-specifiers> and be
853   populated with the registrations below:
854
855   +----------------------+-------------------+----------------------+
856   | Range Specifier Name | Description       | Reference            |
857   +----------------------+-------------------+----------------------+
858   | bytes                | a range of octets | (this specification) |
859   +----------------------+-------------------+----------------------+
860
861   The change controller is: "IETF (iesg@ietf.org) - Internet
862   Engineering Task Force".
863
8647.  Security Considerations
865
866   This section is meant to inform application developers, information
867   providers, and users of the security limitations in HTTP/1.1 as
868   described by this document.  The discussion does not include
869   definitive solutions to the problems revealed, though it does make
870   some suggestions for reducing security risks.
871
8727.1.  Overlapping Ranges
873
874   Range requests containing overlapping ranges may lead to the
875   situation where a server is sending far more data than the size of
876   the complete resource representation.
877
8788.  Acknowledgments
879
880   See Section 9 of [Part1].
881
8829.  References
883
8849.1.  Normative References
885
886   [Part1]    Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
887              "HTTP/1.1, part 1: URIs, Connections, and Message
888              Parsing", draft-ietf-httpbis-p1-messaging-19 (work in
889              progress), March 2012.
890
891   [Part2]    Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
892
893
894
895Fielding, et al.       Expires September 13, 2012              [Page 16]
896
897Internet-Draft              HTTP/1.1, Part 5                  March 2012
898
899
900              "HTTP/1.1, part 2: Message Semantics",
901              draft-ietf-httpbis-p2-semantics-19 (work in progress),
902              March 2012.
903
904   [Part4]    Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
905              "HTTP/1.1, part 4: Conditional Requests",
906              draft-ietf-httpbis-p4-conditional-19 (work in progress),
907              March 2012.
908
909   [Part6]    Fielding, R., Ed., Lafon, Y., Ed., Nottingham, M., Ed.,
910              and J. Reschke, Ed., "HTTP/1.1, part 6: Caching",
911              draft-ietf-httpbis-p6-cache-19 (work in progress),
912              March 2012.
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 September 13, 2012              [Page 17]
952
953Internet-Draft              HTTP/1.1, Part 5                  March 2012
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 September 13, 2012              [Page 18]
1008
1009Internet-Draft              HTTP/1.1, Part 5                  March 2012
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 September 13, 2012              [Page 19]
1064
1065Internet-Draft              HTTP/1.1, Part 5                  March 2012
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.  Changes from RFC 2616
1074
1075   Clarify that it is not ok to use a weak validator in a 206 response.
1076   (Section 3.1)
1077
1078   Change ABNF productions for header fields to only define the field
1079   value.  (Section 5)
1080
1081   Clarify that multipart/byteranges can consist of a single part.
1082   (Appendix A)
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119Fielding, et al.       Expires September 13, 2012              [Page 20]
1120
1121Internet-Draft              HTTP/1.1, Part 5                  March 2012
1122
1123
1124Appendix C.  Collected ABNF
1125
1126   Accept-Ranges = acceptable-ranges
1127
1128   Content-Range = byte-content-range-spec / other-content-range-spec
1129
1130   HTTP-date = <HTTP-date, defined in [Part2], Section 8>
1131
1132   If-Range = entity-tag / HTTP-date
1133
1134   OWS = <OWS, defined in [Part1], Section 3.2.1>
1135
1136   Range = byte-ranges-specifier / other-ranges-specifier
1137
1138   acceptable-ranges = ( *( "," OWS ) range-unit *( OWS "," [ OWS
1139    range-unit ] ) ) / "none"
1140
1141   byte-content-range-spec = bytes-unit SP byte-range-resp-spec "/" (
1142    instance-length / "*" )
1143   byte-range-resp-spec = ( first-byte-pos "-" last-byte-pos ) / "*"
1144   byte-range-set = ( *( "," OWS ) byte-range-spec ) / (
1145    suffix-byte-range-spec *( OWS "," [ ( OWS byte-range-spec ) /
1146    suffix-byte-range-spec ] ) )
1147   byte-range-spec = first-byte-pos "-" [ last-byte-pos ]
1148   byte-ranges-specifier = bytes-unit "=" byte-range-set
1149   bytes-unit = "bytes"
1150
1151   entity-tag = <entity-tag, defined in [Part4], Section 2.3>
1152
1153   first-byte-pos = 1*DIGIT
1154
1155   instance-length = 1*DIGIT
1156
1157   last-byte-pos = 1*DIGIT
1158
1159   other-content-range-spec = other-range-unit SP other-range-resp-spec
1160   other-range-resp-spec = *CHAR
1161   other-range-set = 1*CHAR
1162   other-range-unit = token
1163   other-ranges-specifier = other-range-unit "=" other-range-set
1164
1165   range-unit = bytes-unit / other-range-unit
1166
1167   suffix-byte-range-spec = "-" suffix-length
1168   suffix-length = 1*DIGIT
1169
1170   token = <token, defined in [Part1], Section 3.2.4>
1171
1172
1173
1174
1175Fielding, et al.       Expires September 13, 2012              [Page 21]
1176
1177Internet-Draft              HTTP/1.1, Part 5                  March 2012
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 September 13, 2012              [Page 22]
1232
1233Internet-Draft              HTTP/1.1, Part 5                  March 2012
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 September 13, 2012              [Page 23]
1288
1289Internet-Draft              HTTP/1.1, Part 5                  March 2012
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 September 13, 2012              [Page 24]
1344
1345Internet-Draft              HTTP/1.1, Part 5                  March 2012
1346
1347
1348D.14.  Since draft-ietf-httpbis-p5-range-12
1349
1350   Closed issues:
1351
1352   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/224>: "Header
1353      Classification"
1354
1355D.15.  Since draft-ietf-httpbis-p5-range-13
1356
1357   Closed issues:
1358
1359   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle
1360      ABNFs for header fields"
1361
1362D.16.  Since draft-ietf-httpbis-p5-range-14
1363
1364   None.
1365
1366D.17.  Since draft-ietf-httpbis-p5-range-15
1367
1368   Closed issues:
1369
1370   o  <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/175>: "Security
1371      consideration: range flooding"
1372
1373D.18.  Since draft-ietf-httpbis-p5-range-16
1374
1375   Closed issues:
1376
1377   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/186>: "Document
1378      HTTP's error-handling philosophy"
1379
1380   o  <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/301>: "Content-
1381      Range on responses other than 206"
1382
1383   o  <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/319>: "case
1384      sensitivity of ranges in p5"
1385
1386D.19.  Since draft-ietf-httpbis-p5-range-17
1387
1388   None.
1389
1390D.20.  Since draft-ietf-httpbis-p5-range-18
1391
1392   Closed issues:
1393
1394   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/311>: "Add
1395      limitations to Range to reduce its use as a denial-of-service
1396
1397
1398
1399Fielding, et al.       Expires September 13, 2012              [Page 25]
1400
1401Internet-Draft              HTTP/1.1, Part 5                  March 2012
1402
1403
1404      tool"
1405
1406Index
1407
1408   2
1409      206 Partial Content (status code)  6
1410
1411   4
1412      416 Requested Range Not Satisfiable (status code)  7
1413
1414   A
1415      Accept-Ranges header field  9
1416
1417   C
1418      Content-Range header field  10
1419
1420   G
1421      Grammar
1422         Accept-Ranges  9
1423         acceptable-ranges  9
1424         byte-content-range-spec  10
1425         byte-range-resp-spec  10
1426         byte-range-set  13
1427         byte-range-spec  13
1428         byte-ranges-specifier  13
1429         bytes-unit  5
1430         Content-Range  10
1431         first-byte-pos  13
1432         If-Range  12
1433         instance-length  10
1434         last-byte-pos  13
1435         other-range-unit  5
1436         Range  14
1437         range-unit  5
1438         ranges-specifier  13
1439         suffix-byte-range-spec  13
1440         suffix-length  13
1441
1442   H
1443      Header Fields
1444         Accept-Ranges  9
1445         Content-Range  10
1446         If-Range  11
1447         Range  12
1448
1449   I
1450      If-Range header field  11
1451
1452
1453
1454
1455Fielding, et al.       Expires September 13, 2012              [Page 26]
1456
1457Internet-Draft              HTTP/1.1, Part 5                  March 2012
1458
1459
1460   M
1461      Media Type
1462         multipart/byteranges  17
1463         multipart/x-byteranges  20
1464      multipart/byteranges Media Type  17
1465      multipart/x-byteranges Media Type  20
1466
1467   R
1468      Range header field  12
1469
1470   S
1471      Status Codes
1472         206 Partial Content  6
1473         416 Requested Range Not Satisfiable  7
1474
1475Authors' Addresses
1476
1477   Roy T. Fielding (editor)
1478   Adobe Systems Incorporated
1479   345 Park Ave
1480   San Jose, CA  95110
1481   USA
1482
1483   EMail: fielding@gbiv.com
1484   URI:   http://roy.gbiv.com/
1485
1486
1487   Yves Lafon (editor)
1488   World Wide Web Consortium
1489   W3C / ERCIM
1490   2004, rte des Lucioles
1491   Sophia-Antipolis, AM  06902
1492   France
1493
1494   EMail: ylafon@w3.org
1495   URI:   http://www.raubacapeu.net/people/yves/
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511Fielding, et al.       Expires September 13, 2012              [Page 27]
1512
1513Internet-Draft              HTTP/1.1, Part 5                  March 2012
1514
1515
1516   Julian F. Reschke (editor)
1517   greenbytes GmbH
1518   Hafenweg 16
1519   Muenster, NW  48155
1520   Germany
1521
1522   Phone: +49 251 2807760
1523   Fax:   +49 251 2807761
1524   EMail: julian.reschke@greenbytes.de
1525   URI:   http://greenbytes.de/tech/webdav/
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567Fielding, et al.       Expires September 13, 2012              [Page 28]
1568
Note: See TracBrowser for help on using the repository browser.