source: draft-ietf-httpbis/12/draft-ietf-httpbis-p5-range-12.txt @ 1515

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

prepare publication of -12 drafts on 2010-10-25

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