source: draft-ietf-httpbis/10/draft-ietf-httpbis-p5-range-10.txt

Last change on this file was 956, checked in by fielding@…, 9 years ago

forgot to set eol-style

  • Property svn:eol-style set to native
File size: 47.6 KB
Line 
1
2
3
4HTTPbis Working Group                                   R. Fielding, Ed.
5Internet-Draft                                              Day Software
6Obsoletes: 2616 (if approved)                                  J. Gettys
7Intended status: Standards Track                          Alcatel-Lucent
8Expires: January 13, 2011                                       J. Mogul
9                                                                      HP
10                                                              H. Frystyk
11                                                               Microsoft
12                                                             L. Masinter
13                                                           Adobe Systems
14                                                                P. Leach
15                                                               Microsoft
16                                                          T. Berners-Lee
17                                                                 W3C/MIT
18                                                           Y. Lafon, Ed.
19                                                                     W3C
20                                                         J. Reschke, Ed.
21                                                              greenbytes
22                                                           July 12, 2010
23
24
25         HTTP/1.1, part 5: Range Requests and Partial Responses
26                     draft-ietf-httpbis-p5-range-10
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.11.
48
49Status of This Memo
50
51   This Internet-Draft is submitted in full conformance with the
52
53
54
55Fielding, et al.        Expires January 13, 2011                [Page 1]
56
57Internet-Draft              HTTP/1.1, Part 5                   July 2010
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 January 13, 2011.
73
74Copyright Notice
75
76   Copyright (c) 2010 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
101
102
103
104
105
106
107
108
109
110
111Fielding, et al.        Expires January 13, 2011                [Page 2]
112
113Internet-Draft              HTTP/1.1, Part 5                   July 2010
114
115
116Table of Contents
117
118   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
119     1.1.  Requirements . . . . . . . . . . . . . . . . . . . . . . .  4
120     1.2.  Syntax Notation  . . . . . . . . . . . . . . . . . . . . .  4
121       1.2.1.  Core Rules . . . . . . . . . . . . . . . . . . . . . .  5
122       1.2.2.  ABNF Rules defined in other Parts of the
123               Specification  . . . . . . . . . . . . . . . . . . . .  5
124   2.  Range Units  . . . . . . . . . . . . . . . . . . . . . . . . .  5
125   3.  Status Code Definitions  . . . . . . . . . . . . . . . . . . .  5
126     3.1.  206 Partial Content  . . . . . . . . . . . . . . . . . . .  6
127     3.2.  416 Requested Range Not Satisfiable  . . . . . . . . . . .  6
128   4.  Combining Ranges . . . . . . . . . . . . . . . . . . . . . . .  7
129   5.  Header Field Definitions . . . . . . . . . . . . . . . . . . .  7
130     5.1.  Accept-Ranges  . . . . . . . . . . . . . . . . . . . . . .  7
131     5.2.  Content-Range  . . . . . . . . . . . . . . . . . . . . . .  8
132     5.3.  If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 10
133     5.4.  Range  . . . . . . . . . . . . . . . . . . . . . . . . . . 11
134       5.4.1.  Byte Ranges  . . . . . . . . . . . . . . . . . . . . . 11
135       5.4.2.  Range Retrieval Requests . . . . . . . . . . . . . . . 13
136   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
137     6.1.  Status Code Registration . . . . . . . . . . . . . . . . . 14
138     6.2.  Message Header Registration  . . . . . . . . . . . . . . . 14
139   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
140   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 14
141   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
142     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 15
143     9.2.  Informative References . . . . . . . . . . . . . . . . . . 15
144   Appendix A.  Internet Media Type multipart/byteranges  . . . . . . 16
145   Appendix B.  Compatibility with Previous Versions  . . . . . . . . 18
146     B.1.  Changes from RFC 2068  . . . . . . . . . . . . . . . . . . 18
147     B.2.  Changes from RFC 2616  . . . . . . . . . . . . . . . . . . 18
148   Appendix C.  Collected ABNF  . . . . . . . . . . . . . . . . . . . 19
149   Appendix D.  Change Log (to be removed by RFC Editor before
150                publication)  . . . . . . . . . . . . . . . . . . . . 20
151     D.1.  Since RFC2616  . . . . . . . . . . . . . . . . . . . . . . 20
152     D.2.  Since draft-ietf-httpbis-p5-range-00 . . . . . . . . . . . 20
153     D.3.  Since draft-ietf-httpbis-p5-range-01 . . . . . . . . . . . 20
154     D.4.  Since draft-ietf-httpbis-p5-range-02 . . . . . . . . . . . 21
155     D.5.  Since draft-ietf-httpbis-p5-range-03 . . . . . . . . . . . 21
156     D.6.  Since draft-ietf-httpbis-p5-range-04 . . . . . . . . . . . 21
157     D.7.  Since draft-ietf-httpbis-p5-range-05 . . . . . . . . . . . 21
158     D.8.  Since draft-ietf-httpbis-p5-range-06 . . . . . . . . . . . 22
159     D.9.  Since draft-ietf-httpbis-p5-range-07 . . . . . . . . . . . 22
160     D.10. Since draft-ietf-httpbis-p5-range-08 . . . . . . . . . . . 22
161     D.11. Since draft-ietf-httpbis-p5-range-09 . . . . . . . . . . . 22
162   Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
163
164
165
166
167Fielding, et al.        Expires January 13, 2011                [Page 3]
168
169Internet-Draft              HTTP/1.1, Part 5                   July 2010
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 January 13, 2011                [Page 4]
224
225Internet-Draft              HTTP/1.1, Part 5                   July 2010
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   response entity 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.  An entity can be broken down into subranges according
256   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".
265
266   If a range unit is not understood in a request, a server MUST ignore
267   the whole Range header (Section 5.4).  If a range unit is not
268   understood in a response, an intermediary SHOULD pass the response to
269   the client; a client MUST fail.
270
2713.  Status Code Definitions
272
273
274
275
276
277
278
279Fielding, et al.        Expires January 13, 2011                [Page 5]
280
281Internet-Draft              HTTP/1.1, Part 5                   July 2010
282
283
2843.1.  206 Partial Content
285
286   The server has fulfilled the partial GET request for the resource.
287   The request MUST have included a Range header field (Section 5.4)
288   indicating the desired range, and MAY have included an If-Range
289   header field (Section 5.3) to make the request conditional.
290
291   The response MUST include the following header fields:
292
293   o  Either a Content-Range header field (Section 5.2) indicating the
294      range included with this response, or a multipart/byteranges
295      Content-Type including Content-Range fields for each part.  If a
296      Content-Length header field is present in the response, its value
297      MUST match the actual number of OCTETs transmitted in the message-
298      body.
299
300   o  Date
301
302   o  ETag and/or Content-Location, if the header would have been sent
303      in a 200 response to the same request
304
305   o  Expires, Cache-Control, and/or Vary, if the field-value might
306      differ from that sent in any previous response for the same
307      variant
308
309   If the 206 response is the result of an If-Range request, the
310   response SHOULD NOT include other entity-headers.  Otherwise, the
311   response MUST include all of the entity-headers that would have been
312   returned with a 200 (OK) response to the same request.
313
314   A cache MUST NOT combine a 206 response with other previously cached
315   content if the ETag or Last-Modified headers do not match exactly,
316   see Section 4.
317
318   A cache that does not support the Range and Content-Range headers
319   MUST NOT cache 206 (Partial Content) responses.  Furthermore, if a
320   response uses a range unit that is not understood by the cache, then
321   it MUST NOT be cached either.
322
3233.2.  416 Requested Range Not Satisfiable
324
325   A server SHOULD return a response with this status code if a request
326   included a Range request-header field (Section 5.4), and none of the
327   ranges-specifier values in this field overlap the current extent of
328   the selected resource, and the request did not include an If-Range
329   request-header field (Section 5.3).  (For byte-ranges, this means
330   that the first-byte-pos of all of the byte-range-spec values were
331   greater than the current length of the selected resource.)
332
333
334
335Fielding, et al.        Expires January 13, 2011                [Page 6]
336
337Internet-Draft              HTTP/1.1, Part 5                   July 2010
338
339
340   When this status code is returned for a byte-range request, the
341   response SHOULD include a Content-Range entity-header field
342   specifying the current length of the selected resource (see
343   Section 5.2).  This response MUST NOT use the multipart/byteranges
344   content-type.
345
3464.  Combining Ranges
347
348   A response might transfer only a subrange of an entity-body, either
349   because the request included one or more Range specifications, or
350   because a connection was broken prematurely.  After several such
351   transfers, a cache might have received several ranges of the same
352   entity-body.
353
354   If a cache has a stored non-empty set of subranges for an entity, and
355   an incoming response transfers another subrange, the cache MAY
356   combine the new subrange with the existing set if both the following
357   conditions are met:
358
359   o  Both the incoming response and the cache entry have a cache
360      validator.
361
362   o  The two cache validators match using the strong comparison
363      function (see Section 4 of [Part4]).
364
365   If either requirement is not met, the cache MUST use only the most
366   recent partial response (based on the Date values transmitted with
367   every response, and using the incoming response if these values are
368   equal or missing), and MUST discard the other partial information.
369
3705.  Header Field Definitions
371
372   This section defines the syntax and semantics of HTTP/1.1 header
373   fields related to range requests and partial responses.
374
375   For entity-header fields, both sender and recipient refer to either
376   the client or the server, depending on who sends and who receives the
377   entity.
378
3795.1.  Accept-Ranges
380
381   The "Accept-Ranges" response-header field allows a resource to
382   indicate its acceptance of range requests.
383
384     Accept-Ranges     = "Accept-Ranges" ":" OWS Accept-Ranges-v
385     Accept-Ranges-v   = acceptable-ranges
386     acceptable-ranges = 1#range-unit / "none"
387
388
389
390
391Fielding, et al.        Expires January 13, 2011                [Page 7]
392
393Internet-Draft              HTTP/1.1, Part 5                   July 2010
394
395
396   Origin servers that accept byte-range requests MAY send
397
398     Accept-Ranges: bytes
399
400   but are not required to do so.  Clients MAY generate range requests
401   without having received this header for the resource involved.  Range
402   units are defined in Section 2.
403
404   Servers that do not accept any kind of range request for a resource
405   MAY send
406
407     Accept-Ranges: none
408
409   to advise the client not to attempt a range request.
410
4115.2.  Content-Range
412
413   The "Content-Range" entity-header field is sent with a partial
414   entity-body to specify where in the full entity-body the partial body
415   should be applied.  Range units are defined in Section 2.
416
417     Content-Range = "Content-Range" ":" OWS Content-Range-v
418     Content-Range-v = content-range-spec
419
420     content-range-spec      = byte-content-range-spec
421                             / other-content-range-spec
422     byte-content-range-spec = bytes-unit SP
423                               byte-range-resp-spec "/"
424                               ( instance-length / "*" )
425
426     byte-range-resp-spec    = (first-byte-pos "-" last-byte-pos)
427                             / "*"
428
429     instance-length         = 1*DIGIT
430
431     other-content-range-spec = other-range-unit SP
432                                other-range-resp-spec
433     other-range-resp-spec    = *CHAR
434
435   The header SHOULD indicate the total length of the full entity-body,
436   unless this length is unknown or difficult to determine.  The
437   asterisk "*" character means that the instance-length is unknown at
438   the time when the response was generated.
439
440   Unlike byte-ranges-specifier values (see Section 5.4.1), a byte-
441   range-resp-spec MUST only specify one range, and MUST contain
442   absolute byte positions for both the first and last byte of the
443   range.
444
445
446
447Fielding, et al.        Expires January 13, 2011                [Page 8]
448
449Internet-Draft              HTTP/1.1, Part 5                   July 2010
450
451
452   A byte-content-range-spec with a byte-range-resp-spec whose last-
453   byte-pos value is less than its first-byte-pos value, or whose
454   instance-length value is less than or equal to its last-byte-pos
455   value, is invalid.  The recipient of an invalid byte-content-range-
456   spec MUST ignore it and any content transferred along with it.
457
458   In the case of a byte range request: A server sending a response with
459   status code 416 (Requested range not satisfiable) SHOULD include a
460   Content-Range field with a byte-range-resp-spec of "*".  The
461   instance-length specifies the current length of the selected
462   resource.  A response with status code 206 (Partial Content) MUST NOT
463   include a Content-Range field with a byte-range-resp-spec of "*".
464
465   Examples of byte-content-range-spec values, assuming that the entity
466   contains a total of 1234 bytes:
467
468   o  The first 500 bytes:
469
470        bytes 0-499/1234
471
472   o  The second 500 bytes:
473
474        bytes 500-999/1234
475
476   o  All except for the first 500 bytes:
477
478        bytes 500-1233/1234
479
480   o  The last 500 bytes:
481
482        bytes 734-1233/1234
483
484   When an HTTP message includes the content of a single range (for
485   example, a response to a request for a single range, or to a request
486   for a set of ranges that overlap without any holes), this content is
487   transmitted with a Content-Range header, and a Content-Length header
488   showing the number of bytes actually transferred.  For example,
489
490     HTTP/1.1 206 Partial Content
491     Date: Wed, 15 Nov 1995 06:25:24 GMT
492     Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
493     Content-Range: bytes 21010-47021/47022
494     Content-Length: 26012
495     Content-Type: image/gif
496
497   When an HTTP message includes the content of multiple ranges (for
498   example, a response to a request for multiple non-overlapping
499   ranges), these are transmitted as a multipart message.  The multipart
500
501
502
503Fielding, et al.        Expires January 13, 2011                [Page 9]
504
505Internet-Draft              HTTP/1.1, Part 5                   July 2010
506
507
508   media type used for this purpose is "multipart/byteranges" as defined
509   in Appendix A.  See Appendix B.1 for a compatibility issue.
510
511   A response to a request for a single range MUST NOT be sent using the
512   multipart/byteranges media type.  A response to a request for
513   multiple ranges, whose result is a single range, MAY be sent as a
514   multipart/byteranges media type with one part.  A client that cannot
515   decode a multipart/byteranges message MUST NOT ask for multiple
516   ranges in a single request.
517
518   When a client requests multiple ranges in one request, the server
519   SHOULD return them in the order that they appeared in the request.
520
521   If the server ignores a byte-range-spec because it is syntactically
522   invalid, the server SHOULD treat the request as if the invalid Range
523   header field did not exist.  (Normally, this means return a 200
524   response containing the full entity).
525
526   If the server receives a request (other than one including an If-
527   Range request-header field) with an unsatisfiable Range request-
528   header field (that is, all of whose byte-range-spec values have a
529   first-byte-pos value greater than the current length of the selected
530   resource), it SHOULD return a response code of 416 (Requested range
531   not satisfiable) (Section 3.2).
532
533      Note: Clients cannot depend on servers to send a 416 (Requested
534      range not satisfiable) response instead of a 200 (OK) response for
535      an unsatisfiable Range request-header, since not all servers
536      implement this request-header.
537
5385.3.  If-Range
539
540   If a client has a partial copy of an entity in its cache, and wishes
541   to have an up-to-date copy of the entire entity in its cache, it
542   could use the Range request-header with a conditional GET (using
543   either or both of If-Unmodified-Since and If-Match.)  However, if the
544   condition fails because the entity has been modified, the client
545   would then have to make a second request to obtain the entire current
546   entity-body.
547
548   The "If-Range" request-header field allows a client to "short-
549   circuit" the second request.  Informally, its meaning is "if the
550   entity is unchanged, send me the part(s) that I am missing;
551   otherwise, send me the entire new entity".
552
553     If-Range   = "If-Range" ":" OWS If-Range-v
554     If-Range-v = entity-tag / HTTP-date
555
556
557
558
559Fielding, et al.        Expires January 13, 2011               [Page 10]
560
561Internet-Draft              HTTP/1.1, Part 5                   July 2010
562
563
564   If the client has no entity tag for an entity, but does have a Last-
565   Modified date, it MAY use that date in an If-Range header.  (The
566   server can distinguish between a valid HTTP-date and any form of
567   entity-tag by examining no more than two characters.)  The If-Range
568   header SHOULD only be used together with a Range header, and MUST be
569   ignored if the request does not include a Range header, or if the
570   server does not support the sub-range operation.
571
572   If the entity tag given in the If-Range header matches the current
573   cache validator for the entity, then the server SHOULD provide the
574   specified sub-range of the entity using a 206 (Partial Content)
575   response.  If the cache validator does not match, then the server
576   SHOULD return the entire entity using a 200 (OK) response.
577
5785.4.  Range
579
5805.4.1.  Byte Ranges
581
582   Since all HTTP entities are represented in HTTP messages as sequences
583   of bytes, the concept of a byte range is meaningful for any HTTP
584   entity.  (However, not all clients and servers need to support byte-
585   range operations.)
586
587   Byte range specifications in HTTP apply to the sequence of bytes in
588   the entity-body (not necessarily the same as the message-body).
589
590   A byte range operation MAY specify a single range of bytes, or a set
591   of ranges within a single entity.
592
593     byte-ranges-specifier = bytes-unit "=" byte-range-set
594     byte-range-set  = 1#( byte-range-spec / suffix-byte-range-spec )
595     byte-range-spec = first-byte-pos "-" [ last-byte-pos ]
596     first-byte-pos  = 1*DIGIT
597     last-byte-pos   = 1*DIGIT
598
599   The first-byte-pos value in a byte-range-spec gives the byte-offset
600   of the first byte in a range.  The last-byte-pos value gives the
601   byte-offset of the last byte in the range; that is, the byte
602   positions specified are inclusive.  Byte offsets start at zero.
603
604   If the last-byte-pos value is present, it MUST be greater than or
605   equal to the first-byte-pos in that byte-range-spec, or the byte-
606   range-spec is syntactically invalid.  The recipient of a byte-range-
607   set that includes one or more syntactically invalid byte-range-spec
608   values MUST ignore the header field that includes that byte-range-
609   set.
610
611   If the last-byte-pos value is absent, or if the value is greater than
612
613
614
615Fielding, et al.        Expires January 13, 2011               [Page 11]
616
617Internet-Draft              HTTP/1.1, Part 5                   July 2010
618
619
620   or equal to the current length of the entity-body, last-byte-pos is
621   taken to be equal to one less than the current length of the entity-
622   body in bytes.
623
624   By its choice of last-byte-pos, a client can limit the number of
625   bytes retrieved without knowing the size of the entity.
626
627     suffix-byte-range-spec = "-" suffix-length
628     suffix-length = 1*DIGIT
629
630   A suffix-byte-range-spec is used to specify the suffix of the entity-
631   body, of a length given by the suffix-length value.  (That is, this
632   form specifies the last N bytes of an entity-body.)  If the entity is
633   shorter than the specified suffix-length, the entire entity-body is
634   used.
635
636   If a syntactically valid byte-range-set includes at least one byte-
637   range-spec whose first-byte-pos is less than the current length of
638   the entity-body, or at least one suffix-byte-range-spec with a non-
639   zero suffix-length, then the byte-range-set is satisfiable.
640   Otherwise, the byte-range-set is unsatisfiable.  If the byte-range-
641   set is unsatisfiable, the server SHOULD return a response with a
642   status of 416 (Requested range not satisfiable).  Otherwise, the
643   server SHOULD return a response with a status of 206 (Partial
644   Content) containing the satisfiable ranges of the entity-body.
645
646   Examples of byte-ranges-specifier values (assuming an entity-body of
647   length 10000):
648
649   o  The first 500 bytes (byte offsets 0-499, inclusive):
650
651        bytes=0-499
652
653   o  The second 500 bytes (byte offsets 500-999, inclusive):
654
655        bytes=500-999
656
657   o  The final 500 bytes (byte offsets 9500-9999, inclusive):
658
659        bytes=-500
660
661      Or:
662
663        bytes=9500-
664
665   o  The first and last bytes only (bytes 0 and 9999):
666
667        bytes=0-0,-1
668
669
670
671Fielding, et al.        Expires January 13, 2011               [Page 12]
672
673Internet-Draft              HTTP/1.1, Part 5                   July 2010
674
675
676   o  Several legal but not canonical specifications of the second 500
677      bytes (byte offsets 500-999, inclusive):
678
679        bytes=500-600,601-999
680        bytes=500-700,601-999
681
6825.4.2.  Range Retrieval Requests
683
684   The "Range" request-header field defines the GET method (conditional
685   or not) to request one or more sub-ranges of the response entity-
686   body, instead of the entire entity body.
687
688     Range   = "Range" ":" OWS Range-v
689     Range-v = byte-ranges-specifier
690             / other-ranges-specifier
691     other-ranges-specifier = other-range-unit "=" other-range-set
692     other-range-set = 1*CHAR
693
694   A server MAY ignore the Range header.  However, HTTP/1.1 origin
695   servers and intermediate caches ought to support byte ranges when
696   possible, since Range supports efficient recovery from partially
697   failed transfers, and supports efficient partial retrieval of large
698   entities.
699
700   If the server supports the Range header and the specified range or
701   ranges are appropriate for the entity:
702
703   o  The presence of a Range header in an unconditional GET modifies
704      what is returned if the GET is otherwise successful.  In other
705      words, the response carries a status code of 206 (Partial Content)
706      instead of 200 (OK).
707
708   o  The presence of a Range header in a conditional GET (a request
709      using one or both of If-Modified-Since and If-None-Match, or one
710      or both of If-Unmodified-Since and If-Match) modifies what is
711      returned if the GET is otherwise successful and the condition is
712      true.  It does not affect the 304 (Not Modified) response returned
713      if the conditional is false.
714
715   In some cases, it might be more appropriate to use the If-Range
716   header (see Section 5.3) in addition to the Range header.
717
718   If a proxy that supports ranges receives a Range request, forwards
719   the request to an inbound server, and receives an entire entity in
720   reply, it SHOULD only return the requested range to its client.  It
721   SHOULD store the entire received response in its cache if that is
722   consistent with its cache allocation policies.
723
724
725
726
727Fielding, et al.        Expires January 13, 2011               [Page 13]
728
729Internet-Draft              HTTP/1.1, Part 5                   July 2010
730
731
7326.  IANA Considerations
733
7346.1.  Status Code Registration
735
736   The HTTP Status Code Registry located at
737   <http://www.iana.org/assignments/http-status-codes> should be updated
738   with the registrations below:
739
740   +-------+---------------------------------+-------------+
741   | Value | Description                     | Reference   |
742   +-------+---------------------------------+-------------+
743   | 206   | Partial Content                 | Section 3.1 |
744   | 416   | Requested Range Not Satisfiable | Section 3.2 |
745   +-------+---------------------------------+-------------+
746
7476.2.  Message Header Registration
748
749   The Message Header Registry located at <http://www.iana.org/
750   assignments/message-headers/message-header-index.html> should be
751   updated with the permanent registrations below (see [RFC3864]):
752
753   +-------------------+----------+----------+-------------+
754   | Header Field Name | Protocol | Status   | Reference   |
755   +-------------------+----------+----------+-------------+
756   | Accept-Ranges     | http     | standard | Section 5.1 |
757   | Content-Range     | http     | standard | Section 5.2 |
758   | If-Range          | http     | standard | Section 5.3 |
759   | Range             | http     | standard | Section 5.4 |
760   +-------------------+----------+----------+-------------+
761
762   The change controller is: "IETF (iesg@ietf.org) - Internet
763   Engineering Task Force".
764
7657.  Security Considerations
766
767   No additional security considerations have been identified beyond
768   those applicable to HTTP in general [Part1].
769
7708.  Acknowledgments
771
772   Most of the specification of ranges is based on work originally done
773   by Ari Luotonen and John Franks, with additional input from Steve
774   Zilles, Daniel W. Connolly, Roy T. Fielding, Jim Gettys, Martin
775   Hamilton, Koen Holtman, Shel Kaplan, Paul Leach, Alex Lopez-Ortiz,
776   Larry Masinter, Jeff Mogul, Lou Montulli, David W. Morris, Luigi
777   Rizzo, and Bill Weihl.
778
7799.  References
780
781
782
783Fielding, et al.        Expires January 13, 2011               [Page 14]
784
785Internet-Draft              HTTP/1.1, Part 5                   July 2010
786
787
7889.1.  Normative References
789
790   [Part1]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
791              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
792              and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
793              and Message Parsing", draft-ietf-httpbis-p1-messaging-10
794              (work in progress), July 2010.
795
796   [Part3]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
797              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
798              and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload
799              and Content Negotiation", draft-ietf-httpbis-p3-payload-10
800              (work in progress), July 2010.
801
802   [Part4]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
803              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
804              and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional
805              Requests", draft-ietf-httpbis-p4-conditional-10 (work in
806              progress), July 2010.
807
808   [Part6]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
809              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
810              Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part
811              6: Caching", draft-ietf-httpbis-p6-cache-10 (work in
812              progress), July 2010.
813
814   [RFC2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
815              Extensions (MIME) Part Two: Media Types", RFC 2046,
816              November 1996.
817
818   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
819              Requirement Levels", BCP 14, RFC 2119, March 1997.
820
821   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
822              Specifications: ABNF", STD 68, RFC 5234, January 2008.
823
8249.2.  Informative References
825
826   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
827              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
828              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
829
830   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
831              Procedures for Message Header Fields", BCP 90, RFC 3864,
832              September 2004.
833
834   [RFC4288]  Freed, N. and J. Klensin, "Media Type Specifications and
835              Registration Procedures", BCP 13, RFC 4288, December 2005.
836
837
838
839Fielding, et al.        Expires January 13, 2011               [Page 15]
840
841Internet-Draft              HTTP/1.1, Part 5                   July 2010
842
843
844Appendix A.  Internet Media Type multipart/byteranges
845
846   When an HTTP 206 (Partial Content) response message includes the
847   content of multiple ranges (a response to a request for multiple non-
848   overlapping ranges), these are transmitted as a multipart message-
849   body ([RFC2046], Section 5.1).  The media type for this purpose is
850   called "multipart/byteranges".  The following is to be registered
851   with IANA [RFC4288].
852
853      Note: Despite the name "multipart/byteranges" is not limited to
854      the byte ranges only.
855
856   The multipart/byteranges media type includes one or more parts, each
857   with its own Content-Type and Content-Range fields.  The required
858   boundary parameter specifies the boundary string used to separate
859   each body-part.
860
861   Type name:  multipart
862
863   Subtype name:  byteranges
864
865   Required parameters:  boundary
866
867   Optional parameters:  none
868
869   Encoding considerations:  only "7bit", "8bit", or "binary" are
870      permitted
871
872   Security considerations:  none
873
874   Interoperability considerations:  none
875
876   Published specification:  This specification (see Appendix A).
877
878   Applications that use this media type:
879
880   Additional information:
881
882      Magic number(s):  none
883
884      File extension(s):  none
885
886      Macintosh file type code(s):  none
887
888
889
890
891
892
893
894
895Fielding, et al.        Expires January 13, 2011               [Page 16]
896
897Internet-Draft              HTTP/1.1, Part 5                   July 2010
898
899
900   Person and email address to contact for further information:  See
901      Authors Section.
902
903   Intended usage:  COMMON
904
905   Restrictions on usage:  none
906
907   Author/Change controller:  IESG
908
909   For example:
910
911     HTTP/1.1 206 Partial Content
912     Date: Wed, 15 Nov 1995 06:25:24 GMT
913     Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
914     Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
915
916     --THIS_STRING_SEPARATES
917     Content-type: application/pdf
918     Content-range: bytes 500-999/8000
919
920     ...the first range...
921     --THIS_STRING_SEPARATES
922     Content-type: application/pdf
923     Content-range: bytes 7000-7999/8000
924
925     ...the second range
926     --THIS_STRING_SEPARATES--
927
928   Other example:
929
930     HTTP/1.1 206 Partial Content
931     Date: Tue, 14 Nov 1995 06:25:24 GMT
932     Last-Modified: Tue, 14 July 04:58:08 GMT
933     Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
934
935     --THIS_STRING_SEPARATES
936     Content-type: video/example
937     Content-range: exampleunit 1.2-4.3/25
938
939     ...the first range...
940     --THIS_STRING_SEPARATES
941     Content-type: video/example
942     Content-range: exampleunit 11.2-14.3/25
943
944     ...the second range
945     --THIS_STRING_SEPARATES--
946
947   Notes:
948
949
950
951Fielding, et al.        Expires January 13, 2011               [Page 17]
952
953Internet-Draft              HTTP/1.1, Part 5                   July 2010
954
955
956   1.  Additional CRLFs may precede the first boundary string in the
957       entity.
958
959   2.  Although [RFC2046] permits the boundary string to be quoted, some
960       existing implementations handle a quoted boundary string
961       incorrectly.
962
963   3.  A number of browsers and servers were coded to an early draft of
964       the byteranges specification to use a media type of multipart/
965       x-byteranges, which is almost, but not quite compatible with the
966       version documented in HTTP/1.1.
967
968Appendix B.  Compatibility with Previous Versions
969
970B.1.  Changes from RFC 2068
971
972   Transfer-coding and message lengths all interact in ways that
973   required fixing exactly when chunked encoding is used (to allow for
974   transfer encoding that may not be self delimiting); it was important
975   to straighten out exactly how message lengths are computed.
976   (Section 5.2, see also [Part1], [Part3] and [Part6])
977
978   There are situations where a server (especially a proxy) does not
979   know the full length of a response but is capable of serving a
980   byterange request.  We therefore need a mechanism to allow byteranges
981   with a content-range not indicating the full length of the message.
982   (Section 5.2)
983
984   Range request responses would become very verbose if all meta-data
985   were always returned; by allowing the server to only send needed
986   headers in a 206 response, this problem can be avoided.  (Section 3.1
987   and 5.3)
988
989   Fix problem with unsatisfiable range requests; there are two cases:
990   syntactic problems, and range doesn't exist in the document.  The 416
991   status code was needed to resolve this ambiguity needed to indicate
992   an error for a byte range request that falls outside of the actual
993   contents of a document.  (Section 3.2, 5.2)
994
995B.2.  Changes from RFC 2616
996
997   Clarify that it is not ok to use a weak cache validator in a 206
998   response.  (Section 3.1)
999
1000   Clarify that multipart/byteranges can consist of a single part.
1001   (Appendix A)
1002
1003Appendix C.  Collected ABNF
1004
1005
1006
1007Fielding, et al.        Expires January 13, 2011               [Page 18]
1008
1009Internet-Draft              HTTP/1.1, Part 5                   July 2010
1010
1011
1012   Accept-Ranges = "Accept-Ranges:" OWS Accept-Ranges-v
1013   Accept-Ranges-v = acceptable-ranges
1014
1015   Content-Range = "Content-Range:" OWS Content-Range-v
1016   Content-Range-v = content-range-spec
1017
1018   HTTP-date = <HTTP-date, defined in [Part1], Section 6.1>
1019
1020   If-Range = "If-Range:" OWS If-Range-v
1021   If-Range-v = entity-tag / HTTP-date
1022
1023   OWS = <OWS, defined in [Part1], Section 1.2.2>
1024
1025   Range = "Range:" OWS Range-v
1026   Range-v = byte-ranges-specifier / other-ranges-specifier
1027
1028   acceptable-ranges = ( *( "," OWS ) range-unit *( OWS "," [ OWS
1029    range-unit ] ) ) / "none"
1030
1031   byte-content-range-spec = bytes-unit SP byte-range-resp-spec "/" (
1032    instance-length / "*" )
1033   byte-range-resp-spec = ( first-byte-pos "-" last-byte-pos ) / "*"
1034   byte-range-set = ( *( "," OWS ) byte-range-spec ) / (
1035    suffix-byte-range-spec *( OWS "," [ ( OWS byte-range-spec ) /
1036    suffix-byte-range-spec ] ) )
1037   byte-range-spec = first-byte-pos "-" [ last-byte-pos ]
1038   byte-ranges-specifier = bytes-unit "=" byte-range-set
1039   bytes-unit = "bytes"
1040
1041   content-range-spec = byte-content-range-spec /
1042    other-content-range-spec
1043
1044   entity-tag = <entity-tag, defined in [Part4], Section 2>
1045
1046   first-byte-pos = 1*DIGIT
1047
1048   instance-length = 1*DIGIT
1049
1050   last-byte-pos = 1*DIGIT
1051
1052   other-content-range-spec = other-range-unit SP other-range-resp-spec
1053   other-range-resp-spec = *CHAR
1054   other-range-set = 1*CHAR
1055   other-range-unit = token
1056   other-ranges-specifier = other-range-unit "=" other-range-set
1057
1058   range-unit = bytes-unit / other-range-unit
1059
1060
1061
1062
1063Fielding, et al.        Expires January 13, 2011               [Page 19]
1064
1065Internet-Draft              HTTP/1.1, Part 5                   July 2010
1066
1067
1068   suffix-byte-range-spec = "-" suffix-length
1069   suffix-length = 1*DIGIT
1070
1071   token = <token, defined in [Part1], Section 1.2.2>
1072
1073   ABNF diagnostics:
1074
1075   ; Accept-Ranges defined but not used
1076   ; Content-Range defined but not used
1077   ; If-Range defined but not used
1078   ; Range defined but not used
1079
1080Appendix D.  Change Log (to be removed by RFC Editor before publication)
1081
1082D.1.  Since RFC2616
1083
1084   Extracted relevant partitions from [RFC2616].
1085
1086D.2.  Since draft-ietf-httpbis-p5-range-00
1087
1088   Closed issues:
1089
1090   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/18>: "Cache
1091      validators in 206 responses"
1092      (<http://purl.org/NET/http-errata#ifrange206>)
1093
1094   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and
1095      Informative references"
1096
1097   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/86>: "Normative up-
1098      to-date references"
1099
1100D.3.  Since draft-ietf-httpbis-p5-range-01
1101
1102   Closed issues:
1103
1104   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/55>: "Updating to
1105      RFC4288"
1106
1107   Ongoing work on ABNF conversion
1108   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
1109
1110   o  Add explicit references to BNF syntax and rules imported from
1111      other parts of the specification.
1112
1113
1114
1115
1116
1117
1118
1119Fielding, et al.        Expires January 13, 2011               [Page 20]
1120
1121Internet-Draft              HTTP/1.1, Part 5                   July 2010
1122
1123
1124D.4.  Since draft-ietf-httpbis-p5-range-02
1125
1126   Ongoing work on IANA Message Header Registration
1127   (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>):
1128
1129   o  Reference RFC 3984, and update header registrations for headers
1130      defined in this document.
1131
1132D.5.  Since draft-ietf-httpbis-p5-range-03
1133
1134D.6.  Since draft-ietf-httpbis-p5-range-04
1135
1136   Closed issues:
1137
1138   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/133>: "multipart/
1139      byteranges minimum number of parts"
1140
1141   Ongoing work on ABNF conversion
1142   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
1143
1144   o  Use "/" instead of "|" for alternatives.
1145
1146   o  Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
1147      whitespace ("OWS") and required whitespace ("RWS").
1148
1149   o  Rewrite ABNFs to spell out whitespace rules, factor out header
1150      value format definitions.
1151
1152D.7.  Since draft-ietf-httpbis-p5-range-05
1153
1154   Closed issues:
1155
1156   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/142>: "State base
1157      for *-byte-pos and suffix-length"
1158
1159   Ongoing work on Custom Ranges
1160   (<http://tools.ietf.org/wg/httpbis/trac/ticket/85>):
1161
1162   o  Remove bias in favor of byte ranges; allow custom ranges in ABNF.
1163
1164   Final work on ABNF conversion
1165   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
1166
1167   o  Add appendix containing collected and expanded ABNF, reorganize
1168      ABNF introduction.
1169
1170
1171
1172
1173
1174
1175Fielding, et al.        Expires January 13, 2011               [Page 21]
1176
1177Internet-Draft              HTTP/1.1, Part 5                   July 2010
1178
1179
1180D.8.  Since draft-ietf-httpbis-p5-range-06
1181
1182   Closed issues:
1183
1184   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/161>: "base for
1185      numeric protocol elements"
1186
1187D.9.  Since draft-ietf-httpbis-p5-range-07
1188
1189   Closed issues:
1190
1191   o  Fixed discrepancy in the If-Range definition about allowed
1192      validators.
1193
1194   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/150>: "multipart/
1195      byteranges for custom range units"
1196
1197   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/151>: "range unit
1198      missing from other-ranges-specifier in Range header"
1199
1200   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/198>: "move IANA
1201      registrations for optional status codes"
1202
1203D.10.  Since draft-ietf-httpbis-p5-range-08
1204
1205   No significant changes.
1206
1207D.11.  Since draft-ietf-httpbis-p5-range-09
1208
1209   No significant changes.
1210
1211Index
1212
1213   2
1214      206 Partial Content (status code)  6
1215
1216   4
1217      416 Requested Range Not Satisfiable (status code)  6
1218
1219   A
1220      Accept-Ranges header  7
1221
1222   C
1223      Content-Range header  8
1224
1225   G
1226      Grammar
1227         Accept-Ranges  7
1228
1229
1230
1231Fielding, et al.        Expires January 13, 2011               [Page 22]
1232
1233Internet-Draft              HTTP/1.1, Part 5                   July 2010
1234
1235
1236         Accept-Ranges-v  7
1237         acceptable-ranges  7
1238         byte-content-range-spec  8
1239         byte-range-resp-spec  8
1240         byte-range-set  11
1241         byte-range-spec  11
1242         byte-ranges-specifier  11
1243         bytes-unit  5
1244         Content-Range  8
1245         content-range-spec  8
1246         Content-Range-v  8
1247         first-byte-pos  11
1248         If-Range  10
1249         If-Range-v  10
1250         instance-length  8
1251         last-byte-pos  11
1252         other-range-unit  5
1253         Range  13
1254         range-unit  5
1255         ranges-specifier  11
1256         suffix-byte-range-spec  12
1257         suffix-length  12
1258
1259   H
1260      Headers
1261         Accept-Ranges  7
1262         Content-Range  8
1263         If-Range  10
1264         Range  11
1265
1266   I
1267      If-Range header  10
1268
1269   M
1270      Media Type
1271         multipart/byteranges  16
1272         multipart/x-byteranges  18
1273      multipart/byteranges Media Type  16
1274      multipart/x-byteranges Media Type  18
1275
1276   R
1277      Range header  11
1278
1279   S
1280      Status Codes
1281         206 Partial Content  6
1282         416 Requested Range Not Satisfiable  6
1283
1284
1285
1286
1287Fielding, et al.        Expires January 13, 2011               [Page 23]
1288
1289Internet-Draft              HTTP/1.1, Part 5                   July 2010
1290
1291
1292Authors' Addresses
1293
1294   Roy T. Fielding (editor)
1295   Day Software
1296   23 Corporate Plaza DR, Suite 280
1297   Newport Beach, CA  92660
1298   USA
1299
1300   Phone: +1-949-706-5300
1301   Fax:   +1-949-706-5305
1302   EMail: fielding@gbiv.com
1303   URI:   http://roy.gbiv.com/
1304
1305
1306   Jim Gettys
1307   Alcatel-Lucent Bell Labs
1308   21 Oak Knoll Road
1309   Carlisle, MA  01741
1310   USA
1311
1312   EMail: jg@freedesktop.org
1313   URI:   http://gettys.wordpress.com/
1314
1315
1316   Jeffrey C. Mogul
1317   Hewlett-Packard Company
1318   HP Labs, Large Scale Systems Group
1319   1501 Page Mill Road, MS 1177
1320   Palo Alto, CA  94304
1321   USA
1322
1323   EMail: JeffMogul@acm.org
1324
1325
1326   Henrik Frystyk Nielsen
1327   Microsoft Corporation
1328   1 Microsoft Way
1329   Redmond, WA  98052
1330   USA
1331
1332   EMail: henrikn@microsoft.com
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343Fielding, et al.        Expires January 13, 2011               [Page 24]
1344
1345Internet-Draft              HTTP/1.1, Part 5                   July 2010
1346
1347
1348   Larry Masinter
1349   Adobe Systems, Incorporated
1350   345 Park Ave
1351   San Jose, CA  95110
1352   USA
1353
1354   EMail: LMM@acm.org
1355   URI:   http://larry.masinter.net/
1356
1357
1358   Paul J. Leach
1359   Microsoft Corporation
1360   1 Microsoft Way
1361   Redmond, WA  98052
1362
1363   EMail: paulle@microsoft.com
1364
1365
1366   Tim Berners-Lee
1367   World Wide Web Consortium
1368   MIT Computer Science and Artificial Intelligence Laboratory
1369   The Stata Center, Building 32
1370   32 Vassar Street
1371   Cambridge, MA  02139
1372   USA
1373
1374   EMail: timbl@w3.org
1375   URI:   http://www.w3.org/People/Berners-Lee/
1376
1377
1378   Yves Lafon (editor)
1379   World Wide Web Consortium
1380   W3C / ERCIM
1381   2004, rte des Lucioles
1382   Sophia-Antipolis, AM  06902
1383   France
1384
1385   EMail: ylafon@w3.org
1386   URI:   http://www.raubacapeu.net/people/yves/
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399Fielding, et al.        Expires January 13, 2011               [Page 25]
1400
1401Internet-Draft              HTTP/1.1, Part 5                   July 2010
1402
1403
1404   Julian F. Reschke (editor)
1405   greenbytes GmbH
1406   Hafenweg 16
1407   Muenster, NW  48155
1408   Germany
1409
1410   Phone: +49 251 2807760
1411   Fax:   +49 251 2807761
1412   EMail: julian.reschke@greenbytes.de
1413   URI:   http://greenbytes.de/tech/webdav/
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455Fielding, et al.        Expires January 13, 2011               [Page 26]
1456
Note: See TracBrowser for help on using the repository browser.