source: draft-ietf-httpbis/11/draft-ietf-httpbis-p5-range-11.txt @ 973

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

prepare publication of -11 drafts on 2010-08-04.

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