source: draft-ietf-httpbis/13/draft-ietf-httpbis-p5-range-13.txt @ 2622

Last change on this file since 2622 was 1180, checked in by julian.reschke@…, 9 years ago

prepare publication of -13

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