source: draft-ietf-httpbis/14/draft-ietf-httpbis-p5-range-14.txt @ 2684

Last change on this file since 2684 was 1271, checked in by julian.reschke@…, 10 years ago

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