draft-ietf-httpbis-p5-range-18.txt | draft-ietf-httpbis-p5-range-19.txt | |||
---|---|---|---|---|
HTTPbis Working Group R. Fielding, Ed. | HTTPbis Working Group R. Fielding, Ed. | |||
Internet-Draft Adobe | Internet-Draft Adobe | |||
Obsoletes: 2616 (if approved) J. Gettys | Obsoletes: 2616 (if approved) Y. Lafon, Ed. | |||
Intended status: Standards Track Alcatel-Lucent | Intended status: Standards Track W3C | |||
Expires: July 7, 2012 J. Mogul | Expires: September 13, 2012 J. Reschke, Ed. | |||
HP | ||||
H. Frystyk | ||||
Microsoft | ||||
L. Masinter | ||||
Adobe | ||||
P. Leach | ||||
Microsoft | ||||
T. Berners-Lee | ||||
W3C/MIT | ||||
Y. Lafon, Ed. | ||||
W3C | ||||
J. Reschke, Ed. | ||||
greenbytes | greenbytes | |||
January 4, 2012 | March 12, 2012 | |||
HTTP/1.1, part 5: Range Requests and Partial Responses | HTTP/1.1, part 5: Range Requests and Partial Responses | |||
draft-ietf-httpbis-p5-range-18 | draft-ietf-httpbis-p5-range-19 | |||
Abstract | Abstract | |||
The Hypertext Transfer Protocol (HTTP) is an application-level | The Hypertext Transfer Protocol (HTTP) is an application-level | |||
protocol for distributed, collaborative, hypertext information | protocol for distributed, collaborative, hypertext information | |||
systems. HTTP has been in use by the World Wide Web global | systems. HTTP has been in use by the World Wide Web global | |||
information initiative since 1990. This document is Part 5 of the | information initiative since 1990. This document is Part 5 of the | |||
seven-part specification that defines the protocol referred to as | seven-part specification that defines the protocol referred to as | |||
"HTTP/1.1" and, taken together, obsoletes RFC 2616. | "HTTP/1.1" and, taken together, obsoletes RFC 2616. | |||
skipping to change at page 1, line 49 | skipping to change at page 1, line 37 | |||
Discussion of this draft should take place on the HTTPBIS working | Discussion of this draft should take place on the HTTPBIS working | |||
group mailing list (ietf-http-wg@w3.org), which is archived at | group mailing list (ietf-http-wg@w3.org), which is archived at | |||
<http://lists.w3.org/Archives/Public/ietf-http-wg/>. | <http://lists.w3.org/Archives/Public/ietf-http-wg/>. | |||
The current issues list is at | The current issues list is at | |||
<http://tools.ietf.org/wg/httpbis/trac/report/3> and related | <http://tools.ietf.org/wg/httpbis/trac/report/3> and related | |||
documents (including fancy diffs) can be found at | documents (including fancy diffs) can be found at | |||
<http://tools.ietf.org/wg/httpbis/>. | <http://tools.ietf.org/wg/httpbis/>. | |||
The changes in this draft are summarized in Appendix D.19. | The changes in this draft are summarized in Appendix D.20. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on July 7, 2012. | This Internet-Draft will expire on September 13, 2012. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2012 IETF Trust and the persons identified as the | Copyright (c) 2012 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 2, line 51 | skipping to change at page 2, line 39 | |||
modifications of such material outside the IETF Standards Process. | modifications of such material outside the IETF Standards Process. | |||
Without obtaining an adequate license from the person(s) controlling | Without obtaining an adequate license from the person(s) controlling | |||
the copyright in such materials, this document may not be modified | the copyright in such materials, this document may not be modified | |||
outside the IETF Standards Process, and derivative works of it may | outside the IETF Standards Process, and derivative works of it may | |||
not be created outside the IETF Standards Process, except to format | not be created outside the IETF Standards Process, except to format | |||
it for publication as an RFC or to translate it into languages other | it for publication as an RFC or to translate it into languages other | |||
than English. | than English. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
1.1. Conformance and Error Handling . . . . . . . . . . . . . . 5 | 1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4 | |||
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 | 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5 | |||
1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 6 | 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 5 | |||
1.2.2. ABNF Rules defined in other Parts of the | 1.2.2. ABNF Rules defined in other Parts of the | |||
Specification . . . . . . . . . . . . . . . . . . . . 6 | Specification . . . . . . . . . . . . . . . . . . . . 5 | |||
2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
2.1. Range Specifier Registry . . . . . . . . . . . . . . . . . 7 | 2.1. Range Specifier Registry . . . . . . . . . . . . . . . . . 6 | |||
3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 7 | 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 6 | |||
3.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 7 | 3.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 6 | |||
3.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 8 | 3.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 7 | |||
4. Combining Ranges . . . . . . . . . . . . . . . . . . . . . . . 8 | 4. Responses to a Range Request . . . . . . . . . . . . . . . . . 7 | |||
4.1. Response to a Single and Multiple Ranges Request . . . . . 7 | ||||
4.2. Combining Ranges . . . . . . . . . . . . . . . . . . . . . 8 | ||||
5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 9 | 5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 9 | |||
5.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 9 | 5.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 9 | |||
5.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 10 | 5.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 10 | |||
5.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 12 | 5.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
5.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 13 | 5.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
5.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 13 | 5.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 12 | |||
5.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 15 | 5.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 14 | |||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 | |||
6.1. Status Code Registration . . . . . . . . . . . . . . . . . 16 | 6.1. Status Code Registration . . . . . . . . . . . . . . . . . 15 | |||
6.2. Header Field Registration . . . . . . . . . . . . . . . . 16 | 6.2. Header Field Registration . . . . . . . . . . . . . . . . 15 | |||
6.3. Range Specifier Registration . . . . . . . . . . . . . . . 16 | 6.3. Range Specifier Registration . . . . . . . . . . . . . . . 16 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 | |||
7.1. Overlapping Ranges . . . . . . . . . . . . . . . . . . . . 17 | 7.1. Overlapping Ranges . . . . . . . . . . . . . . . . . . . . 16 | |||
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 | 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 | 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 | |||
9.2. Informative References . . . . . . . . . . . . . . . . . . 18 | 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 | |||
Appendix A. Internet Media Type multipart/byteranges . . . . . . 18 | Appendix A. Internet Media Type multipart/byteranges . . . . . . 17 | |||
Appendix B. Compatibility with Previous Versions . . . . . . . . 21 | Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 20 | |||
B.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 21 | Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 21 | |||
Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 22 | ||||
Appendix D. Change Log (to be removed by RFC Editor before | Appendix D. Change Log (to be removed by RFC Editor before | |||
publication) . . . . . . . . . . . . . . . . . . . . 23 | publication) . . . . . . . . . . . . . . . . . . . . 22 | |||
D.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 23 | D.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 22 | |||
D.2. Since draft-ietf-httpbis-p5-range-00 . . . . . . . . . . . 23 | D.2. Since draft-ietf-httpbis-p5-range-00 . . . . . . . . . . . 22 | |||
D.3. Since draft-ietf-httpbis-p5-range-01 . . . . . . . . . . . 23 | D.3. Since draft-ietf-httpbis-p5-range-01 . . . . . . . . . . . 22 | |||
D.4. Since draft-ietf-httpbis-p5-range-02 . . . . . . . . . . . 23 | D.4. Since draft-ietf-httpbis-p5-range-02 . . . . . . . . . . . 22 | |||
D.5. Since draft-ietf-httpbis-p5-range-03 . . . . . . . . . . . 24 | D.5. Since draft-ietf-httpbis-p5-range-03 . . . . . . . . . . . 23 | |||
D.6. Since draft-ietf-httpbis-p5-range-04 . . . . . . . . . . . 24 | D.6. Since draft-ietf-httpbis-p5-range-04 . . . . . . . . . . . 23 | |||
D.7. Since draft-ietf-httpbis-p5-range-05 . . . . . . . . . . . 24 | D.7. Since draft-ietf-httpbis-p5-range-05 . . . . . . . . . . . 23 | |||
D.8. Since draft-ietf-httpbis-p5-range-06 . . . . . . . . . . . 24 | D.8. Since draft-ietf-httpbis-p5-range-06 . . . . . . . . . . . 23 | |||
D.9. Since draft-ietf-httpbis-p5-range-07 . . . . . . . . . . . 25 | D.9. Since draft-ietf-httpbis-p5-range-07 . . . . . . . . . . . 24 | |||
D.10. Since draft-ietf-httpbis-p5-range-08 . . . . . . . . . . . 25 | D.10. Since draft-ietf-httpbis-p5-range-08 . . . . . . . . . . . 24 | |||
D.11. Since draft-ietf-httpbis-p5-range-09 . . . . . . . . . . . 25 | D.11. Since draft-ietf-httpbis-p5-range-09 . . . . . . . . . . . 24 | |||
D.12. Since draft-ietf-httpbis-p5-range-10 . . . . . . . . . . . 25 | D.12. Since draft-ietf-httpbis-p5-range-10 . . . . . . . . . . . 24 | |||
D.13. Since draft-ietf-httpbis-p5-range-11 . . . . . . . . . . . 25 | D.13. Since draft-ietf-httpbis-p5-range-11 . . . . . . . . . . . 24 | |||
D.14. Since draft-ietf-httpbis-p5-range-12 . . . . . . . . . . . 26 | D.14. Since draft-ietf-httpbis-p5-range-12 . . . . . . . . . . . 25 | |||
D.15. Since draft-ietf-httpbis-p5-range-13 . . . . . . . . . . . 26 | D.15. Since draft-ietf-httpbis-p5-range-13 . . . . . . . . . . . 25 | |||
D.16. Since draft-ietf-httpbis-p5-range-14 . . . . . . . . . . . 26 | D.16. Since draft-ietf-httpbis-p5-range-14 . . . . . . . . . . . 25 | |||
D.17. Since draft-ietf-httpbis-p5-range-15 . . . . . . . . . . . 26 | D.17. Since draft-ietf-httpbis-p5-range-15 . . . . . . . . . . . 25 | |||
D.18. Since draft-ietf-httpbis-p5-range-16 . . . . . . . . . . . 26 | D.18. Since draft-ietf-httpbis-p5-range-16 . . . . . . . . . . . 25 | |||
D.19. Since draft-ietf-httpbis-p5-range-17 . . . . . . . . . . . 26 | D.19. Since draft-ietf-httpbis-p5-range-17 . . . . . . . . . . . 25 | |||
D.20. Since draft-ietf-httpbis-p5-range-18 . . . . . . . . . . . 25 | ||||
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 | |||
1. Introduction | 1. Introduction | |||
HTTP clients often encounter interrupted data transfers as a result | HTTP clients often encounter interrupted data transfers as a result | |||
of cancelled requests or dropped connections. When a client has | of cancelled requests or dropped connections. When a client has | |||
stored a partial representation, it is desirable to request the | stored a partial representation, it is desirable to request the | |||
remainder of that representation in a subsequent request rather than | remainder of that representation in a subsequent request rather than | |||
transfer the entire representation. There are also a number of Web | transfer the entire representation. There are also a number of Web | |||
applications that benefit from being able to request only a subset of | applications that benefit from being able to request only a subset of | |||
skipping to change at page 6, line 13 | skipping to change at page 5, line 13 | |||
define specific error handling mechanisms, except in cases where it | define specific error handling mechanisms, except in cases where it | |||
has direct impact on security. This is because different uses of the | has direct impact on security. This is because different uses of the | |||
protocol require different error handling strategies; for example, a | protocol require different error handling strategies; for example, a | |||
Web browser may wish to transparently recover from a response where | Web browser may wish to transparently recover from a response where | |||
the Location header field doesn't parse according to the ABNF, | the Location header field doesn't parse according to the ABNF, | |||
whereby in a systems control protocol using HTTP, this type of error | whereby in a systems control protocol using HTTP, this type of error | |||
recovery could lead to dangerous consequences. | recovery could lead to dangerous consequences. | |||
1.2. Syntax Notation | 1.2. Syntax Notation | |||
This specification uses the ABNF syntax defined in Section 1.2 of | This specification uses the Augmented Backus-Naur Form (ABNF) | |||
[Part1] (which extends the syntax defined in [RFC5234] with a list | notation of [RFC5234] with the list rule extension defined in Section | |||
rule). Appendix C shows the collected ABNF, with the list rule | 1.2 of [Part1]. Appendix C shows the collected ABNF with the list | |||
expanded. | rule expanded. | |||
The following core rules are included by reference, as defined in | The following core rules are included by reference, as defined in | |||
[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF | [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF | |||
(CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), | (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), | |||
HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit | HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit | |||
sequence of data), SP (space), and VCHAR (any visible US-ASCII | sequence of data), SP (space), and VCHAR (any visible US-ASCII | |||
character). | character). | |||
Note that all rules derived from token are to be compared case- | Note that all rules derived from token are to be compared case- | |||
insensitively, like range-unit and acceptable-ranges. | insensitively, like range-unit and acceptable-ranges. | |||
1.2.1. Core Rules | 1.2.1. Core Rules | |||
The core rules below are defined in [Part1] and [Part2]: | The core rules below are defined in [Part1] and [Part2]: | |||
OWS = <OWS, defined in [Part1], Section 1.2.2> | OWS = <OWS, defined in [Part1], Section 3.2.1> | |||
token = <token, defined in [Part1], Section 3.2.3> | token = <token, defined in [Part1], Section 3.2.4> | |||
HTTP-date = <HTTP-date, defined in [Part2], Section 8> | HTTP-date = <HTTP-date, defined in [Part2], Section 8> | |||
1.2.2. ABNF Rules defined in other Parts of the Specification | 1.2.2. ABNF Rules defined in other Parts of the Specification | |||
The ABNF rules below are defined in other parts: | The ABNF rules below are defined in other parts: | |||
entity-tag = <entity-tag, defined in [Part4], Section 2.3> | entity-tag = <entity-tag, defined in [Part4], Section 2.3> | |||
2. Range Units | 2. Range Units | |||
skipping to change at page 7, line 29 | skipping to change at page 6, line 29 | |||
range specifier names. | range specifier names. | |||
Registrations MUST include the following fields: | Registrations MUST include the following fields: | |||
o Name | o Name | |||
o Description | o Description | |||
o Pointer to specification text | o Pointer to specification text | |||
Values to be added to this name space are subject to IETF review | Values to be added to this name space require IETF Review (see | |||
([RFC5226], Section 4.1). | [RFC5226], Section 4.1). | |||
The registry itself is maintained at | The registry itself is maintained at | |||
<http://www.iana.org/assignments/http-range-specifiers>. | <http://www.iana.org/assignments/http-range-specifiers>. | |||
3. Status Code Definitions | 3. Status Code Definitions | |||
3.1. 206 Partial Content | 3.1. 206 Partial Content | |||
The server has fulfilled the partial GET request for the resource. | The server has fulfilled the partial GET request for the resource. | |||
The request MUST have included a Range header field (Section 5.4) | The request MUST have included a Range header field (Section 5.4) | |||
indicating the desired range, and MAY have included an If-Range | indicating the desired range, and MAY have included an If-Range | |||
header field (Section 5.3) to make the request conditional. | header field (Section 5.3) to make the request conditional. | |||
The response MUST include the following header fields: | The response MUST include the following header fields: | |||
o Either a Content-Range header field (Section 5.2) indicating the | o Either a Content-Range header field (Section 5.2) indicating the | |||
range included with this response, or a multipart/byteranges | range included with this response, or a multipart/byteranges | |||
Content-Type including Content-Range fields for each part. If a | Content-Type including Content-Range fields for each part. If a | |||
Content-Length header field is present in the response, its value | Content-Length header field is present in the response, its value | |||
MUST match the actual number of octets transmitted in the message- | MUST match the actual number of octets transmitted in the message | |||
body. | body. | |||
o Date | o Date | |||
o Cache-Control, ETag, Expires, Content-Location, Last-Modified, | o Cache-Control, ETag, Expires, Content-Location, Last-Modified, | |||
and/or Vary, if the header field would have been sent in a 200 | and/or Vary, if the header field would have been sent in a 200 | |||
response to the same request | response to the same request | |||
If the 206 response is the result of an If-Range request, the | If the 206 response is the result of an If-Range request, the | |||
response SHOULD NOT include other representation header fields. | response SHOULD NOT include other representation header fields. | |||
Otherwise, the response MUST include all of the representation header | Otherwise, the response MUST include all of the representation header | |||
fields that would have been returned with a 200 (OK) response to the | fields that would have been returned with a 200 (OK) response to the | |||
same request. | same request. | |||
Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to | ||||
determine freshness for 206 responses. | ||||
3.2. 416 Requested Range Not Satisfiable | 3.2. 416 Requested Range Not Satisfiable | |||
A server SHOULD return a response with this status code if a request | A server SHOULD return a response with this status code if a request | |||
included a Range header field (Section 5.4), and none of the ranges- | included a Range header field (Section 5.4), and none of the ranges- | |||
specifier values in this field overlap the current extent of the | specifier values in this field overlap the current extent of the | |||
selected resource, and the request did not include an If-Range header | selected resource, and the request did not include an If-Range header | |||
field (Section 5.3). (For byte-ranges, this means that the first- | field (Section 5.3). (For byte-ranges, this means that the first- | |||
byte-pos of all of the byte-range-spec values were greater than the | byte-pos of all of the byte-range-spec values were greater than the | |||
current length of the selected resource.) | current length of the selected resource.) | |||
When this status code is returned for a byte-range request, the | When this status code is returned for a byte-range request, the | |||
response SHOULD include a Content-Range header field specifying the | response SHOULD include a Content-Range header field specifying the | |||
current length of the representation (see Section 5.2). This | current length of the representation (see Section 5.2). This | |||
response MUST NOT use the multipart/byteranges content-type. | response MUST NOT use the multipart/byteranges content-type. For | |||
example, | ||||
4. Combining Ranges | HTTP/1.1 416 Requested Range Not Satisfiable | |||
Date: Mon, 20 Jan 2012 15:41:54 GMT | ||||
Content-Range: bytes */47022 | ||||
Content-Type: image/gif | ||||
Note: Clients cannot depend on servers to send a 416 (Requested | ||||
range not satisfiable) response instead of a 200 (OK) response for | ||||
an unsatisfiable Range header field, since not all servers | ||||
implement this header field. | ||||
4. Responses to a Range Request | ||||
4.1. Response to a Single and Multiple Ranges Request | ||||
When an HTTP message includes the content of a single range (for | ||||
example, a response to a request for a single range, or to a request | ||||
for a set of ranges that overlap without any holes), this content is | ||||
transmitted with a Content-Range header field, and a Content-Length | ||||
header field showing the number of bytes actually transferred. For | ||||
example, | ||||
HTTP/1.1 206 Partial Content | ||||
Date: Wed, 15 Nov 1995 06:25:24 GMT | ||||
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT | ||||
Content-Range: bytes 21010-47021/47022 | ||||
Content-Length: 26012 | ||||
Content-Type: image/gif | ||||
When an HTTP message includes the content of multiple ranges (for | ||||
example, a response to a request for multiple non-overlapping | ||||
ranges), these are transmitted as a multipart message. The multipart | ||||
media type used for this purpose is "multipart/byteranges" as defined | ||||
in Appendix A. | ||||
A server MAY combine requested ranges when those ranges are | ||||
overlapping (see Section 7). | ||||
A response to a request for a single range MUST NOT be sent using the | ||||
multipart/byteranges media type. A response to a request for | ||||
multiple ranges, whose result is a single range, MAY be sent as a | ||||
multipart/byteranges media type with one part. A client that cannot | ||||
decode a multipart/byteranges message MUST NOT ask for multiple | ||||
ranges in a single request. | ||||
When a client requests multiple ranges in one request, the server | ||||
SHOULD return them in the order that they appeared in the request. | ||||
4.2. Combining Ranges | ||||
A response might transfer only a subrange of a representation if the | A response might transfer only a subrange of a representation if the | |||
connection closed prematurely or if the request used one or more | connection closed prematurely or if the request used one or more | |||
Range specifications. After several such transfers, a client might | Range specifications. After several such transfers, a client might | |||
have received several ranges of the same representation. These | have received several ranges of the same representation. These | |||
ranges can only be safely combined if they all have in common the | ranges can only be safely combined if they all have in common the | |||
same strong validator, where "strong validator" is defined to be | same strong validator, where "strong validator" is defined to be | |||
either an entity-tag that is not marked as weak (Section 2.3 of | either an entity-tag that is not marked as weak (Section 2.3 of | |||
[Part4]) or, if no entity-tag is provided, a Last-Modified value that | [Part4]) or, if no entity-tag is provided, a Last-Modified value that | |||
is strong in the sense defined by Section 2.2.2 of [Part4]. | is strong in the sense defined by Section 2.2.2 of [Part4]. | |||
skipping to change at page 9, line 19 | skipping to change at page 9, line 21 | |||
If the new response is a 206 (Partial Content) response and at least | If the new response is a 206 (Partial Content) response and at least | |||
one of the matching stored responses is a 200 (OK), then the combined | one of the matching stored responses is a 200 (OK), then the combined | |||
response header fields consist of the most recent 200 response's | response header fields consist of the most recent 200 response's | |||
header fields. If all of the matching stored responses are 206 | header fields. If all of the matching stored responses are 206 | |||
responses, then the stored response with the most header fields is | responses, then the stored response with the most header fields is | |||
used as the source of header fields for the combined response, except | used as the source of header fields for the combined response, except | |||
that the client MUST use other header fields provided in the new | that the client MUST use other header fields provided in the new | |||
response, aside from Content-Range, to replace all instances of the | response, aside from Content-Range, to replace all instances of the | |||
corresponding header fields in the stored response. | corresponding header fields in the stored response. | |||
The combined response message-body consists of the union of partial | The combined response message body consists of the union of partial | |||
content ranges in the new response and each of the selected | content ranges in the new response and each of the selected | |||
responses. If the union consists of the entire range of the | responses. If the union consists of the entire range of the | |||
representation, then the combined response MUST be recorded as a | representation, then the combined response MUST be recorded as a | |||
complete 200 (OK) response with a Content-Length header field that | complete 200 (OK) response with a Content-Length header field that | |||
reflects the complete length. Otherwise, the combined response(s) | reflects the complete length. Otherwise, the combined response(s) | |||
MUST include a Content-Range header field describing the included | MUST include a Content-Range header field describing the included | |||
range(s) and be recorded as incomplete. If the union consists of a | range(s) and be recorded as incomplete. If the union consists of a | |||
discontinuous range of the representation, then the client MAY store | discontinuous range of the representation, then the client MAY store | |||
it as either a multipart range response or as multiple 206 responses | it as either a multipart range response or as multiple 206 responses | |||
with one continuous range each. | with one continuous range each. | |||
skipping to change at page 11, line 33 | skipping to change at page 11, line 36 | |||
bytes 500-999/1234 | bytes 500-999/1234 | |||
o All except for the first 500 bytes: | o All except for the first 500 bytes: | |||
bytes 500-1233/1234 | bytes 500-1233/1234 | |||
o The last 500 bytes: | o The last 500 bytes: | |||
bytes 734-1233/1234 | bytes 734-1233/1234 | |||
When an HTTP message includes the content of a single range (for | If the server ignores a byte-range-spec (for example if it is | |||
example, a response to a request for a single range, or to a request | syntactically invalid, or if it may be seen as a denial-of-service | |||
for a set of ranges that overlap without any holes), this content is | attack), the server SHOULD treat the request as if the invalid Range | |||
transmitted with a Content-Range header field, and a Content-Length | ||||
header field showing the number of bytes actually transferred. For | ||||
example, | ||||
HTTP/1.1 206 Partial Content | ||||
Date: Wed, 15 Nov 1995 06:25:24 GMT | ||||
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT | ||||
Content-Range: bytes 21010-47021/47022 | ||||
Content-Length: 26012 | ||||
Content-Type: image/gif | ||||
When an HTTP message includes the content of multiple ranges (for | ||||
example, a response to a request for multiple non-overlapping | ||||
ranges), these are transmitted as a multipart message. The multipart | ||||
media type used for this purpose is "multipart/byteranges" as defined | ||||
in Appendix A. | ||||
A response to a request for a single range MUST NOT be sent using the | ||||
multipart/byteranges media type. A response to a request for | ||||
multiple ranges, whose result is a single range, MAY be sent as a | ||||
multipart/byteranges media type with one part. A client that cannot | ||||
decode a multipart/byteranges message MUST NOT ask for multiple | ||||
ranges in a single request. | ||||
When a client requests multiple ranges in one request, the server | ||||
SHOULD return them in the order that they appeared in the request. | ||||
If the server ignores a byte-range-spec because it is syntactically | ||||
invalid, the server SHOULD treat the request as if the invalid Range | ||||
header field did not exist. (Normally, this means return a 200 | header field did not exist. (Normally, this means return a 200 | |||
response containing the full representation). | response containing the full representation). | |||
If the server receives a request (other than one including an If- | ||||
Range header field) with an unsatisfiable Range header field (that | ||||
is, all of whose byte-range-spec values have a first-byte-pos value | ||||
greater than the current length of the selected resource), it SHOULD | ||||
return a response code of 416 (Requested range not satisfiable) | ||||
(Section 3.2). | ||||
Note: Clients cannot depend on servers to send a 416 (Requested | ||||
range not satisfiable) response instead of a 200 (OK) response for | ||||
an unsatisfiable Range header field, since not all servers | ||||
implement this header field. | ||||
5.3. If-Range | 5.3. If-Range | |||
If a client has a partial copy of a representation and wishes to have | If a client has a partial copy of a representation and wishes to have | |||
an up-to-date copy of the entire representation, it could use the | an up-to-date copy of the entire representation, it could use the | |||
Range header field with a conditional GET (using either or both of | Range header field with a conditional GET (using either or both of | |||
If-Unmodified-Since and If-Match.) However, if the condition fails | If-Unmodified-Since and If-Match.) However, if the condition fails | |||
because the representation has been modified, the client would then | because the representation has been modified, the client would then | |||
have to make a second request to obtain the entire current | have to make a second request to obtain the entire current | |||
representation. | representation. | |||
skipping to change at page 13, line 37 | skipping to change at page 12, line 47 | |||
5.4. Range | 5.4. Range | |||
5.4.1. Byte Ranges | 5.4.1. Byte Ranges | |||
Since all HTTP representations are transferred as sequences of bytes, | Since all HTTP representations are transferred as sequences of bytes, | |||
the concept of a byte range is meaningful for any HTTP | the concept of a byte range is meaningful for any HTTP | |||
representation. (However, not all clients and servers need to | representation. (However, not all clients and servers need to | |||
support byte-range operations.) | support byte-range operations.) | |||
Byte range specifications in HTTP apply to the sequence of bytes in | Byte range specifications in HTTP apply to the sequence of bytes in | |||
the representation body (not necessarily the same as the message- | the representation body (not necessarily the same as the message | |||
body). | body). | |||
A byte range operation MAY specify a single range of bytes, or a set | A byte range operation MAY specify a single range of bytes, or a set | |||
of ranges within a single representation. | of ranges within a single representation. | |||
byte-ranges-specifier = bytes-unit "=" byte-range-set | byte-ranges-specifier = bytes-unit "=" byte-range-set | |||
byte-range-set = 1#( byte-range-spec / suffix-byte-range-spec ) | byte-range-set = 1#( byte-range-spec / suffix-byte-range-spec ) | |||
byte-range-spec = first-byte-pos "-" [ last-byte-pos ] | byte-range-spec = first-byte-pos "-" [ last-byte-pos ] | |||
first-byte-pos = 1*DIGIT | first-byte-pos = 1*DIGIT | |||
last-byte-pos = 1*DIGIT | last-byte-pos = 1*DIGIT | |||
skipping to change at page 17, line 31 | skipping to change at page 16, line 40 | |||
some suggestions for reducing security risks. | some suggestions for reducing security risks. | |||
7.1. Overlapping Ranges | 7.1. Overlapping Ranges | |||
Range requests containing overlapping ranges may lead to the | Range requests containing overlapping ranges may lead to the | |||
situation where a server is sending far more data than the size of | situation where a server is sending far more data than the size of | |||
the complete resource representation. | the complete resource representation. | |||
8. Acknowledgments | 8. Acknowledgments | |||
See Section 11 of [Part1]. | See Section 9 of [Part1]. | |||
9. References | 9. References | |||
9.1. Normative References | 9.1. Normative References | |||
[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | [Part1] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., | |||
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | "HTTP/1.1, part 1: URIs, Connections, and Message | |||
and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, | Parsing", draft-ietf-httpbis-p1-messaging-19 (work in | |||
and Message Parsing", draft-ietf-httpbis-p1-messaging-18 | progress), March 2012. | |||
(work in progress), January 2012. | ||||
[Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | [Part2] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., | |||
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | "HTTP/1.1, part 2: Message Semantics", | |||
and J. Reschke, Ed., "HTTP/1.1, part 2: Message | draft-ietf-httpbis-p2-semantics-19 (work in progress), | |||
Semantics", draft-ietf-httpbis-p2-semantics-18 (work in | March 2012. | |||
progress), January 2012. | ||||
[Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | [Part4] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., | |||
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | "HTTP/1.1, part 4: Conditional Requests", | |||
and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional | draft-ietf-httpbis-p4-conditional-19 (work in progress), | |||
Requests", draft-ietf-httpbis-p4-conditional-18 (work in | March 2012. | |||
progress), January 2012. | ||||
[Part6] Fielding, R., Ed., Lafon, Y., Ed., Nottingham, M., Ed., | ||||
and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", | ||||
draft-ietf-httpbis-p6-cache-19 (work in progress), | ||||
March 2012. | ||||
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | |||
Extensions (MIME) Part Two: Media Types", RFC 2046, | Extensions (MIME) Part Two: Media Types", RFC 2046, | |||
November 1996. | November 1996. | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax | [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax | |||
Specifications: ABNF", STD 68, RFC 5234, January 2008. | Specifications: ABNF", STD 68, RFC 5234, January 2008. | |||
skipping to change at page 18, line 38 | skipping to change at page 17, line 49 | |||
Registration Procedures", BCP 13, RFC 4288, December 2005. | Registration Procedures", BCP 13, RFC 4288, December 2005. | |||
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an | [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an | |||
IANA Considerations Section in RFCs", BCP 26, RFC 5226, | IANA Considerations Section in RFCs", BCP 26, RFC 5226, | |||
May 2008. | May 2008. | |||
Appendix A. Internet Media Type multipart/byteranges | Appendix A. Internet Media Type multipart/byteranges | |||
When an HTTP 206 (Partial Content) response message includes the | When an HTTP 206 (Partial Content) response message includes the | |||
content of multiple ranges (a response to a request for multiple non- | content of multiple ranges (a response to a request for multiple non- | |||
overlapping ranges), these are transmitted as a multipart message- | overlapping ranges), these are transmitted as a multipart message | |||
body ([RFC2046], Section 5.1). The media type for this purpose is | body ([RFC2046], Section 5.1). The media type for this purpose is | |||
called "multipart/byteranges". The following is to be registered | called "multipart/byteranges". The following is to be registered | |||
with IANA [RFC4288]. | with IANA [RFC4288]. | |||
Note: Despite the name "multipart/byteranges" is not limited to | Note: Despite the name "multipart/byteranges" is not limited to | |||
the byte ranges only. | the byte ranges only. | |||
The multipart/byteranges media type includes one or more parts, each | The multipart/byteranges media type includes one or more parts, each | |||
with its own Content-Type and Content-Range fields. The required | with its own Content-Type and Content-Range fields. The required | |||
boundary parameter specifies the boundary string used to separate | boundary parameter specifies the boundary string used to separate | |||
skipping to change at page 21, line 10 | skipping to change at page 20, line 10 | |||
2. Although [RFC2046] permits the boundary string to be quoted, some | 2. Although [RFC2046] permits the boundary string to be quoted, some | |||
existing implementations handle a quoted boundary string | existing implementations handle a quoted boundary string | |||
incorrectly. | incorrectly. | |||
3. A number of browsers and servers were coded to an early draft of | 3. A number of browsers and servers were coded to an early draft of | |||
the byteranges specification to use a media type of multipart/ | the byteranges specification to use a media type of multipart/ | |||
x-byteranges, which is almost, but not quite compatible with the | x-byteranges, which is almost, but not quite compatible with the | |||
version documented in HTTP/1.1. | version documented in HTTP/1.1. | |||
Appendix B. Compatibility with Previous Versions | Appendix B. Changes from RFC 2616 | |||
B.1. Changes from RFC 2616 | ||||
Clarify that it is not ok to use a weak validator in a 206 response. | Clarify that it is not ok to use a weak validator in a 206 response. | |||
(Section 3.1) | (Section 3.1) | |||
Change ABNF productions for header fields to only define the field | Change ABNF productions for header fields to only define the field | |||
value. (Section 5) | value. (Section 5) | |||
Clarify that multipart/byteranges can consist of a single part. | Clarify that multipart/byteranges can consist of a single part. | |||
(Appendix A) | (Appendix A) | |||
Appendix C. Collected ABNF | Appendix C. Collected ABNF | |||
Accept-Ranges = acceptable-ranges | Accept-Ranges = acceptable-ranges | |||
Content-Range = byte-content-range-spec / other-content-range-spec | Content-Range = byte-content-range-spec / other-content-range-spec | |||
HTTP-date = <HTTP-date, defined in [Part2], Section 8> | HTTP-date = <HTTP-date, defined in [Part2], Section 8> | |||
If-Range = entity-tag / HTTP-date | If-Range = entity-tag / HTTP-date | |||
OWS = <OWS, defined in [Part1], Section 1.2.2> | OWS = <OWS, defined in [Part1], Section 3.2.1> | |||
Range = byte-ranges-specifier / other-ranges-specifier | Range = byte-ranges-specifier / other-ranges-specifier | |||
acceptable-ranges = ( *( "," OWS ) range-unit *( OWS "," [ OWS | acceptable-ranges = ( *( "," OWS ) range-unit *( OWS "," [ OWS | |||
range-unit ] ) ) / "none" | range-unit ] ) ) / "none" | |||
byte-content-range-spec = bytes-unit SP byte-range-resp-spec "/" ( | byte-content-range-spec = bytes-unit SP byte-range-resp-spec "/" ( | |||
instance-length / "*" ) | instance-length / "*" ) | |||
byte-range-resp-spec = ( first-byte-pos "-" last-byte-pos ) / "*" | byte-range-resp-spec = ( first-byte-pos "-" last-byte-pos ) / "*" | |||
byte-range-set = ( *( "," OWS ) byte-range-spec ) / ( | byte-range-set = ( *( "," OWS ) byte-range-spec ) / ( | |||
skipping to change at page 22, line 51 | skipping to change at page 21, line 51 | |||
other-range-resp-spec = *CHAR | other-range-resp-spec = *CHAR | |||
other-range-set = 1*CHAR | other-range-set = 1*CHAR | |||
other-range-unit = token | other-range-unit = token | |||
other-ranges-specifier = other-range-unit "=" other-range-set | other-ranges-specifier = other-range-unit "=" other-range-set | |||
range-unit = bytes-unit / other-range-unit | range-unit = bytes-unit / other-range-unit | |||
suffix-byte-range-spec = "-" suffix-length | suffix-byte-range-spec = "-" suffix-length | |||
suffix-length = 1*DIGIT | suffix-length = 1*DIGIT | |||
token = <token, defined in [Part1], Section 3.2.3> | token = <token, defined in [Part1], Section 3.2.4> | |||
ABNF diagnostics: | ABNF diagnostics: | |||
; Accept-Ranges defined but not used | ; Accept-Ranges defined but not used | |||
; Content-Range defined but not used | ; Content-Range defined but not used | |||
; If-Range defined but not used | ; If-Range defined but not used | |||
; Range defined but not used | ; Range defined but not used | |||
Appendix D. Change Log (to be removed by RFC Editor before publication) | Appendix D. Change Log (to be removed by RFC Editor before publication) | |||
D.1. Since RFC 2616 | D.1. Since RFC 2616 | |||
skipping to change at page 26, line 47 | skipping to change at page 25, line 47 | |||
o <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/301>: "Content- | o <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/301>: "Content- | |||
Range on responses other than 206" | Range on responses other than 206" | |||
o <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/319>: "case | o <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/319>: "case | |||
sensitivity of ranges in p5" | sensitivity of ranges in p5" | |||
D.19. Since draft-ietf-httpbis-p5-range-17 | D.19. Since draft-ietf-httpbis-p5-range-17 | |||
None. | None. | |||
D.20. Since draft-ietf-httpbis-p5-range-18 | ||||
Closed issues: | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/311>: "Add | ||||
limitations to Range to reduce its use as a denial-of-service | ||||
tool" | ||||
Index | Index | |||
2 | 2 | |||
206 Partial Content (status code) 7 | 206 Partial Content (status code) 6 | |||
4 | 4 | |||
416 Requested Range Not Satisfiable (status code) 8 | 416 Requested Range Not Satisfiable (status code) 7 | |||
A | A | |||
Accept-Ranges header field 9 | Accept-Ranges header field 9 | |||
C | C | |||
Content-Range header field 10 | Content-Range header field 10 | |||
G | G | |||
Grammar | Grammar | |||
Accept-Ranges 9 | Accept-Ranges 9 | |||
acceptable-ranges 9 | acceptable-ranges 9 | |||
byte-content-range-spec 10 | byte-content-range-spec 10 | |||
byte-range-resp-spec 10 | byte-range-resp-spec 10 | |||
byte-range-set 13 | byte-range-set 13 | |||
byte-range-spec 13 | byte-range-spec 13 | |||
byte-ranges-specifier 13 | byte-ranges-specifier 13 | |||
bytes-unit 6 | bytes-unit 5 | |||
Content-Range 10 | Content-Range 10 | |||
first-byte-pos 13 | first-byte-pos 13 | |||
If-Range 12 | If-Range 12 | |||
instance-length 10 | instance-length 10 | |||
last-byte-pos 13 | last-byte-pos 13 | |||
other-range-unit 6 | other-range-unit 5 | |||
Range 15 | Range 14 | |||
range-unit 6 | range-unit 5 | |||
ranges-specifier 13 | ranges-specifier 13 | |||
suffix-byte-range-spec 14 | suffix-byte-range-spec 13 | |||
suffix-length 14 | suffix-length 13 | |||
H | H | |||
Header Fields | Header Fields | |||
Accept-Ranges 9 | Accept-Ranges 9 | |||
Content-Range 10 | Content-Range 10 | |||
If-Range 12 | If-Range 11 | |||
Range 13 | Range 12 | |||
I | I | |||
If-Range header field 12 | If-Range header field 11 | |||
M | M | |||
Media Type | Media Type | |||
multipart/byteranges 18 | multipart/byteranges 17 | |||
multipart/x-byteranges 21 | multipart/x-byteranges 20 | |||
multipart/byteranges Media Type 18 | multipart/byteranges Media Type 17 | |||
multipart/x-byteranges Media Type 21 | multipart/x-byteranges Media Type 20 | |||
R | R | |||
Range header field 13 | Range header field 12 | |||
S | S | |||
Status Codes | Status Codes | |||
206 Partial Content 7 | 206 Partial Content 6 | |||
416 Requested Range Not Satisfiable 8 | 416 Requested Range Not Satisfiable 7 | |||
Authors' Addresses | Authors' Addresses | |||
Roy T. Fielding (editor) | Roy T. Fielding (editor) | |||
Adobe Systems Incorporated | Adobe Systems Incorporated | |||
345 Park Ave | 345 Park Ave | |||
San Jose, CA 95110 | San Jose, CA 95110 | |||
USA | USA | |||
EMail: fielding@gbiv.com | EMail: fielding@gbiv.com | |||
URI: http://roy.gbiv.com/ | URI: http://roy.gbiv.com/ | |||
Jim Gettys | ||||
Alcatel-Lucent Bell Labs | ||||
21 Oak Knoll Road | ||||
Carlisle, MA 01741 | ||||
USA | ||||
EMail: jg@freedesktop.org | ||||
URI: http://gettys.wordpress.com/ | ||||
Jeffrey C. Mogul | ||||
Hewlett-Packard Company | ||||
HP Labs, Large Scale Systems Group | ||||
1501 Page Mill Road, MS 1177 | ||||
Palo Alto, CA 94304 | ||||
USA | ||||
EMail: JeffMogul@acm.org | ||||
Henrik Frystyk Nielsen | ||||
Microsoft Corporation | ||||
1 Microsoft Way | ||||
Redmond, WA 98052 | ||||
USA | ||||
EMail: henrikn@microsoft.com | ||||
Larry Masinter | ||||
Adobe Systems Incorporated | ||||
345 Park Ave | ||||
San Jose, CA 95110 | ||||
USA | ||||
EMail: LMM@acm.org | ||||
URI: http://larry.masinter.net/ | ||||
Paul J. Leach | ||||
Microsoft Corporation | ||||
1 Microsoft Way | ||||
Redmond, WA 98052 | ||||
EMail: paulle@microsoft.com | ||||
Tim Berners-Lee | ||||
World Wide Web Consortium | ||||
MIT Computer Science and Artificial Intelligence Laboratory | ||||
The Stata Center, Building 32 | ||||
32 Vassar Street | ||||
Cambridge, MA 02139 | ||||
USA | ||||
EMail: timbl@w3.org | ||||
URI: http://www.w3.org/People/Berners-Lee/ | ||||
Yves Lafon (editor) | Yves Lafon (editor) | |||
World Wide Web Consortium | World Wide Web Consortium | |||
W3C / ERCIM | W3C / ERCIM | |||
2004, rte des Lucioles | 2004, rte des Lucioles | |||
Sophia-Antipolis, AM 06902 | Sophia-Antipolis, AM 06902 | |||
France | France | |||
EMail: ylafon@w3.org | EMail: ylafon@w3.org | |||
URI: http://www.raubacapeu.net/people/yves/ | URI: http://www.raubacapeu.net/people/yves/ | |||
Julian F. Reschke (editor) | Julian F. Reschke (editor) | |||
End of changes. 41 change blocks. | ||||
216 lines changed or deleted | 172 lines changed or added | |||
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |