draft-lafon-rfc2616bis-03.txt | draft-lafon-rfc2616bis-04.txt | |||
---|---|---|---|---|
Network Working Group R. Fielding | Network Working Group R. Fielding | |||
Internet-Draft Day Software | Internet-Draft Day Software | |||
Obsoletes: 2616 (if approved) J. Gettys | Obsoletes: 2616 (if approved) J. Gettys | |||
Intended status: Standards Track J. Mogul | Intended status: Standards Track One Laptop per Child | |||
Expires: January 1, 2008 HP | Expires: May 21, 2008 J. Mogul | |||
HP | ||||
H. Frystyk | H. Frystyk | |||
Microsoft | Microsoft | |||
L. Masinter | L. Masinter | |||
Adobe Systems | Adobe Systems | |||
P. Leach | P. Leach | |||
Microsoft | Microsoft | |||
T. Berners-Lee | T. Berners-Lee | |||
W3C/MIT | W3C/MIT | |||
Y. Lafon, Ed. | Y. Lafon, Ed. | |||
W3C | W3C | |||
J. Reschke, Ed. | J. Reschke, Ed. | |||
greenbytes | greenbytes | |||
June 30, 2007 | November 18, 2007 | |||
Hypertext Transfer Protocol -- HTTP/1.1 | Hypertext Transfer Protocol -- HTTP/1.1 | |||
draft-lafon-rfc2616bis-03 | draft-lafon-rfc2616bis-04 | |||
Status of this Memo | Status of this Memo | |||
By submitting this Internet-Draft, each author represents that any | By submitting this Internet-Draft, each author represents that any | |||
applicable patent or other IPR claims of which he or she is aware | applicable patent or other IPR claims of which he or she is aware | |||
have been or will be disclosed, and any of which he or she becomes | have been or will be disclosed, and any of which he or she becomes | |||
aware will be disclosed, in accordance with Section 6 of BCP 79. | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
skipping to change at page 1, line 48 | skipping to change at page 1, line 49 | |||
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." | |||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
This Internet-Draft will expire on January 1, 2008. | This Internet-Draft will expire on May 21, 2008. | |||
Copyright Notice | Copyright Notice | |||
Copyright (C) The IETF Trust (2007). | Copyright (C) The IETF Trust (2007). | |||
Abstract | Abstract | |||
The Hypertext Transfer Protocol (HTTP) is an application-level | The Hypertext Transfer Protocol (HTTP) is an application-level | |||
protocol for distributed, collaborative, hypermedia information | protocol for distributed, collaborative, hypermedia information | |||
systems. It is a generic, stateless, protocol which can be used for | systems. It is a generic, stateless, protocol which can be used for | |||
skipping to change at page 5, line 7 | skipping to change at page 5, line 7 | |||
text in word wrapping, page breaks, list formatting, reference | text in word wrapping, page breaks, list formatting, reference | |||
formatting, whitespace usage and appendix numbering. Otherwise, it | formatting, whitespace usage and appendix numbering. Otherwise, it | |||
is supposed to contain an accurate copy of the original specification | is supposed to contain an accurate copy of the original specification | |||
text. See <http://www.w3.org/Protocols/HTTP/1.1/ | text. See <http://www.w3.org/Protocols/HTTP/1.1/ | |||
rfc2616bis-00-from-rfc2616.diff.html> for a comparison between both | rfc2616bis-00-from-rfc2616.diff.html> for a comparison between both | |||
documents, as generated by "rfcdiff" | documents, as generated by "rfcdiff" | |||
(<http://tools.ietf.org/tools/rfcdiff/>). | (<http://tools.ietf.org/tools/rfcdiff/>). | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 12 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . 12 | 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 12 | 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 13 | |||
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . 13 | 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . 14 | |||
1.4. Overall Operation . . . . . . . . . . . . . . . . . . . 17 | 1.4. Overall Operation . . . . . . . . . . . . . . . . . . . 18 | |||
2. Notational Conventions and Generic Grammar . . . . . . . . . 20 | 2. Notational Conventions and Generic Grammar . . . . . . . . . 21 | |||
2.1. Augmented BNF . . . . . . . . . . . . . . . . . . . . . 20 | 2.1. Augmented BNF . . . . . . . . . . . . . . . . . . . . . 21 | |||
2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . . 22 | 2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . . 23 | |||
3. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 24 | 3. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 25 | |||
3.1. HTTP Version . . . . . . . . . . . . . . . . . . . . . . 24 | 3.1. HTTP Version . . . . . . . . . . . . . . . . . . . . . . 25 | |||
3.2. Uniform Resource Identifiers . . . . . . . . . . . . . . 25 | 3.2. Uniform Resource Identifiers . . . . . . . . . . . . . . 26 | |||
3.2.1. General Syntax . . . . . . . . . . . . . . . . . . . 25 | 3.2.1. General Syntax . . . . . . . . . . . . . . . . . . . 26 | |||
3.2.2. http URL . . . . . . . . . . . . . . . . . . . . . . 26 | 3.2.2. http URL . . . . . . . . . . . . . . . . . . . . . . 27 | |||
3.2.3. URI Comparison . . . . . . . . . . . . . . . . . . . 26 | 3.2.3. URI Comparison . . . . . . . . . . . . . . . . . . . 27 | |||
3.3. Date/Time Formats . . . . . . . . . . . . . . . . . . . 27 | 3.3. Date/Time Formats . . . . . . . . . . . . . . . . . . . 28 | |||
3.3.1. Full Date . . . . . . . . . . . . . . . . . . . . . 27 | 3.3.1. Full Date . . . . . . . . . . . . . . . . . . . . . 28 | |||
3.3.2. Delta Seconds . . . . . . . . . . . . . . . . . . . 28 | 3.3.2. Delta Seconds . . . . . . . . . . . . . . . . . . . 29 | |||
3.4. Character Sets . . . . . . . . . . . . . . . . . . . . . 28 | 3.4. Character Sets . . . . . . . . . . . . . . . . . . . . . 29 | |||
3.4.1. Missing Charset . . . . . . . . . . . . . . . . . . 29 | 3.4.1. Missing Charset . . . . . . . . . . . . . . . . . . 30 | |||
3.5. Content Codings . . . . . . . . . . . . . . . . . . . . 30 | 3.5. Content Codings . . . . . . . . . . . . . . . . . . . . 31 | |||
3.6. Transfer Codings . . . . . . . . . . . . . . . . . . . . 31 | 3.6. Transfer Codings . . . . . . . . . . . . . . . . . . . . 32 | |||
3.6.1. Chunked Transfer Coding . . . . . . . . . . . . . . 32 | 3.6.1. Chunked Transfer Coding . . . . . . . . . . . . . . 33 | |||
3.7. Media Types . . . . . . . . . . . . . . . . . . . . . . 33 | 3.7. Media Types . . . . . . . . . . . . . . . . . . . . . . 34 | |||
3.7.1. Canonicalization and Text Defaults . . . . . . . . . 34 | 3.7.1. Canonicalization and Text Defaults . . . . . . . . . 35 | |||
3.7.2. Multipart Types . . . . . . . . . . . . . . . . . . 34 | 3.7.2. Multipart Types . . . . . . . . . . . . . . . . . . 35 | |||
3.8. Product Tokens . . . . . . . . . . . . . . . . . . . . . 35 | 3.8. Product Tokens . . . . . . . . . . . . . . . . . . . . . 36 | |||
3.9. Quality Values . . . . . . . . . . . . . . . . . . . . . 36 | 3.9. Quality Values . . . . . . . . . . . . . . . . . . . . . 37 | |||
3.10. Language Tags . . . . . . . . . . . . . . . . . . . . . 36 | 3.10. Language Tags . . . . . . . . . . . . . . . . . . . . . 37 | |||
3.11. Entity Tags . . . . . . . . . . . . . . . . . . . . . . 37 | 3.11. Entity Tags . . . . . . . . . . . . . . . . . . . . . . 38 | |||
3.12. Range Units . . . . . . . . . . . . . . . . . . . . . . 37 | 3.12. Range Units . . . . . . . . . . . . . . . . . . . . . . 38 | |||
4. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . 39 | 4. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . 40 | |||
4.1. Message Types . . . . . . . . . . . . . . . . . . . . . 39 | 4.1. Message Types . . . . . . . . . . . . . . . . . . . . . 40 | |||
4.2. Message Headers . . . . . . . . . . . . . . . . . . . . 39 | 4.2. Message Headers . . . . . . . . . . . . . . . . . . . . 40 | |||
4.3. Message Body . . . . . . . . . . . . . . . . . . . . . . 40 | 4.3. Message Body . . . . . . . . . . . . . . . . . . . . . . 41 | |||
4.4. Message Length . . . . . . . . . . . . . . . . . . . . . 41 | 4.4. Message Length . . . . . . . . . . . . . . . . . . . . . 42 | |||
4.5. General Header Fields . . . . . . . . . . . . . . . . . 42 | 4.5. General Header Fields . . . . . . . . . . . . . . . . . 43 | |||
5. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 | 5. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 | |||
5.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . 44 | 5.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . 45 | |||
5.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . 44 | 5.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . 45 | |||
5.1.2. Request-URI . . . . . . . . . . . . . . . . . . . . 45 | 5.1.2. Request-URI . . . . . . . . . . . . . . . . . . . . 46 | |||
5.2. The Resource Identified by a Request . . . . . . . . . . 46 | 5.2. The Resource Identified by a Request . . . . . . . . . . 47 | |||
5.3. Request Header Fields . . . . . . . . . . . . . . . . . 47 | 5.3. Request Header Fields . . . . . . . . . . . . . . . . . 48 | |||
6. Response . . . . . . . . . . . . . . . . . . . . . . . . . . 48 | 6. Response . . . . . . . . . . . . . . . . . . . . . . . . . . 49 | |||
6.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . 48 | 6.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . 49 | |||
6.1.1. Status Code and Reason Phrase . . . . . . . . . . . 48 | 6.1.1. Status Code and Reason Phrase . . . . . . . . . . . 49 | |||
6.2. Response Header Fields . . . . . . . . . . . . . . . . . 51 | 6.2. Response Header Fields . . . . . . . . . . . . . . . . . 52 | |||
7. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 | 7. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 | |||
7.1. Entity Header Fields . . . . . . . . . . . . . . . . . . 52 | 7.1. Entity Header Fields . . . . . . . . . . . . . . . . . . 53 | |||
7.2. Entity Body . . . . . . . . . . . . . . . . . . . . . . 52 | 7.2. Entity Body . . . . . . . . . . . . . . . . . . . . . . 53 | |||
7.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 53 | 7.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 54 | |||
7.2.2. Entity Length . . . . . . . . . . . . . . . . . . . 53 | 7.2.2. Entity Length . . . . . . . . . . . . . . . . . . . 54 | |||
8. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 54 | 8. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 55 | |||
8.1. Persistent Connections . . . . . . . . . . . . . . . . . 54 | 8.1. Persistent Connections . . . . . . . . . . . . . . . . . 55 | |||
8.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . 54 | 8.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . 55 | |||
8.1.2. Overall Operation . . . . . . . . . . . . . . . . . 54 | 8.1.2. Overall Operation . . . . . . . . . . . . . . . . . 55 | |||
8.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . 56 | 8.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . 57 | |||
8.1.4. Practical Considerations . . . . . . . . . . . . . . 56 | 8.1.4. Practical Considerations . . . . . . . . . . . . . . 57 | |||
8.2. Message Transmission Requirements . . . . . . . . . . . 57 | 8.2. Message Transmission Requirements . . . . . . . . . . . 58 | |||
8.2.1. Persistent Connections and Flow Control . . . . . . 57 | 8.2.1. Persistent Connections and Flow Control . . . . . . 58 | |||
8.2.2. Monitoring Connections for Error Status Messages . . 57 | 8.2.2. Monitoring Connections for Error Status Messages . . 58 | |||
8.2.3. Use of the 100 (Continue) Status . . . . . . . . . . 58 | 8.2.3. Use of the 100 (Continue) Status . . . . . . . . . . 59 | |||
8.2.4. Client Behavior if Server Prematurely Closes | 8.2.4. Client Behavior if Server Prematurely Closes | |||
Connection . . . . . . . . . . . . . . . . . . . . . 60 | Connection . . . . . . . . . . . . . . . . . . . . . 61 | |||
9. Method Definitions . . . . . . . . . . . . . . . . . . . . . 61 | 9. Method Definitions . . . . . . . . . . . . . . . . . . . . . 62 | |||
9.1. Safe and Idempotent Methods . . . . . . . . . . . . . . 61 | 9.1. Safe and Idempotent Methods . . . . . . . . . . . . . . 62 | |||
9.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . 61 | 9.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . 62 | |||
9.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . 61 | 9.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . 62 | |||
9.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . 62 | 9.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . 63 | |||
9.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . 63 | 9.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . 64 | |||
9.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . 63 | 9.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . 64 | |||
9.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . 64 | 9.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . 65 | |||
9.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . 65 | 9.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . 65 | |||
9.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . 66 | 9.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . 67 | |||
9.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . 66 | 9.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . 67 | |||
9.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . 67 | 9.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . 67 | |||
10. Status Code Definitions . . . . . . . . . . . . . . . . . . . 68 | 10. Status Code Definitions . . . . . . . . . . . . . . . . . . . 68 | |||
10.1. Informational 1xx . . . . . . . . . . . . . . . . . . . 68 | 10.1. Informational 1xx . . . . . . . . . . . . . . . . . . . 68 | |||
10.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 68 | 10.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 68 | |||
10.1.2. 101 Switching Protocols . . . . . . . . . . . . . . 68 | 10.1.2. 101 Switching Protocols . . . . . . . . . . . . . . 68 | |||
10.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . 69 | 10.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . 69 | |||
10.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 69 | 10.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 69 | |||
10.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . 69 | 10.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . 69 | |||
10.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . 69 | 10.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . 69 | |||
10.2.4. 203 Non-Authoritative Information . . . . . . . . . 70 | 10.2.4. 203 Non-Authoritative Information . . . . . . . . . 70 | |||
skipping to change at page 10, line 4 | skipping to change at page 10, line 4 | |||
15.4. Location Headers and Spoofing . . . . . . . . . . . . . 166 | 15.4. Location Headers and Spoofing . . . . . . . . . . . . . 166 | |||
15.5. Content-Disposition Issues . . . . . . . . . . . . . . . 167 | 15.5. Content-Disposition Issues . . . . . . . . . . . . . . . 167 | |||
15.6. Authentication Credentials and Idle Clients . . . . . . 167 | 15.6. Authentication Credentials and Idle Clients . . . . . . 167 | |||
15.7. Proxies and Caching . . . . . . . . . . . . . . . . . . 167 | 15.7. Proxies and Caching . . . . . . . . . . . . . . . . . . 167 | |||
15.7.1. Denial of Service Attacks on Proxies . . . . . . . . 168 | 15.7.1. Denial of Service Attacks on Proxies . . . . . . . . 168 | |||
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 169 | 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 169 | |||
16.1. (RFC2616) . . . . . . . . . . . . . . . . . . . . . . . 169 | 16.1. (RFC2616) . . . . . . . . . . . . . . . . . . . . . . . 169 | |||
16.2. (This Document) . . . . . . . . . . . . . . . . . . . . 170 | 16.2. (This Document) . . . . . . . . . . . . . . . . . . . . 170 | |||
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 171 | 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 171 | |||
17.1. References (to be classified) . . . . . . . . . . . . . 171 | 17.1. References (to be classified) . . . . . . . . . . . . . 171 | |||
17.2. Informative References . . . . . . . . . . . . . . . . . 174 | 17.2. Normative References . . . . . . . . . . . . . . . . . . 171 | |||
17.3. Informative References . . . . . . . . . . . . . . . . . 172 | ||||
Appendix A. Internet Media Type message/http and | Appendix A. Internet Media Type message/http and | |||
application/http . . . . . . . . . . . . . . . . . . 177 | application/http . . . . . . . . . . . . . . . . . . 177 | |||
Appendix B. Internet Media Type multipart/byteranges . . . . . . 179 | Appendix B. Internet Media Type multipart/byteranges . . . . . . 179 | |||
Appendix C. Tolerant Applications . . . . . . . . . . . . . . . 181 | Appendix C. Tolerant Applications . . . . . . . . . . . . . . . 181 | |||
Appendix D. Differences Between HTTP Entities and RFC 2045 | Appendix D. Differences Between HTTP Entities and RFC 2045 | |||
Entities . . . . . . . . . . . . . . . . . . . . . . 182 | Entities . . . . . . . . . . . . . . . . . . . . . . 182 | |||
D.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . 182 | D.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . 182 | |||
D.2. Conversion to Canonical Form . . . . . . . . . . . . . . 182 | D.2. Conversion to Canonical Form . . . . . . . . . . . . . . 182 | |||
D.3. Conversion of Date Formats . . . . . . . . . . . . . . . 183 | D.3. Conversion of Date Formats . . . . . . . . . . . . . . . 183 | |||
D.4. Introduction of Content-Encoding . . . . . . . . . . . . 183 | D.4. Introduction of Content-Encoding . . . . . . . . . . . . 183 | |||
skipping to change at page 10, line 33 | skipping to change at page 10, line 34 | |||
Conserve IP Addresses . . . . . . . . . . . . . . . 186 | Conserve IP Addresses . . . . . . . . . . . . . . . 186 | |||
F.2. Compatibility with HTTP/1.0 Persistent Connections . . . 187 | F.2. Compatibility with HTTP/1.0 Persistent Connections . . . 187 | |||
F.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . 188 | F.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . 188 | |||
F.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . 190 | F.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . 190 | |||
Appendix G. Change Log (to be removed by RFC Editor before | Appendix G. Change Log (to be removed by RFC Editor before | |||
publication) . . . . . . . . . . . . . . . . . . . . 192 | publication) . . . . . . . . . . . . . . . . . . . . 192 | |||
G.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . 192 | G.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . 192 | |||
G.2. Since draft-lafon-rfc2616bis-00 . . . . . . . . . . . . 192 | G.2. Since draft-lafon-rfc2616bis-00 . . . . . . . . . . . . 192 | |||
G.3. Since draft-lafon-rfc2616bis-01 . . . . . . . . . . . . 192 | G.3. Since draft-lafon-rfc2616bis-01 . . . . . . . . . . . . 192 | |||
G.4. Since draft-lafon-rfc2616bis-02 . . . . . . . . . . . . 192 | G.4. Since draft-lafon-rfc2616bis-02 . . . . . . . . . . . . 192 | |||
G.5. Since draft-lafon-rfc2616bis-03 . . . . . . . . . . . . 193 | ||||
Appendix H. Resolved issues (to be removed by RFC Editor | Appendix H. Resolved issues (to be removed by RFC Editor | |||
before publication) . . . . . . . . . . . . . . . . 194 | before publication) . . . . . . . . . . . . . . . . 195 | |||
H.1. i45-rfc977-reference . . . . . . . . . . . . . . . . . . 194 | H.1. unneeded_references . . . . . . . . . . . . . . . . . . 195 | |||
H.2. i46-rfc1700_remove . . . . . . . . . . . . . . . . . . . 194 | H.2. consistent-reason-phrases . . . . . . . . . . . . . . . 195 | |||
H.3. i47-inconsistency-in-date-format-explanation . . . . . . 194 | H.3. i66-iso8859-1-reference . . . . . . . . . . . . . . . . 195 | |||
H.4. i49-connection-header-text . . . . . . . . . . . . . . . 195 | H.4. abnf-edit . . . . . . . . . . . . . . . . . . . . . . . 196 | |||
H.5. i48-date-reference-typo . . . . . . . . . . . . . . . . 195 | H.5. rfc1766_normative . . . . . . . . . . . . . . . . . . . 196 | |||
H.6. i86-normative-up-to-date-references . . . . . . . . . . 196 | ||||
H.7. i68-encoding-references-normative . . . . . . . . . . . 197 | ||||
H.8. rfc2396_normative . . . . . . . . . . . . . . . . . . . 197 | ||||
H.9. usascii_normative . . . . . . . . . . . . . . . . . . . 197 | ||||
H.10. i65-informative-references . . . . . . . . . . . . . . . 197 | ||||
H.11. i31-qdtext-bnf . . . . . . . . . . . . . . . . . . . . . 198 | ||||
H.12. i62-whitespace-in-quoted-pair . . . . . . . . . . . . . 199 | ||||
H.13. i26-import-query-bnf . . . . . . . . . . . . . . . . . . 199 | ||||
H.14. i47-inconsistency-in-date-format-explanation . . . . . . 200 | ||||
H.15. media-reg . . . . . . . . . . . . . . . . . . . . . . . 200 | ||||
H.16. i84-redundant-cross-references . . . . . . . . . . . . . 201 | ||||
H.17. i87-typo-in-13.2.2 . . . . . . . . . . . . . . . . . . . 201 | ||||
H.18. i25-accept-encoding-bnf . . . . . . . . . . . . . . . . 202 | ||||
H.19. remove-CTE-abbrev . . . . . . . . . . . . . . . . . . . 203 | ||||
Appendix I. Open issues (to be removed by RFC Editor prior to | Appendix I. Open issues (to be removed by RFC Editor prior to | |||
publication) . . . . . . . . . . . . . . . . . . . . 197 | publication) . . . . . . . . . . . . . . . . . . . . 204 | |||
I.1. rfc2616bis . . . . . . . . . . . . . . . . . . . . . . . 197 | I.1. rfc2616bis . . . . . . . . . . . . . . . . . . . . . . . 204 | |||
I.2. unneeded_references . . . . . . . . . . . . . . . . . . 197 | I.2. i35-split-normative-and-informative-references . . . . . 204 | |||
I.3. edit . . . . . . . . . . . . . . . . . . . . . . . . . . 197 | I.3. i40-header-registration . . . . . . . . . . . . . . . . 204 | |||
I.4. i66-iso8859-1-reference . . . . . . . . . . . . . . . . 197 | I.4. edit . . . . . . . . . . . . . . . . . . . . . . . . . . 204 | |||
I.5. abnf . . . . . . . . . . . . . . . . . . . . . . . . . . 197 | I.5. abnf . . . . . . . . . . . . . . . . . . . . . . . . . . 204 | |||
I.6. rfc2048_informative_and_obsolete . . . . . . . . . . . . 198 | I.6. rfc2048_informative_and_obsolete . . . . . . . . . . . . 205 | |||
I.7. i34-updated-reference-for-uris . . . . . . . . . . . . . 198 | I.7. i34-updated-reference-for-uris . . . . . . . . . . . . . 205 | |||
I.8. i50-misc-typos . . . . . . . . . . . . . . . . . . . . . 198 | I.8. i50-misc-typos . . . . . . . . . . . . . . . . . . . . . 205 | |||
I.9. i65-informative-references . . . . . . . . . . . . . . . 198 | I.9. i52-sort-1.3-terminology . . . . . . . . . . . . . . . . 206 | |||
I.10. i52-sort-1.3-terminology . . . . . . . . . . . . . . . . 199 | I.10. i63-header-length-limit-with-encoded-words . . . . . . . 206 | |||
I.11. i63-header-length-limit-with-encoded-words . . . . . . . 200 | I.11. i74-character-encodings-for-headers . . . . . . . . . . 207 | |||
I.12. i31-qdtext-bnf . . . . . . . . . . . . . . . . . . . . . 200 | I.12. i64-ws-in-quoted-pair . . . . . . . . . . . . . . . . . 207 | |||
I.13. i62-whitespace-in-quoted-pair . . . . . . . . . . . . . 200 | I.13. i75-rfc2145-normative . . . . . . . . . . . . . . . . . 208 | |||
I.14. i58-what-identifies-an-http-resource . . . . . . . . . . 201 | I.14. i82-rel_path-not-used . . . . . . . . . . . . . . . . . 208 | |||
I.15. i51-http-date-vs-rfc1123-date . . . . . . . . . . . . . 201 | I.15. i58-what-identifies-an-http-resource . . . . . . . . . . 209 | |||
I.16. i67-quoting-charsets . . . . . . . . . . . . . . . . . . 201 | I.16. i51-http-date-vs-rfc1123-date . . . . . . . . . . . . . 209 | |||
I.17. media-reg . . . . . . . . . . . . . . . . . . . . . . . 202 | I.17. i73-clarification-of-the-term-deflate . . . . . . . . . 210 | |||
I.18. languagetag . . . . . . . . . . . . . . . . . . . . . . 202 | I.18. i67-quoting-charsets . . . . . . . . . . . . . . . . . . 210 | |||
I.19. i56-6.1.1-can-be-misread-as-a-complete-list . . . . . . 202 | I.19. i20-default-charsets-for-text-media-types . . . . . . . 210 | |||
I.20. i57-status-code-and-reason-phrase . . . . . . . . . . . 203 | I.20. languagetag . . . . . . . . . . . . . . . . . . . . . . 212 | |||
I.21. i59-status-code-registry . . . . . . . . . . . . . . . . 203 | I.21. i85-custom-ranges . . . . . . . . . . . . . . . . . . . 212 | |||
I.22. i21-put-side-effects . . . . . . . . . . . . . . . . . . 203 | I.22. i30-header-lws . . . . . . . . . . . . . . . . . . . . . 213 | |||
I.23. i54-definition-of-1xx-warn-codes . . . . . . . . . . . . 204 | I.23. i77-line-folding . . . . . . . . . . . . . . . . . . . . 213 | |||
I.24. i60-13.5.1-and-13.5.2 . . . . . . . . . . . . . . . . . 204 | I.24. i19-bodies-on-GET . . . . . . . . . . . . . . . . . . . 214 | |||
I.25. i53-allow-is-not-in-13.5.2 . . . . . . . . . . . . . . . 204 | I.25. i28-connection-closing . . . . . . . . . . . . . . . . . 214 | |||
I.26. i25-accept-encoding-bnf . . . . . . . . . . . . . . . . 205 | I.26. i32-options-asterisk . . . . . . . . . . . . . . . . . . 214 | |||
I.27. i61-redirection-vs-location . . . . . . . . . . . . . . 205 | I.27. i83-options-asterisk-and-proxies . . . . . . . . . . . . 215 | |||
I.28. fragment-combination . . . . . . . . . . . . . . . . . . 205 | I.28. i56-6.1.1-can-be-misread-as-a-complete-list . . . . . . 216 | |||
I.29. i55-updating-to-rfc4288 . . . . . . . . . . . . . . . . 206 | I.29. i57-status-code-and-reason-phrase . . . . . . . . . . . 216 | |||
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 | I.30. i59-status-code-registry . . . . . . . . . . . . . . . . 217 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 219 | I.31. i72-request-method-registry . . . . . . . . . . . . . . 217 | |||
Intellectual Property and Copyright Statements . . . . . . . . . 222 | I.32. i21-put-side-effects . . . . . . . . . . . . . . . . . . 217 | |||
I.33. i27-put-idempotency . . . . . . . . . . . . . . . . . . 218 | ||||
I.34. i79-content-headers-vs-put . . . . . . . . . . . . . . . 219 | ||||
I.35. i33-trace-security-considerations . . . . . . . . . . . 219 | ||||
I.36. i69-clarify-requested-variant . . . . . . . . . . . . . 220 | ||||
I.37. i70-cacheability-of-303 . . . . . . . . . . . . . . . . 221 | ||||
I.38. i76-deprecate-305-use-proxy . . . . . . . . . . . . . . 223 | ||||
I.39. i78-relationship-between-401-authorization-and-www-authe 223 | ||||
I.40. i24-requiring-allow-in-405-responses . . . . . . . . . . 224 | ||||
I.41. i81-content-negotiation-for-media-types . . . . . . . . 224 | ||||
I.42. i54-definition-of-1xx-warn-codes . . . . . . . . . . . . 226 | ||||
I.43. i29-age-calculation . . . . . . . . . . . . . . . . . . 226 | ||||
I.44. i71-examples-for-etag-matching . . . . . . . . . . . . . 227 | ||||
I.45. i60-13.5.1-and-13.5.2 . . . . . . . . . . . . . . . . . 228 | ||||
I.46. i53-allow-is-not-in-13.5.2 . . . . . . . . . . . . . . . 228 | ||||
I.47. i37-vary-and-non-existant-headers . . . . . . . . . . . 228 | ||||
I.48. i38-mismatched-vary . . . . . . . . . . . . . . . . . . 229 | ||||
I.49. i39-etag-uniqueness . . . . . . . . . . . . . . . . . . 229 | ||||
I.50. i23-no-store-invalidation . . . . . . . . . . . . . . . 229 | ||||
I.51. i80-content-location-is-not-special . . . . . . . . . . 230 | ||||
I.52. i22-etag-and-other-metadata-in-status-messages . . . . . 231 | ||||
I.53. i61-redirection-vs-location . . . . . . . . . . . . . . 231 | ||||
I.54. fragment-combination . . . . . . . . . . . . . . . . . . 231 | ||||
I.55. i41-security-considerations . . . . . . . . . . . . . . 232 | ||||
I.56. i55-updating-to-rfc4288 . . . . . . . . . . . . . . . . 232 | ||||
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 245 | ||||
Intellectual Property and Copyright Statements . . . . . . . . . 248 | ||||
1. Introduction | 1. Introduction | |||
1.1. Purpose | 1.1. Purpose | |||
The Hypertext Transfer Protocol (HTTP) is an application-level | The Hypertext Transfer Protocol (HTTP) is an application-level | |||
protocol for distributed, collaborative, hypermedia information | protocol for distributed, collaborative, hypermedia 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. The first version of HTTP, | information initiative since 1990. The first version of HTTP, | |||
referred to as HTTP/0.9, was a simple protocol for raw data transfer | referred to as HTTP/0.9, was a simple protocol for raw data transfer | |||
skipping to change at page 12, line 36 | skipping to change at page 13, line 36 | |||
This protocol includes more stringent requirements than HTTP/1.0 in | This protocol includes more stringent requirements than HTTP/1.0 in | |||
order to ensure reliable implementation of its features. | order to ensure reliable implementation of its features. | |||
Practical information systems require more functionality than simple | Practical information systems require more functionality than simple | |||
retrieval, including search, front-end update, and annotation. HTTP | retrieval, including search, front-end update, and annotation. HTTP | |||
allows an open-ended set of methods and headers that indicate the | allows an open-ended set of methods and headers that indicate the | |||
purpose of a request [RFC2324]. It builds on the discipline of | purpose of a request [RFC2324]. It builds on the discipline of | |||
reference provided by the Uniform Resource Identifier (URI) | reference provided by the Uniform Resource Identifier (URI) | |||
[RFC1630], as a location (URL) [RFC1738] or name (URN) [RFC1737], for | [RFC1630], as a location (URL) [RFC1738] or name (URN) [RFC1737], for | |||
indicating the resource to which a method is to be applied. Messages | indicating the resource to which a method is to be applied. Messages | |||
are passed in a format similar to that used by Internet mail [RFC822] | are passed in a format similar to that used by Internet mail | |||
as defined by the Multipurpose Internet Mail Extensions (MIME) | [RFC2822] as defined by the Multipurpose Internet Mail Extensions | |||
[RFC2045]. | (MIME) [RFC2045]. | |||
HTTP is also used as a generic protocol for communication between | HTTP is also used as a generic protocol for communication between | |||
user agents and proxies/gateways to other Internet systems, including | user agents and proxies/gateways to other Internet systems, including | |||
those supported by the SMTP [RFC821], NNTP [RFC3977], FTP [RFC959], | those supported by the SMTP [RFC2821], NNTP [RFC3977], FTP [RFC959], | |||
Gopher [RFC1436], and WAIS [WAIS] protocols. In this way, HTTP | Gopher [RFC1436], and WAIS [WAIS] protocols. In this way, HTTP | |||
allows basic hypermedia access to resources available from diverse | allows basic hypermedia access to resources available from diverse | |||
applications. | applications. | |||
1.2. Requirements | 1.2. Requirements | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in [RFC2119]. | document are to be interpreted as described in [RFC2119]. | |||
skipping to change at page 20, line 11 | skipping to change at page 21, line 11 | |||
request/response exchange. In HTTP/1.1, a connection may be used for | request/response exchange. In HTTP/1.1, a connection may be used for | |||
one or more request/response exchanges, although connections may be | one or more request/response exchanges, although connections may be | |||
closed for a variety of reasons (see Section 8.1). | closed for a variety of reasons (see Section 8.1). | |||
2. Notational Conventions and Generic Grammar | 2. Notational Conventions and Generic Grammar | |||
2.1. Augmented BNF | 2.1. Augmented BNF | |||
All of the mechanisms specified in this document are described in | All of the mechanisms specified in this document are described in | |||
both prose and an augmented Backus-Naur Form (BNF) similar to that | both prose and an augmented Backus-Naur Form (BNF) similar to that | |||
used by [RFC822]. Implementors will need to be familiar with the | used by [RFC822ABNF]. Implementors will need to be familiar with the | |||
notation in order to understand this specification. The augmented | notation in order to understand this specification. The augmented | |||
BNF includes the following constructs: | BNF includes the following constructs: | |||
name = definition | name = definition | |||
The name of a rule is simply the name itself (without any | The name of a rule is simply the name itself (without any | |||
enclosing "<" and ">") and is separated from its definition by the | enclosing "<" and ">") and is separated from its definition by the | |||
equal "=" character. White space is only significant in that | equal "=" character. White space is only significant in that | |||
indentation of continuation lines is used to indicate a rule | indentation of continuation lines is used to indicate a rule | |||
definition that spans more than one line. Certain basic rules are | definition that spans more than one line. Certain basic rules are | |||
skipping to change at page 23, line 36 | skipping to change at page 24, line 36 | |||
In all other fields, parentheses are considered part of the field | In all other fields, parentheses are considered part of the field | |||
value. | value. | |||
comment = "(" *( ctext | quoted-pair | comment ) ")" | comment = "(" *( ctext | quoted-pair | comment ) ")" | |||
ctext = <any TEXT excluding "(" and ")"> | ctext = <any TEXT excluding "(" and ")"> | |||
A string of text is parsed as a single word if it is quoted using | A string of text is parsed as a single word if it is quoted using | |||
double-quote marks. | double-quote marks. | |||
quoted-string = ( <"> *(qdtext | quoted-pair ) <"> ) | quoted-string = ( <"> *(qdtext | quoted-pair ) <"> ) | |||
qdtext = <any TEXT except <">> | qdtext = <any TEXT excluding <"> and "\"> | |||
The backslash character ("\") MAY be used as a single-character | The backslash character ("\") MAY be used as a single-character | |||
quoting mechanism only within quoted-string and comment constructs. | quoting mechanism only within quoted-string and comment constructs. | |||
quoted-pair = "\" CHAR | quoted-pair = "\" CHAR | |||
3. Protocol Parameters | 3. Protocol Parameters | |||
3.1. HTTP Version | 3.1. HTTP Version | |||
skipping to change at page 25, line 34 | skipping to change at page 26, line 34 | |||
3.2.1. General Syntax | 3.2.1. General Syntax | |||
URIs in HTTP can be represented in absolute form or relative to some | URIs in HTTP can be represented in absolute form or relative to some | |||
known base URI [RFC1808], depending upon the context of their use. | known base URI [RFC1808], depending upon the context of their use. | |||
The two forms are differentiated by the fact that absolute URIs | The two forms are differentiated by the fact that absolute URIs | |||
always begin with a scheme name followed by a colon. For definitive | always begin with a scheme name followed by a colon. For definitive | |||
information on URL syntax and semantics, see "Uniform Resource | information on URL syntax and semantics, see "Uniform Resource | |||
Identifiers (URI): Generic Syntax and Semantics," [RFC2396] (which | Identifiers (URI): Generic Syntax and Semantics," [RFC2396] (which | |||
replaces [RFC1738] and [RFC1808]). This specification adopts the | replaces [RFC1738] and [RFC1808]). This specification adopts the | |||
definitions of "URI-reference", "absoluteURI", "relativeURI", "port", | definitions of "URI-reference", "absoluteURI", "relativeURI", "port", | |||
"host", "abs_path", "rel_path", and "authority" from that | "host", "abs_path", "rel_path", "query", and "authority" from that | |||
specification. | specification. | |||
The HTTP protocol does not place any a priori limit on the length of | The HTTP protocol does not place any a priori limit on the length of | |||
a URI. Servers MUST be able to handle the URI of any resource they | a URI. Servers MUST be able to handle the URI of any resource they | |||
serve, and SHOULD be able to handle URIs of unbounded length if they | serve, and SHOULD be able to handle URIs of unbounded length if they | |||
provide GET-based forms that could generate such URIs. A server | provide GET-based forms that could generate such URIs. A server | |||
SHOULD return 414 (Request-URI Too Long) status if a URI is longer | SHOULD return 414 (Request-URI Too Long) status if a URI is longer | |||
than the server can handle (see Section 10.4.15). | than the server can handle (see Section 10.4.15). | |||
Note: Servers ought to be cautious about depending on URI lengths | Note: Servers ought to be cautious about depending on URI lengths | |||
skipping to change at page 27, line 13 | skipping to change at page 28, line 13 | |||
http://EXAMPLE.com:/%7esmith/home.html | http://EXAMPLE.com:/%7esmith/home.html | |||
3.3. Date/Time Formats | 3.3. Date/Time Formats | |||
3.3.1. Full Date | 3.3.1. Full Date | |||
HTTP applications have historically allowed three different formats | HTTP applications have historically allowed three different formats | |||
for the representation of date/time stamps: | for the representation of date/time stamps: | |||
Sun, 06 Nov 1994 08:49:37 GMT ; [RFC822], updated by [RFC1123] | Sun, 06 Nov 1994 08:49:37 GMT ; [RFC822], updated by [RFC1123] | |||
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by [RFC1036] | Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format | |||
Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format | Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format | |||
The first format is preferred as an Internet standard and represents | The first format is preferred as an Internet standard and represents | |||
a fixed-length subset of that defined by [RFC1123] (an update to | a fixed-length subset of that defined by [RFC1123] (an update to | |||
[RFC822]). The second format is in common use, but is based on the | [RFC822]). The other formats are described here only for | |||
obsolete RFC 1036 date format [RFC1036] and lacks a four-digit year. | compatibility with obsolete implementations. HTTP/1.1 clients and | |||
HTTP/1.1 clients and servers that parse the date value MUST accept | servers that parse the date value MUST accept all three formats (for | |||
all three formats (for compatibility with HTTP/1.0), though they MUST | compatibility with HTTP/1.0), though they MUST only generate the RFC | |||
only generate the RFC 1123 format for representing HTTP-date values | 1123 format for representing HTTP-date values in header fields. See | |||
in header fields. See Appendix C for further information. | Appendix C for further information. | |||
Note: Recipients of date values are encouraged to be robust in | Note: Recipients of date values are encouraged to be robust in | |||
accepting date values that may have been sent by non-HTTP | accepting date values that may have been sent by non-HTTP | |||
applications, as is sometimes the case when retrieving or posting | applications, as is sometimes the case when retrieving or posting | |||
messages via proxies/gateways to SMTP or NNTP. | messages via proxies/gateways to SMTP or NNTP. | |||
All HTTP date/time stamps MUST be represented in Greenwich Mean Time | All HTTP date/time stamps MUST be represented in Greenwich Mean Time | |||
(GMT), without exception. For the purposes of HTTP, GMT is exactly | (GMT), without exception. For the purposes of HTTP, GMT is exactly | |||
equal to UTC (Coordinated Universal Time). This is indicated in the | equal to UTC (Coordinated Universal Time). This is indicated in the | |||
first two formats by the inclusion of "GMT" as the three-letter | first two formats by the inclusion of "GMT" as the three-letter | |||
skipping to change at page 29, line 32 | skipping to change at page 30, line 32 | |||
that registry. Applications SHOULD limit their use of character sets | that registry. Applications SHOULD limit their use of character sets | |||
to those defined by the IANA registry. | to those defined by the IANA registry. | |||
HTTP uses charset in two contexts: within an Accept-Charset request | HTTP uses charset in two contexts: within an Accept-Charset request | |||
header (in which the charset value is an unquoted token) and as the | header (in which the charset value is an unquoted token) and as the | |||
value of a parameter in a Content-Type header (within a request or | value of a parameter in a Content-Type header (within a request or | |||
response), in which case the parameter value of the charset parameter | response), in which case the parameter value of the charset parameter | |||
may be quoted. | may be quoted. | |||
Implementors should be aware of IETF character set requirements | Implementors should be aware of IETF character set requirements | |||
[RFC2279] [RFC2277]. | [RFC3629] [RFC2277]. | |||
3.4.1. Missing Charset | 3.4.1. Missing Charset | |||
Some HTTP/1.0 software has interpreted a Content-Type header without | Some HTTP/1.0 software has interpreted a Content-Type header without | |||
charset parameter incorrectly to mean "recipient should guess." | charset parameter incorrectly to mean "recipient should guess." | |||
Senders wishing to defeat this behavior MAY include a charset | Senders wishing to defeat this behavior MAY include a charset | |||
parameter even when the charset is ISO-8859-1 and SHOULD do so when | parameter even when the charset is ISO-8859-1 and SHOULD do so when | |||
it is known that it will not confuse the recipient. | it is known that it will not confuse the recipient. | |||
Unfortunately, some older HTTP/1.0 clients did not deal properly with | Unfortunately, some older HTTP/1.0 clients did not deal properly with | |||
skipping to change at page 32, line 14 | skipping to change at page 33, line 14 | |||
The Internet Assigned Numbers Authority (IANA) acts as a registry for | The Internet Assigned Numbers Authority (IANA) acts as a registry for | |||
transfer-coding value tokens. Initially, the registry contains the | transfer-coding value tokens. Initially, the registry contains the | |||
following tokens: "chunked" (Section 3.6.1), "gzip" (Section 3.5), | following tokens: "chunked" (Section 3.6.1), "gzip" (Section 3.5), | |||
"compress" (Section 3.5), and "deflate" (Section 3.5). | "compress" (Section 3.5), and "deflate" (Section 3.5). | |||
New transfer-coding value tokens SHOULD be registered in the same way | New transfer-coding value tokens SHOULD be registered in the same way | |||
as new content-coding value tokens (Section 3.5). | as new content-coding value tokens (Section 3.5). | |||
A server which receives an entity-body with a transfer-coding it does | A server which receives an entity-body with a transfer-coding it does | |||
not understand SHOULD return 501 (Unimplemented), and close the | not understand SHOULD return 501 (Not Implemented), and close the | |||
connection. A server MUST NOT send transfer-codings to an HTTP/1.0 | connection. A server MUST NOT send transfer-codings to an HTTP/1.0 | |||
client. | client. | |||
3.6.1. Chunked Transfer Coding | 3.6.1. Chunked Transfer Coding | |||
The chunked encoding modifies the body of a message in order to | The chunked encoding modifies the body of a message in order to | |||
transfer it as a series of chunks, each with its own size indicator, | transfer it as a series of chunks, each with its own size indicator, | |||
followed by an OPTIONAL trailer containing entity-header fields. | followed by an OPTIONAL trailer containing entity-header fields. | |||
This allows dynamically produced content to be transferred along with | This allows dynamically produced content to be transferred along with | |||
the information necessary for the recipient to verify that it has | the information necessary for the recipient to verify that it has | |||
skipping to change at page 33, line 36 | skipping to change at page 34, line 36 | |||
An example process for decoding a Chunked-Body is presented in | An example process for decoding a Chunked-Body is presented in | |||
Appendix D.6. | Appendix D.6. | |||
All HTTP/1.1 applications MUST be able to receive and decode the | All HTTP/1.1 applications MUST be able to receive and decode the | |||
"chunked" transfer-coding, and MUST ignore chunk-extension extensions | "chunked" transfer-coding, and MUST ignore chunk-extension extensions | |||
they do not understand. | they do not understand. | |||
3.7. Media Types | 3.7. Media Types | |||
HTTP uses Internet Media Types [RFC1590] in the Content-Type | HTTP uses Internet Media Types [RFC2048] in the Content-Type | |||
(Section 14.17) and Accept (Section 14.1) header fields in order to | (Section 14.17) and Accept (Section 14.1) header fields in order to | |||
provide open and extensible data typing and type negotiation. | provide open and extensible data typing and type negotiation. | |||
media-type = type "/" subtype *( ";" parameter ) | media-type = type "/" subtype *( ";" parameter ) | |||
type = token | type = token | |||
subtype = token | subtype = token | |||
Parameters MAY follow the type/subtype in the form of attribute/value | Parameters MAY follow the type/subtype in the form of attribute/value | |||
pairs (as defined in Section 3.6). | pairs (as defined in Section 3.6). | |||
skipping to change at page 34, line 13 | skipping to change at page 35, line 13 | |||
might be significant to the processing of a media-type, depending on | might be significant to the processing of a media-type, depending on | |||
its definition within the media type registry. | its definition within the media type registry. | |||
Note that some older HTTP applications do not recognize media type | Note that some older HTTP applications do not recognize media type | |||
parameters. When sending data to older HTTP applications, | parameters. When sending data to older HTTP applications, | |||
implementations SHOULD only use media type parameters when they are | implementations SHOULD only use media type parameters when they are | |||
required by that type/subtype definition. | required by that type/subtype definition. | |||
Media-type values are registered with the Internet Assigned Number | Media-type values are registered with the Internet Assigned Number | |||
Authority (IANA). The media type registration process is outlined in | Authority (IANA). The media type registration process is outlined in | |||
[RFC1590]. Use of non-registered media types is discouraged. | [RFC2048]. Use of non-registered media types is discouraged. | |||
3.7.1. Canonicalization and Text Defaults | 3.7.1. Canonicalization and Text Defaults | |||
Internet media types are registered with a canonical form. An | Internet media types are registered with a canonical form. An | |||
entity-body transferred via HTTP messages MUST be represented in the | entity-body transferred via HTTP messages MUST be represented in the | |||
appropriate canonical form prior to its transmission except for | appropriate canonical form prior to its transmission except for | |||
"text" types, as defined in the next paragraph. | "text" types, as defined in the next paragraph. | |||
When in canonical form, media subtypes of the "text" type use CRLF as | When in canonical form, media subtypes of the "text" type use CRLF as | |||
the text line break. HTTP relaxes this requirement and allows the | the text line break. HTTP relaxes this requirement and allows the | |||
skipping to change at page 35, line 33 | skipping to change at page 36, line 33 | |||
body do not have any significance to HTTP beyond that defined by | body do not have any significance to HTTP beyond that defined by | |||
their MIME semantics. | their MIME semantics. | |||
In general, an HTTP user agent SHOULD follow the same or similar | In general, an HTTP user agent SHOULD follow the same or similar | |||
behavior as a MIME user agent would upon receipt of a multipart type. | behavior as a MIME user agent would upon receipt of a multipart type. | |||
If an application receives an unrecognized multipart subtype, the | If an application receives an unrecognized multipart subtype, the | |||
application MUST treat it as being equivalent to "multipart/mixed". | application MUST treat it as being equivalent to "multipart/mixed". | |||
Note: The "multipart/form-data" type has been specifically defined | Note: The "multipart/form-data" type has been specifically defined | |||
for carrying form data suitable for processing via the POST | for carrying form data suitable for processing via the POST | |||
request method, as described in RFC 1867 [RFC1867]. | request method, as described in [RFC2388]. | |||
3.8. Product Tokens | 3.8. Product Tokens | |||
Product tokens are used to allow communicating applications to | Product tokens are used to allow communicating applications to | |||
identify themselves by software name and version. Most fields using | identify themselves by software name and version. Most fields using | |||
product tokens also allow sub-products which form a significant part | product tokens also allow sub-products which form a significant part | |||
of the application to be listed, separated by white space. By | of the application to be listed, separated by white space. By | |||
convention, the products are listed in order of their significance | convention, the products are listed in order of their significance | |||
for identifying the application. | for identifying the application. | |||
skipping to change at page 39, line 15 | skipping to change at page 40, line 15 | |||
4. HTTP Message | 4. HTTP Message | |||
4.1. Message Types | 4.1. Message Types | |||
HTTP messages consist of requests from client to server and responses | HTTP messages consist of requests from client to server and responses | |||
from server to client. | from server to client. | |||
HTTP-message = Request | Response ; HTTP/1.1 messages | HTTP-message = Request | Response ; HTTP/1.1 messages | |||
Request (Section 5) and Response (Section 6) messages use the generic | Request (Section 5) and Response (Section 6) messages use the generic | |||
message format of [RFC822] for transferring entities (the payload of | message format of [RFC2822] for transferring entities (the payload of | |||
the message). Both types of message consist of a start-line, zero or | the message). Both types of message consist of a start-line, zero or | |||
more header fields (also known as "headers"), an empty line (i.e., a | more header fields (also known as "headers"), an empty line (i.e., a | |||
line with nothing preceding the CRLF) indicating the end of the | line with nothing preceding the CRLF) indicating the end of the | |||
header fields, and possibly a message-body. | header fields, and possibly a message-body. | |||
generic-message = start-line | generic-message = start-line | |||
*(message-header CRLF) | *(message-header CRLF) | |||
CRLF | CRLF | |||
[ message-body ] | [ message-body ] | |||
start-line = Request-Line | Status-Line | start-line = Request-Line | Status-Line | |||
skipping to change at page 39, line 42 | skipping to change at page 40, line 42 | |||
Certain buggy HTTP/1.0 client implementations generate extra CRLF's | Certain buggy HTTP/1.0 client implementations generate extra CRLF's | |||
after a POST request. To restate what is explicitly forbidden by the | after a POST request. To restate what is explicitly forbidden by the | |||
BNF, an HTTP/1.1 client MUST NOT preface or follow a request with an | BNF, an HTTP/1.1 client MUST NOT preface or follow a request with an | |||
extra CRLF. | extra CRLF. | |||
4.2. Message Headers | 4.2. Message Headers | |||
HTTP header fields, which include general-header (Section 4.5), | HTTP header fields, which include general-header (Section 4.5), | |||
request-header (Section 5.3), response-header (Section 6.2), and | request-header (Section 5.3), response-header (Section 6.2), and | |||
entity-header (Section 7.1) fields, follow the same generic format as | entity-header (Section 7.1) fields, follow the same generic format as | |||
that given in Section 3.1 of [RFC822]. Each header field consists of | that given in Section 2.1 of [RFC2822]. Each header field consists | |||
a name followed by a colon (":") and the field value. Field names | of a name followed by a colon (":") and the field value. Field names | |||
are case-insensitive. The field value MAY be preceded by any amount | are case-insensitive. The field value MAY be preceded by any amount | |||
of LWS, though a single SP is preferred. Header fields can be | of LWS, though a single SP is preferred. Header fields can be | |||
extended over multiple lines by preceding each extra line with at | extended over multiple lines by preceding each extra line with at | |||
least one SP or HT. Applications ought to follow "common form", | least one SP or HT. Applications ought to follow "common form", | |||
where one is known or indicated, when generating HTTP constructs, | where one is known or indicated, when generating HTTP constructs, | |||
since there might exist some implementations that fail to accept | since there might exist some implementations that fail to accept | |||
anything beyond the common forms. | anything beyond the common forms. | |||
message-header = field-name ":" [ field-value ] | message-header = field-name ":" [ field-value ] | |||
field-name = token | field-name = token | |||
skipping to change at page 41, line 23 | skipping to change at page 42, line 23 | |||
(Section 5.1.1) does not allow sending an entity-body in requests. A | (Section 5.1.1) does not allow sending an entity-body in requests. A | |||
server SHOULD read and forward a message-body on any request; if the | server SHOULD read and forward a message-body on any request; if the | |||
request method does not include defined semantics for an entity-body, | request method does not include defined semantics for an entity-body, | |||
then the message-body SHOULD be ignored when handling the request. | then the message-body SHOULD be ignored when handling the request. | |||
For response messages, whether or not a message-body is included with | For response messages, whether or not a message-body is included with | |||
a message is dependent on both the request method and the response | a message is dependent on both the request method and the response | |||
status code (Section 6.1.1). All responses to the HEAD request | status code (Section 6.1.1). All responses to the HEAD request | |||
method MUST NOT include a message-body, even though the presence of | method MUST NOT include a message-body, even though the presence of | |||
entity-header fields might lead one to believe they do. All 1xx | entity-header fields might lead one to believe they do. All 1xx | |||
(informational), 204 (no content), and 304 (not modified) responses | (informational), 204 (No Content), and 304 (Not Modified) responses | |||
MUST NOT include a message-body. All other responses do include a | MUST NOT include a message-body. All other responses do include a | |||
message-body, although it MAY be of zero length. | message-body, although it MAY be of zero length. | |||
4.4. Message Length | 4.4. Message Length | |||
The transfer-length of a message is the length of the message-body as | The transfer-length of a message is the length of the message-body as | |||
it appears in the message; that is, after any transfer-codings have | it appears in the message; that is, after any transfer-codings have | |||
been applied. When a message-body is included with a message, the | been applied. When a message-body is included with a message, the | |||
transfer-length of that body is determined by one of the following | transfer-length of that body is determined by one of the following | |||
(in order of precedence): | (in order of precedence): | |||
skipping to change at page 42, line 28 | skipping to change at page 43, line 28 | |||
5. By the server closing the connection. (Closing the connection | 5. By the server closing the connection. (Closing the connection | |||
cannot be used to indicate the end of a request body, since that | cannot be used to indicate the end of a request body, since that | |||
would leave no possibility for the server to send back a | would leave no possibility for the server to send back a | |||
response.) | response.) | |||
For compatibility with HTTP/1.0 applications, HTTP/1.1 requests | For compatibility with HTTP/1.0 applications, HTTP/1.1 requests | |||
containing a message-body MUST include a valid Content-Length header | containing a message-body MUST include a valid Content-Length header | |||
field unless the server is known to be HTTP/1.1 compliant. If a | field unless the server is known to be HTTP/1.1 compliant. If a | |||
request contains a message-body and a Content-Length is not given, | request contains a message-body and a Content-Length is not given, | |||
the server SHOULD respond with 400 (bad request) if it cannot | the server SHOULD respond with 400 (Bad Request) if it cannot | |||
determine the length of the message, or with 411 (length required) if | determine the length of the message, or with 411 (Length Required) if | |||
it wishes to insist on receiving a valid Content-Length. | it wishes to insist on receiving a valid Content-Length. | |||
All HTTP/1.1 applications that receive entities MUST accept the | All HTTP/1.1 applications that receive entities MUST accept the | |||
"chunked" transfer-coding (Section 3.6), thus allowing this mechanism | "chunked" transfer-coding (Section 3.6), thus allowing this mechanism | |||
to be used for messages when the message length cannot be determined | to be used for messages when the message length cannot be determined | |||
in advance. | in advance. | |||
Messages MUST NOT include both a Content-Length header field and a | Messages MUST NOT include both a Content-Length header field and a | |||
transfer-coding. If the message does include a transfer-coding, the | transfer-coding. If the message does include a transfer-coding, the | |||
Content-Length MUST be ignored. | Content-Length MUST be ignored. | |||
skipping to change at page 64, line 49 | skipping to change at page 65, line 49 | |||
If a resource has been created on the origin server, the response | If a resource has been created on the origin server, the response | |||
SHOULD be 201 (Created) and contain an entity which describes the | SHOULD be 201 (Created) and contain an entity which describes the | |||
status of the request and refers to the new resource, and a Location | status of the request and refers to the new resource, and a Location | |||
header (see Section 14.30). | header (see Section 14.30). | |||
Responses to this method are not cacheable, unless the response | Responses to this method are not cacheable, unless the response | |||
includes appropriate Cache-Control or Expires header fields. | includes appropriate Cache-Control or Expires header fields. | |||
However, the 303 (See Other) response can be used to direct the user | However, the 303 (See Other) response can be used to direct the user | |||
agent to retrieve a cacheable resource. | agent to retrieve a cacheable resource. | |||
POST requests MUST obey the message transmission requirements set out | ||||
in Section 8.2. | ||||
See Section 15.1.3 for security considerations. | ||||
9.6. PUT | 9.6. PUT | |||
The PUT method requests that the enclosed entity be stored under the | The PUT method requests that the enclosed entity be stored under the | |||
supplied Request-URI. If the Request-URI refers to an already | supplied Request-URI. If the Request-URI refers to an already | |||
existing resource, the enclosed entity SHOULD be considered as a | existing resource, the enclosed entity SHOULD be considered as a | |||
modified version of the one residing on the origin server. If the | modified version of the one residing on the origin server. If the | |||
Request-URI does not point to an existing resource, and that URI is | Request-URI does not point to an existing resource, and that URI is | |||
capable of being defined as a new resource by the requesting user | capable of being defined as a new resource by the requesting user | |||
agent, the origin server can create the resource with that URI. If a | agent, the origin server can create the resource with that URI. If a | |||
new resource is created, the origin server MUST inform the user agent | new resource is created, the origin server MUST inform the user agent | |||
skipping to change at page 65, line 51 | skipping to change at page 66, line 46 | |||
A single resource MAY be identified by many different URIs. For | A single resource MAY be identified by many different URIs. For | |||
example, an article might have a URI for identifying "the current | example, an article might have a URI for identifying "the current | |||
version" which is separate from the URI identifying each particular | version" which is separate from the URI identifying each particular | |||
version. In this case, a PUT request on a general URI might result | version. In this case, a PUT request on a general URI might result | |||
in several other URIs being defined by the origin server. | in several other URIs being defined by the origin server. | |||
HTTP/1.1 does not define how a PUT method affects the state of an | HTTP/1.1 does not define how a PUT method affects the state of an | |||
origin server. | origin server. | |||
PUT requests MUST obey the message transmission requirements set out | ||||
in Section 8.2. | ||||
Unless otherwise specified for a particular entity-header, the | Unless otherwise specified for a particular entity-header, the | |||
entity-headers in the PUT request SHOULD be applied to the resource | entity-headers in the PUT request SHOULD be applied to the resource | |||
created or modified by the PUT. | created or modified by the PUT. | |||
9.7. DELETE | 9.7. DELETE | |||
The DELETE method requests that the origin server delete the resource | The DELETE method requests that the origin server delete the resource | |||
identified by the Request-URI. This method MAY be overridden by | identified by the Request-URI. This method MAY be overridden by | |||
human intervention (or other means) on the origin server. The client | human intervention (or other means) on the origin server. The client | |||
cannot be guaranteed that the operation has been carried out, even if | cannot be guaranteed that the operation has been carried out, even if | |||
skipping to change at page 71, line 42 | skipping to change at page 71, line 42 | |||
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 entity-headers. Otherwise, the | response SHOULD NOT include other entity-headers. Otherwise, the | |||
response MUST include all of the entity-headers that would have been | response MUST include all of the entity-headers that would have been | |||
returned with a 200 (OK) response to the same request. | returned with a 200 (OK) response to the same request. | |||
A cache MUST NOT combine a 206 response with other previously cached | A cache MUST NOT combine a 206 response with other previously cached | |||
content if the ETag or Last-Modified headers do not match exactly, | content if the ETag or Last-Modified headers do not match exactly, | |||
see 13.5.4. | see 13.5.4. | |||
A cache that does not support the Range and Content-Range headers | A cache that does not support the Range and Content-Range headers | |||
MUST NOT cache 206 (Partial) responses. | MUST NOT cache 206 (Partial Content) responses. | |||
10.3. Redirection 3xx | 10.3. Redirection 3xx | |||
This class of status code indicates that further action needs to be | This class of status code indicates that further action needs to be | |||
taken by the user agent in order to fulfill the request. The action | taken by the user agent in order to fulfill the request. The action | |||
required MAY be carried out by the user agent without interaction | required MAY be carried out by the user agent without interaction | |||
with the user if and only if the method used in the second request is | with the user if and only if the method used in the second request is | |||
GET or HEAD. A client SHOULD detect infinite redirection loops, | GET or HEAD. A client SHOULD detect infinite redirection loops, | |||
since such loops generate network traffic for each redirection. | since such loops generate network traffic for each redirection. | |||
skipping to change at page 87, line 39 | skipping to change at page 87, line 39 | |||
the origin server so specifies, it is the freshness requirement | the origin server so specifies, it is the freshness requirement | |||
of the origin server alone. If a stored response is not "fresh | of the origin server alone. If a stored response is not "fresh | |||
enough" by the most restrictive freshness requirement of both the | enough" by the most restrictive freshness requirement of both the | |||
client and the origin server, in carefully considered | client and the origin server, in carefully considered | |||
circumstances the cache MAY still return the response with the | circumstances the cache MAY still return the response with the | |||
appropriate Warning header (see Section 13.1.5 and 14.46), unless | appropriate Warning header (see Section 13.1.5 and 14.46), unless | |||
such a response is prohibited (e.g., by a "no-store" cache- | such a response is prohibited (e.g., by a "no-store" cache- | |||
directive, or by a "no-cache" cache-request-directive; see | directive, or by a "no-cache" cache-request-directive; see | |||
Section 14.9). | Section 14.9). | |||
3. It is an appropriate 304 (Not Modified), 305 (Proxy Redirect), or | 3. It is an appropriate 304 (Not Modified), 305 (Use Proxy), or | |||
error (4xx or 5xx) response message. | error (4xx or 5xx) response message. | |||
If the cache can not communicate with the origin server, then a | If the cache can not communicate with the origin server, then a | |||
correct cache SHOULD respond as above if the response can be | correct cache SHOULD respond as above if the response can be | |||
correctly served from the cache; if not it MUST return an error or | correctly served from the cache; if not it MUST return an error or | |||
warning indicating that there was a communication failure. | warning indicating that there was a communication failure. | |||
If a cache receives a response (either an entire response, or a 304 | If a cache receives a response (either an entire response, or a 304 | |||
(Not Modified) response) that it would normally forward to the | (Not Modified) response) that it would normally forward to the | |||
requesting client, and the received response is no longer fresh, the | requesting client, and the received response is no longer fresh, the | |||
skipping to change at page 92, line 6 | skipping to change at page 92, line 6 | |||
and history mechanisms. | and history mechanisms. | |||
13.2.2. Heuristic Expiration | 13.2.2. Heuristic Expiration | |||
Since origin servers do not always provide explicit expiration times, | Since origin servers do not always provide explicit expiration times, | |||
HTTP caches typically assign heuristic expiration times, employing | HTTP caches typically assign heuristic expiration times, employing | |||
algorithms that use other header values (such as the Last-Modified | algorithms that use other header values (such as the Last-Modified | |||
time) to estimate a plausible expiration time. The HTTP/1.1 | time) to estimate a plausible expiration time. The HTTP/1.1 | |||
specification does not provide specific algorithms, but does impose | specification does not provide specific algorithms, but does impose | |||
worst-case constraints on their results. Since heuristic expiration | worst-case constraints on their results. Since heuristic expiration | |||
times might compromise semantic transparency, they ought to used | times might compromise semantic transparency, they ought to be used | |||
cautiously, and we encourage origin servers to provide explicit | cautiously, and we encourage origin servers to provide explicit | |||
expiration times as much as possible. | expiration times as much as possible. | |||
13.2.3. Age Calculations | 13.2.3. Age Calculations | |||
In order to know if a cached entry is fresh, a cache needs to know if | In order to know if a cached entry is fresh, a cache needs to know if | |||
its age exceeds its freshness lifetime. We discuss how to calculate | its age exceeds its freshness lifetime. We discuss how to calculate | |||
the latter in Section 13.2.4; this section describes how to calculate | the latter in Section 13.2.4; this section describes how to calculate | |||
the age of a response or cache entry. | the age of a response or cache entry. | |||
skipping to change at page 113, line 13 | skipping to change at page 113, line 13 | |||
The example | The example | |||
Accept: audio/*; q=0.2, audio/basic | Accept: audio/*; q=0.2, audio/basic | |||
SHOULD be interpreted as "I prefer audio/basic, but send me any audio | SHOULD be interpreted as "I prefer audio/basic, but send me any audio | |||
type if it is the best available after an 80% mark-down in quality." | type if it is the best available after an 80% mark-down in quality." | |||
If no Accept header field is present, then it is assumed that the | If no Accept header field is present, then it is assumed that the | |||
client accepts all media types. If an Accept header field is | client accepts all media types. If an Accept header field is | |||
present, and if the server cannot send a response which is acceptable | present, and if the server cannot send a response which is acceptable | |||
according to the combined Accept field value, then the server SHOULD | according to the combined Accept field value, then the server SHOULD | |||
send a 406 (not acceptable) response. | send a 406 (Not Acceptable) response. | |||
A more elaborate example is | A more elaborate example is | |||
Accept: text/plain; q=0.5, text/html, | Accept: text/plain; q=0.5, text/html, | |||
text/x-dvi; q=0.8, text/x-c | text/x-dvi; q=0.8, text/x-c | |||
Verbally, this would be interpreted as "text/html and text/x-c are | Verbally, this would be interpreted as "text/html and text/x-c are | |||
the preferred media types, but if they do not exist, then send the | the preferred media types, but if they do not exist, then send the | |||
text/x-dvi entity, and if that does not exist, send the text/plain | text/x-dvi entity, and if that does not exist, send the text/plain | |||
entity." | entity." | |||
skipping to change at page 114, line 40 | skipping to change at page 114, line 40 | |||
matches every character set (including ISO-8859-1) which is not | matches every character set (including ISO-8859-1) which is not | |||
mentioned elsewhere in the Accept-Charset field. If no "*" is | mentioned elsewhere in the Accept-Charset field. If no "*" is | |||
present in an Accept-Charset field, then all character sets not | present in an Accept-Charset field, then all character sets not | |||
explicitly mentioned get a quality value of 0, except for ISO-8859-1, | explicitly mentioned get a quality value of 0, except for ISO-8859-1, | |||
which gets a quality value of 1 if not explicitly mentioned. | which gets a quality value of 1 if not explicitly mentioned. | |||
If no Accept-Charset header is present, the default is that any | If no Accept-Charset header is present, the default is that any | |||
character set is acceptable. If an Accept-Charset header is present, | character set is acceptable. If an Accept-Charset header is present, | |||
and if the server cannot send a response which is acceptable | and if the server cannot send a response which is acceptable | |||
according to the Accept-Charset header, then the server SHOULD send | according to the Accept-Charset header, then the server SHOULD send | |||
an error response with the 406 (not acceptable) status code, though | an error response with the 406 (Not Acceptable) status code, though | |||
the sending of an unacceptable response is also allowed. | the sending of an unacceptable response is also allowed. | |||
14.3. Accept-Encoding | 14.3. Accept-Encoding | |||
The Accept-Encoding request-header field is similar to Accept, but | The Accept-Encoding request-header field is similar to Accept, but | |||
restricts the content-codings (Section 3.5) that are acceptable in | restricts the content-codings (Section 3.5) that are acceptable in | |||
the response. | the response. | |||
Accept-Encoding = "Accept-Encoding" ":" | Accept-Encoding = "Accept-Encoding" ":" | |||
1#( codings [ ";" "q" "=" qvalue ] ) | #( codings [ ";" "q" "=" qvalue ] ) | |||
codings = ( content-coding | "*" ) | codings = ( content-coding | "*" ) | |||
Examples of its use are: | Examples of its use are: | |||
Accept-Encoding: compress, gzip | Accept-Encoding: compress, gzip | |||
Accept-Encoding: | Accept-Encoding: | |||
Accept-Encoding: * | Accept-Encoding: * | |||
Accept-Encoding: compress;q=0.5, gzip;q=1.0 | Accept-Encoding: compress;q=0.5, gzip;q=1.0 | |||
Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0 | Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0 | |||
A server tests whether a content-coding is acceptable, according to | A server tests whether a content-coding is acceptable, according to | |||
skipping to change at page 135, line 37 | skipping to change at page 135, line 37 | |||
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 | 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 | 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 | for a set of ranges that overlap without any holes), this content is | |||
transmitted with a Content-Range header, and a Content-Length header | transmitted with a Content-Range header, and a Content-Length header | |||
showing the number of bytes actually transferred. For example, | showing the number of bytes actually transferred. For example, | |||
HTTP/1.1 206 Partial content | HTTP/1.1 206 Partial Content | |||
Date: Wed, 15 Nov 1995 06:25:24 GMT | Date: Wed, 15 Nov 1995 06:25:24 GMT | |||
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT | Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT | |||
Content-Range: bytes 21010-47021/47022 | Content-Range: bytes 21010-47021/47022 | |||
Content-Length: 26012 | Content-Length: 26012 | |||
Content-Type: image/gif | Content-Type: image/gif | |||
When an HTTP message includes the content of multiple ranges (for | When an HTTP message includes the content of multiple ranges (for | |||
example, a response to a request for multiple non-overlapping | example, a response to a request for multiple non-overlapping | |||
ranges), these are transmitted as a multipart message. The multipart | ranges), these are transmitted as a multipart message. The multipart | |||
media type used for this purpose is "multipart/byteranges" as defined | media type used for this purpose is "multipart/byteranges" as defined | |||
skipping to change at page 136, line 48 | skipping to change at page 136, line 48 | |||
Content-Type: text/html; charset=ISO-8859-4 | Content-Type: text/html; charset=ISO-8859-4 | |||
Further discussion of methods for identifying the media type of an | Further discussion of methods for identifying the media type of an | |||
entity is provided in Section 7.2.1. | entity is provided in Section 7.2.1. | |||
14.18. Date | 14.18. Date | |||
The Date general-header field represents the date and time at which | The Date general-header field represents the date and time at which | |||
the message was originated, having the same semantics as orig-date in | the message was originated, having the same semantics as orig-date in | |||
RFC 822. The field value is an HTTP-date, as described in | [RFC2822]. The field value is an HTTP-date, as described in | |||
Section 3.3.1; it MUST be sent in rfc1123-date format. | Section 3.3.1; it MUST be sent in rfc1123-date format. | |||
Date = "Date" ":" HTTP-date | Date = "Date" ":" HTTP-date | |||
An example is | An example is | |||
Date: Tue, 15 Nov 1994 08:12:31 GMT | Date: Tue, 15 Nov 1994 08:12:31 GMT | |||
Origin servers MUST include a Date header field in all responses, | Origin servers MUST include a Date header field in all responses, | |||
except in these cases: | except in these cases: | |||
skipping to change at page 139, line 14 | skipping to change at page 139, line 14 | |||
The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy MUST | The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy MUST | |||
return a 417 (Expectation Failed) status if it receives a request | return a 417 (Expectation Failed) status if it receives a request | |||
with an expectation that it cannot meet. However, the Expect | with an expectation that it cannot meet. However, the Expect | |||
request-header itself is end-to-end; it MUST be forwarded if the | request-header itself is end-to-end; it MUST be forwarded if the | |||
request is forwarded. | request is forwarded. | |||
Many older HTTP/1.0 and HTTP/1.1 applications do not understand the | Many older HTTP/1.0 and HTTP/1.1 applications do not understand the | |||
Expect header. | Expect header. | |||
See Section 8.2.3 for the use of the 100 (continue) status. | See Section 8.2.3 for the use of the 100 (Continue) status. | |||
14.21. Expires | 14.21. Expires | |||
The Expires entity-header field gives the date/time after which the | The Expires entity-header field gives the date/time after which the | |||
response is considered stale. A stale cache entry may not normally | response is considered stale. A stale cache entry may not normally | |||
be returned by a cache (either a proxy cache or a user agent cache) | be returned by a cache (either a proxy cache or a user agent cache) | |||
unless it is first validated with the origin server (or with an | unless it is first validated with the origin server (or with an | |||
intermediate cache that has a fresh copy of the entity). See | intermediate cache that has a fresh copy of the entity). See | |||
Section 13.2 for further discussion of the expiration model. | Section 13.2 for further discussion of the expiration model. | |||
skipping to change at page 140, line 16 | skipping to change at page 140, line 16 | |||
The presence of an Expires header field with a date value of some | The presence of an Expires header field with a date value of some | |||
time in the future on a response that otherwise would by default be | time in the future on a response that otherwise would by default be | |||
non-cacheable indicates that the response is cacheable, unless | non-cacheable indicates that the response is cacheable, unless | |||
indicated otherwise by a Cache-Control header field (Section 14.9). | indicated otherwise by a Cache-Control header field (Section 14.9). | |||
14.22. From | 14.22. From | |||
The From request-header field, if given, SHOULD contain an Internet | The From request-header field, if given, SHOULD contain an Internet | |||
e-mail address for the human user who controls the requesting user | e-mail address for the human user who controls the requesting user | |||
agent. The address SHOULD be machine-usable, as defined by "mailbox" | agent. The address SHOULD be machine-usable, as defined by "mailbox" | |||
in [RFC822] as updated by [RFC1123]: | in Section 3.4 of [RFC2822]: | |||
From = "From" ":" mailbox | From = "From" ":" mailbox | |||
An example is: | An example is: | |||
From: webmaster@w3.org | From: webmaster@w3.org | |||
This header field MAY be used for logging purposes and as a means for | This header field MAY be used for logging purposes and as a means for | |||
identifying the source of invalid or unwanted requests. It SHOULD | identifying the source of invalid or unwanted requests. It SHOULD | |||
NOT be used as an insecure form of access protection. The | NOT be used as an insecure form of access protection. The | |||
skipping to change at page 142, line 43 | skipping to change at page 142, line 43 | |||
The result of a request having both an If-Match header field and | The result of a request having both an If-Match header field and | |||
either an If-None-Match or an If-Modified-Since header fields is | either an If-None-Match or an If-Modified-Since header fields is | |||
undefined by this specification. | undefined by this specification. | |||
14.25. If-Modified-Since | 14.25. If-Modified-Since | |||
The If-Modified-Since request-header field is used with a method to | The If-Modified-Since request-header field is used with a method to | |||
make it conditional: if the requested variant has not been modified | make it conditional: if the requested variant has not been modified | |||
since the time specified in this field, an entity will not be | since the time specified in this field, an entity will not be | |||
returned from the server; instead, a 304 (not modified) response will | returned from the server; instead, a 304 (Not Modified) response will | |||
be returned without any message-body. | be returned without any message-body. | |||
If-Modified-Since = "If-Modified-Since" ":" HTTP-date | If-Modified-Since = "If-Modified-Since" ":" HTTP-date | |||
An example of the field is: | An example of the field is: | |||
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT | If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT | |||
A GET method with an If-Modified-Since header and no Range header | A GET method with an If-Modified-Since header and no Range header | |||
requests that the identified entity be transferred only if it has | requests that the identified entity be transferred only if it has | |||
been modified since the date given by the If-Modified-Since header. | been modified since the date given by the If-Modified-Since header. | |||
skipping to change at page 146, line 4 | skipping to change at page 146, line 4 | |||
If the client has no entity tag for an entity, but does have a Last- | If the client has no entity tag for an entity, but does have a Last- | |||
Modified date, it MAY use that date in an If-Range header. (The | Modified date, it MAY use that date in an If-Range header. (The | |||
server can distinguish between a valid HTTP-date and any form of | server can distinguish between a valid HTTP-date and any form of | |||
entity-tag by examining no more than two characters.) The If-Range | entity-tag by examining no more than two characters.) The If-Range | |||
header SHOULD only be used together with a Range header, and MUST be | header SHOULD only be used together with a Range header, and MUST be | |||
ignored if the request does not include a Range header, or if the | ignored if the request does not include a Range header, or if the | |||
server does not support the sub-range operation. | server does not support the sub-range operation. | |||
If the entity tag given in the If-Range header matches the current | If the entity tag given in the If-Range header matches the current | |||
entity tag for the entity, then the server SHOULD provide the | entity tag for the entity, then the server SHOULD provide the | |||
specified sub-range of the entity using a 206 (Partial content) | specified sub-range of the entity using a 206 (Partial Content) | |||
response. If the entity tag does not match, then the server SHOULD | response. If the entity tag does not match, then the server SHOULD | |||
return the entire entity using a 200 (OK) response. | return the entire entity using a 200 (OK) response. | |||
14.28. If-Unmodified-Since | 14.28. If-Unmodified-Since | |||
The If-Unmodified-Since request-header field is used with a method to | The If-Unmodified-Since request-header field is used with a method to | |||
make it conditional. If the requested resource has not been modified | make it conditional. If the requested resource has not been modified | |||
since the time specified in this field, the server SHOULD perform the | since the time specified in this field, the server SHOULD perform the | |||
requested operation as if the If-Unmodified-Since header were not | requested operation as if the If-Unmodified-Since header were not | |||
present. | present. | |||
skipping to change at page 158, line 37 | skipping to change at page 158, line 37 | |||
client), play a role in the selection of the response representation. | client), play a role in the selection of the response representation. | |||
The "*" value MUST NOT be generated by a proxy server; it may only be | The "*" value MUST NOT be generated by a proxy server; it may only be | |||
generated by an origin server. | generated by an origin server. | |||
14.45. Via | 14.45. Via | |||
The Via general-header field MUST be used by gateways and proxies to | The Via general-header field MUST be used by gateways and proxies to | |||
indicate the intermediate protocols and recipients between the user | indicate the intermediate protocols and recipients between the user | |||
agent and the server on requests, and between the origin server and | agent and the server on requests, and between the origin server and | |||
the client on responses. It is analogous to the "Received" field of | the client on responses. It is analogous to the "Received" field of | |||
[RFC822] and is intended to be used for tracking message forwards, | [RFC2822] and is intended to be used for tracking message forwards, | |||
avoiding request loops, and identifying the protocol capabilities of | avoiding request loops, and identifying the protocol capabilities of | |||
all senders along the request/response chain. | all senders along the request/response chain. | |||
Via = "Via" ":" 1#( received-protocol received-by [ comment ] ) | Via = "Via" ":" 1#( received-protocol received-by [ comment ] ) | |||
received-protocol = [ protocol-name "/" ] protocol-version | received-protocol = [ protocol-name "/" ] protocol-version | |||
protocol-name = token | protocol-name = token | |||
protocol-version = token | protocol-version = token | |||
received-by = ( host [ ":" port ] ) | pseudonym | received-by = ( host [ ":" port ] ) | pseudonym | |||
pseudonym = token | pseudonym = token | |||
skipping to change at page 169, line 10 | skipping to change at page 169, line 10 | |||
15.7.1. Denial of Service Attacks on Proxies | 15.7.1. Denial of Service Attacks on Proxies | |||
They exist. They are hard to defend against. Research continues. | They exist. They are hard to defend against. Research continues. | |||
Beware. | Beware. | |||
16. Acknowledgments | 16. Acknowledgments | |||
16.1. (RFC2616) | 16.1. (RFC2616) | |||
This specification makes heavy use of the augmented BNF and generic | This specification makes heavy use of the augmented BNF and generic | |||
constructs defined by David H. Crocker for [RFC822]. Similarly, it | constructs defined by David H. Crocker for [RFC822ABNF]. Similarly, | |||
reuses many of the definitions provided by Nathaniel Borenstein and | it reuses many of the definitions provided by Nathaniel Borenstein | |||
Ned Freed for MIME [RFC2045]. We hope that their inclusion in this | and Ned Freed for MIME [RFC2045]. We hope that their inclusion in | |||
specification will help reduce past confusion over the relationship | this specification will help reduce past confusion over the | |||
between HTTP and Internet mail message formats. | relationship between HTTP and Internet mail message formats. | |||
The HTTP protocol has evolved considerably over the years. It has | The HTTP protocol has evolved considerably over the years. It has | |||
benefited from a large and active developer community--the many | benefited from a large and active developer community--the many | |||
people who have participated on the www-talk mailing list--and it is | people who have participated on the www-talk mailing list--and it is | |||
that community which has been most responsible for the success of | that community which has been most responsible for the success of | |||
HTTP and of the World-Wide Web in general. Marc Andreessen, Robert | HTTP and of the World-Wide Web in general. Marc Andreessen, Robert | |||
Cailliau, Daniel W. Connolly, Bob Denny, John Franks, Jean-Francois | Cailliau, Daniel W. Connolly, Bob Denny, John Franks, Jean-Francois | |||
Groff, Phillip M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob | Groff, Phillip M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob | |||
McCool, Lou Montulli, Dave Raggett, Tony Sanders, and Marc | McCool, Lou Montulli, Dave Raggett, Tony Sanders, and Marc | |||
VanHeyningen deserve special recognition for their efforts in | VanHeyningen deserve special recognition for their efforts in | |||
skipping to change at page 170, line 23 | skipping to change at page 170, line 23 | |||
The Apache Group, Anselm Baird-Smith, author of Jigsaw, and Henrik | The Apache Group, Anselm Baird-Smith, author of Jigsaw, and Henrik | |||
Frystyk implemented RFC 2068 early, and we wish to thank them for the | Frystyk implemented RFC 2068 early, and we wish to thank them for the | |||
discovery of many of the problems that this document attempts to | discovery of many of the problems that this document attempts to | |||
rectify. | rectify. | |||
16.2. (This Document) | 16.2. (This Document) | |||
This document has benefited greatly from the comments of all those | This document has benefited greatly from the comments of all those | |||
participating in the HTTP-WG. In particular, we thank Scott Lawrence | participating in the HTTP-WG. In particular, we thank Scott Lawrence | |||
for maintaining the RFC2616 Errata list, and Mark Baker, Roy | for maintaining the RFC2616 Errata list, and Mark Baker, David Booth, | |||
Fielding, Bjoern Hoehrmann, Brian Kell, Jamie Lokier, Larry Masinter, | Adrien de Croy, Martin Duerst, Roy Fielding, Hugo Haas, Bjoern | |||
Howard Melman, Alexey Melnikov, Jeff Mogul, Henrik Nordstrom, Alex | Hoehrmann, Brian Kell, Jamie Lokier, Paul Marquess, Larry Masinter, | |||
Rousskov, Travis Snoozy and Dan Winship for contributions to it. | Howard Melman, Alexey Melnikov, Jeff Mogul, Henrik Nordstrom, Joe | |||
Orton, Alex Rousskov, Travis Snoozy and Dan Winship for further | ||||
contributions. | ||||
17. References | 17. References | |||
17.1. References (to be classified) | 17.1. References (to be classified) | |||
[RFC1737] Masinter, L. and K. Sollins, "Functional Requirements for | ||||
Uniform Resource Names", RFC 1737, December 1994. | ||||
[RFC2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose | ||||
Internet Mail Extensions (MIME) Part Four: Registration | ||||
Procedures", BCP 13, RFC 2048, November 1996. | ||||
17.2. Normative References | ||||
[ISO-8859-1] | [ISO-8859-1] | |||
International Organization for Standardization, | International Organization for Standardization, | |||
"Information technology - 8-bit single byte coded graphic | "Information technology -- 8-bit single-byte coded graphic | |||
- character sets", 1987-1990. | character sets -- Part 1: Latin alphabet No. 1", ISO/ | |||
IEC 8859-1:1998, 1998. | ||||
Part 1: Latin alphabet No. 1, ISO-8859-1:1987. Part 2: | [RFC1766] Alvestrand, H., "Tags for the Identification of | |||
Latin alphabet No. 2, ISO-8859-2, 1987. Part 3: Latin | Languages", RFC 1766, March 1995. | |||
alphabet No. 3, ISO-8859-3, 1988. Part 4: Latin alphabet | ||||
No. 4, ISO-8859-4, 1988. Part 5: Latin/Cyrillic alphabet, | [RFC1864] Myers, J. and M. Rose, "The Content-MD5 Header Field", | |||
ISO-8859-5, 1988. Part 6: Latin/Arabic alphabet, ISO- | RFC 1864, October 1995. | |||
8859-6, 1987. Part 7: Latin/Greek alphabet, ISO-8859-7, | ||||
1987. Part 8: Latin/Hebrew alphabet, ISO-8859-8, 1988. | [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format | |||
Part 9: Latin alphabet No. 5, ISO-8859-9, 1990. | Specification version 3.3", RFC 1950, May 1996. | |||
RFC1950 is an Informational RFC, thus it may be less | ||||
stable than this specification. On the other hand, this | ||||
downward reference was present since [RFC2068] (published | ||||
in 1997), therefore it is unlikely to cause problems in | ||||
practice. | ||||
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification | ||||
version 1.3", RFC 1951, May 1996. | ||||
RFC1951 is an Informational RFC, thus it may be less | ||||
stable than this specification. On the other hand, this | ||||
downward reference was present since [RFC2068] (published | ||||
in 1997), therefore it is unlikely to cause problems in | ||||
practice. | ||||
[RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G. | ||||
Randers-Pehrson, "GZIP file format specification version | ||||
4.3", RFC 1952, May 1996. | ||||
RFC1952 is an Informational RFC, thus it may be less | ||||
stable than this specification. On the other hand, this | ||||
downward reference was present since [RFC2068] (published | ||||
in 1997), therefore it is unlikely to cause problems in | ||||
practice. | ||||
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | ||||
Extensions (MIME) Part One: Format of Internet Message | ||||
Bodies", RFC 2045, November 1996. | ||||
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | ||||
Extensions (MIME) Part Two: Media Types", RFC 2046, | ||||
November 1996. | ||||
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) | ||||
Part Three: Message Header Extensions for Non-ASCII Text", | ||||
RFC 2047, November 1996. | ||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | ||||
Requirement Levels", BCP 14, RFC 2119, March 1997. | ||||
[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform | ||||
Resource Identifiers (URI): Generic Syntax", RFC 2396, | ||||
August 1998. | ||||
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., | ||||
Leach, P., Luotonen, A., and L. Stewart, "HTTP | ||||
Authentication: Basic and Digest Access Authentication", | ||||
RFC 2617, June 1999. | ||||
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, | ||||
April 2001. | ||||
[RFC822ABNF] | ||||
Crocker, D., "Standard for the format of ARPA Internet | ||||
text messages", STD 11, RFC 822, August 1982. | ||||
[USASCII] American National Standards Institute, "Coded Character | ||||
Set -- 7-bit American Standard Code for Information | ||||
Interchange", ANSI X3.4, 1986. | ||||
17.3. Informative References | ||||
[Luo1998] Luotonen, A., "Tunneling TCP based protocols through Web | [Luo1998] Luotonen, A., "Tunneling TCP based protocols through Web | |||
proxy servers", Work in Progress. | proxy servers", draft-luotonen-web-proxy-tunneling-01 | |||
(work in progress), August 1998. | ||||
[Nie1997] Nielsen, H., Gettys, J., Prud'hommeaux, E., Lie, H., and | [Nie1997] Nielsen, H., Gettys, J., Prud'hommeaux, E., Lie, H., and | |||
C. Lilley, "Network Performance Effects of HTTP/1.1, CSS1, | C. Lilley, "Network Performance Effects of HTTP/1.1, CSS1, | |||
and PNG", Proceedings of ACM SIGCOMM '97, Cannes France , | and PNG", Proceedings of ACM SIGCOMM '97, Cannes France , | |||
Sep 1997. | Sep 1997. | |||
[Pad1995] Padmanabhan, V. and J. Mogul, "Improving HTTP Latency", | [Pad1995] Padmanabhan, V. and J. Mogul, "Improving HTTP Latency", | |||
Computer Networks and ISDN Systems v. 28, pp. 25-35, | Computer Networks and ISDN Systems v. 28, pp. 25-35, | |||
Dec 1995. | Dec 1995. | |||
Slightly revised version of paper in Proc. 2nd | Slightly revised version of paper in Proc. 2nd | |||
International WWW Conference '94: Mosaic and the Web, Oct. | International WWW Conference '94: Mosaic and the Web, Oct. | |||
1994, which is available at <http://www.ncsa.uiuc.edu/SDG/ | 1994, which is available at <http://www.ncsa.uiuc.edu/SDG/ | |||
IT94/Proceedings/DDay/mogul/HTTPLatency.html>. | IT94/Proceedings/DDay/mogul/HTTPLatency.html>. | |||
[RFC1036] Horton, M. and R. Adams, "Standard for interchange of | ||||
USENET messages", RFC 1036, December 1987. | ||||
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application | [RFC1123] Braden, R., "Requirements for Internet Hosts - Application | |||
and Support", STD 3, RFC 1123, October 1989. | and Support", STD 3, RFC 1123, October 1989. | |||
[RFC1305] Mills, D., "Network Time Protocol (Version 3) | [RFC1305] Mills, D., "Network Time Protocol (Version 3) | |||
Specification, Implementation", RFC 1305, March 1992. | Specification, Implementation", RFC 1305, March 1992. | |||
[RFC1436] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., | [RFC1436] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., | |||
Torrey, D., and B. Alberti, "The Internet Gopher Protocol | Torrey, D., and B. Alberti, "The Internet Gopher Protocol | |||
(a distributed document search and retrieval protocol)", | (a distributed document search and retrieval protocol)", | |||
RFC 1436, March 1993. | RFC 1436, March 1993. | |||
[RFC1590] Postel, J., "Media Type Registration Procedure", RFC 1590, | ||||
March 1994. | ||||
[RFC1630] Berners-Lee, T., "Universal Resource Identifiers in WWW: A | [RFC1630] Berners-Lee, T., "Universal Resource Identifiers in WWW: A | |||
Unifying Syntax for the Expression of Names and Addresses | Unifying Syntax for the Expression of Names and Addresses | |||
of Objects on the Network as used in the World-Wide Web", | of Objects on the Network as used in the World-Wide Web", | |||
RFC 1630, June 1994. | RFC 1630, June 1994. | |||
[RFC1737] Masinter, L. and K. Sollins, "Functional Requirements for | ||||
Uniform Resource Names", RFC 1737, December 1994. | ||||
[RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform | [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform | |||
Resource Locators (URL)", RFC 1738, December 1994. | Resource Locators (URL)", RFC 1738, December 1994. | |||
[RFC1766] Alvestrand, H., "Tags for the Identification of | ||||
Languages", RFC 1766, March 1995. | ||||
[RFC1806] Troost, R. and S. Dorner, "Communicating Presentation | [RFC1806] Troost, R. and S. Dorner, "Communicating Presentation | |||
Information in Internet Messages: The Content-Disposition | Information in Internet Messages: The Content-Disposition | |||
Header", RFC 1806, June 1995. | Header", RFC 1806, June 1995. | |||
[RFC1808] Fielding, R., "Relative Uniform Resource Locators", | [RFC1808] Fielding, R., "Relative Uniform Resource Locators", | |||
RFC 1808, June 1995. | RFC 1808, June 1995. | |||
[RFC1864] Myers, J. and M. Rose, "The Content-MD5 Header Field", | ||||
RFC 1864, October 1995. | ||||
[RFC1866] Berners-Lee, T. and D. Connolly, "Hypertext Markup | ||||
Language - 2.0", RFC 1866, November 1995. | ||||
[RFC1867] Masinter, L. and E. Nebel, "Form-based File Upload in | ||||
HTML", RFC 1867, November 1995. | ||||
[RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", | [RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", | |||
RFC 1900, February 1996. | RFC 1900, February 1996. | |||
[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext | [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext | |||
Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. | Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. | |||
[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format | ||||
Specification version 3.3", RFC 1950, May 1996. | ||||
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification | ||||
version 1.3", RFC 1951, May 1996. | ||||
[RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G. | ||||
Randers-Pehrson, "GZIP file format specification version | ||||
4.3", RFC 1952, May 1996. | ||||
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision | [RFC2026] Bradner, S., "The Internet Standards Process -- Revision | |||
3", BCP 9, RFC 2026, October 1996. | 3", BCP 9, RFC 2026, October 1996. | |||
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | ||||
Extensions (MIME) Part One: Format of Internet Message | ||||
Bodies", RFC 2045, November 1996. | ||||
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | ||||
Extensions (MIME) Part Two: Media Types", RFC 2046, | ||||
November 1996. | ||||
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) | ||||
Part Three: Message Header Extensions for Non-ASCII Text", | ||||
RFC 2047, November 1996. | ||||
[RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | |||
Extensions (MIME) Part Five: Conformance Criteria and | Extensions (MIME) Part Five: Conformance Criteria and | |||
Examples", RFC 2049, November 1996. | Examples", RFC 2049, November 1996. | |||
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. | [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. | |||
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", | Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", | |||
RFC 2068, January 1997. | RFC 2068, January 1997. | |||
[RFC2069] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., | ||||
Luotonen, A., Sink, E., and L. Stewart, "An Extension to | ||||
HTTP : Digest Access Authentication", RFC 2069, | ||||
January 1997. | ||||
[RFC2076] Palme, J., "Common Internet Message Headers", RFC 2076, | [RFC2076] Palme, J., "Common Internet Message Headers", RFC 2076, | |||
February 1997. | February 1997. | |||
[RFC2110] Palme, J. and A. Hopmann, "MIME E-mail Encapsulation of | ||||
Aggregate Documents, such as HTML (MHTML)", RFC 2110, | ||||
March 1997. | ||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | ||||
Requirement Levels", BCP 14, RFC 2119, March 1997. | ||||
[RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use | [RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use | |||
and Interpretation of HTTP Version Numbers", RFC 2145, | and Interpretation of HTTP Version Numbers", RFC 2145, | |||
May 1997. | May 1997. | |||
[RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating | [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating | |||
Presentation Information in Internet Messages: The | Presentation Information in Internet Messages: The | |||
Content-Disposition Header Field", RFC 2183, August 1997. | Content-Disposition Header Field", RFC 2183, August 1997. | |||
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and | [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and | |||
Languages", BCP 18, RFC 2277, January 1998. | Languages", BCP 18, RFC 2277, January 1998. | |||
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO | ||||
10646", RFC 2279, January 1998. | ||||
[RFC2324] Masinter, L., "Hyper Text Coffee Pot Control Protocol | [RFC2324] Masinter, L., "Hyper Text Coffee Pot Control Protocol | |||
(HTCPCP/1.0)", RFC 2324, April 1998. | (HTCPCP/1.0)", RFC 2324, April 1998. | |||
[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform | [RFC2388] Masinter, L., "Returning Values from Forms: multipart/ | |||
Resource Identifiers (URI): Generic Syntax", RFC 2396, | form-data", RFC 2388, August 1998. | |||
August 1998. | ||||
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., | [RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud, | |||
Leach, P., Luotonen, A., and L. Stewart, "HTTP | "MIME Encapsulation of Aggregate Documents, such as HTML | |||
Authentication: Basic and Digest Access Authentication", | (MHTML)", RFC 2557, March 1999. | |||
RFC 2617, June 1999. | ||||
[RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, | [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., | |||
RFC 821, August 1982. | Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext | |||
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. | ||||
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, | ||||
April 2001. | ||||
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO | ||||
10646", RFC 3629, STD 63, November 2003. | ||||
[RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)", | ||||
RFC 3977, October 2006. | ||||
[RFC822] Crocker, D., "Standard for the format of ARPA Internet | [RFC822] Crocker, D., "Standard for the format of ARPA Internet | |||
text messages", STD 11, RFC 822, August 1982. | text messages", STD 11, RFC 822, August 1982. | |||
[RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol", | [RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol", | |||
STD 9, RFC 959, October 1985. | STD 9, RFC 959, October 1985. | |||
[Spero] Spero, S., "Analysis of HTTP Performance Problems", | [Spero] Spero, S., "Analysis of HTTP Performance Problems", | |||
<http://sunsite.unc.edu/mdma-release/http-prob.html>. | <http://sunsite.unc.edu/mdma-release/http-prob.html>. | |||
[Tou1998] Touch, J., Heidemann, J., and K. Obraczka, "Analysis of | [Tou1998] Touch, J., Heidemann, J., and K. Obraczka, "Analysis of | |||
HTTP Performance", ISI Research Report ISI/RR-98-463 | HTTP Performance", USC/ISI ISI/RR-98-463, Dec 1998, | |||
(original report dated Aug.1996), Aug 1998, | ||||
<http://www.isi.edu/touch/pubs/http-perf96/>. | <http://www.isi.edu/touch/pubs/http-perf96/>. | |||
[USASCII] American National Standards Institute, "Coded Character | (Original report dated Aug. 1996) | |||
Set -- 7-bit American Standard Code for Information | ||||
Interchange", ANSI X3.4, 1986. | ||||
[WAIS] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., | [WAIS] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., | |||
Wang, R., Sui, J., and M. Grinbaum, "WAIS Interface | Wang, R., Sui, J., and M. Grinbaum, "WAIS Interface | |||
Protocol Prototype Functional Specification (v1.5)", | Protocol Prototype Functional Specification (v1.5)", | |||
Thinking Machines Corporation , April 1990. | Thinking Machines Corporation , April 1990. | |||
17.2. Informative References | ||||
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., | ||||
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext | ||||
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. | ||||
[RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)", | ||||
RFC 3977, October 2006. | ||||
URIs | URIs | |||
[1] <mailto:ietf-http-wg@w3.org> | [1] <mailto:ietf-http-wg@w3.org> | |||
[2] <mailto:ietf-http-wg-request@w3.org?subject=subscribe> | [2] <mailto:ietf-http-wg-request@w3.org?subject=subscribe> | |||
[3] <http://tools.ietf.org/html/draft-lafon-rfc2616bis-01> | [3] <http://tools.ietf.org/html/draft-lafon-rfc2616bis-01> | |||
Appendix A. Internet Media Type message/http and application/http | Appendix A. Internet Media Type message/http and application/http | |||
In addition to defining the HTTP/1.1 protocol, this document serves | In addition to defining the HTTP/1.1 protocol, this document serves | |||
as the specification for the Internet media type "message/http" and | as the specification for the Internet media type "message/http" and | |||
"application/http". The message/http type can be used to enclose a | "application/http". The message/http type can be used to enclose a | |||
single HTTP request or response message, provided that it obeys the | single HTTP request or response message, provided that it obeys the | |||
MIME restrictions for all "message" types regarding line length and | MIME restrictions for all "message" types regarding line length and | |||
encodings. The application/http type can be used to enclose a | encodings. The application/http type can be used to enclose a | |||
pipeline of one or more HTTP request or response messages (not | pipeline of one or more HTTP request or response messages (not | |||
intermixed). The following is to be registered with IANA [RFC1590]. | intermixed). The following is to be registered with IANA [RFC2048]. | |||
Media Type name: message | Media Type name: message | |||
Media subtype name: http | Media subtype name: http | |||
Required parameters: none | Required parameters: none | |||
Optional parameters: version, msgtype | Optional parameters: version, msgtype | |||
version: The HTTP-Version number of the enclosed message (e.g., | version: The HTTP-Version number of the enclosed message (e.g., | |||
skipping to change at page 182, line 8 | skipping to change at page 182, line 8 | |||
local time zone MUST NOT influence the calculation or comparison | local time zone MUST NOT influence the calculation or comparison | |||
of an age or expiration time. | of an age or expiration time. | |||
o If an HTTP header incorrectly carries a date value with a time | o If an HTTP header incorrectly carries a date value with a time | |||
zone other than GMT, it MUST be converted into GMT using the most | zone other than GMT, it MUST be converted into GMT using the most | |||
conservative possible conversion. | conservative possible conversion. | |||
Appendix D. Differences Between HTTP Entities and RFC 2045 Entities | Appendix D. Differences Between HTTP Entities and RFC 2045 Entities | |||
HTTP/1.1 uses many of the constructs defined for Internet Mail | HTTP/1.1 uses many of the constructs defined for Internet Mail | |||
([RFC822]) and the Multipurpose Internet Mail Extensions (MIME | ([RFC2822]) and the Multipurpose Internet Mail Extensions (MIME | |||
[RFC2045]) to allow entities to be transmitted in an open variety of | [RFC2045]) to allow entities to be transmitted in an open variety of | |||
representations and with extensible mechanisms. However, RFC 2045 | representations and with extensible mechanisms. However, RFC 2045 | |||
discusses mail, and HTTP has a few features that are different from | discusses mail, and HTTP has a few features that are different from | |||
those described in RFC 2045. These differences were carefully chosen | those described in RFC 2045. These differences were carefully chosen | |||
to optimize performance over binary connections, to allow greater | to optimize performance over binary connections, to allow greater | |||
freedom in the use of new media types, to make date comparisons | freedom in the use of new media types, to make date comparisons | |||
easier, and to acknowledge the practice of some early HTTP servers | easier, and to acknowledge the practice of some early HTTP servers | |||
and clients. | and clients. | |||
This appendix describes specific areas where HTTP differs from RFC | This appendix describes specific areas where HTTP differs from RFC | |||
skipping to change at page 183, line 41 | skipping to change at page 183, line 41 | |||
media type, proxies and gateways from HTTP to MIME-compliant | media type, proxies and gateways from HTTP to MIME-compliant | |||
protocols MUST either change the value of the Content-Type header | protocols MUST either change the value of the Content-Type header | |||
field or decode the entity-body before forwarding the message. (Some | field or decode the entity-body before forwarding the message. (Some | |||
experimental applications of Content-Type for Internet mail have used | experimental applications of Content-Type for Internet mail have used | |||
a media-type parameter of ";conversions=<content-coding>" to perform | a media-type parameter of ";conversions=<content-coding>" to perform | |||
a function equivalent to Content-Encoding. However, this parameter | a function equivalent to Content-Encoding. However, this parameter | |||
is not part of RFC 2045). | is not part of RFC 2045). | |||
D.5. No Content-Transfer-Encoding | D.5. No Content-Transfer-Encoding | |||
HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC | HTTP does not use the Content-Transfer-Encoding field of RFC 2045. | |||
2045. Proxies and gateways from MIME-compliant protocols to HTTP | Proxies and gateways from MIME-compliant protocols to HTTP MUST | |||
MUST remove any CTE encoding prior to delivering the response message | remove any Content-Transfer-Encoding prior to delivering the response | |||
to an HTTP client. | message to an HTTP client. | |||
Proxies and gateways from HTTP to MIME-compliant protocols are | Proxies and gateways from HTTP to MIME-compliant protocols are | |||
responsible for ensuring that the message is in the correct format | responsible for ensuring that the message is in the correct format | |||
and encoding for safe transport on that protocol, where "safe | and encoding for safe transport on that protocol, where "safe | |||
transport" is defined by the limitations of the protocol being used. | transport" is defined by the limitations of the protocol being used. | |||
Such a proxy or gateway SHOULD label the data with an appropriate | Such a proxy or gateway SHOULD label the data with an appropriate | |||
Content-Transfer-Encoding if doing so will improve the likelihood of | Content-Transfer-Encoding if doing so will improve the likelihood of | |||
safe transport over the destination protocol. | safe transport over the destination protocol. | |||
D.6. Introduction of Transfer-Encoding | D.6. Introduction of Transfer-Encoding | |||
skipping to change at page 184, line 32 | skipping to change at page 184, line 32 | |||
read entity-header | read entity-header | |||
while (entity-header not empty) { | while (entity-header not empty) { | |||
append entity-header to existing header fields | append entity-header to existing header fields | |||
read entity-header | read entity-header | |||
} | } | |||
Content-Length := length | Content-Length := length | |||
Remove "chunked" from Transfer-Encoding | Remove "chunked" from Transfer-Encoding | |||
D.7. MHTML and Line Length Limitations | D.7. MHTML and Line Length Limitations | |||
HTTP implementations which share code with MHTML [RFC2110] | HTTP implementations which share code with MHTML [RFC2557] | |||
implementations need to be aware of MIME line length limitations. | implementations need to be aware of MIME line length limitations. | |||
Since HTTP does not have this limitation, HTTP does not fold long | Since HTTP does not have this limitation, HTTP does not fold long | |||
lines. MHTML messages being transported by HTTP follow all | lines. MHTML messages being transported by HTTP follow all | |||
conventions of MHTML, including line length limitations and folding, | conventions of MHTML, including line length limitations and folding, | |||
canonicalization, etc., since HTTP transports all message-bodies as | canonicalization, etc., since HTTP transports all message-bodies as | |||
payload (see Section 3.7.2) and does not interpret the content or any | payload (see Section 3.7.2) and does not interpret the content or any | |||
MIME header lines that might be contained therein. | MIME header lines that might be contained therein. | |||
Appendix E. Additional Features | Appendix E. Additional Features | |||
skipping to change at page 188, line 20 | skipping to change at page 188, line 20 | |||
Clarified which error code should be used for inbound server failures | Clarified which error code should be used for inbound server failures | |||
(e.g. DNS failures). (Section 10.5.5). | (e.g. DNS failures). (Section 10.5.5). | |||
CREATE had a race that required an Etag be sent when a resource is | CREATE had a race that required an Etag be sent when a resource is | |||
first created. (Section 10.2.2). | first created. (Section 10.2.2). | |||
Content-Base was deleted from the specification: it was not | Content-Base was deleted from the specification: it was not | |||
implemented widely, and there is no simple, safe way to introduce it | implemented widely, and there is no simple, safe way to introduce it | |||
without a robust extension mechanism. In addition, it is used in a | without a robust extension mechanism. In addition, it is used in a | |||
similar, but not identical fashion in MHTML [RFC2110]. | similar, but not identical fashion in MHTML [RFC2557]. | |||
Transfer-coding and message lengths all interact in ways that | Transfer-coding and message lengths all interact in ways that | |||
required fixing exactly when chunked encoding is used (to allow for | required fixing exactly when chunked encoding is used (to allow for | |||
transfer encoding that may not be self delimiting); it was important | transfer encoding that may not be self delimiting); it was important | |||
to straighten out exactly how message lengths are computed. | to straighten out exactly how message lengths are computed. | |||
(Sections 3.6, 4.4, 7.2.2, 13.5.2, 14.13, 14.16) | (Sections 3.6, 4.4, 7.2.2, 13.5.2, 14.13, 14.16) | |||
A content-coding of "identity" was introduced, to solve problems | A content-coding of "identity" was introduced, to solve problems | |||
discovered in caching. (Section 3.5) | discovered in caching. (Section 3.5) | |||
skipping to change at page 190, line 33 | skipping to change at page 190, line 33 | |||
The PATCH, LINK, UNLINK methods were defined but not commonly | The PATCH, LINK, UNLINK methods were defined but not commonly | |||
implemented in previous versions of this specification. See | implemented in previous versions of this specification. See | |||
[RFC2068]. | [RFC2068]. | |||
The Alternates, Content-Version, Derived-From, Link, URI, Public and | The Alternates, Content-Version, Derived-From, Link, URI, Public and | |||
Content-Base header fields were defined in previous versions of this | Content-Base header fields were defined in previous versions of this | |||
specification, but not commonly implemented. See [RFC2068]. | specification, but not commonly implemented. See [RFC2068]. | |||
F.4. Changes from RFC 2616 | F.4. Changes from RFC 2616 | |||
Fix bug in BNF allowing backslash characters in qdtext production. | ||||
(Section 2.2) | ||||
Clarify that HTTP-Version is case sensitive. (Section 3.1) | Clarify that HTTP-Version is case sensitive. (Section 3.1) | |||
Eliminate overlooked reference to "unsafe" characters. | Eliminate overlooked reference to "unsafe" characters. | |||
(Section 3.2.3) | (Section 3.2.3) | |||
Clarify contexts that charset is used in. (Section 3.4) | Clarify contexts that charset is used in. (Section 3.4) | |||
Remove reference to non-existant identity transfer-coding value | Remove reference to non-existant identity transfer-coding value | |||
tokens. (Sections 3.6, 4.4 and D.5) | tokens. (Sections 3.6, 4.4 and D.5) | |||
skipping to change at page 191, line 17 | skipping to change at page 191, line 20 | |||
safe to automatically redirect, and further that the user agent is | safe to automatically redirect, and further that the user agent is | |||
able to make that determination based on the request method | able to make that determination based on the request method | |||
semantics. (Sections 10.3.2, 10.3.3 and 10.3.8 ) | semantics. (Sections 10.3.2, 10.3.3 and 10.3.8 ) | |||
Fix misspelled header and clarify requirements for hop-by-hop headers | Fix misspelled header and clarify requirements for hop-by-hop headers | |||
introduced in future specifications. (Section 13.5.1) | introduced in future specifications. (Section 13.5.1) | |||
Clarify denial of service attack avoidance requirement. | Clarify denial of service attack avoidance requirement. | |||
(Section 13.10) | (Section 13.10) | |||
Fix bug in BNF disallowing empty Accept-Encoding headers. | ||||
(Section 14.3) | ||||
Clarify exactly when close connection options must be sent. | Clarify exactly when close connection options must be sent. | |||
(Section 14.10) | (Section 14.10) | |||
Correct syntax of Location header to allow fragment, as referred | Correct syntax of Location header to allow fragment, as referred | |||
symbol wasn't what was expected, and add some clarifications as to | symbol wasn't what was expected, and add some clarifications as to | |||
when it would not be appropriate. (Section 14.30) | when it would not be appropriate. (Section 14.30) | |||
In the description of the Server header, the Via field was described | In the description of the Server header, the Via field was described | |||
as a SHOULD. The requirement was and is stated correctly in the | as a SHOULD. The requirement was and is stated correctly in the | |||
description of the Via header, Section 14.45. (Section 14.38) | description of the Via header, Section 14.45. (Section 14.38) | |||
skipping to change at page 194, line 5 | skipping to change at page 193, line 18 | |||
13.5.1-and-13.5.2", "i61-redirection-vs-location", "i62-whitespace- | 13.5.1-and-13.5.2", "i61-redirection-vs-location", "i62-whitespace- | |||
in-quoted-pair", "i63-header-length-limit-with-encoded-words" and | in-quoted-pair", "i63-header-length-limit-with-encoded-words" and | |||
"i67-quoting-charsets". | "i67-quoting-charsets". | |||
Add and resolve issues "i45-rfc977-reference", "i46-rfc1700_remove", | Add and resolve issues "i45-rfc977-reference", "i46-rfc1700_remove", | |||
"i47-inconsistency-in-date-format-explanation", "i48-date-reference- | "i47-inconsistency-in-date-format-explanation", "i48-date-reference- | |||
typo" and "i49-connection-header-text". | typo" and "i49-connection-header-text". | |||
Rename "References" to "References (to be classified)". | Rename "References" to "References (to be classified)". | |||
G.5. Since draft-lafon-rfc2616bis-03 | ||||
Add issues "i19-bodies-on-GET", "i20-default-charsets-for-text-media- | ||||
types", "i22-etag-and-other-metadata-in-status-messages", "i23-no- | ||||
store-invalidation", "i24-requiring-allow-in-405-responses", "i27- | ||||
put-idempotency", "i28-connection-closing", "i29-age-calculation", | ||||
"i30-header-lws", "i32-options-asterisk", "i33-trace-security- | ||||
considerations", "i35-split-normative-and-informative-references", | ||||
"i37-vary-and-non-existant-headers", "i38-mismatched-vary", "i39- | ||||
etag-uniqueness", "i40-header-registration", "i41-security- | ||||
considerations", "i64-ws-in-quoted-pair", "i69-clarify-requested- | ||||
variant", "i70-cacheability-of-303", "i71-examples-for-etag- | ||||
matching", "i72-request-method-registry", "i73-clarification-of-the- | ||||
term-deflate", "i74-character-encodings-for-headers", "i75-rfc2145- | ||||
normative", "i76-deprecate-305-use-proxy", "i77-line-folding", "i78- | ||||
relationship-between-401-authorization-and-www-authenticate", "i79- | ||||
content-headers-vs-put", "i80-content-location-is-not-special", "i81- | ||||
content-negotiation-for-media-types", "i82-rel_path-not-used" and | ||||
"i83-options-asterisk-and-proxies" and "i85-custom-ranges". | ||||
Reopen and close issue "i47-inconsistency-in-date-format- | ||||
explanation". | ||||
Resolve issues "unneeded_references" and "i62-whitespace-in-quoted- | ||||
pair" (as duplicate of "i64-ws-in-quoted-pair"). | ||||
Add and resolve issues "abnf-edit", "consistent-reason-phrases", | ||||
"i25-accept-encoding-bnf", "i26-import-query-bnf", "i31-qdtext-bnf", | ||||
"i65-informative-references", "i66-iso8859-1-reference", "i68- | ||||
encoding-references-normative", "i84-redundant-cross-references", | ||||
"i86-normative-up-to-date-references", "i87-typo-in-13.2.2", "media- | ||||
reg" (which wasn't resolved by drafts -02 and -03, after all), | ||||
"remove-CTE-abbrev", "rfc1766_normative", "rfc2396_normative" and | ||||
"usascii_normative". | ||||
Add new section "Normative References" (the old "References (to be | ||||
classified)" section will be removed once all references are re- | ||||
classified). | ||||
Update contact information for Jim Gettys. | ||||
Appendix H. Resolved issues (to be removed by RFC Editor before | Appendix H. Resolved issues (to be removed by RFC Editor before | |||
publication) | publication) | |||
Issues that were either rejected or resolved in this version of this | Issues that were either rejected or resolved in this version of this | |||
document. | document. | |||
H.1. i45-rfc977-reference | H.1. unneeded_references | |||
Type: edit | Type: edit | |||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i45> | <http://lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/0054>, | |||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i44> | ||||
julian.reschke@greenbytes.de (2006-10-26): Classify RFC977 (NNTP) as | julian.reschke@greenbytes.de (2006-10-19): The reference entries for | |||
informative, and update the reference to RFC3977. | RFC1866, RFC2069 and RFC2026 are unused. Remove them? | |||
Resolution (2006-10-26): Done. | julian.reschke@greenbytes.de (2006-11-02): See also | |||
<http://lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/0118>. | ||||
H.2. i46-rfc1700_remove | Resolution (2006-10-24): Remove references to RFC1866 and RFC2069 for | |||
now. Keep RFC2026 for now; it's referenced from Editorial note. | ||||
H.2. consistent-reason-phrases | ||||
Type: edit | Type: edit | |||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i46> | <http://www.w3.org/mid/472E16C5.8000703@gmx.de> | |||
julian.reschke@greenbytes.de (2006-11-12): RFC1700 ("ASSIGNED | julian.reschke@greenbytes.de (2007-11-04): Use consistent status | |||
NUMBERS") has been obsoleted by RFC3232 ("Assigned Numbers: RFC 1700 | reason phrases. | |||
is Replaced by an On-line Database"). | ||||
draft-gettys-http-v11-spec-rev-00 just updates the reference, which I | ||||
think is a bug. | ||||
In fact, RFC2616 refers to RCF1700 | ||||
(1) for the definition of the default TCP port (Section 1.4), | ||||
(2) for a reference to the character set registry (Section 3.4) and | ||||
(3) for a reference to the media type registry (Section 3.7). | ||||
I propose to remove the reference, and to make the following changes: | ||||
(1) Replace reference with in-lined URL of the IANA port registry, | ||||
(2) Replace the first reference with the in-lined URL of the IANA | ||||
character set registry, and drop the second one, and | ||||
(3) Drop the reference, as the next sentence refers to the Media Type | ||||
Registration Process anyway. | ||||
(see also <http://lists.w3.org/Archives/Public/ietf-http-wg/ | ||||
2006OctDec/0181.html> | ||||
Resolution (2007-03-18): Accepted during the Prague meeting, see | Resolution (2007-11-15): Done. | |||
http://www.w3.org/2007/03/18-rfc2616-minutes.html#action21. | ||||
H.3. i47-inconsistency-in-date-format-explanation | H.3. i66-iso8859-1-reference | |||
Type: change | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i66> | ||||
julian.reschke@greenbytes.de (2006-10-28): Classify ISO8859 as | ||||
normative, and simplify reference to only refer to ISO8859 Part 1 | ||||
(because that's the only part needed here), and update to the 1998 | ||||
version. | ||||
Resolution (2006-10-28): Done. | ||||
H.4. abnf-edit | ||||
Type: edit | ||||
<http://www.w3.org/mid/4739C417.2040203@gmx.de> | ||||
julian.reschke@greenbytes.de (2007-11-13): Fix minor editorial issues | ||||
with BNF causing problems with ABNF parsers, such as (1) inconsistent | ||||
indentation and (2) missing whitespace. | ||||
Resolution (2007-11-15): Done. | ||||
H.5. rfc1766_normative | ||||
Type: edit | ||||
julian.reschke@greenbytes.de (2006-11-15): Classify RFC1766 ("Tags | ||||
for the Identification of Languages") as normative (update to RFC4646 | ||||
in a separate step, see issue languagetag). | ||||
Resolution (2006-11-15): Done. | ||||
H.6. i86-normative-up-to-date-references | ||||
Type: edit | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i86> | ||||
julian.reschke@greenbytes.de (2006-11-12): Classify RFC1864 ("The | ||||
Content-MD5 Header Field") as normative. Note that note this | ||||
disagrees with draft-gettys-http-v11-spec-rev-00 which made it | ||||
informative. | ||||
julian.reschke@greenbytes.de (2006-11-14): Classify RFC2045 | ||||
("Multipurpose Internet Mail Extensions (MIME) Part One: Format of | ||||
Internet Message Bodies") as normative. | ||||
julian.reschke@greenbytes.de (2006-11-12): Classify RFC2046 | ||||
("Multipurpose Internet Mail Extensions (MIME) Part Two: Media | ||||
Types") as normative. | ||||
julian.reschke@greenbytes.de (2006-11-12): Classify RFC2047 ("MIME | ||||
(Multipurpose Internet Mail Extensions) Part Three: Message Header | ||||
Extensions for Non-ASCII Text") as normative. | ||||
julian.reschke@greenbytes.de (2006-10-27): Classify RFC2119 (Key | ||||
words for use in RFCs to Indicate Requirement Levels) as normative. | ||||
julian.reschke@greenbytes.de (2006-10-27): Classify RFC2617 (HTTP | ||||
Authentication) as normative. | ||||
Resolution (2007-10-12): Done. | ||||
H.7. i68-encoding-references-normative | ||||
Type: edit | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i68> | ||||
julian.reschke@greenbytes.de (2007-05-28): Classify RFC1950 (ZLIB), | ||||
RFC1951 (DEFLATE) and RFC1952 (GZIP) as normative (note this | ||||
disagrees with draft-gettys-http-v11-spec-rev-00 which made it | ||||
informative). | ||||
julian.reschke@greenbytes.de (2007-06-16): RFC4897 requires us to add | ||||
notes to the references explaining why the downref was made (see | ||||
<http://tools.ietf.org/html/rfc4897#section-3.1>). | ||||
Resolution (2007-06-18): Done. | ||||
H.8. rfc2396_normative | ||||
Type: edit | ||||
julian.reschke@greenbytes.de (2006-11-13): Classify RFC2396 ("Uniform | ||||
Resource Identifiers (URI): Generic Syntax") as normative (update to | ||||
RFC3986 in a separate step, see i34-updated-reference-for-uris). | ||||
Resolution (2006-11-13): Done. | ||||
H.9. usascii_normative | ||||
Type: edit | ||||
julian.reschke@greenbytes.de (2006-10-27): Classify USASCII as | ||||
normative. | ||||
Resolution (2006-10-27): Done. | ||||
H.10. i65-informative-references | ||||
Type: edit | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i65> | ||||
julian.reschke@greenbytes.de (2007-05-28): The following references | ||||
are informative: Luo1998 ("Tunneling TCP based protocols through Web | ||||
proxy servers", also update reference to quote the expired Internet | ||||
Draft properly). Nie1997 ("Network Performance Effects of HTTP/1.1, | ||||
CSS1, and PNG"). Pad1995 ("Improving HTTP Latency"). RFC821 (SMTP), | ||||
also update the reference to RFC2821. RFC822 ("STANDARD FOR THE | ||||
FORMAT OF ARPA INTERNET TEXT MESSAGES") -- but add another instance | ||||
as RFC822ABNF for the cases where the reference if for the ABNF part | ||||
(these references will later be replaced by references to RFC4234 | ||||
(see issue abnf)). RFC959 (FTP). RFC1036 ("Standard for Interchange | ||||
of USENET Messages"). RFC1123 ("Requirements for Internet Hosts -- | ||||
Application and Support") -- it is only used as a background | ||||
reference for rfc1123-date, which this spec defines itself (note this | ||||
disagrees with draft-gettys-http-v11-spec-rev-00 which made it | ||||
normative). RFC1305 ("Network Time Protocol (Version 3)"). RFC1436 | ||||
(Gopher). RFC1630 (URI Syntax) -- there'll be a normative reference | ||||
to a newer spec. RFC1738 (URL) -- there'll be a normative reference | ||||
to a newer spec. RFC1806 ("Communicating Presentation Information in | ||||
Internet Messages: The Content-Disposition Header"). RFC1808 | ||||
(Relative Uniform Resource Locators). RFC1867 ("Form-based File | ||||
Upload in HTML"), also update the reference to RFC2388 ("Returning | ||||
Values from Forms: multipart/form-data"). RFC1900 ("Renumbering | ||||
Needs Work"). RFC1945 (HTTP/1.0). RFC2026 ("The Internet Standards | ||||
Process -- Revision 3"). RFC2049 ("Multipurpose Internet Mail | ||||
Extensions (MIME) Part Five: Conformance Criteria and Examples"). | ||||
RFC2068 (HTTP/1.1). RFC2076 ("Common Internet Message Headers"). | ||||
RFC2110 (MHTML), also update the reference to RFC2557. RFC2145 ("Use | ||||
and Interpretation of HTTP Version Numbers"). RFC2183 | ||||
("Communicating Presentation Information in Internet Messages: The | ||||
Content-Disposition Header Field"). RFC2277 ("IETF Policy on | ||||
Character Sets and Languages"). RFC2279 (UTF8), also update the | ||||
reference to RFC3629. RFC2324 (HTCPCP/1.0). Spero ("Analysis of | ||||
HTTP Performance Problems"). Tou1998 ("Analysis of HTTP | ||||
Performance"). WAIS ("WAIS Interface Protocol Prototype Functional | ||||
Specification (v1.5)"). | ||||
derhoermi@gmx.net (2007-05-28): _On RFC1950-1952:_ Understanding | ||||
these documents is required in order to understand the coding values | ||||
defined for the coding registry established and used by the document; | ||||
why would it be appropriate to cite them as informative? | ||||
Resolution (2007-06-12): Done (with the exceptions noted by Bjoern | ||||
Hoehrmann). | ||||
H.11. i31-qdtext-bnf | ||||
In Section 2.2: | ||||
Type: change | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i31> | ||||
jamie@shareable.org (2004-03-15): ...I wrote a regular expression | ||||
based on the RFC 2616 definition, and that allows "foo\" as a quoted- | ||||
string. That's not intended, is it? | ||||
Resolution (2007-06-18): Resolved as per | ||||
http://www.w3.org/2007/03/18-rfc2616-minutes.html#action13. | ||||
H.12. i62-whitespace-in-quoted-pair | ||||
In Section 2.2: | ||||
Type: change | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i62> | ||||
dan.winship@gmail.com (2007-04-20): (...) RFC 2822 updates RFC 822's | ||||
quoted-pair rule to disallow CR, LF, and NUL. We should probably | ||||
make the same change. | ||||
Resolution (2007-10-07): Closed as duplicate of i64-ws-in-quoted- | ||||
pair. | ||||
H.13. i26-import-query-bnf | ||||
In Section 3.2.2: | ||||
Type: edit | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i26> | ||||
abodeman@yahoo.com (2005-05-23): | ||||
In section 3.2.2, http_URL is defined as follows: | ||||
"http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query | ||||
]]" -- http://tools.ietf.org/html/rfc2616.html#section-3.2.2 | ||||
However, RFC 2616 does not contain a rule called "query". I assume | ||||
this is meant to be the same "query" that is defined in RFC 2396, | ||||
since section 3.2.1 incorporates "URI-reference", "absoluteURI", | ||||
"relativeURI", "port", "host", "abs_path", "rel_path", and | ||||
"authority" from that specification (but "query" is missing from this | ||||
list). | ||||
Resolution (2007-10-06): Add "query" to the list of definitions | ||||
adopted from RCF2396 (note that RFC2396 has been obsoleted by | ||||
RFC3986, but this is a separate issue). | ||||
H.14. i47-inconsistency-in-date-format-explanation | ||||
In Section 3.3.1: | In Section 3.3.1: | |||
Type: edit | Type: edit | |||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i47> | <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i47> | |||
julian.reschke@greenbytes.de (2006-11-20): Should say "...obsolete | julian.reschke@greenbytes.de (2006-11-20): Should say "...obsolete | |||
RFC1036 date format [...]..." instead of "...obsolete RFC 850 [12] | RFC1036 date format [...]..." instead of "...obsolete RFC 850 [12] | |||
date format...". | date format...". | |||
See also <http://lists.w3.org/Archives/Public/ietf-http-wg/ | See also <http://lists.w3.org/Archives/Public/ietf-http-wg/ | |||
2006OctDec/0187.html>. | 2006OctDec/0187.html>. | |||
Resolution (2006-11-20): Done. | fielding@gbiv.com (2007-11-02): | |||
H.4. i49-connection-header-text | The proposed resolution to this issue (in draft 03) is incorrect | |||
because RFC1036 doesn't define the date format in question. This was | ||||
an error introduced in the 2616 editing cycle. It should be fixed by | ||||
removing reference to 1036, as described below: | ||||
In Section 13.5.1: | <del>RFC 850, obsoleted by RFC 1036</del><ins>obsolete RFC 850 | |||
format</ins> | ||||
<del>The second format is in common use, but is based on the obsolete | ||||
RFC 850 [RFC1036] date format and lacks a four-digit year.</del><ins> | ||||
The other formats are described here only for compatibility with | ||||
obsolete implementations.</ins> | ||||
Resolution (2007-11-03): Resolved as proposed by Roy. | ||||
H.15. media-reg | ||||
In Section 3.7: | ||||
Type: change | Type: change | |||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i49> | <http://purl.org/NET/http-errata#media-reg>, | |||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i8> | ||||
julian.reschke@greenbytes.de (2006-12-12): "Other hop-by-hop headers | derhoermi@gmx.net (2000-09-10): See <http://lists.w3.org/Archives/ | |||
MUST be listed in a Connection header, (section 14.10) to be | Public/ietf-http-wg-old/2000SepDec/0013>. | |||
introduced into HTTP/1.1 (or later)." doesn't really make sense. | ||||
(See <http://lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/ | ||||
0264.html>) | ||||
Jeff.Mogul@hp.com (2006-12-12): Proposed rewrite: " Other hop-by-hop | Resolution (2006-11-14): Done (note that RFC2048 has been obsoleted | |||
headers, if they are introduced either in HTTP/1.1 or later versions | now as well; see separate issue rfc2048_informative_and_obsolete). | |||
of HTTP/1.x, MUST be listed in a Connection header (Section 14.10)." | Note that the prosed resolution in | |||
(See <http://lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/ | http://purl.org/NET/http-errata#media-reg contains typos both in the | |||
0265.html>) | original text ("4288" rather than "1590") and in the proposed | |||
resolution ("Mulitpurpose"). | ||||
Resolution (2006-12-15): Resolve as proposed by Jeff Mogul in <http:/ | H.16. i84-redundant-cross-references | |||
/lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/0265.html>. | ||||
H.5. i48-date-reference-typo | In Section 9.5: | |||
In Section 14.18: | Type: change | |||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i84> | ||||
fielding@gbiv.com (2007-09-28): | ||||
RFC 2616 sections 9.5 (POST) and 9.6 (PUT) have the following useless | ||||
waste of bits | ||||
"POST requests MUST obey the message transmission requirements set | ||||
out in section 8.2. | ||||
See section 15.1.3 for security considerations." -- | ||||
http://tools.ietf.org/html/rfc2616#section-9.5 | ||||
and | ||||
"PUT requests MUST obey the message transmission requirements set | ||||
out in section 8.2." -- | ||||
http://tools.ietf.org/html/rfc2616#section-9.6 | ||||
respectively. They can be safely deleted without changing HTTP. | ||||
Section 8.2 is not specific to PUT and POST. Likewise, a content- | ||||
free forward pointer to just one of the many subsections on security | ||||
consideration is a total waste of brain cells. | ||||
Those are just two examples of what can only be described as a | ||||
spaghetti style of content-free cross-references within the spec that | ||||
make it very hard to read. They should be removed in general at the | ||||
editors' discretion. | ||||
Resolution (2007-09-29): Remove text as proposed. | ||||
H.17. i87-typo-in-13.2.2 | ||||
In Section 13.2.2: | ||||
Type: edit | Type: edit | |||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i48> | <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i87> | |||
fielding@gbiv.com (2007-09-07): | ||||
julian.reschke@greenbytes.de (2006-11-20): Should say "rfc1123-date | This typo is still in the current draft. | |||
format [...]" instead of "[...]-date format". | ||||
See also <http://lists.w3.org/Archives/Public/ietf-http-wg/ | ||||
2006OctDec/0186.html> | ||||
hno@squid-cache.org (2006-11-29): Better without the [8], making it | ||||
an internal reference to the grammar. The rfc1123-date is not a copy | ||||
of RFC1123, only a subset thereof. | ||||
The relation to RFC 1123 is already well established elsewhere in | ||||
3.3.1, including the MUST level requirement on sending the RFC 1123 | ||||
derived format. | ||||
A similar RFC 1123 reference which is better replaced by a rfc1123- | ||||
date grammar reference is also seen in 14.21 Last-Modified. | ||||
Resolution (2006-11-30): Done. | s/ought to used/ought to be used/; | |||
Resolution (2007-09-08): Fixed. | ||||
H.18. i25-accept-encoding-bnf | ||||
In Section 14.3: | ||||
Type: change | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i25> | ||||
abodeman@yahoo.com (2005-06-02): | ||||
In section 14.3, the definition of Accept-Encoding is given as | ||||
follows: | ||||
Accept-Encoding = "Accept-Encoding" ":" | ||||
1#( codings [ ";" "q" "=" qvalue ] ) | ||||
This definition implies that there must be at least one non-null | ||||
codings. However, just below this definition, one of the examples | ||||
given has an empty Accept-Encoding field-value: | ||||
Accept-Encoding: compress, gzip | ||||
Accept-Encoding: | ||||
Accept-Encoding: * | ||||
Accept-Encoding: compress;q=0.5, gzip;q=1.0 | ||||
Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0 | ||||
Furthermore, the fourth rule for testing whether a content-coding is | ||||
acceptable mentions the possibility that the field-value may be | ||||
empty. | ||||
It seems, then, that the definition for Accept-Encoding should be | ||||
revised: | ||||
Accept-Encoding = "Accept-Encoding" ":" | ||||
#( codings [ ";" "q" "=" qvalue ] ) | ||||
Resolution (2007-03-18): Accepted during the Prague meeting, see | ||||
http://www.w3.org/2007/03/18-rfc2616-minutes.html#action09. | ||||
H.19. remove-CTE-abbrev | ||||
In Section D.5: | ||||
Type: edit | ||||
<file:///C:/projects/w3c/WWW/Protocols/HTTP/1.1/rfc2616bis/issues/ | ||||
index.html#i16> | ||||
fielding@gbiv.com (2007-11-02): ...there is absolutely no reason to | ||||
abbreviate the field name when it is only used twice in the entire | ||||
document... | ||||
Resolution (2007-11-15): Done. | ||||
Appendix I. Open issues (to be removed by RFC Editor prior to | Appendix I. Open issues (to be removed by RFC Editor prior to | |||
publication) | publication) | |||
I.1. rfc2616bis | I.1. rfc2616bis | |||
Type: edit | Type: edit | |||
julian.reschke@greenbytes.de (2006-10-10): Umbrella issue for changes | julian.reschke@greenbytes.de (2006-10-10): Umbrella issue for changes | |||
with respect to the revision process itself. | with respect to the revision process itself. | |||
I.2. unneeded_references | I.2. i35-split-normative-and-informative-references | |||
Type: edit | Type: change | |||
<http://lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/0054> | <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i35> | |||
julian.reschke@greenbytes.de (2006-10-19): The reference entries for | References are now required to be split into "Normative" and | |||
RFC1866, RFC2069 and RFC2026 are unused. Remove them? | "Informative". | |||
julian.reschke@greenbytes.de (2006-11-02): See also | julian.reschke@gmx.de (2007-10-12): See related issues: i65- | |||
http://lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/0118 and | informative-references, i68-encoding-references-normative, i75- | |||
http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i44. | rfc2145-normative, rfc1737_informative_and_obsolete, | |||
rfc1766_normative, i86-normative-up-to-date-references, | ||||
rfc2048_informative_and_obsolete, rfc2396_normative, rfc2616bis, | ||||
rfc2822_normative, unneeded_references, uri_vs_request_uri and | ||||
usascii_normative. | ||||
I.3. edit | I.3. i40-header-registration | |||
Type: edit | Type: change | |||
julian.reschke@greenbytes.de (2006-10-08): Umbrella issue for | <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i40> | |||
editorial fixes/enhancements. | ||||
I.4. i66-iso8859-1-reference | A revision of RFC2616 should mention BCP 90 (Registration Procedures | |||
for Message Header Fields) and should take over as the authoritative | ||||
reference for the headers it contains. | ||||
Type: change | I.4. edit | |||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i66> | Type: edit | |||
julian.reschke@greenbytes.de (2006-10-28): Classify ISO8859 as | julian.reschke@greenbytes.de (2006-10-08): Umbrella issue for | |||
normative, and simplify reference to only refer to ISO8859 Part 1 | editorial fixes/enhancements. | |||
(because that's the only part needed here), and update to the 1998 | ||||
version. | ||||
I.5. abnf | I.5. abnf | |||
Type: change | Type: change | |||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i36> | <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i36> | |||
julian.reschke@greenbytes.de (2006-12-03): Update BNF to RFC4234 | julian.reschke@greenbytes.de (2006-12-03): Update BNF to RFC4234 | |||
(plan to be added). | (plan to be added). | |||
julian.reschke@greenbytes.de (2007-07-24): See | ||||
<http://www.w3.org/mid/45FBAB8C.6010809@gmx.de> for a to-do list. | ||||
julian.reschke@greenbytes.de (2007-11-13): See | ||||
<http://www.w3.org/mid/4739C417.2040203@gmx.de> for a summary of | ||||
issues with the current ABNF. | ||||
I.6. rfc2048_informative_and_obsolete | I.6. rfc2048_informative_and_obsolete | |||
Type: edit | Type: edit | |||
julian.reschke@greenbytes.de (2006-11-15): Classify RFC2048 | julian.reschke@greenbytes.de (2006-11-15): Classify RFC2048 | |||
("Multipurpose Internet Mail Extensions (MIME) Part Four: | ("Multipurpose Internet Mail Extensions (MIME) Part Four: | |||
Registration Procedures") as informative, update to RFC4288, | Registration Procedures") as informative, update to RFC4288, | |||
potentially update the application/http and multipart/byteranges MIME | potentially update the application/http and multipart/byteranges MIME | |||
type registration. Also, in Section 3.7 fix first reference to refer | type registration. Also, in Section 3.7 fix first reference to refer | |||
to RFC2046 (it's about media types in general, not the registration | to RFC2046 (it's about media types in general, not the registration | |||
skipping to change at page 198, line 36 | skipping to change at page 205, line 46 | |||
julian.reschke@greenbytes.de (2006-11-14): Update RFC2396 ("Uniform | julian.reschke@greenbytes.de (2006-11-14): Update RFC2396 ("Uniform | |||
Resource Identifiers (URI): Generic Syntax") to RFC3986. | Resource Identifiers (URI): Generic Syntax") to RFC3986. | |||
I.8. i50-misc-typos | I.8. i50-misc-typos | |||
Type: edit | Type: edit | |||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i50> | <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i50> | |||
a-travis@microsoft.com (2006-12-18): (See http://lists.w3.org/ | a-travis@microsoft.com (2006-12-18): (See <http://lists.w3.org/ | |||
Archives/Public/ietf-http-wg/2006OctDec/0275.html). | Archives/Public/ietf-http-wg/2006OctDec/0275.html>). | |||
julian.reschke@greenbytes.de (2007-06-29): Some of the strictly | julian.reschke@greenbytes.de (2007-06-29): Some of the strictly | |||
editorial issues have been resolves as part of issue "edit". | editorial issues have been resolves as part of issue "edit". | |||
I.9. i65-informative-references | I.9. i52-sort-1.3-terminology | |||
Type: edit | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i65> | ||||
julian.reschke@greenbytes.de (2007-05-28): The following references | ||||
are informative: Luo1998 ("Tunneling TCP based protocols through Web | ||||
proxy servers", also update reference to quote the expired Internet | ||||
Draft properly). Nie1997 ("Network Performance Effects of HTTP/1.1, | ||||
CSS1, and PNG"). Pad1995 ("Improving HTTP Latency"). RFC821 (SMTP), | ||||
also update the reference to RFC2821. RFC822 ("STANDARD FOR THE | ||||
FORMAT OF ARPA INTERNET TEXT MESSAGES") -- but add another instance | ||||
as RFC822ABNF for the cases where the reference if for the ABNF part | ||||
(these references will later be replaced by references to RFC4234 | ||||
(see issue abnf)). RFC959 (FTP). RFC1036 ("Standard for Interchange | ||||
of USENET Messages"). RFC1123 ("Requirements for Internet Hosts -- | ||||
Application and Support") -- it is only used as a background | ||||
reference for rfc1123-date, which this spec defines itself (note this | ||||
disagrees with draft-gettys-http-v11-spec-rev-00 which made it | ||||
normative). RFC1305 ("Network Time Protocol (Version 3)"). RFC1436 | ||||
(Gopher). RFC1630 (URI Syntax) -- there'll be a normative reference | ||||
to a newer spec. RFC1738 (URL) -- there'll be a normative reference | ||||
to a newer spec. RFC1806 ("Communicating Presentation Information in | ||||
Internet Messages: The Content-Disposition Header"). RFC1808 | ||||
(Relative Uniform Resource Locators). RFC1867 ("Form-based File | ||||
Upload in HTML"), also update the reference to RFC2388 ("Returning | ||||
Values from Forms: multipart/form-data"). RFC1900 ("Renumbering | ||||
Needs Work"). RFC1945 (HTTP/1.0). RFC2026 ("The Internet Standards | ||||
Process -- Revision 3"). RFC2049 ("Multipurpose Internet Mail | ||||
Extensions (MIME) Part Five: Conformance Criteria and Examples"). | ||||
RFC2068 (HTTP/1.1). RFC2076 ("Common Internet Message Headers"). | ||||
RFC2110 (MHTML), also update the reference to RFC2557. RFC2145 ("Use | ||||
and Interpretation of HTTP Version Numbers"). RFC2183 | ||||
("Communicating Presentation Information in Internet Messages: The | ||||
Content-Disposition Header Field"). RFC2277 ("IETF Policy on | ||||
Character Sets and Languages"). RFC2279 (UTF8), also update the | ||||
reference to RFC3629. RFC2324 (HTCPCP/1.0). Spero ("Analysis of | ||||
HTTP Performance Problems"). Tou1998 ("Analysis of HTTP | ||||
Performance"). WAIS ("WAIS Interface Protocol Prototype Functional | ||||
Specification (v1.5)"). | ||||
derhoermi@gmx.net (2007-05-28): _On RFC1950-1952:_ Understanding | ||||
these documents is required in order to understand the coding values | ||||
defined for the coding registry established and used by the document; | ||||
why would it be appropriate to cite them as informative? | ||||
I.10. i52-sort-1.3-terminology | ||||
In Section 1.3: | In Section 1.3: | |||
Type: edit | Type: edit | |||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i52> | <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i52> | |||
a-travis@microsoft.com (2006-12-21): It's irritating to try and look | a-travis@microsoft.com (2006-12-21): It's irritating to try and look | |||
up definitions in section 1.3. IMHO, the entries really should be | up definitions in section 1.3. IMHO, the entries really should be | |||
sorted alphabetically, despite the fact that the terms have | sorted alphabetically, despite the fact that the terms have | |||
dependencies on one another. | dependencies on one another. | |||
julian.reschke@greenytes.de (2006-06-15): See action item | julian.reschke@greenytes.de (2006-06-15): See action item | |||
http://www.w3.org/2007/03/18-rfc2616-minutes.html#action23 and | <http://www.w3.org/2007/03/18-rfc2616-minutes.html#action23> and | |||
proposal in http://lists.w3.org/Archives/Public/ietf-http-wg/ | proposal in <http://lists.w3.org/Archives/Public/ietf-http-wg/ | |||
2007AprJun/0350.html. | 2007AprJun/0350.html>. | |||
julian.reschke@greenytes.de (2006-06-15): | ||||
I personally think we should not do this change: | ||||
julian.reschke@greenytes.de (2006-06-15): I personally think we | ||||
should not do this change: | ||||
(1) Sorting paragraphs makes it very hard to verify the changes; in | (1) Sorting paragraphs makes it very hard to verify the changes; in | |||
essence, a reviewer would either need to trust us, or re-do the | essence, a reviewer would either need to trust us, or re-do the | |||
shuffling to control whether it's correct (nothing lost, no change in | shuffling to control whether it's correct (nothing lost, no change in | |||
the definitions). | the definitions). | |||
(2) In the RFC2616 ordering, things that belong together (such as | (2) In the RFC2616 ordering, things that belong together (such as | |||
"client", "user agent", "server" ...) are close to each other. | "client", "user agent", "server" ...) are close to each other. | |||
(3) Contrary to RFC2616, the text version of new spec will contain an | (3) Contrary to RFC2616, the text version of new spec will contain an | |||
alphabetical index section anyway (unless it's removed upon | alphabetical index section anyway (unless it's removed upon | |||
publication :-). | publication :-). | |||
I.11. i63-header-length-limit-with-encoded-words | I.10. i63-header-length-limit-with-encoded-words | |||
In Section 2.2: | In Section 2.2: | |||
Type: change | Type: change | |||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i63> | <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i63> | |||
derhoermi@gmx.net (2007-05-14): (See http://lists.w3.org/Archives/ | derhoermi@gmx.net (2007-05-14): (See <http://lists.w3.org/Archives/ | |||
Public/ietf-http-wg/2007AprJun/0050.html). | Public/ietf-http-wg/2007AprJun/0050.html>). | |||
I.12. i31-qdtext-bnf | I.11. i74-character-encodings-for-headers | |||
In Section 2.2: | In Section 2.2: | |||
Type: change | Type: change | |||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i31> | <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i74> | |||
jamie@shareable.org (2004-03-15): ...I wrote a regular expression | duerst@it.aoyama.ac.jp (2007-07-10): RFC 2616 prescribes that headers | |||
based on the RFC 2616 definition, and that allows "foo\" as a quoted- | containing non-ASCII have to use either iso-8859-1 or RFC 2047. This | |||
string. That's not intended, is it? | is unnecessarily complex and not necessarily followed. At the least, | |||
new extensions should be allowed to specify that UTF-8 is used. | ||||
I.13. i62-whitespace-in-quoted-pair | I.12. i64-ws-in-quoted-pair | |||
In Section 2.2: | In Section 2.2: | |||
Type: change | Type: change | |||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i62> | ||||
dan.winship@gmail.com (2007-04-20): (...) RFC 2822 updates RFC 822's | <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i64> | |||
quoted-pair rule to disallow CR, LF, and NUL. We should probably | ||||
make the same change. | ||||
I.14. i58-what-identifies-an-http-resource | dan.winship@gmail.com (2007-04-20): | |||
I think quoted-pair is broken too. Merging your fix into RFC2616 | ||||
gives: | ||||
quoted-string = ( <"> *(qdtext | quoted-pair ) <"> ) | ||||
qdtext = <any TEXT excluding '"' and '\'> | ||||
quoted-pair = "\" CHAR | ||||
CHAR = <any US-ASCII character (octets 0 - 127)> | ||||
but that means you can do this: | ||||
HTTP/1.1 200 OK | ||||
Warning: "Don't misparse \ | ||||
this: it's really a single header!" | ||||
(if the receiving implementation follows the recommendations in 19.3 | ||||
you need to escape the LF instead of the CR, but it's otherwise the | ||||
same.) | ||||
RFC 2822 updates RFC 822's quoted-pair rule to disallow CR, LF, and | ||||
NUL. We should probably make the same change. | ||||
I.13. i75-rfc2145-normative | ||||
In Section 3.1: | ||||
Type: change | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i75> | ||||
Jeff.Mogul@hp.com (2007-06-07): http://www.ietf.org/rfc/rfc2145.txt: | ||||
There are references from RFC2616, section 3.1, to this document. | ||||
Perhaps these should be marked as normative; certainly, a proxy | ||||
implemention that violates RFC2145 is non-compliant in any reasonable | ||||
sense of the word. | ||||
I.14. i82-rel_path-not-used | ||||
In Section 3.2.1: | ||||
Type: change | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i82> | ||||
julian.reschke@gmx.de (2007-10-07): | ||||
RFC2616 changed the ABNF for http_URL so that it doesn't use rel_path | ||||
(as defined in RFC2396) anymore. | ||||
However, that definition is still "adopted" in: | ||||
"URIs in HTTP can be represented in absolute form or relative to | ||||
some known base URI [11], depending upon the context of their use. | ||||
The two forms are differentiated by the fact that absolute URIs | ||||
always begin with a scheme name followed by a colon. For | ||||
definitive information on URL syntax and semantics, see "Uniform | ||||
Resource Identifiers (URI): Generic Syntax and Semantics," RFC | ||||
2396 [42] (which replaces RFCs 1738 [4] and RFC 1808 [11]). This | ||||
specification adopts the definitions of "URI-reference", | ||||
"absoluteURI", "relativeURI", "port", "host","abs_path", | ||||
"rel_path", and "authority" from that specification." -- | ||||
http://tools.ietf.org/html/rfc2616#section-3.2.1 | ||||
...and used in: | ||||
"We note one exception to this rule: since some applications have | ||||
traditionally used GETs and HEADs with query URLs (those | ||||
containing a "?" in the rel_path part) to perform operations with | ||||
significant side effects, caches MUST NOT treat responses to such | ||||
URIs as fresh unless the server provides an explicit expiration | ||||
time. This specifically means that responses from HTTP/1.0 | ||||
servers for such URIs SHOULD NOT be taken from a cache. See | ||||
Section 9.1.1 for related information." -- | ||||
http://tools.ietf.org/html/rfc2616#section-13.9 | ||||
Proposal: | ||||
1) get rid of the mention in 3.2.1, and | ||||
2) in 13.9 paragraph 2, replace "...query URLs (those containing a | ||||
"?" in the rel_path part)..." by "...URLs containing a query part..." | ||||
I.15. i58-what-identifies-an-http-resource | ||||
In Section 3.2.2: | In Section 3.2.2: | |||
Type: change | Type: change | |||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i58> | <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i58> | |||
julian.reschke@gmx.de (2007-01-23): 3.2.2 really doesn't say what | julian.reschke@gmx.de (2007-01-23): | |||
identifies the resource: | ||||
3.2.2 really doesn't say what identifies the resource: | ||||
"If the port is empty or not given, port 80 is assumed. The | "If the port is empty or not given, port 80 is assumed. The | |||
semantics are that the identified resource is located at the server | semantics are that the identified resource is located at the | |||
listening for TCP connections on that port of that host, and the | server listening for TCP connections on that port of that host, | |||
Request-URI for the resource is abs_path (Section 5.1.2)." | and the Request-URI for the resource is abs_path (Section 5.1.2)." | |||
But it *does* say what part of the HTTP URL becomes the Request-URI, | -- http://tools.ietf.org/html/rfc2616#section-3.2.2 | |||
But it _does_ say what part of the HTTP URL becomes the Request-URI, | ||||
and that definitively needs to be fixed. | and that definitively needs to be fixed. | |||
I.15. i51-http-date-vs-rfc1123-date | I.16. i51-http-date-vs-rfc1123-date | |||
In Section 3.3.1: | In Section 3.3.1: | |||
Type: change | Type: change | |||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i51> | <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i51> | |||
a-travis@microsoft.com (2006-12-18): On closer inspection, shouldn't | a-travis@microsoft.com (2006-12-18): On closer inspection, shouldn't | |||
the BNF for that section (14.18) be "rfc1123-date" and not "HTTP- | the BNF for that section (14.18) be "rfc1123-date" and not "HTTP- | |||
date"? I mean, why say it's an HTTP-date, but only RFC 1123 form is | date"? I mean, why say it's an HTTP-date, but only RFC 1123 form is | |||
allowed (conflicting with the definition of HTTP-date)*? Likewise, | allowed (conflicting with the definition of HTTP-date)*? Likewise, | |||
shouldn't we just use the rfc1123-date moniker throughout the | shouldn't we just use the rfc1123-date moniker throughout the | |||
document whenever explicitly referring to only dates in RFC 1123 | document whenever explicitly referring to only dates in RFC 1123 | |||
format? | format? | |||
I.16. i67-quoting-charsets | I.17. i73-clarification-of-the-term-deflate | |||
In Section 3.5: | ||||
Type: change | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i73> | ||||
paul_marquess@yahoo.co.uk (2007-08-07): | ||||
There is ambiguity in that definition because of the inconsistent use | ||||
of the term "deflate". This has resulted in a long standing | ||||
confusion about how to implement "deflate" encoding. | ||||
There was a time a few years back when most of the high profile | ||||
browser and some http server implementations incorrectly implemented | ||||
http "deflate" encoding using RFC 1951 without the RFC 1950 wrapper. | ||||
Admittedly most, if not all, of the incorrect implementations have | ||||
now been fixed, but the fix applied recognises the reality that there | ||||
are incorrect implementations of "deflate" out in the wild. All | ||||
browsers now seem to be able to cope with "deflate" in both its | ||||
RFC1950 or RFC1951 incarnations. | ||||
So I suggest there are two issues that need to be addressed | ||||
1. The definition of "deflate" needs to be rewritten to remove the | ||||
ambiguity. | ||||
2. Document the reality that there are incorrect implementations, | ||||
and recommend that anyone writing a "deflate" decoder should cope | ||||
with both forms. | ||||
I.18. i67-quoting-charsets | ||||
In Section 3.7: | In Section 3.7: | |||
Type: change | Type: change | |||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i67> | <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i67> | |||
maiera@de.ibm.com (2007-05-23): (See http://lists.w3.org/Archives/ | maiera@de.ibm.com (2007-05-23): (See <http://lists.w3.org/Archives/ | |||
Public/ietf-http-wg/2007AprJun/0065.html). | Public/ietf-http-wg/2007AprJun/0065.html>). | |||
I.17. media-reg | I.19. i20-default-charsets-for-text-media-types | |||
In Section 3.7: | In Section 3.7.1: | |||
Type: change | Type: change | |||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i20> | ||||
<http://purl.org/NET/http-errata#media-reg> | mnot@yahoo-inc.com (2006-05-01): | |||
derhoermi@gmx.net (2000-09-10): See | 2616 Section 3.7.1 states; | |||
http://lists.w3.org/Archives/Public/ietf-http-wg-old/2000SepDec/0013. | ||||
julian.reschke@greenbytes.de (2007-04-20): See also | "When no explicit charset parameter is provided by the sender, | |||
http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i8. | media subtypes of the "text" type are defined to have a default | |||
charset value of "ISO-8859-1" when received via HTTP." -- | ||||
http://tools.ietf.org/html/rfc2616#section-3.7.1 | ||||
I.18. languagetag | However, many, if not all, of the text/* media types define their own | |||
defaults; text/plain (RFC2046), for example, defaults to ASCII, as | ||||
does text/xml (RFC3023). | ||||
How do these format-specific defaults interact with HTTP's default? | ||||
Is HTTP really overriding them? | ||||
I'm far from the first to be confused by this text, and I'm sure it's | ||||
been asked before, but I haven't been able to find a definitive | ||||
answer. If errata are still being considered, perhaps removing/ | ||||
modifying this line would be a good start... | ||||
duerst@it.aoyama.ac.jp (2007-10-05): | ||||
Here is another issue that apparently hasn't yet been listed. The | ||||
HTTP spec, in section 3.7.1, currently claims that for subtypes of | ||||
the media type "text", there is a default of iso-8859-1. | ||||
In actual practice, this is, at best, wishful thinking. It may also | ||||
pretty much look like it's actually true if you are in Western Europe | ||||
or in the Americas, but it doesn't apply world-wide. There are tons | ||||
of Web sites in Asia (and Asia is home to more than half of the | ||||
World's population) that have no charset, and that are not in iso- | ||||
8859-1. And browsers in these regions don't expect pages to be iso- | ||||
8859-1. | ||||
... | ||||
So the text below should be changed to say that data in all character | ||||
sets SHOULD be labeled, and move the default to historic. Some | ||||
adequate adjustments should also be made to Section 3.4.1. I'll | ||||
gladly help with word-smithing. | ||||
I.20. languagetag | ||||
In Section 3: | In Section 3: | |||
Type: change | Type: change | |||
<http://purl.org/NET/http-errata#languagetag> | <http://purl.org/NET/http-errata#languagetag>, | |||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i13> | ||||
julian.reschke@greenbytes.de (2006-10-14): See | julian.reschke@greenbytes.de (2006-10-14): See | |||
http://purl.org/NET/http-errata#languagetag. | <http://purl.org/NET/http-errata#languagetag>. | |||
julian.reschke@greenbytes.de (2006-10-14): In the meantime RFC3066 | julian.reschke@greenbytes.de (2006-10-14): In the meantime RFC3066 | |||
has been obsoleted by RFC4646. See also | has been obsoleted by RFC4646. See also | |||
http://lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/0001. | <http://lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/0001>. | |||
julian.reschke@greenbytes.de (2006-11-15): See also | I.21. i85-custom-ranges | |||
http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i13. | ||||
I.19. i56-6.1.1-can-be-misread-as-a-complete-list | In Section 3.12: | |||
Type: change | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i85> | ||||
kornel@geekhood.net (2007-08-25): | ||||
The RFC 2616 seems to suggest such possibility in 3.12 Range Units: | ||||
there's a "other-range-unit" defined. | ||||
However definition of Content-Range uses "ranges-specifier" and Range | ||||
uses "content-range-spec", which both seem to allow only byte ranges. | ||||
In such case, is there any use for "other-range-unit" in Accept- | ||||
Ranges? | ||||
LMM@acm.org (2007-08-31): | ||||
What I remember was that I pushed for custom ranges and that there | ||||
was a lot of push-back from people who thought it was too much | ||||
complexity. | ||||
I think the idea 'sort of' got into the spec, but not fully fleshed | ||||
out. | ||||
I agree that it belongs in the issue list, to either clarify how to | ||||
use custom ranges (with a range unit registry, for example) or else | ||||
to remove the feature. | ||||
I.22. i30-header-lws | ||||
In Section 4.2: | ||||
Type: change | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i30> | ||||
jamie@shareable.org (2004-03-15): _See | ||||
<http://www.w3.org/mid/20040315183116.GC9731@mail.shareable.org>_. | ||||
I.23. i77-line-folding | ||||
In Section 4.2: | ||||
Type: change | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i77> | ||||
fielding@gbiv.com (2007-01-19): | ||||
...I think the spec should reflect the standard, not be artificially | ||||
restricted by adherence to past revisions of itself. By standard, I | ||||
mean the measure expected by all of the implementations that are | ||||
exchanging legitimate communication via HTTP. AFAIK, there are no | ||||
servers or clients that send legitimate messages with anything other | ||||
than | ||||
Field-name: field-value | ||||
so it is time for the spec to reflect that fact. My only caveat is | ||||
that there should be an exception for the message/http media type, | ||||
such that messages received via SMTP shall allow line folding. | ||||
... | ||||
...MUST NOT send such LWS is fine, including when a message is | ||||
forwarded, but forbidding a server from processing such a message is | ||||
not going to happen because it would make all implementations non- | ||||
compliant. | ||||
Servers should be configurable in regards to robust or restricted | ||||
parsing behavior, and nothing we say can improve the "security" of | ||||
broken software that was deployed years ago. Software that correctly | ||||
parses according to the RFC is not subject to those perceived | ||||
security issues. | ||||
I.24. i19-bodies-on-GET | ||||
In Section 4.3: | ||||
Type: change | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i19> | ||||
Jeff.Mogul@hp.com (2006-06-22): (See <http://www.w3.org/mid/ | ||||
200606221739.k5MHd3PA013395@pobox-pa.hpl.hp.com>). | ||||
I.25. i28-connection-closing | ||||
In Section 4.4: | ||||
Type: change | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i28> | ||||
joe@manyfish.co.uk (2005-02-26): The phrase "unless the message is | ||||
terminated by closing the connection" in Section 4.4 is unnecessary. | ||||
Section 3.6 uses the same phrase; it is a little confusing. In 4.4 | ||||
you could almost read it to mean that presence of "Connection: close" | ||||
would mean that a T-E header should be ignored, which is presumably | ||||
not the intent (and certainly not the practice). | ||||
julian.reschke@gmx.de (2007-10-06): Discussed during the Prague | ||||
meeting, see | ||||
<http://www.w3.org/2007/03/18-rfc2616-minutes.html#action01>. | ||||
I.26. i32-options-asterisk | ||||
In Section 5.1.2: | ||||
Type: change | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i32> | ||||
julian.reschke@gmx.de (2003-11-24): I'd like to see a clarification | ||||
about what clients can expect upon OPTIONS *. In particular, can | ||||
they expect to find out about *any* method name supported on that | ||||
server? I'm asking because this doesn't seem to be the case for at | ||||
least two major server bases, being: | ||||
- Apache (for instance, additional method names supported by mod_dav | ||||
aren't listed) and | ||||
- generic Java servlet engines (servlet API does not support | ||||
delegation of requests against "*" to all installed web | ||||
applications). | ||||
julian.reschke@gmx.de (2007-10-08): | ||||
Quote Roy Fielding: | ||||
"...Allow only applies to URIs, not *..." -- http:// | ||||
mail-archives.apache.org/mod_mbox/httpd-dev/ | ||||
200710.mbox/%3c24EE5E9D-9FBB-4530-9735-33BD768FC633@gbiv.com%3e | ||||
I.27. i83-options-asterisk-and-proxies | ||||
In Section 5.1.2: | ||||
Type: change | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i83> | ||||
hno@squid-cache.org (2007-10-01): _Text about proxying OPTIONS * | ||||
contained in RFC2068 was lost in RCF2616._ | ||||
julian.reschke@gmx.de (2007-10-03): | ||||
The lost text says: | ||||
"If a proxy receives a request without any path in the Request-URI | ||||
and the method specified is capable of supporting the asterisk | ||||
form of request, then the last proxy on the request chain MUST | ||||
forward the request with "*" as the final Request-URI. For | ||||
example, the request | ||||
OPTIONS http://www.ics.uci.edu:8001 HTTP/1.1 | ||||
would be forwarded by the proxy as | ||||
OPTIONS * HTTP/1.1 | ||||
Host: www.ics.uci.edu:8001 | ||||
after connecting to port 8001 of host "www.ics.uci.edu"." -- | ||||
http://tools.ietf.org/html/rfc2068#section-5.1.2 | ||||
hno@squid-cache.org (2007-10-04): | ||||
... | ||||
There is one slight problem with the above and it's " and the method | ||||
specified is capable of supporting the asterisk form of request". | ||||
This requires the proxy to know about each such method, and with HTTP | ||||
being extensible it's not fully possible. In RFC2616 only OPTIONS | ||||
meets this criteria. | ||||
Is there a possibility for other methods than OPTIONS which may make | ||||
sense on a global resource-less context? I think not. If this is | ||||
complemented with a restriction that the special request-URI "*" may | ||||
only be used in OPTIONS requests then it's fine. Interoperability of | ||||
extension methods using "*" will be tricky at best.. | ||||
... | ||||
I.28. i56-6.1.1-can-be-misread-as-a-complete-list | ||||
In Section 6.1.1: | In Section 6.1.1: | |||
Type: edit | Type: edit | |||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i56> | <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i56> | |||
henrik@henriknordstrom.net (2007-01-11): The second sentence in the | henrik@henriknordstrom.net (2007-01-11): The second sentence in the | |||
first paragraph can on a quick reading be misread as section 10 | first paragraph can on a quick reading be misread as section 10 | |||
contains a complete definiton of all possible status codes, where it | contains a complete definiton of all possible status codes, where it | |||
in reality only has the status codes defined by this RFC. | in reality only has the status codes defined by this RFC. | |||
I.20. i57-status-code-and-reason-phrase | I.29. i57-status-code-and-reason-phrase | |||
In Section 6.1.1: | In Section 6.1.1: | |||
Type: change | Type: change | |||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i57> | <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i57> | |||
henrik@henriknordstrom.net (2007-01-11): 6.1.1 is apparently a bit | henrik@henriknordstrom.net (2007-01-11): | |||
too vague about how applications should parse and process the | ||||
information, making some implementations parse the reason phrase | 6.1.1 is apparently a bit too vague about how applications should | |||
(probably exact matches on the complete status line, not just status | parse and process the information, making some implementations parse | |||
code) to determine the outcome. | the reason phrase (probably exact matches on the complete status | |||
line, not just status code) to determine the outcome. | ||||
There should be a SHOULD requirement or equivalent that applications | There should be a SHOULD requirement or equivalent that applications | |||
use the status code to determine the status of the response and only | use the status code to determine the status of the response and only | |||
process the Reason Phrase as a comment intended for humans. | process the Reason Phrase as a comment intended for humans. | |||
It's true that later in the same section there is a reverse MAY | It's true that later in the same section there is a reverse MAY | |||
requirement implying this by saying that the phrases in the rfc is | requirement implying this by saying that the phrases in the rfc is | |||
just an example and may be replaced without affecting the protocol, | just an example and may be replaced without affecting the protocol, | |||
but apparently it's not sufficient for implementers to understand | but apparently it's not sufficient for implementers to understand | |||
that applications should not decide the outcome based on the reason | that applications should not decide the outcome based on the reason | |||
phrase. | phrase. | |||
I.21. i59-status-code-registry | I.30. i59-status-code-registry | |||
In Section 6.1.1: | In Section 6.1.1: | |||
Type: edit | Type: edit | |||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i59> | <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i59> | |||
henrik@henriknordstrom.net (2007-02-18): The IANA status code | henrik@henriknordstrom.net (2007-02-18): The IANA status code | |||
registry should be referred to. | registry should be referred to. | |||
I.22. i21-put-side-effects | I.31. i72-request-method-registry | |||
In Section 9: | ||||
Type: change | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i72> | ||||
henrik@henriknordstrom.net (2007-08-06): I see a need for an official | ||||
HTTP request method registry to be established, preferably maintained | ||||
by IANA. | ||||
I.32. i21-put-side-effects | ||||
In Section 9.6: | In Section 9.6: | |||
Type: change | Type: change | |||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i21> | <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i21> | |||
mnot@yahoo-inc.com (2006-04-03): (See http://lists.w3.org/Archives/ | mnot@yahoo-inc.com (2006-04-03): | |||
Public/ietf-http-wg/2006AprJun/0002.html). | ||||
I.23. i54-definition-of-1xx-warn-codes | 2616 specifically allows PUT to have side effects; | |||
"A single resource MAY be identified by many different URIs. For | ||||
example, an article might have a URI for identifying "the current | ||||
version" which is separate from the URI identifying each | ||||
particular version. In this case, a PUT request on a general URI | ||||
might result in several other URIs being defined by the origin | ||||
server. | ||||
HTTP/1.1 does not define how a PUT method affects the state of an | ||||
origin server." -- | ||||
http://tools.ietf.org/html/rfc2616.html#section-9.6 | ||||
and it also says (in the context of PUT) | ||||
"If a new resource is created, the origin server MUST inform the | ||||
user agent via the 201 (Created) response." -- | ||||
http://tools.ietf.org/html/rfc2616.html#section-9.6 | ||||
So, if I PUT something to /foo, and it has the side effect if | ||||
creating /foo;2006-04-03, is the response required to be a 201 | ||||
Created? | ||||
I.e., read literally, the above requirement requires a 201 Created | ||||
when PUT results in *any* resource being created -- even as a side | ||||
effect. | ||||
This is IMO unnecessarily constraining, and should be relaxed; e.g., | ||||
changed to something like | ||||
_"If a new resource is created at the Request-URI, the origin server | ||||
MUST inform the user agent via the 201 (Created) response."_ | ||||
julian.reschke@gmx.de (2007-10-06): Discussed during the Prague | ||||
meeting, see | ||||
<http://www.w3.org/2007/03/18-rfc2616-minutes.html#action06>: | ||||
_Combine to make second sentence dependent upon the first: "If the | ||||
Request-URI does not point to an existing resource, and that URI is | ||||
capable of being defined as a new resource by the requesting user | ||||
agent, the origin server can create the resource with that URI. If a | ||||
new resource is created, the origin server MUST inform the user agent | ||||
via the 201 (Created) response."_ | ||||
I.33. i27-put-idempotency | ||||
In Section 9.6: | ||||
Type: change | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i27> | ||||
mnot@yahoo-inc.com (2005-03-16): It _appears_ that RFC3253 changes | ||||
the idempotency of PUT; is this allowed? RFC3253 doesn't update or | ||||
obsolete 2616... | ||||
I can see a situation where a 3253-naive client decides to retry a | ||||
timed-out PUT (after all, it's idempotent) and gets some side effects | ||||
it didn't bargain for. Not a _huge_ problem that happens every day, | ||||
but it's a bit worrisome. | ||||
julian.reschke@gmx.de (2007-10-06): Discussed during the Prague | ||||
meeting, see | ||||
<http://www.w3.org/2007/03/18-rfc2616-minutes.html#action10>: | ||||
_"Loosen definition of Idempotency as per Roy."_ -- See | ||||
<http://tech.groups.yahoo.com/group/rest-discuss/message/7387>: _Just | ||||
ignore the definition of idempotent in RFC 2616. Anything specified | ||||
in HTTP that defines how the server shall implement the semantics of | ||||
an interface method is wrong, by definition. What matters is the | ||||
effect on the interface as expected by the client, not what actually | ||||
happens on the server to implement that effect._ | ||||
I.34. i79-content-headers-vs-put | ||||
In Section 9.6: | ||||
Type: change | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i79> | ||||
julian.reschke@greenbytes.de (2007-07-25): It's not clear to me what | ||||
Content-* headers are? All headers starting with the character | ||||
sequence "Content-"? Just those defined in RFC2616? | ||||
I.35. i33-trace-security-considerations | ||||
In Section 9.8: | ||||
Type: change | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i33> | ||||
rousskov@measurement-factory.com (2003-02-14): | ||||
There is an HTTP-related security violation approach found/researched | ||||
by White Hat Security: | ||||
PR: <http://www.whitehatsec.com/press_releases/WH-PR-20030120.txt> | ||||
Details: | ||||
<http://www.betanews.com/whitehat/WH-WhitePaper_XST_ebook.pdf> | ||||
I bet many of you have seen the related advisories/PR. For those who | ||||
have not, here is the gist: | ||||
"Modern browsers usually do not allow scripts embedded in HTML to | ||||
access cookies and authentication information exchanged between | ||||
HTTP client and server. However, a script can get access to that | ||||
info by sending a simple HTTP TRACE request to the originating | ||||
(innocent) server. The user agent will auto-include current | ||||
authentication info in such request. The server will echo all the | ||||
authentication information back, for script to read and [mis]use. | ||||
Apparently, sending an HTTP request is possible via many scripting | ||||
methods like ActiveX. See the URL above for details." | ||||
With numerous XSS (cross-site-scripting) vulnerabilities in user | ||||
agents, this seems like a real and nasty problem. TRACE method | ||||
support is optional per RFC 2616, but many popular servers support | ||||
it. White Hat Security advises server administrators to disable | ||||
support for TRACE. | ||||
What is your opinion? Should TRACE be supported by default? Is it a | ||||
good idea to mention this "exposure" vulnerability in HTTP errata or | ||||
elsewhere? | ||||
I.36. i69-clarify-requested-variant | ||||
In Section 10.2.2: | ||||
Type: change | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i69> | ||||
julian.reschke@gmx.de (2007-07-13): The spec uses the term "requested | ||||
variant" in several places (10.2.2 201 Created, 10.2.5 204 No | ||||
Content, 14.19 ETag, 14.25 If-Modified-Since, 14.28 If-Unmodified- | ||||
Since). It's quite clear what it means in the context of HEAD/GET, | ||||
somewhat clear for PUT, but not clear at all for other methods. We | ||||
really need to clarify this, potentially choosing a different term. | ||||
fielding@gbiv.com (2007-08-06): | ||||
...Think of variant as the target of a request once URI+Vary-fields | ||||
is taken into account. It is the resource-as-subdivided-by- | ||||
negotiation, which was the original definition before it got mixed up | ||||
in committee. Now, if we add the notion of a method that acts by | ||||
indirection (PROPFIND), then we merely add that notion to the | ||||
definition in general. | ||||
_variant_ | ||||
_The ultimate target resource of a request after indirections caused | ||||
by content negotiation (varying by request fields) and method | ||||
association (e.g., PROPFIND) have been taken into account. Some | ||||
variant resources may also be identified directly by their own URI, | ||||
which may be indicated by a Content-Location in the response._ | ||||
I.37. i70-cacheability-of-303 | ||||
In Section 10.3.4: | ||||
Type: change | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i70> | ||||
fielding@gbiv.com (2007-07-12): | ||||
On the cacheability requirement: ... I have no idea why the | ||||
specification says that. Cache-control can be used to override it. | ||||
"A response received with any other status code MUST NOT be | ||||
returned in a reply to a subsequent request unless there are | ||||
Cache-Control directives or another header(s) that explicitly | ||||
allow it. For example, these include the following: an Expires | ||||
header (section 14.21); a "max-age", "must-revalidate", "proxy- | ||||
revalidate", "public" or "private" Cache-Control directive | ||||
(section 14.9)." -- | ||||
http://tools.ietf.org/html/rfc2616#section-13.4 | ||||
It looks like the contradiction was added to RFC 2616 when somebody | ||||
decided to convert the commentary on its use with POST into a fixed | ||||
requirement on all 303 responses. It is just a bug in the spec. | ||||
fielding@gbiv.com (2007-07-13): | ||||
My suggestion is to change the entire section to: | ||||
10.3.4. 303 See Other | ||||
The server directs the user agent to a different resource, indicated | ||||
by a URI in the Location header field, that provides an indirect | ||||
response to the original request. The user agent MAY perform a GET | ||||
request on the URI in the Location field in order to obtain a | ||||
representation corresponding to the response, be redirected again, or | ||||
end with an error status. The Location URI is not a substitute | ||||
reference for the originally requested resource. | ||||
The 303 status is generally applicable to any HTTP method. It is | ||||
primarily used to allow the output of a POST action to redirect the | ||||
user agent to a selected resource, since doing so provides the | ||||
information corresponding to the POST response in a form that can be | ||||
separately identified, bookmarked, and cached independent of the | ||||
original request. | ||||
A 303 response to a GET request indicates that the requested resource | ||||
does not have a representation of its own that can be transferred by | ||||
the server over HTTP. The Location URI indicates a resource that is | ||||
descriptive of the requested resource such that the follow-on | ||||
representation may be useful without implying that that it adequately | ||||
represents the previously requested resource. Note that answers to | ||||
the questions of what can be represented, what representations are | ||||
adequate, and what might be a useful description are outside the | ||||
scope of HTTP and thus entirely determined by the resource owner(s). | ||||
A 303 response SHOULD NOT be cached unless it is indicated as | ||||
cacheable by Cache-Control or Expires header fields. Except for | ||||
responses to a HEAD request, the entity of a 303 response SHOULD | ||||
contain a short hypertext note with a hyperlink to the Location URI. | ||||
dbooth@hp.com (2007-07-03): ... s/The Location URI indicates/The | ||||
Location URI SHOULD indicate/ ... | ||||
dbooth@hp.com (2007-10-04): | ||||
...My thinking was that the owner of the URI originally requested may | ||||
not be the same as the owner of the redirect URI, and hence the first | ||||
owner might not have control over whether the resource at the | ||||
redirect URI really *is* "descriptive of the requested resource", | ||||
even though it is thought to be. | ||||
BTW, I do notice one other thing. I suggest changing the following | ||||
sentence: | ||||
"A 303 response to a GET request indicates that the requested | ||||
resource does not have a representation of its own that can be | ||||
transferred by the server over HTTP." | ||||
to: | ||||
"A 303 response to a GET request indicates that the requested | ||||
resource does not have a representation of its own, available from | ||||
the request URI, that can be transferred by the server over HTTP." | ||||
The reason is that if the same resource were requested via a | ||||
different URI, it might indeed provide a representation of its own | ||||
(if it were an information resource). The original text would have | ||||
prevented 303 URIs from identifying information resources, rather | ||||
than permitting them to identify any kind of resource. | ||||
fielding@gbiv.com (2007-10-16): | ||||
... | ||||
In which case it would be redirected via a 301, 302, or 307. 303 only | ||||
redirects to different resources, which means the requested resource | ||||
for the 303 response is different from the target resource, even if | ||||
that difference can't be measured in bits. Even if they aren't, in | ||||
fact, different, the client is being told by the server that they | ||||
should be interpreted as different, and that makes it fact as far as | ||||
HTTP's interface is concerned. | ||||
There is no information resource in HTTP, for the same reason that | ||||
there is no spoon in the Matrix. | ||||
I.38. i76-deprecate-305-use-proxy | ||||
In Section 10.3.6: | ||||
Type: change | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i76> | ||||
adrien@qbik.com (2007-06-15): | ||||
I can't find any browser that supports this. | ||||
* IE 6 silently fails (shows blank page, does not attempt connection | ||||
to proxy). | ||||
* FF 2 silently fails (shows blank page, does not attempt connection | ||||
to proxy). | ||||
* Opera displays message "The server tried to redirect Opera to the | ||||
alternative proxy "http://xxxxxxxx". For security reasons this is no | ||||
longer supported." | ||||
So looks like the main browsers (haven't tried Safari) have de facto | ||||
deprecated it. | ||||
Is it an optional code to handle? RFC2616 is extremely sparse in its | ||||
description of the status code. | ||||
I.39. i78-relationship-between-401-authorization-and-www-authenticate | ||||
In Section 10.4.2: | ||||
Type: change | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i78> | ||||
hugo@yahoo-inc.com (2007-07-25): Are these mechanisms exclusive? | ||||
I.e., can they only be used together, or can a cookie-based | ||||
authentication scheme (for example) use 401? (full message at <http:/ | ||||
/www.w3.org/mid/5A4607FB-6F74-4C7F-BF60-37E0EFEC97DF@yahoo-inc.com>) | ||||
I.40. i24-requiring-allow-in-405-responses | ||||
In Section 10.4.6: | ||||
Type: change | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i24> | ||||
fielding@gbiv.com (2005-06-23): | ||||
In RFC 2616, 10.4.6 405 Method Not Allowed: | ||||
"The method specified in the Request-Line is not allowed for the | ||||
resource identified by the Request-URI. The response MUST include | ||||
an Allow header containing a list of valid methods for the | ||||
requested resource." -- | ||||
http://tools.ietf.org/html/rfc2616#section-10.4.6 | ||||
which has the effect of requiring that a server advertise all methods | ||||
to a resource. In some cases, method implementation is implemented | ||||
across several (extensible) parts of a server and thus not known. In | ||||
other cases, it may not be prudent to tell an unauthenticated client | ||||
all of the methods that might be available to other clients. | ||||
I think the above should be modified to s/MUST/MAY/; does anyone here | ||||
know of a reason not to make that change? | ||||
julian.reschke@gmx.de (2007-10-06): Discussed during the Prague | ||||
meeting, see | ||||
<http://www.w3.org/2007/03/18-rfc2616-minutes.html#action08>. | ||||
I.41. i81-content-negotiation-for-media-types | ||||
In Section 12: | ||||
Type: change | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i81> | ||||
lmm@acm.org (2006-04-11): | ||||
HTTP content negotiation was one of those "nice in theory" protocol | ||||
additions that, in practice, didn't work out. The original theory of | ||||
content negotiation was worked out when the idea of the web was that | ||||
browsers would support a handful of media types (text, html, a couple | ||||
of image types), and so it might be reasonable to send an 'accept:' | ||||
header listing all of the types supported. But in practice as the | ||||
web evolved, browsers would support hundreds of types of all | ||||
varieties, and even automatically locate readers for content-types, | ||||
so it wasn't practical to send an 'accept:' header for all of the | ||||
types. | ||||
So content negotiation in practice doesn't use accept: headers except | ||||
in limited circumstances; for the most part, the sites send some kind | ||||
of 'active content' or content that autoselects for itself what else | ||||
to download; e.g., a HTML page which contains Javascript code to | ||||
detect the client's capabilities and figure out which other URLs to | ||||
load. The most common kind of content negotiation uses the 'user | ||||
agent' identification header, or some other 'x-...' extension headers | ||||
to detect browser versions, among other things, to identify buggy | ||||
implementations or proprietary extensions. | ||||
I think we should deprecate HTTP content negotiation, if only to make | ||||
it clear to people reading the spec that it doesn't really work that | ||||
way in practice. | ||||
Many people seem to use HTTP content negotiation as a motivation for | ||||
adding 'version' parameters to MIME types or registering new MIME | ||||
types, with the hopes that the MIME types or parameters would be | ||||
useful in HTTP content negotiation, and we should warn them that it | ||||
isn't really productive to do so. That's why it might be useful | ||||
advice to add to the guidelines for registering MIME types, should | ||||
those ever be updated. | ||||
rjgodoy@hotmail.com (2007-11-03): _See | ||||
http://www.w3.org/mid/BAY118-DAV15B52BB86A84968870D8E0AD8E0@phx.gbl_. | ||||
lmm@acm.org (2007-11-03): | ||||
Clearly "deprecate" was hyperbole. (I can say that since I raised | ||||
the issue in the first place.) However, Accept headers have a | ||||
limited domain of applicability, e.g., when the client has a limited | ||||
repertoire of types that it is actually willing to accept, and this | ||||
is generally not true on typical desktop web browsers (maybe some | ||||
phones might have such a limitation). | ||||
The point about changing the 406 requirement so that it matches | ||||
reality should also be added to the issue. | ||||
I.42. i54-definition-of-1xx-warn-codes | ||||
In Section 13.1.2: | In Section 13.1.2: | |||
Type: change | Type: change | |||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i54> | <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i54> | |||
a-travis@microsoft.com (2006-12-22): See | a-travis@microsoft.com (2006-12-22): See | |||
http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i54. | <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i54>. | |||
I.24. i60-13.5.1-and-13.5.2 | I.43. i29-age-calculation | |||
In Section 13.2.3: | ||||
Type: change | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i29> | ||||
rousskov@measurement-factory.com (2002-08-30): | ||||
RFC 2616 says: | ||||
"Because the request that resulted in the returned Age value must | ||||
have been initiated prior to that Age value's generation, we can | ||||
correct for delays imposed by the network by recording the time at | ||||
which the request was initiated. Then, when an Age value is | ||||
received, it MUST be interpreted relative to the time the request | ||||
was initiated. So, we compute | ||||
corrected_initial_age = corrected_received_age + (now - | ||||
request_time)" -- | ||||
http://tools.ietf.org/html/rfc2616#section-13.2.3 | ||||
I suspect the formula does not match the true intent of the RFC | ||||
authors. I believe that corrected_initial_age formula counts server- | ||||
to-client delays twice. It does that because the | ||||
corrected_received_age component already accounts for one server-to- | ||||
client delay. Here is an annotated definition from the RFC: | ||||
corrected_received_age = max( | ||||
now - date_value, # trust the clock (includes server-to-client delay!) | ||||
age_value) # all-HTTP/1.1 paths (no server-to-client delay) | ||||
I think it is possible to fix the corrected_initial_age formula to | ||||
match the intent (note this is the *initial* not *received* age): | ||||
corrected_initial_age = max( | ||||
now - date_value, # trust the clock (includes delays) | ||||
age_value + now - request_time) # trust Age, add network delays | ||||
There is no need for corrected_received_age. | ||||
Moreover, it looks ALL the formulas computing current_age go away | ||||
with the above new corrected_initial_age definition as long as "now" | ||||
is still defined as "the current time" (i.e., the time when | ||||
current_age is calculated): | ||||
current_age = corrected_initial_age | ||||
So, we end up with a single formula for all cases and all times: | ||||
current_age = max(now - date_value, age_value + now - request_time) = = now - min(date_value, request_time - age_value) | ||||
It even has a clear physical meaning -- the min() part is the | ||||
conservative estimate of object creation time. | ||||
julian.reschke@gmx.de (2007-10-06): Discussed during the Prague | ||||
meeting, see | ||||
<http://www.w3.org/2007/03/18-rfc2616-minutes.html#action11>. | ||||
I.44. i71-examples-for-etag-matching | ||||
In Section 13.3.3: | ||||
Type: change | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i71> | ||||
julian.reschke@greenbytes.de (2006-12-02): Add examples for weak and | ||||
strong matching. | ||||
julian.reschke@greenbytes.de (2007-06-07): Backed out example, | ||||
because it's controversial. We need to answer the question: "Are | ||||
there circumstances where a server will weakly match the etags "1" | ||||
and W/"1"? | ||||
julian.reschke@greenbytes.de (2007-07-17): Re-added example table for | ||||
further discussion. | ||||
I.45. i60-13.5.1-and-13.5.2 | ||||
In Section 13.5: | In Section 13.5: | |||
Type: edit | Type: edit | |||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i60> | <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i60> | |||
mnot@yahoo-inc.com (2007-03-30): 13.5.1 and 13.5.2 describe how | mnot@yahoo-inc.com (2007-03-30): 13.5.1 and 13.5.2 describe how | |||
proxies should handle headers, even though it's in a section entitled | proxies should handle headers, even though it's in a section entitled | |||
"Caching in HTTP." People have a hard time finding them. Would it | "Caching in HTTP." People have a hard time finding them. Would it | |||
be helpful to try to separate out the purely intermediary-related | be helpful to try to separate out the purely intermediary-related | |||
material from section 13 to a more appropriate place (e.g., section | material from section 13 to a more appropriate place (e.g., section | |||
8, or a new section)? | 8, or a new section)? | |||
I.25. i53-allow-is-not-in-13.5.2 | I.46. i53-allow-is-not-in-13.5.2 | |||
In Section 13.5.2: | In Section 13.5.2: | |||
Type: change | Type: change | |||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i53> | <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i53> | |||
a-travis@microsoft.com (2006-12-20): Section 14.7 states: | a-travis@microsoft.com (2006-12-20): | |||
Section 14.7 states: | ||||
"A proxy MUST NOT modify the Allow header field even if it does not | "A proxy MUST NOT modify the Allow header field even if it does not | |||
understand all the methods specified, since the user agent might have | understand all the methods specified, since the user agent might have | |||
other means of communicating with the origin server." | other means of communicating with the origin server." | |||
However, section 13.5.2 (Non-modifiable Headers) makes no mention of | However, section 13.5.2 (Non-modifiable Headers) makes no mention of | |||
Allow. This seems like an error, but I'm not entirely sure what the | Allow. This seems like an error, but I'm not entirely sure what the | |||
fix should be -- remove 13.5.2 and push the (not-)modifiable | fix should be -- remove 13.5.2 and push the (not-)modifiable | |||
information in the definition of the respective headers, or to | information in the definition of the respective headers, or to | |||
maintain 13.5.2 in parallel with all of the header definitions, or to | maintain 13.5.2 in parallel with all of the header definitions, or to | |||
push all the information out of the header definitions into 13.5.2. | push all the information out of the header definitions into 13.5.2. | |||
The easy fix for now would be to just make a mention of Allow in | The easy fix for now would be to just make a mention of Allow in | |||
13.5.2. | 13.5.2. | |||
Additionally, Server should also be included. | Additionally, Server should also be included. | |||
I.26. i25-accept-encoding-bnf | I.47. i37-vary-and-non-existant-headers | |||
In Section 14.3: | In Section 13.6: | |||
Type: change | Type: change | |||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i37> | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i25> | jamie@shareable.org (2004-02-23): (See | |||
<http://www.w3.org/mid/20040223204041.GA32719@mail.shareable.org>). | ||||
abodeman@yahoo.com (2005-06-02): In section 14.3, the definition of | I.48. i38-mismatched-vary | |||
Accept-Encoding is given as follows: | ||||
Accept-Encoding = "Accept-Encoding" ":" 1#( codings [ ";" "q" "=" | ||||
qvalue ] ) | ||||
This definition implies that there must be at least one non-null | ||||
codings. However, just below this definition, one of the examples | ||||
given has an empty Accept-Encoding field-value: | ||||
Accept-Encoding: compress, gzip | ||||
Accept-Encoding: | ||||
Accept-Encoding: * | ||||
Accept-Encoding: compress;q=0.5, gzip;q=1.0 | ||||
Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0 | ||||
Furthermore, the fourth rule for testing whether a content-coding is | ||||
acceptable mentions the possibility that the field-value may be | ||||
empty. | ||||
It seems, then, that the definition for Accept-Encoding should be | ||||
revised: | ||||
Accept-Encoding = "Accept-Encoding" ":" #( codings [ ";" "q" "=" | ||||
qvalue ] ) | ||||
I.27. i61-redirection-vs-location | In Section 13.6: | |||
Type: change | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i38> | ||||
hno@squid-cache.org (2006-10-20): | ||||
When one cached variant has one Vary header, and then another variant | ||||
is received with a different Vary header. Lets say the first has | ||||
Vary: Accept-Language | ||||
and the second | ||||
Vary: Accept-Encoding | ||||
what is the appropriate behaviour for a cache? | ||||
I.49. i39-etag-uniqueness | ||||
In Section 13.6: | ||||
Type: change | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i39> | ||||
henrik@henriknordstrom.net (2006-10-19): From experience I think it's | ||||
also worthwhile to further stress the importance of ETag uniqueness | ||||
among variants of a URI. Very few implementations get this part | ||||
correct. In fact most major web servers have issues here... | ||||
Some even strongly believe that entities with different Content- | ||||
Encoding is the same entity, arguing that since most encoding (at | ||||
least the standardized ones) can be converted to the same identity | ||||
encoding so they are in fact the same entity and should have the same | ||||
strong ETag. | ||||
I.50. i23-no-store-invalidation | ||||
In Section 14.9.2: | ||||
Type: change | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i23> | ||||
rousskov@measurement-factory.com (2005-07-26): Responses to HTTP | ||||
requests with "Cache-control: no-store" are not cachable. Recently, | ||||
we came across a cache that does not cache responses to no-store | ||||
requests but also does not invalidate an older cached entity with the | ||||
same URL. When future requests stop using no-store, the old cached | ||||
entity is served. | ||||
For example, the following happens in our test case: | ||||
1. Client requests an entity A without using no-store. | ||||
2. Cache proxies the transaction and caches the response (entity A). | ||||
3. Client requests the same entity A using "Cache-control: no- | ||||
store". | ||||
4. Cache proxies the transaction and does NOT cache the response. | ||||
5. Client requests the same entity A again, without using no-store. | ||||
6. Cache serves the "old" entity A cached in step #2 above. | ||||
Does the cache violate the intent of RFC 2616 in step #6? If yes, | ||||
should that intent be made explicit (I cannot find any explicit rules | ||||
prohibiting the above behavior)? | ||||
If no, should the cache check that response in step #4 does not | ||||
indicate that cached entity A is stale? I cannot find explicit rules | ||||
requiring that, but we do have similar rules about 304 and HEAD | ||||
responses invalidating older cached entities. | ||||
I.51. i80-content-location-is-not-special | ||||
In Section 14.14: | ||||
Type: change | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i80> | ||||
julian.reschke@greenbytes.de (2007-07-31): | ||||
The definition of Content-Location ends with: | ||||
""The meaning of the Content-Location header in PUT or POST | ||||
requests is undefined; servers are free to ignore it in those | ||||
cases." " -- http://tools.ietf.org/html/rfc2616#section-14.14 | ||||
This was added in RFC2616 (does not appear in RFC2068). | ||||
I have no problem allowing servers to ignore it. However: | ||||
1) It seems that the meaning of Content-Location is universal for | ||||
messages that carry an entity; I'm not sure what's the point in | ||||
claiming that meaning does not apply to PUT or POST. | ||||
2) Also: every time a limited set of methods is mentioned somewhere | ||||
it feels like problematic spec writing. What makes PUT or POST so | ||||
special in comparison to other methods? Maybe that they are the only | ||||
methods in RFC2616 that carry request entity bodies? In which case | ||||
the statement should be rephrased accordingly... | ||||
I.52. i22-etag-and-other-metadata-in-status-messages | ||||
In Section 14.19: | ||||
Type: change | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i22> | ||||
julian.reschke@gmx.de (2006-08-09): (See proposal at <http:// | ||||
greenbytes.de/tech/webdav/#draft-reschke-http-etag-on-write>). | ||||
I.53. i61-redirection-vs-location | ||||
In Section 14.30: | In Section 14.30: | |||
Type: edit | Type: edit | |||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i61> | <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i61> | |||
julian.reschke@gmx.de (2007-04-19): The first sentence could be | julian.reschke@gmx.de (2007-04-19): The first sentence could be | |||
understood as if the presence of the "Location" response header | understood as if the presence of the "Location" response header | |||
always implies some kind of redirection. See also http:// | always implies some kind of redirection. See also <http:// | |||
lists.w3.org/Archives/Public/ietf-http-wg/2007AprJun/0020.html. | lists.w3.org/Archives/Public/ietf-http-wg/2007AprJun/0020.html>. | |||
I.28. fragment-combination | I.54. fragment-combination | |||
In Section 14.30: | In Section 14.30: | |||
Type: change | Type: change | |||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i43> | <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i43> | |||
fielding@kiwi.ics.uci.edu (1999-08-06): See | ||||
http://lists.w3.org/Archives/Public/ietf-http-wg-old/1999MayAug/0103. | fielding@kiwi.ics.uci.edu (1999-08-06): See <http://lists.w3.org/ | |||
Archives/Public/ietf-http-wg-old/1999MayAug/0103>. | ||||
julian.reschke@greenbytes.de (2006-10-29): Part of this was fixed in | julian.reschke@greenbytes.de (2006-10-29): Part of this was fixed in | |||
draft 01 (see issue location-fragments). This leaves us with the | draft 01 (see issue | |||
open issue: _At present, the behavior in the case where there was a | <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i6>). This | |||
fragment with the original URI, e.g.: | leaves us with the open issue: _At present, the behavior in the case | |||
where there was a fragment with the original URI, e.g.: | ||||
http://host1.example.com/resource1#fragment1 where /resource1 | http://host1.example.com/resource1#fragment1 where /resource1 | |||
redirects to http://host2.example.com/resource2#fragment2 is | redirects to http://host2.example.com/resource2#fragment2 is | |||
'fragment1' discarded? Do you find fragment2 and then find fragment1 | 'fragment1' discarded? Do you find fragment2 and then find fragment1 | |||
within it? We don't have fragment combination rules._. See also | within it? We don't have fragment combination rules._. | |||
http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i43. | ||||
I.29. i55-updating-to-rfc4288 | I.55. i41-security-considerations | |||
In Section 15: | ||||
Type: change | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i41> | ||||
What work needs to be done to the Security Considerations section of | ||||
RFC2616 to allow publication of a revision? E.g., does HTTP need to | ||||
specify a Mandatory To Implement mechanism? | ||||
I.56. i55-updating-to-rfc4288 | ||||
In Section A: | In Section A: | |||
Type: edit | Type: edit | |||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i56> | <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i55> | |||
julian.reschke@gmx.de (2007-01-05): The update from RFC2048 to | julian.reschke@gmx.de (2007-01-05): The update from RFC2048 to | |||
RFC4288 requires minor modifications for the media type registrations | RFC4288 requires minor modifications for the media type registrations | |||
for "message/http", "application/http" and "multipart/byteranges". | for "message/http", "application/http" and "multipart/byteranges". | |||
Index | Index | |||
1 | 1 | |||
100 Continue (status code) 68 | 100 Continue (status code) 68 | |||
101 Switching Protocols (status code) 68 | 101 Switching Protocols (status code) 68 | |||
110 Response is stale (warn code) 161 | ||||
111 Revalidation failed (warn code) 161 | ||||
112 Disconnected operation (warn code) 161 | ||||
113 Heuristic expiration (warn code) 161 | ||||
199 Miscellaneous warning (warn code) 161 | ||||
2 | 2 | |||
200 OK (status code) 69 | 200 OK (status code) 69 | |||
201 Created (status code) 69 | 201 Created (status code) 69 | |||
202 Accepted (status code) 69 | 202 Accepted (status code) 69 | |||
203 Non-Authoritative Information (status code) 70 | 203 Non-Authoritative Information (status code) 70 | |||
204 No Content (status code) 70 | 204 No Content (status code) 70 | |||
205 Reset Content (status code) 70 | 205 Reset Content (status code) 70 | |||
206 Partial Content (status code) 71 | 206 Partial Content (status code) 71 | |||
214 Transformation applied (warn code) 162 | ||||
299 Miscellaneous persistent warning (warn code) 162 | ||||
3 | 3 | |||
300 Multiple Choices (status code) 72 | 300 Multiple Choices (status code) 72 | |||
301 Moved Permanently (status code) 72 | 301 Moved Permanently (status code) 72 | |||
302 Found (status code) 73 | 302 Found (status code) 73 | |||
303 See Other (status code) 73 | 303 See Other (status code) 73 | |||
304 Not Modified (status code) 74 | 304 Not Modified (status code) 74 | |||
305 Use Proxy (status code) 74 | 305 Use Proxy (status code) 74 | |||
306 (Unused) (status code) 75 | 306 (Unused) (status code) 75 | |||
307 Temporary Redirect (status code) 75 | 307 Temporary Redirect (status code) 75 | |||
skipping to change at page 208, line 16 | skipping to change at page 234, line 23 | |||
504 Gateway Timeout (status code) 81 | 504 Gateway Timeout (status code) 81 | |||
505 HTTP Version Not Supported (status code) 81 | 505 HTTP Version Not Supported (status code) 81 | |||
A | A | |||
Accept header 112 | Accept header 112 | |||
Accept-Charset header 114 | Accept-Charset header 114 | |||
Accept-Encoding header 114 | Accept-Encoding header 114 | |||
Accept-Language header 116 | Accept-Language header 116 | |||
Accept-Ranges header 117 | Accept-Ranges header 117 | |||
Age header 117 | Age header 117 | |||
age 16 | age 17 | |||
Allow header 118 | Allow header 118 | |||
Alternates header 190 | Alternates header 190 | |||
application/http Media Type 177 | application/http Media Type 177 | |||
Authorization header 118 | Authorization header 118 | |||
C | C | |||
Cache Directives | Cache Directives | |||
max-age 124, 126 | max-age 124, 126 | |||
max-stale 124 | max-stale 124 | |||
min-fresh 124 | min-fresh 124 | |||
must-revalidate 126 | must-revalidate 126 | |||
no-cache 122 | no-cache 122 | |||
no-store 122 | no-store 122 | |||
no-transform 127 | no-transform 127 | |||
only-if-cached 126 | only-if-cached 126 | |||
private 121 | private 121 | |||
proxy-revalidate 127 | proxy-revalidate 127 | |||
public 121 | public 121 | |||
s-maxage 123 | s-maxage 123 | |||
cache 15 | cache 16 | |||
Cache-Control header 119 | Cache-Control header 119 | |||
cacheable 15 | cacheable 16 | |||
client 14 | client 15 | |||
compress 30 | compress (content coding) 31 | |||
CONNECT method 67 | CONNECT method 67 | |||
Connection header 129 | Connection header 129 | |||
connection 13 | connection 14 | |||
content negotiation 14 | Content Codings 31 | |||
compress 31 | ||||
deflate 31 | ||||
gzip 31 | ||||
identity 31 | ||||
content negotiation 15 | ||||
Content-Base header 190 | Content-Base header 190 | |||
Content-Disposition header 185 | Content-Disposition header 185 | |||
Content-Encoding header 130 | Content-Encoding header 130 | |||
Content-Language header 130 | Content-Language header 130 | |||
Content-Length header 131 | Content-Length header 131 | |||
Content-Location header 132 | Content-Location header 132 | |||
Content-MD5 header 133 | Content-MD5 header 133 | |||
Content-Range header 134 | Content-Range header 134 | |||
Content-Type header 136 | Content-Type header 136 | |||
Content-Version header 190 | Content-Version header 190 | |||
D | D | |||
Date header 136 | Date header 136 | |||
deflate 30 | deflate (content coding) 31 | |||
DELETE method 66 | DELETE method 67 | |||
Derived-From header 190 | Derived-From header 190 | |||
downstream 17 | downstream 18 | |||
E | E | |||
entity 13 | entity 14 | |||
ETag header 138 | ETag header 138 | |||
Expect header 138 | Expect header 138 | |||
Expires header 139 | Expires header 139 | |||
explicit expiration time 16 | explicit expiration time 17 | |||
F | F | |||
first-hand 15 | first-hand 16 | |||
fresh 16 | fresh 17 | |||
freshness lifetime 16 | freshness lifetime 17 | |||
From header 140 | From header 140 | |||
G | G | |||
gateway 15 | gateway 16 | |||
GET method 63 | GET method 64 | |||
Grammar | Grammar | |||
Accept 112 | Accept 112 | |||
Accept-Charset 114 | Accept-Charset 114 | |||
Accept-Encoding 114 | Accept-Encoding 114 | |||
accept-extension 112 | accept-extension 112 | |||
Accept-Language 116 | Accept-Language 116 | |||
accept-params 112 | accept-params 112 | |||
Accept-Ranges 117 | Accept-Ranges 117 | |||
acceptable-ranges 117 | acceptable-ranges 117 | |||
Age 118 | Age 118 | |||
age-value 118 | age-value 118 | |||
Allow 118 | Allow 118 | |||
ALPHA 22 | ALPHA 23 | |||
asctime-date 28 | asctime-date 29 | |||
attribute 31 | attribute 32 | |||
Authorization 119 | Authorization 119 | |||
byte-content-range-spec 134 | byte-content-range-spec 134 | |||
byte-range-resp-spec 134 | byte-range-resp-spec 134 | |||
byte-range-set 150 | byte-range-set 150 | |||
byte-range-spec 150 | byte-range-spec 150 | |||
byte-ranges-specifier 150 | byte-ranges-specifier 150 | |||
bytes-unit 37 | bytes-unit 38 | |||
Cache-Control 120 | Cache-Control 120 | |||
cache-directive 120 | cache-directive 120 | |||
cache-extension 120 | cache-extension 120 | |||
cache-request-directive 120 | cache-request-directive 120 | |||
cache-response-directive 120 | cache-response-directive 120 | |||
CHAR 22 | CHAR 23 | |||
charset 29 | charset 30 | |||
chunk 32 | chunk 33 | |||
chunk-data 32 | chunk-data 33 | |||
chunk-ext-name 32 | chunk-ext-name 33 | |||
chunk-ext-val 32 | chunk-ext-val 33 | |||
chunk-extension 32 | chunk-extension 33 | |||
chunk-size 32 | chunk-size 33 | |||
Chunked-Body 32 | Chunked-Body 33 | |||
codings 114 | codings 114 | |||
comment 23 | comment 24 | |||
Connection 129 | Connection 129 | |||
connection-token 129 | connection-token 129 | |||
content-coding 30 | content-coding 31 | |||
content-disposition 185 | content-disposition 185 | |||
Content-Encoding 130 | Content-Encoding 130 | |||
Content-Language 131 | Content-Language 131 | |||
Content-Length 131 | Content-Length 131 | |||
Content-Location 132 | Content-Location 132 | |||
Content-MD5 133 | Content-MD5 133 | |||
Content-Range 134 | Content-Range 134 | |||
content-range-spec 134 | content-range-spec 134 | |||
Content-Type 136 | Content-Type 136 | |||
CR 22 | CR 23 | |||
CRLF 22 | CRLF 23 | |||
ctext 23 | ctext 24 | |||
CTL 22 | CTL 23 | |||
Date 136 | Date 136 | |||
date1 28 | date1 29 | |||
date2 28 | date2 29 | |||
date3 28 | date3 29 | |||
delta-seconds 28 | delta-seconds 29 | |||
DIGIT 22 | DIGIT 23 | |||
disp-extension-parm 185 | disp-extension-parm 185 | |||
disp-extension-token 185 | disp-extension-token 185 | |||
disposition-parm 185 | disposition-parm 185 | |||
disposition-type 185 | disposition-type 185 | |||
entity-body 52 | entity-body 53 | |||
entity-header 52 | entity-header 53 | |||
entity-tag 37 | entity-tag 38 | |||
ETag 138 | ETag 138 | |||
Expect 138 | Expect 138 | |||
expect-params 138 | expect-params 138 | |||
expectation 138 | expectation 138 | |||
expectation-extension 138 | expectation-extension 138 | |||
Expires 139 | Expires 139 | |||
extension-code 50 | extension-code 51 | |||
extension-header 52 | extension-header 53 | |||
extension-method 44 | extension-method 45 | |||
extension-pragma 148 | extension-pragma 148 | |||
field-content 40 | field-content 41 | |||
field-name 40 | field-name 41 | |||
field-value 40 | field-value 41 | |||
filename-parm 185 | filename-parm 185 | |||
first-byte-pos 150 | first-byte-pos 150 | |||
From 140 | From 140 | |||
general-header 43 | general-header 44 | |||
generic-message 39 | generic-message 40 | |||
HEX 23 | HEX 24 | |||
Host 141 | Host 141 | |||
HT 22 | HT 23 | |||
HTTP-date 28 | HTTP-date 29 | |||
HTTP-message 39 | HTTP-message 40 | |||
HTTP-Version 24 | HTTP-Version 25 | |||
http_URL 26 | http_URL 27 | |||
If-Match 141 | If-Match 141 | |||
If-Modified-Since 142 | If-Modified-Since 142 | |||
If-None-Match 144 | If-None-Match 144 | |||
If-Range 145 | If-Range 145 | |||
If-Unmodified-Since 146 | If-Unmodified-Since 146 | |||
instance-length 134 | instance-length 134 | |||
language-range 116 | language-range 116 | |||
language-tag 36 | language-tag 37 | |||
last-byte-pos 150 | last-byte-pos 150 | |||
last-chunk 32 | last-chunk 33 | |||
Last-Modified 146 | Last-Modified 146 | |||
LF 22 | LF 23 | |||
LOALPHA 22 | LOALPHA 23 | |||
Location 147 | Location 147 | |||
LWS 22 | LWS 23 | |||
Max-Forwards 148 | Max-Forwards 148 | |||
md5-digest 133 | md5-digest 133 | |||
media-range 112 | media-range 112 | |||
media-type 33 | media-type 34 | |||
message-body 40 | message-body 41 | |||
message-header 40 | message-header 41 | |||
Method 44 | Method 45 | |||
MIME-Version 182 | MIME-Version 182 | |||
month 28 | month 29 | |||
OCTET 22 | OCTET 23 | |||
opaque-tag 37 | opaque-tag 38 | |||
other-range-unit 37 | other-range-unit 38 | |||
parameter 31 | parameter 32 | |||
Pragma 148 | Pragma 148 | |||
pragma-directive 148 | pragma-directive 148 | |||
primary-tag 36 | primary-tag 37 | |||
product 35 | product 36 | |||
product-version 35 | product-version 36 | |||
protocol-name 158 | protocol-name 158 | |||
protocol-version 158 | protocol-version 158 | |||
Proxy-Authenticate 149 | Proxy-Authenticate 149 | |||
Proxy-Authorization 149 | Proxy-Authorization 149 | |||
pseudonym 158 | pseudonym 158 | |||
qdtext 23 | qdtext 24 | |||
quoted-pair 23 | quoted-pair 24 | |||
quoted-string 23 | quoted-string 24 | |||
qvalue 36 | qvalue 37 | |||
Range 152 | Range 152 | |||
range-unit 37 | range-unit 38 | |||
ranges-specifier 150 | ranges-specifier 150 | |||
Reason-Phrase 50 | Reason-Phrase 51 | |||
received-by 158 | received-by 158 | |||
received-protocol 158 | received-protocol 158 | |||
Referer 152 | Referer 152 | |||
Request 44 | Request 45 | |||
request-header 47 | request-header 48 | |||
Request-Line 44 | Request-Line 45 | |||
Request-URI 45 | Request-URI 46 | |||
Response 48 | Response 49 | |||
response-header 51 | response-header 52 | |||
Retry-After 153 | Retry-After 153 | |||
rfc850-date 28 | rfc850-date 29 | |||
rfc1123-date 28 | rfc1123-date 29 | |||
separators 23 | separators 24 | |||
Server 153 | Server 153 | |||
SP 22 | SP 23 | |||
start-line 39 | start-line 40 | |||
Status-Code 50 | Status-Code 51 | |||
Status-Line 48 | Status-Line 49 | |||
subtag 36 | subtag 37 | |||
subtype 33 | subtype 34 | |||
suffix-byte-range-spec 151 | suffix-byte-range-spec 151 | |||
suffix-length 151 | suffix-length 151 | |||
t-codings 154 | t-codings 154 | |||
TE 154 | TE 154 | |||
TEXT 22 | TEXT 23 | |||
time 28 | time 29 | |||
token 23 | token 24 | |||
Trailer 155 | Trailer 155 | |||
trailer 32 | trailer 33 | |||
transfer-coding 31 | transfer-coding 32 | |||
Transfer-Encoding 155 | Transfer-Encoding 155 | |||
transfer-extension 31 | transfer-extension 32 | |||
type 33 | type 34 | |||
UPALPHA 22 | UPALPHA 23 | |||
Upgrade 156 | Upgrade 156 | |||
User-Agent 157 | User-Agent 157 | |||
value 31 | value 32 | |||
Vary 157 | Vary 157 | |||
Via 158 | Via 158 | |||
warn-agent 160 | warn-agent 160 | |||
warn-code 160 | warn-code 160 | |||
warn-date 160 | warn-date 160 | |||
warn-text 160 | warn-text 160 | |||
Warning 160 | Warning 160 | |||
warning-value 160 | warning-value 160 | |||
weak 37 | weak 38 | |||
weekday 28 | weekday 29 | |||
wkday 28 | wkday 29 | |||
WWW-Authenticate 162 | WWW-Authenticate 162 | |||
gzip 30 | gzip (content coding) 31 | |||
H | H | |||
HEAD method 63 | HEAD method 64 | |||
Headers | Headers | |||
Accept 112 | Accept 112 | |||
Accept-Charset 114 | Accept-Charset 114 | |||
Accept-Encoding 114 | Accept-Encoding 114 | |||
Accept-Language 116 | Accept-Language 116 | |||
Accept-Ranges 117 | Accept-Ranges 117 | |||
Age 117 | Age 117 | |||
Allow 118 | Allow 118 | |||
Alternate 190 | Alternate 190 | |||
Authorization 118 | Authorization 118 | |||
skipping to change at page 214, line 38 | skipping to change at page 240, line 50 | |||
TE 154 | TE 154 | |||
Trailer 155 | Trailer 155 | |||
Transfer-Encoding 155 | Transfer-Encoding 155 | |||
Upgrade 156 | Upgrade 156 | |||
URI 190 | URI 190 | |||
User-Agent 157 | User-Agent 157 | |||
Vary 157 | Vary 157 | |||
Via 158 | Via 158 | |||
Warning 160 | Warning 160 | |||
WWW-Authenticate 162 | WWW-Authenticate 162 | |||
heuristic expiration time 16 | heuristic expiration time 17 | |||
Host header 140 | Host header 140 | |||
I | I | |||
identity 30 | identity (content coding) 31 | |||
If-Match header 141 | If-Match header 141 | |||
If-Modified-Since header 142 | If-Modified-Since header 142 | |||
If-None-Match header 144 | If-None-Match header 144 | |||
If-Range header 145 | If-Range header 145 | |||
If-Unmodified-Since header 146 | If-Unmodified-Since header 146 | |||
inbound 17 | inbound 18 | |||
L | L | |||
Last-Modified header 146 | Last-Modified header 146 | |||
Link header 190 | Link header 190 | |||
LINK method 190 | LINK method 190 | |||
Location header 147 | Location header 147 | |||
M | M | |||
max-age | max-age | |||
Cache Directive 124, 126 | Cache Directive 124, 126 | |||
Max-Forwards header 148 | Max-Forwards header 148 | |||
max-stale | max-stale | |||
Cache Directive 124 | Cache Directive 124 | |||
Media Type | Media Type | |||
application/http 177 | application/http 177 | |||
message/http 177 | message/http 177 | |||
multipart/byteranges 179 | multipart/byteranges 179 | |||
multipart/x-byteranges 180 | multipart/x-byteranges 180 | |||
message 13 | message 14 | |||
message/http Media Type 177 | message/http Media Type 177 | |||
Methods | Methods | |||
CONNECT 67 | CONNECT 67 | |||
DELETE 66 | DELETE 67 | |||
GET 63 | GET 64 | |||
HEAD 63 | HEAD 64 | |||
LINK 190 | LINK 190 | |||
OPTIONS 62 | OPTIONS 63 | |||
PATCH 190 | PATCH 190 | |||
POST 64 | POST 65 | |||
PUT 65 | PUT 65 | |||
TRACE 66 | TRACE 67 | |||
UNLINK 190 | UNLINK 190 | |||
min-fresh | min-fresh | |||
Cache Directive 124 | Cache Directive 124 | |||
multipart/byteranges Media Type 179 | multipart/byteranges Media Type 179 | |||
multipart/x-byteranges Media Type 180 | multipart/x-byteranges Media Type 180 | |||
must-revalidate | must-revalidate | |||
Cache Directive 126 | Cache Directive 126 | |||
N | N | |||
no-cache | no-cache | |||
Cache Directive 122 | Cache Directive 122 | |||
no-store | no-store | |||
Cache Directive 122 | Cache Directive 122 | |||
no-transform | no-transform | |||
Cache Directive 127 | Cache Directive 127 | |||
O | O | |||
only-if-cached | only-if-cached | |||
Cache Directive 126 | Cache Directive 126 | |||
OPTIONS method 62 | OPTIONS method 63 | |||
origin server 14 | origin server 15 | |||
outbound 17 | outbound 18 | |||
P | P | |||
PATCH method 190 | PATCH method 190 | |||
POST method 64 | POST method 65 | |||
Pragma header 148 | Pragma header 148 | |||
private | private | |||
Cache Directive 121 | Cache Directive 121 | |||
proxy 14 | proxy 15 | |||
Proxy-Authenticate header 149 | Proxy-Authenticate header 149 | |||
Proxy-Authorization header 149 | Proxy-Authorization header 149 | |||
proxy-revalidate | proxy-revalidate | |||
Cache Directive 127 | Cache Directive 127 | |||
Public header 190 | Public header 190 | |||
public | public | |||
Cache Directive 121 | Cache Directive 121 | |||
PUT method 65 | PUT method 65 | |||
R | R | |||
Range header 150 | Range header 150 | |||
Referer header 152 | Referer header 152 | |||
representation 13 | representation 14 | |||
request 13 | request 14 | |||
resource 13 | resource 14 | |||
response 13 | response 14 | |||
Retry-After header 153 | Retry-After header 153 | |||
S | S | |||
s-maxage | s-maxage | |||
Cache Directive 123 | Cache Directive 123 | |||
semantically transparent 16 | semantically transparent 17 | |||
Server header 153 | Server header 153 | |||
server 14 | server 15 | |||
stale 16 | stale 17 | |||
Status Codes | Status Codes | |||
100 Continue 68 | 100 Continue 68 | |||
101 Switching Protocols 68 | 101 Switching Protocols 68 | |||
200 OK 69 | 200 OK 69 | |||
201 Created 69 | 201 Created 69 | |||
202 Accepted 69 | 202 Accepted 69 | |||
203 Non-Authoritative Information 70 | 203 Non-Authoritative Information 70 | |||
204 No Content 70 | 204 No Content 70 | |||
205 Reset Content 70 | 205 Reset Content 70 | |||
206 Partial Content 71 | 206 Partial Content 71 | |||
skipping to change at page 217, line 36 | skipping to change at page 243, line 47 | |||
417 Expectation Failed 80 | 417 Expectation Failed 80 | |||
500 Internal Server Error 80 | 500 Internal Server Error 80 | |||
501 Not Implemented 80 | 501 Not Implemented 80 | |||
502 Bad Gateway 80 | 502 Bad Gateway 80 | |||
503 Service Unavailable 81 | 503 Service Unavailable 81 | |||
504 Gateway Timeout 81 | 504 Gateway Timeout 81 | |||
505 HTTP Version Not Supported 81 | 505 HTTP Version Not Supported 81 | |||
T | T | |||
TE header 154 | TE header 154 | |||
TRACE method 66 | TRACE method 67 | |||
Trailer header 155 | Trailer header 155 | |||
Transfer-Encoding header 155 | Transfer-Encoding header 155 | |||
tunnel 15 | tunnel 16 | |||
U | U | |||
UNLINK method 190 | UNLINK method 190 | |||
Upgrade header 156 | Upgrade header 156 | |||
upstream 17 | upstream 18 | |||
URI header 190 | URI header 190 | |||
user agent 14 | user agent 15 | |||
User-Agent header 157 | User-Agent header 157 | |||
V | V | |||
validator 16 | validator 17 | |||
variant 14 | variant 15 | |||
Vary header 157 | Vary header 157 | |||
Via header 158 | Via header 158 | |||
W | W | |||
Warn Codes | ||||
110 Response is stale 161 | ||||
111 Revalidation failed 161 | ||||
112 Disconnected operation 161 | ||||
113 Heuristic expiration 161 | ||||
199 Miscellaneous warning 161 | ||||
214 Transformation applied 162 | ||||
299 Miscellaneous persistent warning 162 | ||||
Warning header 160 | Warning header 160 | |||
WWW-Authenticate header 162 | WWW-Authenticate header 162 | |||
Authors' Addresses | Authors' Addresses | |||
Roy T. Fielding | Roy T. Fielding | |||
Day Software | Day Software | |||
23 Corporate Plaza DR, Suite 215 | 23 Corporate Plaza DR, Suite 215 | |||
Newport Beach, CA 92660 | Newport Beach, CA 92660 | |||
USA | USA | |||
Phone: +1-949-706-5300 | Phone: +1-949-706-5300 | |||
Fax: +1-949-706-5305 | Fax: +1-949-706-5305 | |||
Email: fielding@gbiv.com | Email: fielding@gbiv.com | |||
URI: http://roy.gbiv.com/ | URI: http://roy.gbiv.com/ | |||
James Gettys | Jim Gettys | |||
Hewlett-Packard Company | One Laptop per Child | |||
HP Labs, Cambridge Research Laboratory | 1 Cambridge Center, 10th floor | |||
One Cambridge Center | Cambridge, MA 02142 | |||
Cambridge, MA 02138 | ||||
USA | USA | |||
Email: Jim.Gettys@hp.com | URI: http://www.laptop.org/ | |||
Jeffrey C. Mogul | Jeffrey C. Mogul | |||
Hewlett-Packard Company | Hewlett-Packard Company | |||
HP Labs, Large Scale Systems Group | HP Labs, Large Scale Systems Group | |||
1501 Page Mill Road, MS 1177 | 1501 Page Mill Road, MS 1177 | |||
Palo Alto, CA 94304 | Palo Alto, CA 94304 | |||
USA | USA | |||
Email: JeffMogul@acm.org | Email: JeffMogul@acm.org | |||
End of changes. 233 change blocks. | ||||
640 lines changed or deleted | 1932 lines changed or added | |||
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |