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. | |||
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 | |||
many tasks beyond its use for hypertext, such as name servers and | many tasks beyond its use for hypertext, such as name servers and | |||
distributed object management systems, through extension of its | distributed object management systems, through extension of its | |||
request methods, error codes and headers [RFC2324]. A feature of | request methods, error codes and headers [RFC2324]. A feature of | |||
HTTP is the typing and negotiation of data representation, allowing | HTTP is the typing and negotiation of data representation, allowing | |||
skipping to change at page 4, line 7 ¶ | skipping to change at page 4, 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 . . . . . . . . . . . . . . . . . . . . . . . . 11 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . 11 | 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 11 | 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 12 | |||
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . 12 | 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . 13 | |||
1.4. Overall Operation . . . . . . . . . . . . . . . . . . . 16 | 1.4. Overall Operation . . . . . . . . . . . . . . . . . . . 17 | |||
2. Notational Conventions and Generic Grammar . . . . . . . . . 19 | 2. Notational Conventions and Generic Grammar . . . . . . . . . 20 | |||
2.1. Augmented BNF . . . . . . . . . . . . . . . . . . . . . 19 | 2.1. Augmented BNF . . . . . . . . . . . . . . . . . . . . . 20 | |||
2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . . 21 | 2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . . 22 | |||
3. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 23 | 3. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 24 | |||
3.1. HTTP Version . . . . . . . . . . . . . . . . . . . . . . 23 | 3.1. HTTP Version . . . . . . . . . . . . . . . . . . . . . . 24 | |||
3.2. Uniform Resource Identifiers . . . . . . . . . . . . . . 24 | 3.2. Uniform Resource Identifiers . . . . . . . . . . . . . . 25 | |||
3.2.1. General Syntax . . . . . . . . . . . . . . . . . . . 24 | 3.2.1. General Syntax . . . . . . . . . . . . . . . . . . . 25 | |||
3.2.2. http URL . . . . . . . . . . . . . . . . . . . . . . 25 | 3.2.2. http URL . . . . . . . . . . . . . . . . . . . . . . 26 | |||
3.2.3. URI Comparison . . . . . . . . . . . . . . . . . . . 25 | 3.2.3. URI Comparison . . . . . . . . . . . . . . . . . . . 26 | |||
3.3. Date/Time Formats . . . . . . . . . . . . . . . . . . . 26 | 3.3. Date/Time Formats . . . . . . . . . . . . . . . . . . . 27 | |||
3.3.1. Full Date . . . . . . . . . . . . . . . . . . . . . 26 | 3.3.1. Full Date . . . . . . . . . . . . . . . . . . . . . 27 | |||
3.3.2. Delta Seconds . . . . . . . . . . . . . . . . . . . 27 | 3.3.2. Delta Seconds . . . . . . . . . . . . . . . . . . . 28 | |||
3.4. Character Sets . . . . . . . . . . . . . . . . . . . . . 27 | 3.4. Character Sets . . . . . . . . . . . . . . . . . . . . . 28 | |||
3.4.1. Missing Charset . . . . . . . . . . . . . . . . . . 28 | 3.4.1. Missing Charset . . . . . . . . . . . . . . . . . . 29 | |||
3.5. Content Codings . . . . . . . . . . . . . . . . . . . . 29 | 3.5. Content Codings . . . . . . . . . . . . . . . . . . . . 30 | |||
3.6. Transfer Codings . . . . . . . . . . . . . . . . . . . . 30 | 3.6. Transfer Codings . . . . . . . . . . . . . . . . . . . . 31 | |||
3.6.1. Chunked Transfer Coding . . . . . . . . . . . . . . 31 | 3.6.1. Chunked Transfer Coding . . . . . . . . . . . . . . 32 | |||
3.7. Media Types . . . . . . . . . . . . . . . . . . . . . . 32 | 3.7. Media Types . . . . . . . . . . . . . . . . . . . . . . 33 | |||
3.7.1. Canonicalization and Text Defaults . . . . . . . . . 33 | 3.7.1. Canonicalization and Text Defaults . . . . . . . . . 34 | |||
3.7.2. Multipart Types . . . . . . . . . . . . . . . . . . 33 | 3.7.2. Multipart Types . . . . . . . . . . . . . . . . . . 34 | |||
3.8. Product Tokens . . . . . . . . . . . . . . . . . . . . . 34 | 3.8. Product Tokens . . . . . . . . . . . . . . . . . . . . . 35 | |||
3.9. Quality Values . . . . . . . . . . . . . . . . . . . . . 35 | 3.9. Quality Values . . . . . . . . . . . . . . . . . . . . . 36 | |||
3.10. Language Tags . . . . . . . . . . . . . . . . . . . . . 35 | 3.10. Language Tags . . . . . . . . . . . . . . . . . . . . . 36 | |||
3.11. Entity Tags . . . . . . . . . . . . . . . . . . . . . . 36 | 3.11. Entity Tags . . . . . . . . . . . . . . . . . . . . . . 37 | |||
3.12. Range Units . . . . . . . . . . . . . . . . . . . . . . 36 | 3.12. Range Units . . . . . . . . . . . . . . . . . . . . . . 37 | |||
4. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . 38 | 4. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . 39 | |||
4.1. Message Types . . . . . . . . . . . . . . . . . . . . . 38 | 4.1. Message Types . . . . . . . . . . . . . . . . . . . . . 39 | |||
4.2. Message Headers . . . . . . . . . . . . . . . . . . . . 38 | 4.2. Message Headers . . . . . . . . . . . . . . . . . . . . 39 | |||
4.3. Message Body . . . . . . . . . . . . . . . . . . . . . . 39 | 4.3. Message Body . . . . . . . . . . . . . . . . . . . . . . 40 | |||
4.4. Message Length . . . . . . . . . . . . . . . . . . . . . 40 | 4.4. Message Length . . . . . . . . . . . . . . . . . . . . . 41 | |||
4.5. General Header Fields . . . . . . . . . . . . . . . . . 41 | 4.5. General Header Fields . . . . . . . . . . . . . . . . . 42 | |||
5. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 | 5. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 | |||
5.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . 43 | 5.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . 44 | |||
5.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . 43 | 5.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . 44 | |||
5.1.2. Request-URI . . . . . . . . . . . . . . . . . . . . 44 | 5.1.2. Request-URI . . . . . . . . . . . . . . . . . . . . 45 | |||
5.2. The Resource Identified by a Request . . . . . . . . . . 45 | 5.2. The Resource Identified by a Request . . . . . . . . . . 46 | |||
5.3. Request Header Fields . . . . . . . . . . . . . . . . . 46 | 5.3. Request Header Fields . . . . . . . . . . . . . . . . . 47 | |||
6. Response . . . . . . . . . . . . . . . . . . . . . . . . . . 47 | 6. Response . . . . . . . . . . . . . . . . . . . . . . . . . . 48 | |||
6.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . 47 | 6.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . 48 | |||
6.1.1. Status Code and Reason Phrase . . . . . . . . . . . 47 | 6.1.1. Status Code and Reason Phrase . . . . . . . . . . . 48 | |||
6.2. Response Header Fields . . . . . . . . . . . . . . . . . 50 | 6.2. Response Header Fields . . . . . . . . . . . . . . . . . 51 | |||
7. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 | 7. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 | |||
7.1. Entity Header Fields . . . . . . . . . . . . . . . . . . 51 | 7.1. Entity Header Fields . . . . . . . . . . . . . . . . . . 52 | |||
7.2. Entity Body . . . . . . . . . . . . . . . . . . . . . . 51 | 7.2. Entity Body . . . . . . . . . . . . . . . . . . . . . . 52 | |||
7.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 52 | 7.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 53 | |||
7.2.2. Entity Length . . . . . . . . . . . . . . . . . . . 52 | 7.2.2. Entity Length . . . . . . . . . . . . . . . . . . . 53 | |||
8. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 53 | 8. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 54 | |||
8.1. Persistent Connections . . . . . . . . . . . . . . . . . 53 | 8.1. Persistent Connections . . . . . . . . . . . . . . . . . 54 | |||
8.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . 53 | 8.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . 54 | |||
8.1.2. Overall Operation . . . . . . . . . . . . . . . . . 53 | 8.1.2. Overall Operation . . . . . . . . . . . . . . . . . 54 | |||
8.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . 55 | 8.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . 56 | |||
8.1.4. Practical Considerations . . . . . . . . . . . . . . 55 | 8.1.4. Practical Considerations . . . . . . . . . . . . . . 56 | |||
8.2. Message Transmission Requirements . . . . . . . . . . . 56 | 8.2. Message Transmission Requirements . . . . . . . . . . . 57 | |||
8.2.1. Persistent Connections and Flow Control . . . . . . 56 | 8.2.1. Persistent Connections and Flow Control . . . . . . 57 | |||
8.2.2. Monitoring Connections for Error Status Messages . . 56 | 8.2.2. Monitoring Connections for Error Status Messages . . 57 | |||
8.2.3. Use of the 100 (Continue) Status . . . . . . . . . . 57 | 8.2.3. Use of the 100 (Continue) Status . . . . . . . . . . 58 | |||
8.2.4. Client Behavior if Server Prematurely Closes | 8.2.4. Client Behavior if Server Prematurely Closes | |||
Connection . . . . . . . . . . . . . . . . . . . . . 59 | Connection . . . . . . . . . . . . . . . . . . . . . 60 | |||
9. Method Definitions . . . . . . . . . . . . . . . . . . . . . 60 | 9. Method Definitions . . . . . . . . . . . . . . . . . . . . . 61 | |||
9.1. Safe and Idempotent Methods . . . . . . . . . . . . . . 60 | 9.1. Safe and Idempotent Methods . . . . . . . . . . . . . . 61 | |||
9.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . 60 | 9.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . 61 | |||
9.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . 60 | 9.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . 61 | |||
9.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . 61 | 9.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . 62 | |||
9.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . 62 | 9.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . 63 | |||
9.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . 62 | 9.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . 63 | |||
9.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . 63 | 9.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . 64 | |||
9.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . 64 | 9.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . 64 | |||
9.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . 65 | 9.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . 66 | |||
9.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . 65 | 9.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . 66 | |||
9.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . 66 | 9.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . 66 | |||
10. Status Code Definitions . . . . . . . . . . . . . . . . . . . 67 | 10. Status Code Definitions . . . . . . . . . . . . . . . . . . . 67 | |||
10.1. Informational 1xx . . . . . . . . . . . . . . . . . . . 67 | 10.1. Informational 1xx . . . . . . . . . . . . . . . . . . . 67 | |||
10.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 67 | 10.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 67 | |||
10.1.2. 101 Switching Protocols . . . . . . . . . . . . . . 67 | 10.1.2. 101 Switching Protocols . . . . . . . . . . . . . . 67 | |||
10.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . 68 | 10.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . 68 | |||
10.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 68 | 10.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 68 | |||
10.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . 68 | 10.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . 68 | |||
10.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . 68 | 10.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . 68 | |||
10.2.4. 203 Non-Authoritative Information . . . . . . . . . 69 | 10.2.4. 203 Non-Authoritative Information . . . . . . . . . 69 | |||
skipping to change at page 9, line 4 ¶ | skipping to change at page 9, line 4 ¶ | |||
15.4. Location Headers and Spoofing . . . . . . . . . . . . . 165 | 15.4. Location Headers and Spoofing . . . . . . . . . . . . . 165 | |||
15.5. Content-Disposition Issues . . . . . . . . . . . . . . . 166 | 15.5. Content-Disposition Issues . . . . . . . . . . . . . . . 166 | |||
15.6. Authentication Credentials and Idle Clients . . . . . . 166 | 15.6. Authentication Credentials and Idle Clients . . . . . . 166 | |||
15.7. Proxies and Caching . . . . . . . . . . . . . . . . . . 166 | 15.7. Proxies and Caching . . . . . . . . . . . . . . . . . . 166 | |||
15.7.1. Denial of Service Attacks on Proxies . . . . . . . . 167 | 15.7.1. Denial of Service Attacks on Proxies . . . . . . . . 167 | |||
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 168 | 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 168 | |||
16.1. (RFC2616) . . . . . . . . . . . . . . . . . . . . . . . 168 | 16.1. (RFC2616) . . . . . . . . . . . . . . . . . . . . . . . 168 | |||
16.2. (This Document) . . . . . . . . . . . . . . . . . . . . 169 | 16.2. (This Document) . . . . . . . . . . . . . . . . . . . . 169 | |||
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 170 | 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 170 | |||
17.1. References (to be classified) . . . . . . . . . . . . . 170 | 17.1. References (to be classified) . . . . . . . . . . . . . 170 | |||
17.2. Informative References . . . . . . . . . . . . . . . . . 173 | 17.2. Normative References . . . . . . . . . . . . . . . . . . 170 | |||
17.3. Informative References . . . . . . . . . . . . . . . . . 171 | ||||
Appendix A. Internet Media Type message/http and | Appendix A. Internet Media Type message/http and | |||
application/http . . . . . . . . . . . . . . . . . . 176 | application/http . . . . . . . . . . . . . . . . . . 176 | |||
Appendix B. Internet Media Type multipart/byteranges . . . . . . 178 | Appendix B. Internet Media Type multipart/byteranges . . . . . . 178 | |||
Appendix C. Tolerant Applications . . . . . . . . . . . . . . . 180 | Appendix C. Tolerant Applications . . . . . . . . . . . . . . . 180 | |||
Appendix D. Differences Between HTTP Entities and RFC 2045 | Appendix D. Differences Between HTTP Entities and RFC 2045 | |||
Entities . . . . . . . . . . . . . . . . . . . . . . 181 | Entities . . . . . . . . . . . . . . . . . . . . . . 181 | |||
D.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . 181 | D.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . 181 | |||
D.2. Conversion to Canonical Form . . . . . . . . . . . . . . 181 | D.2. Conversion to Canonical Form . . . . . . . . . . . . . . 181 | |||
D.3. Conversion of Date Formats . . . . . . . . . . . . . . . 182 | D.3. Conversion of Date Formats . . . . . . . . . . . . . . . 182 | |||
D.4. Introduction of Content-Encoding . . . . . . . . . . . . 182 | D.4. Introduction of Content-Encoding . . . . . . . . . . . . 182 | |||
skipping to change at page 9, line 33 ¶ | skipping to change at page 9, line 34 ¶ | |||
Conserve IP Addresses . . . . . . . . . . . . . . . 185 | Conserve IP Addresses . . . . . . . . . . . . . . . 185 | |||
F.2. Compatibility with HTTP/1.0 Persistent Connections . . . 186 | F.2. Compatibility with HTTP/1.0 Persistent Connections . . . 186 | |||
F.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . 187 | F.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . 187 | |||
F.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . 189 | F.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . 189 | |||
Appendix G. Change Log (to be removed by RFC Editor before | Appendix G. Change Log (to be removed by RFC Editor before | |||
publication) . . . . . . . . . . . . . . . . . . . . 191 | publication) . . . . . . . . . . . . . . . . . . . . 191 | |||
G.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . 191 | G.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . 191 | |||
G.2. Since draft-lafon-rfc2616bis-00 . . . . . . . . . . . . 191 | G.2. Since draft-lafon-rfc2616bis-00 . . . . . . . . . . . . 191 | |||
G.3. Since draft-lafon-rfc2616bis-01 . . . . . . . . . . . . 191 | G.3. Since draft-lafon-rfc2616bis-01 . . . . . . . . . . . . 191 | |||
G.4. Since draft-lafon-rfc2616bis-02 . . . . . . . . . . . . 191 | G.4. Since draft-lafon-rfc2616bis-02 . . . . . . . . . . . . 191 | |||
G.5. Since draft-lafon-rfc2616bis-03 . . . . . . . . . . . . 192 | ||||
Appendix H. Resolved issues (to be removed by RFC Editor | Appendix H. Resolved issues (to be removed by RFC Editor | |||
before publication) . . . . . . . . . . . . . . . . 193 | before publication) . . . . . . . . . . . . . . . . 194 | |||
H.1. i45-rfc977-reference . . . . . . . . . . . . . . . . . . 193 | H.1. unneeded_references . . . . . . . . . . . . . . . . . . 194 | |||
H.2. i46-rfc1700_remove . . . . . . . . . . . . . . . . . . . 193 | H.2. consistent-reason-phrases . . . . . . . . . . . . . . . 194 | |||
H.3. i47-inconsistency-in-date-format-explanation . . . . . . 193 | H.3. i66-iso8859-1-reference . . . . . . . . . . . . . . . . 194 | |||
H.4. i49-connection-header-text . . . . . . . . . . . . . . . 194 | H.4. abnf-edit . . . . . . . . . . . . . . . . . . . . . . . 195 | |||
H.5. i48-date-reference-typo . . . . . . . . . . . . . . . . 194 | H.5. rfc1766_normative . . . . . . . . . . . . . . . . . . . 195 | |||
H.6. i86-normative-up-to-date-references . . . . . . . . . . 195 | ||||
H.7. i68-encoding-references-normative . . . . . . . . . . . 196 | ||||
H.8. rfc2396_normative . . . . . . . . . . . . . . . . . . . 196 | ||||
H.9. usascii_normative . . . . . . . . . . . . . . . . . . . 196 | ||||
H.10. i65-informative-references . . . . . . . . . . . . . . . 196 | ||||
H.11. i31-qdtext-bnf . . . . . . . . . . . . . . . . . . . . . 197 | ||||
H.12. i62-whitespace-in-quoted-pair . . . . . . . . . . . . . 198 | ||||
H.13. i26-import-query-bnf . . . . . . . . . . . . . . . . . . 198 | ||||
H.14. i47-inconsistency-in-date-format-explanation . . . . . . 199 | ||||
H.15. media-reg . . . . . . . . . . . . . . . . . . . . . . . 199 | ||||
H.16. i84-redundant-cross-references . . . . . . . . . . . . . 200 | ||||
H.17. i87-typo-in-13.2.2 . . . . . . . . . . . . . . . . . . . 200 | ||||
H.18. i25-accept-encoding-bnf . . . . . . . . . . . . . . . . 201 | ||||
H.19. remove-CTE-abbrev . . . . . . . . . . . . . . . . . . . 202 | ||||
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) . . . . . . . . . . . . . . . . . . . . 196 | publication) . . . . . . . . . . . . . . . . . . . . 203 | |||
I.1. rfc2616bis . . . . . . . . . . . . . . . . . . . . . . . 196 | I.1. rfc2616bis . . . . . . . . . . . . . . . . . . . . . . . 203 | |||
I.2. unneeded_references . . . . . . . . . . . . . . . . . . 196 | I.2. i35-split-normative-and-informative-references . . . . . 203 | |||
I.3. edit . . . . . . . . . . . . . . . . . . . . . . . . . . 196 | I.3. i40-header-registration . . . . . . . . . . . . . . . . 203 | |||
I.4. i66-iso8859-1-reference . . . . . . . . . . . . . . . . 196 | I.4. edit . . . . . . . . . . . . . . . . . . . . . . . . . . 203 | |||
I.5. abnf . . . . . . . . . . . . . . . . . . . . . . . . . . 196 | I.5. abnf . . . . . . . . . . . . . . . . . . . . . . . . . . 203 | |||
I.6. rfc2048_informative_and_obsolete . . . . . . . . . . . . 197 | I.6. rfc2048_informative_and_obsolete . . . . . . . . . . . . 204 | |||
I.7. i34-updated-reference-for-uris . . . . . . . . . . . . . 197 | I.7. i34-updated-reference-for-uris . . . . . . . . . . . . . 204 | |||
I.8. i50-misc-typos . . . . . . . . . . . . . . . . . . . . . 197 | I.8. i50-misc-typos . . . . . . . . . . . . . . . . . . . . . 204 | |||
I.9. i65-informative-references . . . . . . . . . . . . . . . 197 | I.9. i52-sort-1.3-terminology . . . . . . . . . . . . . . . . 205 | |||
I.10. i52-sort-1.3-terminology . . . . . . . . . . . . . . . . 198 | I.10. i63-header-length-limit-with-encoded-words . . . . . . . 205 | |||
I.11. i63-header-length-limit-with-encoded-words . . . . . . . 199 | I.11. i74-character-encodings-for-headers . . . . . . . . . . 206 | |||
I.12. i31-qdtext-bnf . . . . . . . . . . . . . . . . . . . . . 199 | I.12. i64-ws-in-quoted-pair . . . . . . . . . . . . . . . . . 206 | |||
I.13. i62-whitespace-in-quoted-pair . . . . . . . . . . . . . 199 | I.13. i75-rfc2145-normative . . . . . . . . . . . . . . . . . 207 | |||
I.14. i58-what-identifies-an-http-resource . . . . . . . . . . 200 | I.14. i82-rel_path-not-used . . . . . . . . . . . . . . . . . 207 | |||
I.15. i51-http-date-vs-rfc1123-date . . . . . . . . . . . . . 200 | I.15. i58-what-identifies-an-http-resource . . . . . . . . . . 208 | |||
I.16. i67-quoting-charsets . . . . . . . . . . . . . . . . . . 200 | I.16. i51-http-date-vs-rfc1123-date . . . . . . . . . . . . . 208 | |||
I.17. media-reg . . . . . . . . . . . . . . . . . . . . . . . 201 | I.17. i73-clarification-of-the-term-deflate . . . . . . . . . 209 | |||
I.18. languagetag . . . . . . . . . . . . . . . . . . . . . . 201 | I.18. i67-quoting-charsets . . . . . . . . . . . . . . . . . . 209 | |||
I.19. i56-6.1.1-can-be-misread-as-a-complete-list . . . . . . 201 | I.19. i20-default-charsets-for-text-media-types . . . . . . . 209 | |||
I.20. i57-status-code-and-reason-phrase . . . . . . . . . . . 202 | I.20. languagetag . . . . . . . . . . . . . . . . . . . . . . 211 | |||
I.21. i59-status-code-registry . . . . . . . . . . . . . . . . 202 | I.21. i85-custom-ranges . . . . . . . . . . . . . . . . . . . 211 | |||
I.22. i21-put-side-effects . . . . . . . . . . . . . . . . . . 202 | I.22. i30-header-lws . . . . . . . . . . . . . . . . . . . . . 212 | |||
I.23. i54-definition-of-1xx-warn-codes . . . . . . . . . . . . 203 | I.23. i77-line-folding . . . . . . . . . . . . . . . . . . . . 212 | |||
I.24. i60-13.5.1-and-13.5.2 . . . . . . . . . . . . . . . . . 203 | I.24. i19-bodies-on-GET . . . . . . . . . . . . . . . . . . . 213 | |||
I.25. i53-allow-is-not-in-13.5.2 . . . . . . . . . . . . . . . 203 | I.25. i28-connection-closing . . . . . . . . . . . . . . . . . 213 | |||
I.26. i25-accept-encoding-bnf . . . . . . . . . . . . . . . . 204 | I.26. i32-options-asterisk . . . . . . . . . . . . . . . . . . 213 | |||
I.27. i61-redirection-vs-location . . . . . . . . . . . . . . 204 | I.27. i83-options-asterisk-and-proxies . . . . . . . . . . . . 214 | |||
I.28. fragment-combination . . . . . . . . . . . . . . . . . . 204 | I.28. i56-6.1.1-can-be-misread-as-a-complete-list . . . . . . 215 | |||
I.29. i55-updating-to-rfc4288 . . . . . . . . . . . . . . . . 205 | I.29. i57-status-code-and-reason-phrase . . . . . . . . . . . 215 | |||
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 | I.30. i59-status-code-registry . . . . . . . . . . . . . . . . 216 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 218 | I.31. i72-request-method-registry . . . . . . . . . . . . . . 216 | |||
Intellectual Property and Copyright Statements . . . . . . . . . 221 | I.32. i21-put-side-effects . . . . . . . . . . . . . . . . . . 216 | |||
I.33. i27-put-idempotency . . . . . . . . . . . . . . . . . . 217 | ||||
I.34. i79-content-headers-vs-put . . . . . . . . . . . . . . . 218 | ||||
I.35. i33-trace-security-considerations . . . . . . . . . . . 218 | ||||
I.36. i69-clarify-requested-variant . . . . . . . . . . . . . 219 | ||||
I.37. i70-cacheability-of-303 . . . . . . . . . . . . . . . . 220 | ||||
I.38. i76-deprecate-305-use-proxy . . . . . . . . . . . . . . 222 | ||||
I.39. i78-relationship-between-401-authorization-and-www-authe 222 | ||||
I.40. i24-requiring-allow-in-405-responses . . . . . . . . . . 223 | ||||
I.41. i81-content-negotiation-for-media-types . . . . . . . . 223 | ||||
I.42. i54-definition-of-1xx-warn-codes . . . . . . . . . . . . 225 | ||||
I.43. i29-age-calculation . . . . . . . . . . . . . . . . . . 225 | ||||
I.44. i71-examples-for-etag-matching . . . . . . . . . . . . . 226 | ||||
I.45. i60-13.5.1-and-13.5.2 . . . . . . . . . . . . . . . . . 227 | ||||
I.46. i53-allow-is-not-in-13.5.2 . . . . . . . . . . . . . . . 227 | ||||
I.47. i37-vary-and-non-existant-headers . . . . . . . . . . . 227 | ||||
I.48. i38-mismatched-vary . . . . . . . . . . . . . . . . . . 228 | ||||
I.49. i39-etag-uniqueness . . . . . . . . . . . . . . . . . . 228 | ||||
I.50. i23-no-store-invalidation . . . . . . . . . . . . . . . 228 | ||||
I.51. i80-content-location-is-not-special . . . . . . . . . . 229 | ||||
I.52. i22-etag-and-other-metadata-in-status-messages . . . . . 230 | ||||
I.53. i61-redirection-vs-location . . . . . . . . . . . . . . 230 | ||||
I.54. fragment-combination . . . . . . . . . . . . . . . . . . 230 | ||||
I.55. i41-security-considerations . . . . . . . . . . . . . . 231 | ||||
I.56. i55-updating-to-rfc4288 . . . . . . . . . . . . . . . . 231 | ||||
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 244 | ||||
Intellectual Property and Copyright Statements . . . . . . . . . 247 | ||||
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 11, line 36 ¶ | skipping to change at page 12, 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 19, line 11 ¶ | skipping to change at page 20, 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 21, line 13 ¶ | skipping to change at page 22, line 13 ¶ | |||
separators) MUST exist between any two tokens (for the definition | separators) MUST exist between any two tokens (for the definition | |||
of "token" below), since they would otherwise be interpreted as a | of "token" below), since they would otherwise be interpreted as a | |||
single token. | single token. | |||
2.2. Basic Rules | 2.2. Basic Rules | |||
The following rules are used throughout this specification to | The following rules are used throughout this specification to | |||
describe basic parsing constructs. The US-ASCII coded character set | describe basic parsing constructs. The US-ASCII coded character set | |||
is defined by ANSI X3.4-1986 [USASCII]. | is defined by ANSI X3.4-1986 [USASCII]. | |||
OCTET = <any 8-bit sequence of data> | OCTET = <any 8-bit sequence of data> | |||
CHAR = <any US-ASCII character (octets 0 - 127)> | CHAR = <any US-ASCII character (octets 0 - 127)> | |||
UPALPHA = <any US-ASCII uppercase letter "A".."Z"> | UPALPHA = <any US-ASCII uppercase letter "A".."Z"> | |||
LOALPHA = <any US-ASCII lowercase letter "a".."z"> | LOALPHA = <any US-ASCII lowercase letter "a".."z"> | |||
ALPHA = UPALPHA | LOALPHA | ALPHA = UPALPHA | LOALPHA | |||
DIGIT = <any US-ASCII digit "0".."9"> | DIGIT = <any US-ASCII digit "0".."9"> | |||
CTL = <any US-ASCII control character | CTL = <any US-ASCII control character | |||
(octets 0 - 31) and DEL (127)> | (octets 0 - 31) and DEL (127)> | |||
CR = <US-ASCII CR, carriage return (13)> | CR = <US-ASCII CR, carriage return (13)> | |||
LF = <US-ASCII LF, linefeed (10)> | LF = <US-ASCII LF, linefeed (10)> | |||
SP = <US-ASCII SP, space (32)> | SP = <US-ASCII SP, space (32)> | |||
HT = <US-ASCII HT, horizontal-tab (9)> | HT = <US-ASCII HT, horizontal-tab (9)> | |||
<"> = <US-ASCII double-quote mark (34)> | <"> = <US-ASCII double-quote mark (34)> | |||
HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all | HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all | |||
protocol elements except the entity-body (see Appendix C for tolerant | protocol elements except the entity-body (see Appendix C for tolerant | |||
applications). The end-of-line marker within an entity-body is | applications). The end-of-line marker within an entity-body is | |||
defined by its associated media type, as described in Section 3.7. | defined by its associated media type, as described in Section 3.7. | |||
CRLF = CR LF | CRLF = CR LF | |||
HTTP/1.1 header field values can be folded onto multiple lines if the | HTTP/1.1 header field values can be folded onto multiple lines if the | |||
continuation line begins with a space or horizontal tab. All linear | continuation line begins with a space or horizontal tab. All linear | |||
white space, including folding, has the same semantics as SP. A | white space, including folding, has the same semantics as SP. A | |||
recipient MAY replace any linear white space with a single SP before | recipient MAY replace any linear white space with a single SP before | |||
interpreting the field value or forwarding the message downstream. | interpreting the field value or forwarding the message downstream. | |||
LWS = [CRLF] 1*( SP | HT ) | LWS = [CRLF] 1*( SP | HT ) | |||
The TEXT rule is only used for descriptive field contents and values | The TEXT rule is only used for descriptive field contents and values | |||
that are not intended to be interpreted by the message parser. Words | that are not intended to be interpreted by the message parser. Words | |||
of *TEXT MAY contain characters from character sets other than ISO- | of *TEXT MAY contain characters from character sets other than ISO- | |||
8859-1 [ISO-8859-1] only when encoded according to the rules of | 8859-1 [ISO-8859-1] only when encoded according to the rules of | |||
[RFC2047]. | [RFC2047]. | |||
TEXT = <any OCTET except CTLs, | TEXT = <any OCTET except CTLs, | |||
but including LWS> | but including LWS> | |||
A CRLF is allowed in the definition of TEXT only as part of a header | A CRLF is allowed in the definition of TEXT only as part of a header | |||
field continuation. It is expected that the folding LWS will be | field continuation. It is expected that the folding LWS will be | |||
replaced with a single SP before interpretation of the TEXT value. | replaced with a single SP before interpretation of the TEXT value. | |||
Hexadecimal numeric characters are used in several protocol elements. | Hexadecimal numeric characters are used in several protocol elements. | |||
HEX = "A" | "B" | "C" | "D" | "E" | "F" | HEX = "A" | "B" | "C" | "D" | "E" | "F" | |||
| "a" | "b" | "c" | "d" | "e" | "f" | DIGIT | | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT | |||
Many HTTP/1.1 header field values consist of words separated by LWS | Many HTTP/1.1 header field values consist of words separated by LWS | |||
or special characters. These special characters MUST be in a quoted | or special characters. These special characters MUST be in a quoted | |||
string to be used within a parameter value (as defined in | string to be used within a parameter value (as defined in | |||
Section 3.6). | Section 3.6). | |||
token = 1*<any CHAR except CTLs or separators> | token = 1*<any CHAR except CTLs or separators> | |||
separators = "(" | ")" | "<" | ">" | "@" | separators = "(" | ")" | "<" | ">" | "@" | |||
| "," | ";" | ":" | "\" | <"> | | "," | ";" | ":" | "\" | <"> | |||
| "/" | "[" | "]" | "?" | "=" | | "/" | "[" | "]" | "?" | "=" | |||
| "{" | "}" | SP | HT | | "{" | "}" | SP | HT | |||
Comments can be included in some HTTP header fields by surrounding | Comments can be included in some HTTP header fields by surrounding | |||
the comment text with parentheses. Comments are only allowed in | the comment text with parentheses. Comments are only allowed in | |||
fields containing "comment" as part of their field value definition. | fields containing "comment" as part of their field value definition. | |||
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 | |||
HTTP uses a "<major>.<minor>" numbering scheme to indicate versions | HTTP uses a "<major>.<minor>" numbering scheme to indicate versions | |||
of the protocol. The protocol versioning policy is intended to allow | of the protocol. The protocol versioning policy is intended to allow | |||
the sender to indicate the format of a message and its capacity for | the sender to indicate the format of a message and its capacity for | |||
understanding further HTTP communication, rather than the features | understanding further HTTP communication, rather than the features | |||
obtained via that communication. No change is made to the version | obtained via that communication. No change is made to the version | |||
skipping to change at page 23, line 26 ¶ | skipping to change at page 24, line 26 ¶ | |||
The <minor> number is incremented when the changes made to the | The <minor> number is incremented when the changes made to the | |||
protocol add features which do not change the general message parsing | protocol add features which do not change the general message parsing | |||
algorithm, but which may add to the message semantics and imply | algorithm, but which may add to the message semantics and imply | |||
additional capabilities of the sender. The <major> number is | additional capabilities of the sender. The <major> number is | |||
incremented when the format of a message within the protocol is | incremented when the format of a message within the protocol is | |||
changed. See [RFC2145] for a fuller explanation. | changed. See [RFC2145] for a fuller explanation. | |||
The version of an HTTP message is indicated by an HTTP-Version field | The version of an HTTP message is indicated by an HTTP-Version field | |||
in the first line of the message. | in the first line of the message. | |||
HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT | HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT | |||
Note that the major and minor numbers MUST be treated as separate | Note that the major and minor numbers MUST be treated as separate | |||
integers and that each MAY be incremented higher than a single digit. | integers and that each MAY be incremented higher than a single digit. | |||
Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is | Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is | |||
lower than HTTP/12.3. Leading zeros MUST be ignored by recipients | lower than HTTP/12.3. Leading zeros MUST be ignored by recipients | |||
and MUST NOT be sent. | and MUST NOT be sent. | |||
An application that sends a request or response message that includes | An application that sends a request or response message that includes | |||
HTTP-Version of "HTTP/1.1" MUST be at least conditionally compliant | HTTP-Version of "HTTP/1.1" MUST be at least conditionally compliant | |||
with this specification. Applications that are at least | with this specification. Applications that are at least | |||
skipping to change at page 24, line 34 ¶ | skipping to change at page 25, 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 | |||
above 255 bytes, because some older client or proxy | above 255 bytes, because some older client or proxy | |||
implementations might not properly support these lengths. | implementations might not properly support these lengths. | |||
3.2.2. http URL | 3.2.2. http URL | |||
The "http" scheme is used to locate network resources via the HTTP | The "http" scheme is used to locate network resources via the HTTP | |||
protocol. This section defines the scheme-specific syntax and | protocol. This section defines the scheme-specific syntax and | |||
semantics for http URLs. | semantics for http URLs. | |||
http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]] | http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]] | |||
If the port is empty or not given, port 80 is assumed. The semantics | If the port is empty or not given, port 80 is assumed. The semantics | |||
are that the identified resource is located at the server listening | are that the identified resource is located at the server listening | |||
for TCP connections on that port of that host, and the Request-URI | for TCP connections on that port of that host, and the Request-URI | |||
for the resource is abs_path (Section 5.1.2). The use of IP | for the resource is abs_path (Section 5.1.2). The use of IP | |||
addresses in URLs SHOULD be avoided whenever possible (see | addresses in URLs SHOULD be avoided whenever possible (see | |||
[RFC1900]). If the abs_path is not present in the URL, it MUST be | [RFC1900]). If the abs_path is not present in the URL, it MUST be | |||
given as "/" when used as a Request-URI for a resource | given as "/" when used as a Request-URI for a resource | |||
(Section 5.1.2). If a proxy receives a host name which is not a | (Section 5.1.2). If a proxy receives a host name which is not a | |||
fully qualified domain name, it MAY add its domain to the host name | fully qualified domain name, it MAY add its domain to the host name | |||
skipping to change at page 26, line 13 ¶ | skipping to change at page 27, 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 | |||
abbreviation for time zone, and MUST be assumed when reading the | abbreviation for time zone, and MUST be assumed when reading the | |||
asctime format. HTTP-date is case sensitive and MUST NOT include | asctime format. HTTP-date is case sensitive and MUST NOT include | |||
additional LWS beyond that specifically included as SP in the | additional LWS beyond that specifically included as SP in the | |||
grammar. | grammar. | |||
HTTP-date = rfc1123-date | rfc850-date | asctime-date | HTTP-date = rfc1123-date | rfc850-date | asctime-date | |||
rfc1123-date = wkday "," SP date1 SP time SP "GMT" | rfc1123-date = wkday "," SP date1 SP time SP "GMT" | |||
rfc850-date = weekday "," SP date2 SP time SP "GMT" | rfc850-date = weekday "," SP date2 SP time SP "GMT" | |||
asctime-date = wkday SP date3 SP time SP 4DIGIT | asctime-date = wkday SP date3 SP time SP 4DIGIT | |||
date1 = 2DIGIT SP month SP 4DIGIT | date1 = 2DIGIT SP month SP 4DIGIT | |||
; day month year (e.g., 02 Jun 1982) | ; day month year (e.g., 02 Jun 1982) | |||
date2 = 2DIGIT "-" month "-" 2DIGIT | date2 = 2DIGIT "-" month "-" 2DIGIT | |||
; day-month-year (e.g., 02-Jun-82) | ; day-month-year (e.g., 02-Jun-82) | |||
date3 = month SP ( 2DIGIT | ( SP 1DIGIT )) | date3 = month SP ( 2DIGIT | ( SP 1DIGIT )) | |||
; month day (e.g., Jun 2) | ; month day (e.g., Jun 2) | |||
time = 2DIGIT ":" 2DIGIT ":" 2DIGIT | time = 2DIGIT ":" 2DIGIT ":" 2DIGIT | |||
; 00:00:00 - 23:59:59 | ; 00:00:00 - 23:59:59 | |||
wkday = "Mon" | "Tue" | "Wed" | wkday = "Mon" | "Tue" | "Wed" | |||
| "Thu" | "Fri" | "Sat" | "Sun" | | "Thu" | "Fri" | "Sat" | "Sun" | |||
weekday = "Monday" | "Tuesday" | "Wednesday" | weekday = "Monday" | "Tuesday" | "Wednesday" | |||
| "Thursday" | "Friday" | "Saturday" | "Sunday" | | "Thursday" | "Friday" | "Saturday" | "Sunday" | |||
month = "Jan" | "Feb" | "Mar" | "Apr" | month = "Jan" | "Feb" | "Mar" | "Apr" | |||
| "May" | "Jun" | "Jul" | "Aug" | | "May" | "Jun" | "Jul" | "Aug" | |||
| "Sep" | "Oct" | "Nov" | "Dec" | | "Sep" | "Oct" | "Nov" | "Dec" | |||
Note: HTTP requirements for the date/time stamp format apply only to | Note: HTTP requirements for the date/time stamp format apply only to | |||
their usage within the protocol stream. Clients and servers are not | their usage within the protocol stream. Clients and servers are not | |||
required to use these formats for user presentation, request logging, | required to use these formats for user presentation, request logging, | |||
etc. | etc. | |||
3.3.2. Delta Seconds | 3.3.2. Delta Seconds | |||
Some HTTP header fields allow a time value to be specified as an | Some HTTP header fields allow a time value to be specified as an | |||
integer number of seconds, represented in decimal, after the time | integer number of seconds, represented in decimal, after the time | |||
that the message was received. | that the message was received. | |||
delta-seconds = 1*DIGIT | delta-seconds = 1*DIGIT | |||
3.4. Character Sets | 3.4. Character Sets | |||
HTTP uses the same definition of the term "character set" as that | HTTP uses the same definition of the term "character set" as that | |||
described for MIME: | described for MIME: | |||
The term "character set" is used in this document to refer to a | The term "character set" is used in this document to refer to a | |||
method used with one or more tables to convert a sequence of octets | method used with one or more tables to convert a sequence of octets | |||
into a sequence of characters. Note that unconditional conversion in | into a sequence of characters. Note that unconditional conversion in | |||
the other direction is not required, in that not all characters may | the other direction is not required, in that not all characters may | |||
skipping to change at page 28, line 17 ¶ | skipping to change at page 29, line 17 ¶ | |||
Note: This use of the term "character set" is more commonly | Note: This use of the term "character set" is more commonly | |||
referred to as a "character encoding." However, since HTTP and | referred to as a "character encoding." However, since HTTP and | |||
MIME share the same registry, it is important that the terminology | MIME share the same registry, it is important that the terminology | |||
also be shared. | also be shared. | |||
HTTP character sets are identified by case-insensitive tokens. The | HTTP character sets are identified by case-insensitive tokens. The | |||
complete set of tokens is defined by the IANA Character Set registry | complete set of tokens is defined by the IANA Character Set registry | |||
(<http://www.iana.org/assignments/character-sets>). | (<http://www.iana.org/assignments/character-sets>). | |||
charset = token | charset = token | |||
Although HTTP allows an arbitrary token to be used as a charset | Although HTTP allows an arbitrary token to be used as a charset | |||
value, any token that has a predefined value within the IANA | value, any token that has a predefined value within the IANA | |||
Character Set registry MUST represent the character set defined by | Character Set registry MUST represent the character set defined by | |||
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 29, line 14 ¶ | skipping to change at page 30, line 14 ¶ | |||
3.5. Content Codings | 3.5. Content Codings | |||
Content coding values indicate an encoding transformation that has | Content coding values indicate an encoding transformation that has | |||
been or can be applied to an entity. Content codings are primarily | been or can be applied to an entity. Content codings are primarily | |||
used to allow a document to be compressed or otherwise usefully | used to allow a document to be compressed or otherwise usefully | |||
transformed without losing the identity of its underlying media type | transformed without losing the identity of its underlying media type | |||
and without loss of information. Frequently, the entity is stored in | and without loss of information. Frequently, the entity is stored in | |||
coded form, transmitted directly, and only decoded by the recipient. | coded form, transmitted directly, and only decoded by the recipient. | |||
content-coding = token | content-coding = token | |||
All content-coding values are case-insensitive. HTTP/1.1 uses | All content-coding values are case-insensitive. HTTP/1.1 uses | |||
content-coding values in the Accept-Encoding (Section 14.3) and | content-coding values in the Accept-Encoding (Section 14.3) and | |||
Content-Encoding (Section 14.11) header fields. Although the value | Content-Encoding (Section 14.11) header fields. Although the value | |||
describes the content-coding, what is more important is that it | describes the content-coding, what is more important is that it | |||
indicates what decoding mechanism will be required to remove the | indicates what decoding mechanism will be required to remove the | |||
encoding. | encoding. | |||
The Internet Assigned Numbers Authority (IANA) acts as a registry for | The Internet Assigned Numbers Authority (IANA) acts as a registry for | |||
content-coding value tokens. Initially, the registry contains the | content-coding value tokens. Initially, the registry contains the | |||
skipping to change at page 30, line 23 ¶ | skipping to change at page 31, line 23 ¶ | |||
conform to the purpose of content coding defined in this section. | conform to the purpose of content coding defined in this section. | |||
3.6. Transfer Codings | 3.6. Transfer Codings | |||
Transfer-coding values are used to indicate an encoding | Transfer-coding values are used to indicate an encoding | |||
transformation that has been, can be, or may need to be applied to an | transformation that has been, can be, or may need to be applied to an | |||
entity-body in order to ensure "safe transport" through the network. | entity-body in order to ensure "safe transport" through the network. | |||
This differs from a content coding in that the transfer-coding is a | This differs from a content coding in that the transfer-coding is a | |||
property of the message, not of the original entity. | property of the message, not of the original entity. | |||
transfer-coding = "chunked" | transfer-extension | transfer-coding = "chunked" | transfer-extension | |||
transfer-extension = token *( ";" parameter ) | transfer-extension = token *( ";" parameter ) | |||
Parameters are in the form of attribute/value pairs. | Parameters are in the form of attribute/value pairs. | |||
parameter = attribute "=" value | parameter = attribute "=" value | |||
attribute = token | attribute = token | |||
value = token | quoted-string | value = token | quoted-string | |||
All transfer-coding values are case-insensitive. HTTP/1.1 uses | All transfer-coding values are case-insensitive. HTTP/1.1 uses | |||
transfer-coding values in the TE header field (Section 14.39) and in | transfer-coding values in the TE header field (Section 14.39) and in | |||
the Transfer-Encoding header field (Section 14.41). | the Transfer-Encoding header field (Section 14.41). | |||
Whenever a transfer-coding is applied to a message-body, the set of | Whenever a transfer-coding is applied to a message-body, the set of | |||
transfer-codings MUST include "chunked", unless the message is | transfer-codings MUST include "chunked", unless the message is | |||
terminated by closing the connection. When the "chunked" transfer- | terminated by closing the connection. When the "chunked" transfer- | |||
coding is used, it MUST be the last transfer-coding applied to the | coding is used, it MUST be the last transfer-coding applied to the | |||
message-body. The "chunked" transfer-coding MUST NOT be applied more | message-body. The "chunked" transfer-coding MUST NOT be applied more | |||
skipping to change at page 31, line 14 ¶ | skipping to change at page 32, 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 | |||
received the full message. | received the full message. | |||
Chunked-Body = *chunk | Chunked-Body = *chunk | |||
last-chunk | last-chunk | |||
trailer | trailer | |||
CRLF | CRLF | |||
chunk = chunk-size [ chunk-extension ] CRLF | chunk = chunk-size [ chunk-extension ] CRLF | |||
chunk-data CRLF | chunk-data CRLF | |||
chunk-size = 1*HEX | chunk-size = 1*HEX | |||
last-chunk = 1*("0") [ chunk-extension ] CRLF | last-chunk = 1*("0") [ chunk-extension ] CRLF | |||
chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] ) | chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] ) | |||
chunk-ext-name = token | chunk-ext-name = token | |||
chunk-ext-val = token | quoted-string | chunk-ext-val = token | quoted-string | |||
chunk-data = chunk-size(OCTET) | chunk-data = chunk-size(OCTET) | |||
trailer = *(entity-header CRLF) | trailer = *(entity-header CRLF) | |||
The chunk-size field is a string of hex digits indicating the size of | The chunk-size field is a string of hex digits indicating the size of | |||
the chunk-data in octets. The chunked encoding is ended by any chunk | the chunk-data in octets. The chunked encoding is ended by any chunk | |||
whose size is zero, followed by the trailer, which is terminated by | whose size is zero, followed by the trailer, which is terminated by | |||
an empty line. | an empty line. | |||
The trailer allows the sender to include additional HTTP header | The trailer allows the sender to include additional HTTP header | |||
fields at the end of the message. The Trailer header field can be | fields at the end of the message. The Trailer header field can be | |||
used to indicate which header fields are included in a trailer (see | used to indicate which header fields are included in a trailer (see | |||
Section 14.40). | Section 14.40). | |||
skipping to change at page 32, line 36 ¶ | skipping to change at page 33, 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). | |||
The type, subtype, and parameter attribute names are case- | The type, subtype, and parameter attribute names are case- | |||
insensitive. Parameter values might or might not be case-sensitive, | insensitive. Parameter values might or might not be case-sensitive, | |||
depending on the semantics of the parameter name. Linear white space | depending on the semantics of the parameter name. Linear white space | |||
(LWS) MUST NOT be used between the type and subtype, nor between an | (LWS) MUST NOT be used between the type and subtype, nor between an | |||
attribute and its value. The presence or absence of a parameter | attribute and its value. The presence or absence of a parameter | |||
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 34, line 33 ¶ | skipping to change at page 35, 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. | |||
product = token ["/" product-version] | product = token ["/" product-version] | |||
product-version = token | product-version = token | |||
Examples: | Examples: | |||
User-Agent: CERN-LineMode/2.15 libwww/2.17b3 | User-Agent: CERN-LineMode/2.15 libwww/2.17b3 | |||
Server: Apache/0.8.4 | Server: Apache/0.8.4 | |||
Product tokens SHOULD be short and to the point. They MUST NOT be | Product tokens SHOULD be short and to the point. They MUST NOT be | |||
used for advertising or other non-essential information. Although | used for advertising or other non-essential information. Although | |||
any token character MAY appear in a product-version, this token | any token character MAY appear in a product-version, this token | |||
SHOULD only be used for a version identifier (i.e., successive | SHOULD only be used for a version identifier (i.e., successive | |||
skipping to change at page 35, line 24 ¶ | skipping to change at page 36, line 24 ¶ | |||
HTTP content negotiation (Section 12) uses short "floating point" | HTTP content negotiation (Section 12) uses short "floating point" | |||
numbers to indicate the relative importance ("weight") of various | numbers to indicate the relative importance ("weight") of various | |||
negotiable parameters. A weight is normalized to a real number in | negotiable parameters. A weight is normalized to a real number in | |||
the range 0 through 1, where 0 is the minimum and 1 the maximum | the range 0 through 1, where 0 is the minimum and 1 the maximum | |||
value. If a parameter has a quality value of 0, then content with | value. If a parameter has a quality value of 0, then content with | |||
this parameter is `not acceptable' for the client. HTTP/1.1 | this parameter is `not acceptable' for the client. HTTP/1.1 | |||
applications MUST NOT generate more than three digits after the | applications MUST NOT generate more than three digits after the | |||
decimal point. User configuration of these values SHOULD also be | decimal point. User configuration of these values SHOULD also be | |||
limited in this fashion. | limited in this fashion. | |||
qvalue = ( "0" [ "." 0*3DIGIT ] ) | qvalue = ( "0" [ "." 0*3DIGIT ] ) | |||
| ( "1" [ "." 0*3("0") ] ) | | ( "1" [ "." 0*3("0") ] ) | |||
"Quality values" is a misnomer, since these values merely represent | "Quality values" is a misnomer, since these values merely represent | |||
relative degradation in desired quality. | relative degradation in desired quality. | |||
3.10. Language Tags | 3.10. Language Tags | |||
A language tag identifies a natural language spoken, written, or | A language tag identifies a natural language spoken, written, or | |||
otherwise conveyed by human beings for communication of information | otherwise conveyed by human beings for communication of information | |||
to other human beings. Computer languages are explicitly excluded. | to other human beings. Computer languages are explicitly excluded. | |||
HTTP uses language tags within the Accept-Language and Content- | HTTP uses language tags within the Accept-Language and Content- | |||
Language fields. | Language fields. | |||
The syntax and registry of HTTP language tags is the same as that | The syntax and registry of HTTP language tags is the same as that | |||
defined by [RFC1766]. In summary, a language tag is composed of 1 or | defined by [RFC1766]. In summary, a language tag is composed of 1 or | |||
more parts: A primary language tag and a possibly empty series of | more parts: A primary language tag and a possibly empty series of | |||
subtags: | subtags: | |||
language-tag = primary-tag *( "-" subtag ) | language-tag = primary-tag *( "-" subtag ) | |||
primary-tag = 1*8ALPHA | primary-tag = 1*8ALPHA | |||
subtag = 1*8ALPHA | subtag = 1*8ALPHA | |||
White space is not allowed within the tag and all tags are case- | White space is not allowed within the tag and all tags are case- | |||
insensitive. The name space of language tags is administered by the | insensitive. The name space of language tags is administered by the | |||
IANA. Example tags include: | IANA. Example tags include: | |||
en, en-US, en-cockney, i-cherokee, x-pig-latin | en, en-US, en-cockney, i-cherokee, x-pig-latin | |||
where any two-letter primary-tag is an ISO-639 language abbreviation | where any two-letter primary-tag is an ISO-639 language abbreviation | |||
and any two-letter initial subtag is an ISO-3166 country code. (The | and any two-letter initial subtag is an ISO-3166 country code. (The | |||
last three tags above are not registered tags; all but the last are | last three tags above are not registered tags; all but the last are | |||
skipping to change at page 36, line 20 ¶ | skipping to change at page 37, line 20 ¶ | |||
3.11. Entity Tags | 3.11. Entity Tags | |||
Entity tags are used for comparing two or more entities from the same | Entity tags are used for comparing two or more entities from the same | |||
requested resource. HTTP/1.1 uses entity tags in the ETag | requested resource. HTTP/1.1 uses entity tags in the ETag | |||
(Section 14.19), If-Match (Section 14.24), If-None-Match | (Section 14.19), If-Match (Section 14.24), If-None-Match | |||
(Section 14.26), and If-Range (Section 14.27) header fields. The | (Section 14.26), and If-Range (Section 14.27) header fields. The | |||
definition of how they are used and compared as cache validators is | definition of how they are used and compared as cache validators is | |||
in Section 13.3.3. An entity tag consists of an opaque quoted | in Section 13.3.3. An entity tag consists of an opaque quoted | |||
string, possibly prefixed by a weakness indicator. | string, possibly prefixed by a weakness indicator. | |||
entity-tag = [ weak ] opaque-tag | entity-tag = [ weak ] opaque-tag | |||
weak = "W/" | weak = "W/" | |||
opaque-tag = quoted-string | opaque-tag = quoted-string | |||
A "strong entity tag" MAY be shared by two entities of a resource | A "strong entity tag" MAY be shared by two entities of a resource | |||
only if they are equivalent by octet equality. | only if they are equivalent by octet equality. | |||
A "weak entity tag," indicated by the "W/" prefix, MAY be shared by | A "weak entity tag," indicated by the "W/" prefix, MAY be shared by | |||
two entities of a resource only if the entities are equivalent and | two entities of a resource only if the entities are equivalent and | |||
could be substituted for each other with no significant change in | could be substituted for each other with no significant change in | |||
semantics. A weak entity tag can only be used for weak comparison. | semantics. A weak entity tag can only be used for weak comparison. | |||
An entity tag MUST be unique across all versions of all entities | An entity tag MUST be unique across all versions of all entities | |||
skipping to change at page 36, line 47 ¶ | skipping to change at page 37, line 47 ¶ | |||
entities. | entities. | |||
3.12. Range Units | 3.12. Range Units | |||
HTTP/1.1 allows a client to request that only part (a range of) the | HTTP/1.1 allows a client to request that only part (a range of) the | |||
response entity be included within the response. HTTP/1.1 uses range | response entity be included within the response. HTTP/1.1 uses range | |||
units in the Range (Section 14.35) and Content-Range (Section 14.16) | units in the Range (Section 14.35) and Content-Range (Section 14.16) | |||
header fields. An entity can be broken down into subranges according | header fields. An entity can be broken down into subranges according | |||
to various structural units. | to various structural units. | |||
range-unit = bytes-unit | other-range-unit | range-unit = bytes-unit | other-range-unit | |||
bytes-unit = "bytes" | bytes-unit = "bytes" | |||
other-range-unit = token | other-range-unit = token | |||
The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1 | The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1 | |||
implementations MAY ignore ranges specified using other units. | implementations MAY ignore ranges specified using other units. | |||
HTTP/1.1 has been designed to allow implementations of applications | HTTP/1.1 has been designed to allow implementations of applications | |||
that do not depend on knowledge of ranges. | that do not depend on knowledge of ranges. | |||
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 | |||
In the interest of robustness, servers SHOULD ignore any empty | In the interest of robustness, servers SHOULD ignore any empty | |||
line(s) received where a Request-Line is expected. In other words, | line(s) received where a Request-Line is expected. In other words, | |||
if the server is reading the protocol stream at the beginning of a | if the server is reading the protocol stream at the beginning of a | |||
message and receives a CRLF first, it should ignore the CRLF. | message and receives a CRLF first, it should ignore the CRLF. | |||
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 | |||
field-value = *( field-content | LWS ) | field-value = *( field-content | LWS ) | |||
field-content = <the OCTETs making up the field-value | field-content = <the OCTETs making up the field-value | |||
and consisting of either *TEXT or combinations | and consisting of either *TEXT or combinations | |||
of token, separators, and quoted-string> | of token, separators, and quoted-string> | |||
The field-content does not include any leading or trailing LWS: | The field-content does not include any leading or trailing LWS: | |||
linear white space occurring before the first non-whitespace | linear white space occurring before the first non-whitespace | |||
character of the field-value or after the last non-whitespace | character of the field-value or after the last non-whitespace | |||
character of the field-value. Such leading or trailing LWS MAY be | character of the field-value. Such leading or trailing LWS MAY be | |||
removed without changing the semantics of the field value. Any LWS | removed without changing the semantics of the field value. Any LWS | |||
that occurs between field-content MAY be replaced with a single SP | that occurs between field-content MAY be replaced with a single SP | |||
before interpreting the field value or forwarding the message | before interpreting the field value or forwarding the message | |||
downstream. | downstream. | |||
skipping to change at page 39, line 45 ¶ | skipping to change at page 40, line 45 ¶ | |||
change the order of these field values when a message is forwarded. | change the order of these field values when a message is forwarded. | |||
4.3. Message Body | 4.3. Message Body | |||
The message-body (if any) of an HTTP message is used to carry the | The message-body (if any) of an HTTP message is used to carry the | |||
entity-body associated with the request or response. The message- | entity-body associated with the request or response. The message- | |||
body differs from the entity-body only when a transfer-coding has | body differs from the entity-body only when a transfer-coding has | |||
been applied, as indicated by the Transfer-Encoding header field | been applied, as indicated by the Transfer-Encoding header field | |||
(Section 14.41). | (Section 14.41). | |||
message-body = entity-body | message-body = entity-body | |||
| <entity-body encoded as per Transfer-Encoding> | | <entity-body encoded as per Transfer-Encoding> | |||
Transfer-Encoding MUST be used to indicate any transfer-codings | Transfer-Encoding MUST be used to indicate any transfer-codings | |||
applied by an application to ensure safe and proper transfer of the | applied by an application to ensure safe and proper transfer of the | |||
message. Transfer-Encoding is a property of the message, not of the | message. Transfer-Encoding is a property of the message, not of the | |||
entity, and thus MAY be added or removed by any application along the | entity, and thus MAY be added or removed by any application along the | |||
request/response chain. (However, Section 3.6 places restrictions on | request/response chain. (However, Section 3.6 places restrictions on | |||
when certain transfer-codings may be used.) | when certain transfer-codings may be used.) | |||
The rules for when a message-body is allowed in a message differ for | The rules for when a message-body is allowed in a message differ for | |||
requests and responses. | requests and responses. | |||
skipping to change at page 40, line 23 ¶ | skipping to change at page 41, 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 41, line 28 ¶ | skipping to change at page 42, 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 42, line 5 ¶ | skipping to change at page 43, line 5 ¶ | |||
the message-body. HTTP/1.1 user agents MUST notify the user when an | the message-body. HTTP/1.1 user agents MUST notify the user when an | |||
invalid length is received and detected. | invalid length is received and detected. | |||
4.5. General Header Fields | 4.5. General Header Fields | |||
There are a few header fields which have general applicability for | There are a few header fields which have general applicability for | |||
both request and response messages, but which do not apply to the | both request and response messages, but which do not apply to the | |||
entity being transferred. These header fields apply only to the | entity being transferred. These header fields apply only to the | |||
message being transmitted. | message being transmitted. | |||
general-header = Cache-Control ; Section 14.9 | general-header = Cache-Control ; Section 14.9 | |||
| Connection ; Section 14.10 | | Connection ; Section 14.10 | |||
| Date ; Section 14.18 | | Date ; Section 14.18 | |||
| Pragma ; Section 14.32 | | Pragma ; Section 14.32 | |||
| Trailer ; Section 14.40 | | Trailer ; Section 14.40 | |||
| Transfer-Encoding ; Section 14.41 | | Transfer-Encoding ; Section 14.41 | |||
| Upgrade ; Section 14.42 | | Upgrade ; Section 14.42 | |||
| Via ; Section 14.45 | | Via ; Section 14.45 | |||
| Warning ; Section 14.46 | | Warning ; Section 14.46 | |||
General-header field names can be extended reliably only in | General-header field names can be extended reliably only in | |||
combination with a change in the protocol version. However, new or | combination with a change in the protocol version. However, new or | |||
experimental header fields may be given the semantics of general | experimental header fields may be given the semantics of general | |||
header fields if all parties in the communication recognize them to | header fields if all parties in the communication recognize them to | |||
be general-header fields. Unrecognized header fields are treated as | be general-header fields. Unrecognized header fields are treated as | |||
entity-header fields. | entity-header fields. | |||
5. Request | 5. Request | |||
A request message from a client to a server includes, within the | A request message from a client to a server includes, within the | |||
first line of that message, the method to be applied to the resource, | first line of that message, the method to be applied to the resource, | |||
the identifier of the resource, and the protocol version in use. | the identifier of the resource, and the protocol version in use. | |||
Request = Request-Line ; Section 5.1 | Request = Request-Line ; Section 5.1 | |||
*(( general-header ; Section 4.5 | *(( general-header ; Section 4.5 | |||
| request-header ; Section 5.3 | | request-header ; Section 5.3 | |||
| entity-header ) CRLF) ; Section 7.1 | | entity-header ) CRLF) ; Section 7.1 | |||
CRLF | CRLF | |||
[ message-body ] ; Section 4.3 | [ message-body ] ; Section 4.3 | |||
5.1. Request-Line | 5.1. Request-Line | |||
The Request-Line begins with a method token, followed by the Request- | The Request-Line begins with a method token, followed by the Request- | |||
URI and the protocol version, and ending with CRLF. The elements are | URI and the protocol version, and ending with CRLF. The elements are | |||
separated by SP characters. No CR or LF is allowed except in the | separated by SP characters. No CR or LF is allowed except in the | |||
final CRLF sequence. | final CRLF sequence. | |||
Request-Line = Method SP Request-URI SP HTTP-Version CRLF | Request-Line = Method SP Request-URI SP HTTP-Version CRLF | |||
5.1.1. Method | 5.1.1. Method | |||
The Method token indicates the method to be performed on the resource | The Method token indicates the method to be performed on the resource | |||
identified by the Request-URI. The method is case-sensitive. | identified by the Request-URI. The method is case-sensitive. | |||
Method = "OPTIONS" ; Section 9.2 | Method = "OPTIONS" ; Section 9.2 | |||
| "GET" ; Section 9.3 | | "GET" ; Section 9.3 | |||
| "HEAD" ; Section 9.4 | | "HEAD" ; Section 9.4 | |||
| "POST" ; Section 9.5 | | "POST" ; Section 9.5 | |||
| "PUT" ; Section 9.6 | | "PUT" ; Section 9.6 | |||
| "DELETE" ; Section 9.7 | | "DELETE" ; Section 9.7 | |||
| "TRACE" ; Section 9.8 | | "TRACE" ; Section 9.8 | |||
| "CONNECT" ; Section 9.9 | | "CONNECT" ; Section 9.9 | |||
| extension-method | | extension-method | |||
extension-method = token | extension-method = token | |||
The list of methods allowed by a resource can be specified in an | The list of methods allowed by a resource can be specified in an | |||
Allow header field (Section 14.7). The return code of the response | Allow header field (Section 14.7). The return code of the response | |||
always notifies the client whether a method is currently allowed on a | always notifies the client whether a method is currently allowed on a | |||
resource, since the set of allowed methods can change dynamically. | resource, since the set of allowed methods can change dynamically. | |||
An origin server SHOULD return the status code 405 (Method Not | An origin server SHOULD return the status code 405 (Method Not | |||
Allowed) if the method is known by the origin server but not allowed | Allowed) if the method is known by the origin server but not allowed | |||
for the requested resource, and 501 (Not Implemented) if the method | for the requested resource, and 501 (Not Implemented) if the method | |||
is unrecognized or not implemented by the origin server. The methods | is unrecognized or not implemented by the origin server. The methods | |||
GET and HEAD MUST be supported by all general-purpose servers. All | GET and HEAD MUST be supported by all general-purpose servers. All | |||
other methods are OPTIONAL; however, if the above methods are | other methods are OPTIONAL; however, if the above methods are | |||
implemented, they MUST be implemented with the same semantics as | implemented, they MUST be implemented with the same semantics as | |||
those specified in Section 9. | those specified in Section 9. | |||
5.1.2. Request-URI | 5.1.2. Request-URI | |||
The Request-URI is a Uniform Resource Identifier (Section 3.2) and | The Request-URI is a Uniform Resource Identifier (Section 3.2) and | |||
identifies the resource upon which to apply the request. | identifies the resource upon which to apply the request. | |||
Request-URI = "*" | Request-URI = "*" | |||
| absoluteURI | | absoluteURI | |||
| abs_path [ "?" query ] | | abs_path [ "?" query ] | |||
| authority | | authority | |||
The four options for Request-URI are dependent on the nature of the | The four options for Request-URI are dependent on the nature of the | |||
request. The asterisk "*" means that the request does not apply to a | request. The asterisk "*" means that the request does not apply to a | |||
particular resource, but to the server itself, and is only allowed | particular resource, but to the server itself, and is only allowed | |||
when the method used does not necessarily apply to a resource. One | when the method used does not necessarily apply to a resource. One | |||
example would be | example would be | |||
OPTIONS * HTTP/1.1 | OPTIONS * HTTP/1.1 | |||
The absoluteURI form is REQUIRED when the request is being made to a | The absoluteURI form is REQUIRED when the request is being made to a | |||
skipping to change at page 46, line 19 ¶ | skipping to change at page 47, line 19 ¶ | |||
exact resource is being requested. | exact resource is being requested. | |||
5.3. Request Header Fields | 5.3. Request Header Fields | |||
The request-header fields allow the client to pass additional | The request-header fields allow the client to pass additional | |||
information about the request, and about the client itself, to the | information about the request, and about the client itself, to the | |||
server. These fields act as request modifiers, with semantics | server. These fields act as request modifiers, with semantics | |||
equivalent to the parameters on a programming language method | equivalent to the parameters on a programming language method | |||
invocation. | invocation. | |||
request-header = Accept ; Section 14.1 | request-header = Accept ; Section 14.1 | |||
| Accept-Charset ; Section 14.2 | | Accept-Charset ; Section 14.2 | |||
| Accept-Encoding ; Section 14.3 | | Accept-Encoding ; Section 14.3 | |||
| Accept-Language ; Section 14.4 | | Accept-Language ; Section 14.4 | |||
| Authorization ; Section 14.8 | | Authorization ; Section 14.8 | |||
| Expect ; Section 14.20 | | Expect ; Section 14.20 | |||
| From ; Section 14.22 | | From ; Section 14.22 | |||
| Host ; Section 14.23 | | Host ; Section 14.23 | |||
| If-Match ; Section 14.24 | | If-Match ; Section 14.24 | |||
| If-Modified-Since ; Section 14.25 | | If-Modified-Since ; Section 14.25 | |||
| If-None-Match ; Section 14.26 | | If-None-Match ; Section 14.26 | |||
| If-Range ; Section 14.27 | | If-Range ; Section 14.27 | |||
| If-Unmodified-Since ; Section 14.28 | | If-Unmodified-Since ; Section 14.28 | |||
| Max-Forwards ; Section 14.31 | | Max-Forwards ; Section 14.31 | |||
| Proxy-Authorization ; Section 14.34 | | Proxy-Authorization ; Section 14.34 | |||
| Range ; Section 14.35 | | Range ; Section 14.35 | |||
| Referer ; Section 14.36 | | Referer ; Section 14.36 | |||
| TE ; Section 14.39 | | TE ; Section 14.39 | |||
| User-Agent ; Section 14.43 | | User-Agent ; Section 14.43 | |||
Request-header field names can be extended reliably only in | Request-header field names can be extended reliably only in | |||
combination with a change in the protocol version. However, new or | combination with a change in the protocol version. However, new or | |||
experimental header fields MAY be given the semantics of request- | experimental header fields MAY be given the semantics of request- | |||
header fields if all parties in the communication recognize them to | header fields if all parties in the communication recognize them to | |||
be request-header fields. Unrecognized header fields are treated as | be request-header fields. Unrecognized header fields are treated as | |||
entity-header fields. | entity-header fields. | |||
6. Response | 6. Response | |||
After receiving and interpreting a request message, a server responds | After receiving and interpreting a request message, a server responds | |||
with an HTTP response message. | with an HTTP response message. | |||
Response = Status-Line ; Section 6.1 | Response = Status-Line ; Section 6.1 | |||
*(( general-header ; Section 4.5 | *(( general-header ; Section 4.5 | |||
| response-header ; Section 6.2 | | response-header ; Section 6.2 | |||
| entity-header ) CRLF) ; Section 7.1 | | entity-header ) CRLF) ; Section 7.1 | |||
CRLF | CRLF | |||
[ message-body ] ; Section 7.2 | [ message-body ] ; Section 7.2 | |||
6.1. Status-Line | 6.1. Status-Line | |||
The first line of a Response message is the Status-Line, consisting | The first line of a Response message is the Status-Line, consisting | |||
of the protocol version followed by a numeric status code and its | of the protocol version followed by a numeric status code and its | |||
associated textual phrase, with each element separated by SP | associated textual phrase, with each element separated by SP | |||
characters. No CR or LF is allowed except in the final CRLF | characters. No CR or LF is allowed except in the final CRLF | |||
sequence. | sequence. | |||
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF | Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF | |||
6.1.1. Status Code and Reason Phrase | 6.1.1. Status Code and Reason Phrase | |||
The Status-Code element is a 3-digit integer result code of the | The Status-Code element is a 3-digit integer result code of the | |||
attempt to understand and satisfy the request. These codes are fully | attempt to understand and satisfy the request. These codes are fully | |||
defined in Section 10. The Reason-Phrase is intended to give a short | defined in Section 10. The Reason-Phrase is intended to give a short | |||
textual description of the Status-Code. The Status-Code is intended | textual description of the Status-Code. The Status-Code is intended | |||
for use by automata and the Reason-Phrase is intended for the human | for use by automata and the Reason-Phrase is intended for the human | |||
user. The client is not required to examine or display the Reason- | user. The client is not required to examine or display the Reason- | |||
Phrase. | Phrase. | |||
skipping to change at page 49, line 5 ¶ | skipping to change at page 50, line 5 ¶ | |||
o 5xx: Server Error - The server failed to fulfill an apparently | o 5xx: Server Error - The server failed to fulfill an apparently | |||
valid request | valid request | |||
The individual values of the numeric status codes defined for | The individual values of the numeric status codes defined for | |||
HTTP/1.1, and an example set of corresponding Reason-Phrase's, are | HTTP/1.1, and an example set of corresponding Reason-Phrase's, are | |||
presented below. The reason phrases listed here are only | presented below. The reason phrases listed here are only | |||
recommendations -- they MAY be replaced by local equivalents without | recommendations -- they MAY be replaced by local equivalents without | |||
affecting the protocol. | affecting the protocol. | |||
Status-Code = | Status-Code = | |||
"100" ; Section 10.1.1: Continue | "100" ; Section 10.1.1: Continue | |||
| "101" ; Section 10.1.2: Switching Protocols | | "101" ; Section 10.1.2: Switching Protocols | |||
| "200" ; Section 10.2.1: OK | | "200" ; Section 10.2.1: OK | |||
| "201" ; Section 10.2.2: Created | | "201" ; Section 10.2.2: Created | |||
| "202" ; Section 10.2.3: Accepted | | "202" ; Section 10.2.3: Accepted | |||
| "203" ; Section 10.2.4: Non-Authoritative Information | | "203" ; Section 10.2.4: Non-Authoritative Information | |||
| "204" ; Section 10.2.5: No Content | | "204" ; Section 10.2.5: No Content | |||
| "205" ; Section 10.2.6: Reset Content | | "205" ; Section 10.2.6: Reset Content | |||
| "206" ; Section 10.2.7: Partial Content | | "206" ; Section 10.2.7: Partial Content | |||
| "300" ; Section 10.3.1: Multiple Choices | | "300" ; Section 10.3.1: Multiple Choices | |||
| "301" ; Section 10.3.2: Moved Permanently | | "301" ; Section 10.3.2: Moved Permanently | |||
| "302" ; Section 10.3.3: Found | | "302" ; Section 10.3.3: Found | |||
| "303" ; Section 10.3.4: See Other | | "303" ; Section 10.3.4: See Other | |||
| "304" ; Section 10.3.5: Not Modified | | "304" ; Section 10.3.5: Not Modified | |||
| "305" ; Section 10.3.6: Use Proxy | | "305" ; Section 10.3.6: Use Proxy | |||
| "307" ; Section 10.3.8: Temporary Redirect | | "307" ; Section 10.3.8: Temporary Redirect | |||
| "400" ; Section 10.4.1: Bad Request | | "400" ; Section 10.4.1: Bad Request | |||
| "401" ; Section 10.4.2: Unauthorized | | "401" ; Section 10.4.2: Unauthorized | |||
| "402" ; Section 10.4.3: Payment Required | | "402" ; Section 10.4.3: Payment Required | |||
| "403" ; Section 10.4.4: Forbidden | | "403" ; Section 10.4.4: Forbidden | |||
| "404" ; Section 10.4.5: Not Found | | "404" ; Section 10.4.5: Not Found | |||
| "405" ; Section 10.4.6: Method Not Allowed | | "405" ; Section 10.4.6: Method Not Allowed | |||
| "406" ; Section 10.4.7: Not Acceptable | | "406" ; Section 10.4.7: Not Acceptable | |||
| "407" ; Section 10.4.8: Proxy Authentication Required | | "407" ; Section 10.4.8: Proxy Authentication Required | |||
| "408" ; Section 10.4.9: Request Time-out | | "408" ; Section 10.4.9: Request Time-out | |||
| "409" ; Section 10.4.10: Conflict | | "409" ; Section 10.4.10: Conflict | |||
| "410" ; Section 10.4.11: Gone | | "410" ; Section 10.4.11: Gone | |||
| "411" ; Section 10.4.12: Length Required | | "411" ; Section 10.4.12: Length Required | |||
| "412" ; Section 10.4.13: Precondition Failed | | "412" ; Section 10.4.13: Precondition Failed | |||
| "413" ; Section 10.4.14: Request Entity Too Large | | "413" ; Section 10.4.14: Request Entity Too Large | |||
| "414" ; Section 10.4.15: Request-URI Too Large | | "414" ; Section 10.4.15: Request-URI Too Large | |||
| "415" ; Section 10.4.16: Unsupported Media Type | | "415" ; Section 10.4.16: Unsupported Media Type | |||
| "416" ; Section 10.4.17: Requested range not satisfiable | | "416" ; Section 10.4.17: Requested range not satisfiable | |||
| "417" ; Section 10.4.18: Expectation Failed | | "417" ; Section 10.4.18: Expectation Failed | |||
| "500" ; Section 10.5.1: Internal Server Error | | "500" ; Section 10.5.1: Internal Server Error | |||
| "501" ; Section 10.5.2: Not Implemented | | "501" ; Section 10.5.2: Not Implemented | |||
| "502" ; Section 10.5.3: Bad Gateway | | "502" ; Section 10.5.3: Bad Gateway | |||
| "503" ; Section 10.5.4: Service Unavailable | | "503" ; Section 10.5.4: Service Unavailable | |||
| "504" ; Section 10.5.5: Gateway Time-out | | "504" ; Section 10.5.5: Gateway Time-out | |||
| "505" ; Section 10.5.6: HTTP Version not supported | | "505" ; Section 10.5.6: HTTP Version not supported | |||
| extension-code | | extension-code | |||
extension-code = 3DIGIT | extension-code = 3DIGIT | |||
Reason-Phrase = *<TEXT, excluding CR, LF> | Reason-Phrase = *<TEXT, excluding CR, LF> | |||
HTTP status codes are extensible. HTTP applications are not required | HTTP status codes are extensible. HTTP applications are not required | |||
to understand the meaning of all registered status codes, though such | to understand the meaning of all registered status codes, though such | |||
understanding is obviously desirable. However, applications MUST | understanding is obviously desirable. However, applications MUST | |||
understand the class of any status code, as indicated by the first | understand the class of any status code, as indicated by the first | |||
digit, and treat any unrecognized response as being equivalent to the | digit, and treat any unrecognized response as being equivalent to the | |||
x00 status code of that class, with the exception that an | x00 status code of that class, with the exception that an | |||
unrecognized response MUST NOT be cached. For example, if an | unrecognized response MUST NOT be cached. For example, if an | |||
unrecognized status code of 431 is received by the client, it can | unrecognized status code of 431 is received by the client, it can | |||
safely assume that there was something wrong with its request and | safely assume that there was something wrong with its request and | |||
skipping to change at page 50, line 23 ¶ | skipping to change at page 51, line 23 ¶ | |||
with the response, since that entity is likely to include human- | with the response, since that entity is likely to include human- | |||
readable information which will explain the unusual status. | readable information which will explain the unusual status. | |||
6.2. Response Header Fields | 6.2. Response Header Fields | |||
The response-header fields allow the server to pass additional | The response-header fields allow the server to pass additional | |||
information about the response which cannot be placed in the Status- | information about the response which cannot be placed in the Status- | |||
Line. These header fields give information about the server and | Line. These header fields give information about the server and | |||
about further access to the resource identified by the Request-URI. | about further access to the resource identified by the Request-URI. | |||
response-header = Accept-Ranges ; Section 14.5 | response-header = Accept-Ranges ; Section 14.5 | |||
| Age ; Section 14.6 | | Age ; Section 14.6 | |||
| ETag ; Section 14.19 | | ETag ; Section 14.19 | |||
| Location ; Section 14.30 | | Location ; Section 14.30 | |||
| Proxy-Authenticate ; Section 14.33 | | Proxy-Authenticate ; Section 14.33 | |||
| Retry-After ; Section 14.37 | | Retry-After ; Section 14.37 | |||
| Server ; Section 14.38 | | Server ; Section 14.38 | |||
| Vary ; Section 14.44 | | Vary ; Section 14.44 | |||
| WWW-Authenticate ; Section 14.47 | | WWW-Authenticate ; Section 14.47 | |||
Response-header field names can be extended reliably only in | Response-header field names can be extended reliably only in | |||
combination with a change in the protocol version. However, new or | combination with a change in the protocol version. However, new or | |||
experimental header fields MAY be given the semantics of response- | experimental header fields MAY be given the semantics of response- | |||
header fields if all parties in the communication recognize them to | header fields if all parties in the communication recognize them to | |||
be response-header fields. Unrecognized header fields are treated as | be response-header fields. Unrecognized header fields are treated as | |||
entity-header fields. | entity-header fields. | |||
7. Entity | 7. Entity | |||
skipping to change at page 51, line 22 ¶ | skipping to change at page 52, line 22 ¶ | |||
In this section, both sender and recipient refer to either the client | In this section, both sender and recipient refer to either the client | |||
or the server, depending on who sends and who receives the entity. | or the server, depending on who sends and who receives the entity. | |||
7.1. Entity Header Fields | 7.1. Entity Header Fields | |||
Entity-header fields define metainformation about the entity-body or, | Entity-header fields define metainformation about the entity-body or, | |||
if no body is present, about the resource identified by the request. | if no body is present, about the resource identified by the request. | |||
Some of this metainformation is OPTIONAL; some might be REQUIRED by | Some of this metainformation is OPTIONAL; some might be REQUIRED by | |||
portions of this specification. | portions of this specification. | |||
entity-header = Allow ; Section 14.7 | entity-header = Allow ; Section 14.7 | |||
| Content-Encoding ; Section 14.11 | | Content-Encoding ; Section 14.11 | |||
| Content-Language ; Section 14.12 | | Content-Language ; Section 14.12 | |||
| Content-Length ; Section 14.13 | | Content-Length ; Section 14.13 | |||
| Content-Location ; Section 14.14 | | Content-Location ; Section 14.14 | |||
| Content-MD5 ; Section 14.15 | | Content-MD5 ; Section 14.15 | |||
| Content-Range ; Section 14.16 | | Content-Range ; Section 14.16 | |||
| Content-Type ; Section 14.17 | | Content-Type ; Section 14.17 | |||
| Expires ; Section 14.21 | | Expires ; Section 14.21 | |||
| Last-Modified ; Section 14.29 | | Last-Modified ; Section 14.29 | |||
| extension-header | | extension-header | |||
extension-header = message-header | extension-header = message-header | |||
The extension-header mechanism allows additional entity-header fields | The extension-header mechanism allows additional entity-header fields | |||
to be defined without changing the protocol, but these fields cannot | to be defined without changing the protocol, but these fields cannot | |||
be assumed to be recognizable by the recipient. Unrecognized header | be assumed to be recognizable by the recipient. Unrecognized header | |||
fields SHOULD be ignored by the recipient and MUST be forwarded by | fields SHOULD be ignored by the recipient and MUST be forwarded by | |||
transparent proxies. | transparent proxies. | |||
7.2. Entity Body | 7.2. Entity Body | |||
The entity-body (if any) sent with an HTTP request or response is in | The entity-body (if any) sent with an HTTP request or response is in | |||
a format and encoding defined by the entity-header fields. | a format and encoding defined by the entity-header fields. | |||
entity-body = *OCTET | entity-body = *OCTET | |||
An entity-body is only present in a message when a message-body is | An entity-body is only present in a message when a message-body is | |||
present, as described in Section 4.3. The entity-body is obtained | present, as described in Section 4.3. The entity-body is obtained | |||
from the message-body by decoding any Transfer-Encoding that might | from the message-body by decoding any Transfer-Encoding that might | |||
have been applied to ensure safe and proper transfer of the message. | have been applied to ensure safe and proper transfer of the message. | |||
7.2.1. Type | 7.2.1. Type | |||
When an entity-body is included with a message, the data type of that | When an entity-body is included with a message, the data type of that | |||
body is determined via the header fields Content-Type and Content- | body is determined via the header fields Content-Type and Content- | |||
skipping to change at page 63, line 49 ¶ | skipping to change at page 64, 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 64, line 51 ¶ | skipping to change at page 65, 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 70, line 42 ¶ | skipping to change at page 70, 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 86, line 39 ¶ | skipping to change at page 86, 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 91, line 6 ¶ | skipping to change at page 91, 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 111, line 20 ¶ | skipping to change at page 111, line 20 ¶ | |||
sends and who receives the entity. | sends and who receives the entity. | |||
14.1. Accept | 14.1. Accept | |||
The Accept request-header field can be used to specify certain media | The Accept request-header field can be used to specify certain media | |||
types which are acceptable for the response. Accept headers can be | types which are acceptable for the response. Accept headers can be | |||
used to indicate that the request is specifically limited to a small | used to indicate that the request is specifically limited to a small | |||
set of desired types, as in the case of a request for an in-line | set of desired types, as in the case of a request for an in-line | |||
image. | image. | |||
Accept = "Accept" ":" | Accept = "Accept" ":" | |||
#( media-range [ accept-params ] ) | #( media-range [ accept-params ] ) | |||
media-range = ( "*/*" | media-range = ( "*/*" | |||
| ( type "/" "*" ) | | ( type "/" "*" ) | |||
| ( type "/" subtype ) | | ( type "/" subtype ) | |||
) *( ";" parameter ) | ) *( ";" parameter ) | |||
accept-params = ";" "q" "=" qvalue *( accept-extension ) | accept-params = ";" "q" "=" qvalue *( accept-extension ) | |||
accept-extension = ";" token [ "=" ( token | quoted-string ) ] | accept-extension = ";" token [ "=" ( token | quoted-string ) ] | |||
The asterisk "*" character is used to group media types into ranges, | The asterisk "*" character is used to group media types into ranges, | |||
with "*/*" indicating all media types and "type/*" indicating all | with "*/*" indicating all media types and "type/*" indicating all | |||
subtypes of that type. The media-range MAY include media type | subtypes of that type. The media-range MAY include media type | |||
parameters that are applicable to that range. | parameters that are applicable to that range. | |||
Each media-range MAY be followed by one or more accept-params, | Each media-range MAY be followed by one or more accept-params, | |||
beginning with the "q" parameter for indicating a relative quality | beginning with the "q" parameter for indicating a relative quality | |||
factor. The first "q" parameter (if any) separates the media-range | factor. The first "q" parameter (if any) separates the media-range | |||
parameter(s) from the accept-params. Quality factors allow the user | parameter(s) from the accept-params. Quality factors allow the user | |||
skipping to change at page 112, line 13 ¶ | skipping to change at page 112, 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 113, line 19 ¶ | skipping to change at page 113, line 19 ¶ | |||
default set ought to be configurable by the user. | default set ought to be configurable by the user. | |||
14.2. Accept-Charset | 14.2. Accept-Charset | |||
The Accept-Charset request-header field can be used to indicate what | The Accept-Charset request-header field can be used to indicate what | |||
character sets are acceptable for the response. This field allows | character sets are acceptable for the response. This field allows | |||
clients capable of understanding more comprehensive or special- | clients capable of understanding more comprehensive or special- | |||
purpose character sets to signal that capability to a server which is | purpose character sets to signal that capability to a server which is | |||
capable of representing documents in those character sets. | capable of representing documents in those character sets. | |||
Accept-Charset = "Accept-Charset" ":" | Accept-Charset = "Accept-Charset" ":" | |||
1#( ( charset | "*" )[ ";" "q" "=" qvalue ] ) | 1#( ( charset | "*" ) [ ";" "q" "=" qvalue ] ) | |||
Character set values are described in Section 3.4. Each charset MAY | Character set values are described in Section 3.4. Each charset MAY | |||
be given an associated quality value which represents the user's | be given an associated quality value which represents the user's | |||
preference for that charset. The default value is q=1. An example | preference for that charset. The default value is q=1. An example | |||
is | is | |||
Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 | Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 | |||
The special value "*", if present in the Accept-Charset field, | The special value "*", if present in the Accept-Charset field, | |||
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 115, line 16 ¶ | skipping to change at page 115, line 16 ¶ | |||
Note: Most HTTP/1.0 applications do not recognize or obey qvalues | Note: Most HTTP/1.0 applications do not recognize or obey qvalues | |||
associated with content-codings. This means that qvalues will not | associated with content-codings. This means that qvalues will not | |||
work and are not permitted with x-gzip or x-compress. | work and are not permitted with x-gzip or x-compress. | |||
14.4. Accept-Language | 14.4. Accept-Language | |||
The Accept-Language request-header field is similar to Accept, but | The Accept-Language request-header field is similar to Accept, but | |||
restricts the set of natural languages that are preferred as a | restricts the set of natural languages that are preferred as a | |||
response to the request. Language tags are defined in Section 3.10. | response to the request. Language tags are defined in Section 3.10. | |||
Accept-Language = "Accept-Language" ":" | Accept-Language = "Accept-Language" ":" | |||
1#( language-range [ ";" "q" "=" qvalue ] ) | 1#( language-range [ ";" "q" "=" qvalue ] ) | |||
language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" ) | language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" ) | |||
Each language-range MAY be given an associated quality value which | Each language-range MAY be given an associated quality value which | |||
represents an estimate of the user's preference for the languages | represents an estimate of the user's preference for the languages | |||
specified by that range. The quality value defaults to "q=1". For | specified by that range. The quality value defaults to "q=1". For | |||
example, | example, | |||
Accept-Language: da, en-gb;q=0.8, en;q=0.7 | Accept-Language: da, en-gb;q=0.8, en;q=0.7 | |||
would mean: "I prefer Danish, but will accept British English and | would mean: "I prefer Danish, but will accept British English and | |||
other types of English." A language-range matches a language-tag if | other types of English." A language-range matches a language-tag if | |||
skipping to change at page 116, line 28 ¶ | skipping to change at page 116, line 28 ¶ | |||
might assume that on selecting "en-gb", they will be served any | might assume that on selecting "en-gb", they will be served any | |||
kind of English document if British English is not available. A | kind of English document if British English is not available. A | |||
user agent might suggest in such a case to add "en" to get the | user agent might suggest in such a case to add "en" to get the | |||
best matching behavior. | best matching behavior. | |||
14.5. Accept-Ranges | 14.5. Accept-Ranges | |||
The Accept-Ranges response-header field allows the server to indicate | The Accept-Ranges response-header field allows the server to indicate | |||
its acceptance of range requests for a resource: | its acceptance of range requests for a resource: | |||
Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges | Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges | |||
acceptable-ranges = 1#range-unit | "none" | acceptable-ranges = 1#range-unit | "none" | |||
Origin servers that accept byte-range requests MAY send | Origin servers that accept byte-range requests MAY send | |||
Accept-Ranges: bytes | Accept-Ranges: bytes | |||
but are not required to do so. Clients MAY generate byte-range | but are not required to do so. Clients MAY generate byte-range | |||
requests without having received this header for the resource | requests without having received this header for the resource | |||
involved. Range units are defined in Section 3.12. | involved. Range units are defined in Section 3.12. | |||
Servers that do not accept any kind of range request for a resource | Servers that do not accept any kind of range request for a resource | |||
skipping to change at page 117, line 6 ¶ | skipping to change at page 117, line 6 ¶ | |||
to advise the client not to attempt a range request. | to advise the client not to attempt a range request. | |||
14.6. Age | 14.6. Age | |||
The Age response-header field conveys the sender's estimate of the | The Age response-header field conveys the sender's estimate of the | |||
amount of time since the response (or its revalidation) was generated | amount of time since the response (or its revalidation) was generated | |||
at the origin server. A cached response is "fresh" if its age does | at the origin server. A cached response is "fresh" if its age does | |||
not exceed its freshness lifetime. Age values are calculated as | not exceed its freshness lifetime. Age values are calculated as | |||
specified in Section 13.2.3. | specified in Section 13.2.3. | |||
Age = "Age" ":" age-value | Age = "Age" ":" age-value | |||
age-value = delta-seconds | age-value = delta-seconds | |||
Age values are non-negative decimal integers, representing time in | Age values are non-negative decimal integers, representing time in | |||
seconds. | seconds. | |||
If a cache receives a value larger than the largest positive integer | If a cache receives a value larger than the largest positive integer | |||
it can represent, or if any of its age calculations overflows, it | it can represent, or if any of its age calculations overflows, it | |||
MUST transmit an Age header with a value of 2147483648 (2^31). An | MUST transmit an Age header with a value of 2147483648 (2^31). An | |||
HTTP/1.1 server that includes a cache MUST include an Age header | HTTP/1.1 server that includes a cache MUST include an Age header | |||
field in every response generated from its own cache. Caches SHOULD | field in every response generated from its own cache. Caches SHOULD | |||
use an arithmetic type of at least 31 bits of range. | use an arithmetic type of at least 31 bits of range. | |||
14.7. Allow | 14.7. Allow | |||
The Allow entity-header field lists the set of methods supported by | The Allow entity-header field lists the set of methods supported by | |||
the resource identified by the Request-URI. The purpose of this | the resource identified by the Request-URI. The purpose of this | |||
field is strictly to inform the recipient of valid methods associated | field is strictly to inform the recipient of valid methods associated | |||
with the resource. An Allow header field MUST be present in a 405 | with the resource. An Allow header field MUST be present in a 405 | |||
(Method Not Allowed) response. | (Method Not Allowed) response. | |||
Allow = "Allow" ":" #Method | Allow = "Allow" ":" #Method | |||
Example of use: | Example of use: | |||
Allow: GET, HEAD, PUT | Allow: GET, HEAD, PUT | |||
This field cannot prevent a client from trying other methods. | This field cannot prevent a client from trying other methods. | |||
However, the indications given by the Allow header field value SHOULD | However, the indications given by the Allow header field value SHOULD | |||
be followed. The actual set of allowed methods is defined by the | be followed. The actual set of allowed methods is defined by the | |||
origin server at the time of each request. | origin server at the time of each request. | |||
skipping to change at page 118, line 9 ¶ | skipping to change at page 118, line 9 ¶ | |||
14.8. Authorization | 14.8. Authorization | |||
A user agent that wishes to authenticate itself with a server-- | A user agent that wishes to authenticate itself with a server-- | |||
usually, but not necessarily, after receiving a 401 response--does so | usually, but not necessarily, after receiving a 401 response--does so | |||
by including an Authorization request-header field with the request. | by including an Authorization request-header field with the request. | |||
The Authorization field value consists of credentials containing the | The Authorization field value consists of credentials containing the | |||
authentication information of the user agent for the realm of the | authentication information of the user agent for the realm of the | |||
resource being requested. | resource being requested. | |||
Authorization = "Authorization" ":" credentials | Authorization = "Authorization" ":" credentials | |||
HTTP access authentication is described in "HTTP Authentication: | HTTP access authentication is described in "HTTP Authentication: | |||
Basic and Digest Access Authentication" [RFC2617]. If a request is | Basic and Digest Access Authentication" [RFC2617]. If a request is | |||
authenticated and a realm specified, the same credentials SHOULD be | authenticated and a realm specified, the same credentials SHOULD be | |||
valid for all other requests within this realm (assuming that the | valid for all other requests within this realm (assuming that the | |||
authentication scheme itself does not require otherwise, such as | authentication scheme itself does not require otherwise, such as | |||
credentials that vary according to a challenge value or using | credentials that vary according to a challenge value or using | |||
synchronized clocks). | synchronized clocks). | |||
When a shared cache (see Section 13.7) receives a request containing | When a shared cache (see Section 13.7) receives a request containing | |||
skipping to change at page 119, line 30 ¶ | skipping to change at page 119, line 30 ¶ | |||
cache-request-directive = | cache-request-directive = | |||
"no-cache" ; Section 14.9.1 | "no-cache" ; Section 14.9.1 | |||
| "no-store" ; Section 14.9.2 | | "no-store" ; Section 14.9.2 | |||
| "max-age" "=" delta-seconds ; Section 14.9.3, 14.9.4 | | "max-age" "=" delta-seconds ; Section 14.9.3, 14.9.4 | |||
| "max-stale" [ "=" delta-seconds ] ; Section 14.9.3 | | "max-stale" [ "=" delta-seconds ] ; Section 14.9.3 | |||
| "min-fresh" "=" delta-seconds ; Section 14.9.3 | | "min-fresh" "=" delta-seconds ; Section 14.9.3 | |||
| "no-transform" ; Section 14.9.5 | | "no-transform" ; Section 14.9.5 | |||
| "only-if-cached" ; Section 14.9.4 | | "only-if-cached" ; Section 14.9.4 | |||
| cache-extension ; Section 14.9.6 | | cache-extension ; Section 14.9.6 | |||
cache-response-directive = | cache-response-directive = | |||
"public" ; Section 14.9.1 | "public" ; Section 14.9.1 | |||
| "private" [ "=" <"> 1#field-name <"> ] ; Section 14.9.1 | | "private" [ "=" <"> 1#field-name <"> ] ; Section 14.9.1 | |||
| "no-cache" [ "=" <"> 1#field-name <"> ]; Section 14.9.1 | | "no-cache" [ "=" <"> 1#field-name <"> ]; Section 14.9.1 | |||
| "no-store" ; Section 14.9.2 | | "no-store" ; Section 14.9.2 | |||
| "no-transform" ; Section 14.9.5 | | "no-transform" ; Section 14.9.5 | |||
| "must-revalidate" ; Section 14.9.4 | | "must-revalidate" ; Section 14.9.4 | |||
| "proxy-revalidate" ; Section 14.9.4 | | "proxy-revalidate" ; Section 14.9.4 | |||
| "max-age" "=" delta-seconds ; Section 14.9.3 | | "max-age" "=" delta-seconds ; Section 14.9.3 | |||
| "s-maxage" "=" delta-seconds ; Section 14.9.3 | | "s-maxage" "=" delta-seconds ; Section 14.9.3 | |||
| cache-extension ; Section 14.9.6 | | cache-extension ; Section 14.9.6 | |||
cache-extension = token [ "=" ( token | quoted-string ) ] | cache-extension = token [ "=" ( token | quoted-string ) ] | |||
When a directive appears without any 1#field-name parameter, the | When a directive appears without any 1#field-name parameter, the | |||
directive applies to the entire request or response. When such a | directive applies to the entire request or response. When such a | |||
directive appears with a 1#field-name parameter, it applies only to | directive appears with a 1#field-name parameter, it applies only to | |||
the named field or fields, and not to the rest of the request or | the named field or fields, and not to the rest of the request or | |||
response. This mechanism supports extensibility; implementations of | response. This mechanism supports extensibility; implementations of | |||
future versions of the HTTP protocol might apply these directives to | future versions of the HTTP protocol might apply these directives to | |||
header fields not defined in HTTP/1.1. | header fields not defined in HTTP/1.1. | |||
skipping to change at page 128, line 20 ¶ | skipping to change at page 128, line 20 ¶ | |||
correct even if the cache does not understand the extension(s). | correct even if the cache does not understand the extension(s). | |||
14.10. Connection | 14.10. Connection | |||
The Connection general-header field allows the sender to specify | The Connection general-header field allows the sender to specify | |||
options that are desired for that particular connection and MUST NOT | options that are desired for that particular connection and MUST NOT | |||
be communicated by proxies over further connections. | be communicated by proxies over further connections. | |||
The Connection header has the following grammar: | The Connection header has the following grammar: | |||
Connection = "Connection" ":" 1#(connection-token) | Connection = "Connection" ":" 1#(connection-token) | |||
connection-token = token | connection-token = token | |||
HTTP/1.1 proxies MUST parse the Connection header field before a | HTTP/1.1 proxies MUST parse the Connection header field before a | |||
message is forwarded and, for each connection-token in this field, | message is forwarded and, for each connection-token in this field, | |||
remove any header field(s) from the message with the same name as the | remove any header field(s) from the message with the same name as the | |||
connection-token. Connection options are signaled by the presence of | connection-token. Connection options are signaled by the presence of | |||
a connection-token in the Connection header field, not by any | a connection-token in the Connection header field, not by any | |||
corresponding additional header field(s), since the additional header | corresponding additional header field(s), since the additional header | |||
field may not be sent if there are no parameters associated with that | field may not be sent if there are no parameters associated with that | |||
connection option. | connection option. | |||
skipping to change at page 129, line 22 ¶ | skipping to change at page 129, line 22 ¶ | |||
14.11. Content-Encoding | 14.11. Content-Encoding | |||
The Content-Encoding entity-header field is used as a modifier to the | The Content-Encoding entity-header field is used as a modifier to the | |||
media-type. When present, its value indicates what additional | media-type. When present, its value indicates what additional | |||
content codings have been applied to the entity-body, and thus what | content codings have been applied to the entity-body, and thus what | |||
decoding mechanisms must be applied in order to obtain the media-type | decoding mechanisms must be applied in order to obtain the media-type | |||
referenced by the Content-Type header field. Content-Encoding is | referenced by the Content-Type header field. Content-Encoding is | |||
primarily used to allow a document to be compressed without losing | primarily used to allow a document to be compressed without losing | |||
the identity of its underlying media type. | the identity of its underlying media type. | |||
Content-Encoding = "Content-Encoding" ":" 1#content-coding | Content-Encoding = "Content-Encoding" ":" 1#content-coding | |||
Content codings are defined in Section 3.5. An example of its use is | Content codings are defined in Section 3.5. An example of its use is | |||
Content-Encoding: gzip | Content-Encoding: gzip | |||
The content-coding is a characteristic of the entity identified by | The content-coding is a characteristic of the entity identified by | |||
the Request-URI. Typically, the entity-body is stored with this | the Request-URI. Typically, the entity-body is stored with this | |||
encoding and is only decoded before rendering or analogous usage. | encoding and is only decoded before rendering or analogous usage. | |||
However, a non-transparent proxy MAY modify the content-coding if the | However, a non-transparent proxy MAY modify the content-coding if the | |||
new coding is known to be acceptable to the recipient, unless the | new coding is known to be acceptable to the recipient, unless the | |||
skipping to change at page 130, line 6 ¶ | skipping to change at page 130, line 6 ¶ | |||
Additional information about the encoding parameters MAY be provided | Additional information about the encoding parameters MAY be provided | |||
by other entity-header fields not defined by this specification. | by other entity-header fields not defined by this specification. | |||
14.12. Content-Language | 14.12. Content-Language | |||
The Content-Language entity-header field describes the natural | The Content-Language entity-header field describes the natural | |||
language(s) of the intended audience for the enclosed entity. Note | language(s) of the intended audience for the enclosed entity. Note | |||
that this might not be equivalent to all the languages used within | that this might not be equivalent to all the languages used within | |||
the entity-body. | the entity-body. | |||
Content-Language = "Content-Language" ":" 1#language-tag | Content-Language = "Content-Language" ":" 1#language-tag | |||
Language tags are defined in Section 3.10. The primary purpose of | Language tags are defined in Section 3.10. The primary purpose of | |||
Content-Language is to allow a user to identify and differentiate | Content-Language is to allow a user to identify and differentiate | |||
entities according to the user's own preferred language. Thus, if | entities according to the user's own preferred language. Thus, if | |||
the body content is intended only for a Danish-literate audience, the | the body content is intended only for a Danish-literate audience, the | |||
appropriate field is | appropriate field is | |||
Content-Language: da | Content-Language: da | |||
If no Content-Language is specified, the default is that the content | If no Content-Language is specified, the default is that the content | |||
skipping to change at page 130, line 45 ¶ | skipping to change at page 130, line 45 ¶ | |||
Content-Language MAY be applied to any media type -- it is not | Content-Language MAY be applied to any media type -- it is not | |||
limited to textual documents. | limited to textual documents. | |||
14.13. Content-Length | 14.13. Content-Length | |||
The Content-Length entity-header field indicates the size of the | The Content-Length entity-header field indicates the size of the | |||
entity-body, in decimal number of OCTETs, sent to the recipient or, | entity-body, in decimal number of OCTETs, sent to the recipient or, | |||
in the case of the HEAD method, the size of the entity-body that | in the case of the HEAD method, the size of the entity-body that | |||
would have been sent had the request been a GET. | would have been sent had the request been a GET. | |||
Content-Length = "Content-Length" ":" 1*DIGIT | Content-Length = "Content-Length" ":" 1*DIGIT | |||
An example is | An example is | |||
Content-Length: 3495 | Content-Length: 3495 | |||
Applications SHOULD use this field to indicate the transfer-length of | Applications SHOULD use this field to indicate the transfer-length of | |||
the message-body, unless this is prohibited by the rules in | the message-body, unless this is prohibited by the rules in | |||
Section 4.4. | Section 4.4. | |||
Any Content-Length greater than or equal to zero is a valid value. | Any Content-Length greater than or equal to zero is a valid value. | |||
skipping to change at page 131, line 30 ¶ | skipping to change at page 131, line 30 ¶ | |||
The Content-Location entity-header field MAY be used to supply the | The Content-Location entity-header field MAY be used to supply the | |||
resource location for the entity enclosed in the message when that | resource location for the entity enclosed in the message when that | |||
entity is accessible from a location separate from the requested | entity is accessible from a location separate from the requested | |||
resource's URI. A server SHOULD provide a Content-Location for the | resource's URI. A server SHOULD provide a Content-Location for the | |||
variant corresponding to the response entity; especially in the case | variant corresponding to the response entity; especially in the case | |||
where a resource has multiple entities associated with it, and those | where a resource has multiple entities associated with it, and those | |||
entities actually have separate locations by which they might be | entities actually have separate locations by which they might be | |||
individually accessed, the server SHOULD provide a Content-Location | individually accessed, the server SHOULD provide a Content-Location | |||
for the particular variant which is returned. | for the particular variant which is returned. | |||
Content-Location = "Content-Location" ":" | Content-Location = "Content-Location" ":" | |||
( absoluteURI | relativeURI ) | ( absoluteURI | relativeURI ) | |||
The value of Content-Location also defines the base URI for the | The value of Content-Location also defines the base URI for the | |||
entity. | entity. | |||
The Content-Location value is not a replacement for the original | The Content-Location value is not a replacement for the original | |||
requested URI; it is only a statement of the location of the resource | requested URI; it is only a statement of the location of the resource | |||
corresponding to this particular entity at the time of the request. | corresponding to this particular entity at the time of the request. | |||
Future requests MAY specify the Content-Location URI as the request- | Future requests MAY specify the Content-Location URI as the request- | |||
URI if the desire is to identify the source of that particular | URI if the desire is to identify the source of that particular | |||
entity. | entity. | |||
skipping to change at page 132, line 16 ¶ | skipping to change at page 132, line 16 ¶ | |||
undefined; servers are free to ignore it in those cases. | undefined; servers are free to ignore it in those cases. | |||
14.15. Content-MD5 | 14.15. Content-MD5 | |||
The Content-MD5 entity-header field, as defined in [RFC1864], is an | The Content-MD5 entity-header field, as defined in [RFC1864], is an | |||
MD5 digest of the entity-body for the purpose of providing an end-to- | MD5 digest of the entity-body for the purpose of providing an end-to- | |||
end message integrity check (MIC) of the entity-body. (Note: a MIC | end message integrity check (MIC) of the entity-body. (Note: a MIC | |||
is good for detecting accidental modification of the entity-body in | is good for detecting accidental modification of the entity-body in | |||
transit, but is not proof against malicious attacks.) | transit, but is not proof against malicious attacks.) | |||
Content-MD5 = "Content-MD5" ":" md5-digest | Content-MD5 = "Content-MD5" ":" md5-digest | |||
md5-digest = <base64 of 128 bit MD5 digest as per [RFC1864]> | md5-digest = <base64 of 128 bit MD5 digest as per [RFC1864]> | |||
The Content-MD5 header field MAY be generated by an origin server or | The Content-MD5 header field MAY be generated by an origin server or | |||
client to function as an integrity check of the entity-body. Only | client to function as an integrity check of the entity-body. Only | |||
origin servers or clients MAY generate the Content-MD5 header field; | origin servers or clients MAY generate the Content-MD5 header field; | |||
proxies and gateways MUST NOT generate it, as this would defeat its | proxies and gateways MUST NOT generate it, as this would defeat its | |||
value as an end-to-end integrity check. Any recipient of the entity- | value as an end-to-end integrity check. Any recipient of the entity- | |||
body, including gateways and proxies, MAY check that the digest value | body, including gateways and proxies, MAY check that the digest value | |||
in this header field matches that of the entity-body as received. | in this header field matches that of the entity-body as received. | |||
The MD5 digest is computed based on the content of the entity-body, | The MD5 digest is computed based on the content of the entity-body, | |||
skipping to change at page 133, line 26 ¶ | skipping to change at page 133, line 26 ¶ | |||
the digest is the transmission byte order defined for the type. | the digest is the transmission byte order defined for the type. | |||
Lastly, HTTP allows transmission of text types with any of several | Lastly, HTTP allows transmission of text types with any of several | |||
line break conventions and not just the canonical form using CRLF. | line break conventions and not just the canonical form using CRLF. | |||
14.16. Content-Range | 14.16. Content-Range | |||
The Content-Range entity-header is sent with a partial entity-body to | The Content-Range entity-header is sent with a partial entity-body to | |||
specify where in the full entity-body the partial body should be | specify where in the full entity-body the partial body should be | |||
applied. Range units are defined in Section 3.12. | applied. Range units are defined in Section 3.12. | |||
Content-Range = "Content-Range" ":" content-range-spec | Content-Range = "Content-Range" ":" content-range-spec | |||
content-range-spec = byte-content-range-spec | content-range-spec = byte-content-range-spec | |||
byte-content-range-spec = bytes-unit SP | byte-content-range-spec = bytes-unit SP | |||
byte-range-resp-spec "/" | byte-range-resp-spec "/" | |||
( instance-length | "*" ) | ( instance-length | "*" ) | |||
byte-range-resp-spec = (first-byte-pos "-" last-byte-pos) | byte-range-resp-spec = (first-byte-pos "-" last-byte-pos) | |||
| "*" | | "*" | |||
instance-length = 1*DIGIT | instance-length = 1*DIGIT | |||
The header SHOULD indicate the total length of the full entity-body, | The header SHOULD indicate the total length of the full entity-body, | |||
unless this length is unknown or difficult to determine. The | unless this length is unknown or difficult to determine. The | |||
asterisk "*" character means that the instance-length is unknown at | asterisk "*" character means that the instance-length is unknown at | |||
the time when the response was generated. | the time when the response was generated. | |||
Unlike byte-ranges-specifier values (see Section 14.35.1), a byte- | Unlike byte-ranges-specifier values (see Section 14.35.1), a byte- | |||
range-resp-spec MUST only specify one range, and MUST contain | range-resp-spec MUST only specify one range, and MUST contain | |||
absolute byte positions for both the first and last byte of the | absolute byte positions for both the first and last byte of the | |||
range. | range. | |||
skipping to change at page 134, line 37 ¶ | skipping to change at page 134, 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 135, line 35 ¶ | skipping to change at page 135, line 35 ¶ | |||
range not satisfiable) response instead of a 200 (OK) response for | range not satisfiable) response instead of a 200 (OK) response for | |||
an unsatisfiable Range request-header, since not all servers | an unsatisfiable Range request-header, since not all servers | |||
implement this request-header. | implement this request-header. | |||
14.17. Content-Type | 14.17. Content-Type | |||
The Content-Type entity-header field indicates the media type of the | The Content-Type entity-header field indicates the media type of the | |||
entity-body sent to the recipient or, in the case of the HEAD method, | entity-body sent to the recipient or, in the case of the HEAD method, | |||
the media type that would have been sent had the request been a GET. | the media type that would have been sent had the request been a GET. | |||
Content-Type = "Content-Type" ":" media-type | Content-Type = "Content-Type" ":" media-type | |||
Media types are defined in Section 3.7. An example of the field is | Media types are defined in Section 3.7. An example of the field is | |||
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: | |||
1. If the response status code is 100 (Continue) or 101 (Switching | 1. If the response status code is 100 (Continue) or 101 (Switching | |||
Protocols), the response MAY include a Date header field, at the | Protocols), the response MAY include a Date header field, at the | |||
server's option. | server's option. | |||
2. If the response status code conveys a server error, e.g. 500 | 2. If the response status code conveys a server error, e.g. 500 | |||
(Internal Server Error) or 503 (Service Unavailable), and it is | (Internal Server Error) or 503 (Service Unavailable), and it is | |||
inconvenient or impossible to generate a valid Date. | inconvenient or impossible to generate a valid Date. | |||
3. If the server does not have a clock that can provide a reasonable | 3. If the server does not have a clock that can provide a reasonable | |||
approximation of the current time, its responses MUST NOT include | approximation of the current time, its responses MUST NOT include | |||
a Date header field. In this case, the rules in Section 14.18.1 | a Date header field. In this case, the rules in Section 14.18.1 | |||
MUST be followed. | MUST be followed. | |||
A received message that does not have a Date header field MUST be | A received message that does not have a Date header field MUST be | |||
assigned one by the recipient if the message will be cached by that | assigned one by the recipient if the message will be cached by that | |||
skipping to change at page 137, line 17 ¶ | skipping to change at page 137, line 17 ¶ | |||
resource). | resource). | |||
14.19. ETag | 14.19. ETag | |||
The ETag response-header field provides the current value of the | The ETag response-header field provides the current value of the | |||
entity tag for the requested variant. The headers used with entity | entity tag for the requested variant. The headers used with entity | |||
tags are described in Sections 14.24, 14.26 and 14.44. The entity | tags are described in Sections 14.24, 14.26 and 14.44. The entity | |||
tag MAY be used for comparison with other entities from the same | tag MAY be used for comparison with other entities from the same | |||
resource (see Section 13.3.3). | resource (see Section 13.3.3). | |||
ETag = "ETag" ":" entity-tag | ETag = "ETag" ":" entity-tag | |||
Examples: | Examples: | |||
ETag: "xyzzy" | ETag: "xyzzy" | |||
ETag: W/"xyzzy" | ETag: W/"xyzzy" | |||
ETag: "" | ETag: "" | |||
14.20. Expect | 14.20. Expect | |||
The Expect request-header field is used to indicate that particular | The Expect request-header field is used to indicate that particular | |||
server behaviors are required by the client. | server behaviors are required by the client. | |||
Expect = "Expect" ":" 1#expectation | Expect = "Expect" ":" 1#expectation | |||
expectation = "100-continue" | expectation-extension | expectation = "100-continue" | expectation-extension | |||
expectation-extension = token [ "=" ( token | quoted-string ) | expectation-extension = token [ "=" ( token | quoted-string ) | |||
*expect-params ] | *expect-params ] | |||
expect-params = ";" token [ "=" ( token | quoted-string ) ] | expect-params = ";" token [ "=" ( token | quoted-string ) ] | |||
A server that does not understand or is unable to comply with any of | A server that does not understand or is unable to comply with any of | |||
the expectation values in the Expect field of a request MUST respond | the expectation values in the Expect field of a request MUST respond | |||
with appropriate error status. The server MUST respond with a 417 | with appropriate error status. The server MUST respond with a 417 | |||
(Expectation Failed) status if any of the expectations cannot be met | (Expectation Failed) status if any of the expectations cannot be met | |||
or, if there are other problems with the request, some other 4xx | or, if there are other problems with the request, some other 4xx | |||
status. | status. | |||
This header field is defined with extensible syntax to allow for | This header field is defined with extensible syntax to allow for | |||
future extensions. If a server receives a request containing an | future extensions. If a server receives a request containing an | |||
skipping to change at page 138, line 14 ¶ | skipping to change at page 138, 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. | |||
The presence of an Expires field does not imply that the original | The presence of an Expires field does not imply that the original | |||
resource will change or cease to exist at, before, or after that | resource will change or cease to exist at, before, or after that | |||
time. | time. | |||
The format is an absolute date and time as defined by HTTP-date in | The format is an absolute date and time as defined by HTTP-date in | |||
Section 3.3.1; it MUST be in rfc1123-date format: | Section 3.3.1; it MUST be in rfc1123-date format: | |||
Expires = "Expires" ":" HTTP-date | Expires = "Expires" ":" HTTP-date | |||
An example of its use is | An example of its use is | |||
Expires: Thu, 01 Dec 1994 16:00:00 GMT | Expires: Thu, 01 Dec 1994 16:00:00 GMT | |||
Note: if a response includes a Cache-Control field with the max- | Note: if a response includes a Cache-Control field with the max- | |||
age directive (see Section 14.9.3), that directive overrides the | age directive (see Section 14.9.3), that directive overrides the | |||
Expires field. | Expires field. | |||
HTTP/1.1 clients and caches MUST treat other invalid date formats, | HTTP/1.1 clients and caches MUST treat other invalid date formats, | |||
skipping to change at page 139, line 16 ¶ | skipping to change at page 139, 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 | |||
interpretation of this field is that the request is being performed | interpretation of this field is that the request is being performed | |||
on behalf of the person given, who accepts responsibility for the | on behalf of the person given, who accepts responsibility for the | |||
skipping to change at page 140, line 7 ¶ | skipping to change at page 140, line 7 ¶ | |||
The Host request-header field specifies the Internet host and port | The Host request-header field specifies the Internet host and port | |||
number of the resource being requested, as obtained from the original | number of the resource being requested, as obtained from the original | |||
URI given by the user or referring resource (generally an HTTP URL, | URI given by the user or referring resource (generally an HTTP URL, | |||
as described in Section 3.2.2). The Host field value MUST represent | as described in Section 3.2.2). The Host field value MUST represent | |||
the naming authority of the origin server or gateway given by the | the naming authority of the origin server or gateway given by the | |||
original URL. This allows the origin server or gateway to | original URL. This allows the origin server or gateway to | |||
differentiate between internally-ambiguous URLs, such as the root "/" | differentiate between internally-ambiguous URLs, such as the root "/" | |||
URL of a server for multiple host names on a single IP address. | URL of a server for multiple host names on a single IP address. | |||
Host = "Host" ":" host [ ":" port ] ; Section 3.2.2 | Host = "Host" ":" host [ ":" port ] ; Section 3.2.2 | |||
A "host" without any trailing port information implies the default | A "host" without any trailing port information implies the default | |||
port for the service requested (e.g., "80" for an HTTP URL). For | port for the service requested (e.g., "80" for an HTTP URL). For | |||
example, a request on the origin server for | example, a request on the origin server for | |||
<http://www.example.org/pub/WWW/> would properly include: | <http://www.example.org/pub/WWW/> would properly include: | |||
GET /pub/WWW/ HTTP/1.1 | GET /pub/WWW/ HTTP/1.1 | |||
Host: www.example.org | Host: www.example.org | |||
A client MUST include a Host header field in all HTTP/1.1 request | A client MUST include a Host header field in all HTTP/1.1 request | |||
skipping to change at page 140, line 42 ¶ | skipping to change at page 140, line 42 ¶ | |||
conditional. A client that has one or more entities previously | conditional. A client that has one or more entities previously | |||
obtained from the resource can verify that one of those entities is | obtained from the resource can verify that one of those entities is | |||
current by including a list of their associated entity tags in the | current by including a list of their associated entity tags in the | |||
If-Match header field. Entity tags are defined in Section 3.11. The | If-Match header field. Entity tags are defined in Section 3.11. The | |||
purpose of this feature is to allow efficient updates of cached | purpose of this feature is to allow efficient updates of cached | |||
information with a minimum amount of transaction overhead. It is | information with a minimum amount of transaction overhead. It is | |||
also used, on updating requests, to prevent inadvertent modification | also used, on updating requests, to prevent inadvertent modification | |||
of the wrong version of a resource. As a special case, the value "*" | of the wrong version of a resource. As a special case, the value "*" | |||
matches any current entity of the resource. | matches any current entity of the resource. | |||
If-Match = "If-Match" ":" ( "*" | 1#entity-tag ) | If-Match = "If-Match" ":" ( "*" | 1#entity-tag ) | |||
If any of the entity tags match the entity tag of the entity that | If any of the entity tags match the entity tag of the entity that | |||
would have been returned in the response to a similar GET request | would have been returned in the response to a similar GET request | |||
(without the If-Match header) on that resource, or if "*" is given | (without the If-Match header) on that resource, or if "*" is given | |||
and any current entity exists for that resource, then the server MAY | and any current entity exists for that resource, then the server MAY | |||
perform the requested method as if the If-Match header field did not | perform the requested method as if the If-Match header field did not | |||
exist. | exist. | |||
A server MUST use the strong comparison function (see Section 13.3.3) | A server MUST use the strong comparison function (see Section 13.3.3) | |||
to compare the entity tags in If-Match. | to compare the entity tags in If-Match. | |||
skipping to change at page 141, line 43 ¶ | skipping to change at page 141, 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. | |||
The algorithm for determining this includes the following cases: | The algorithm for determining this includes the following cases: | |||
skipping to change at page 143, line 24 ¶ | skipping to change at page 143, line 24 ¶ | |||
current by including a list of their associated entity tags in the | current by including a list of their associated entity tags in the | |||
If-None-Match header field. The purpose of this feature is to allow | If-None-Match header field. The purpose of this feature is to allow | |||
efficient updates of cached information with a minimum amount of | efficient updates of cached information with a minimum amount of | |||
transaction overhead. It is also used to prevent a method (e.g. | transaction overhead. It is also used to prevent a method (e.g. | |||
PUT) from inadvertently modifying an existing resource when the | PUT) from inadvertently modifying an existing resource when the | |||
client believes that the resource does not exist. | client believes that the resource does not exist. | |||
As a special case, the value "*" matches any current entity of the | As a special case, the value "*" matches any current entity of the | |||
resource. | resource. | |||
If-None-Match = "If-None-Match" ":" ( "*" | 1#entity-tag ) | If-None-Match = "If-None-Match" ":" ( "*" | 1#entity-tag ) | |||
If any of the entity tags match the entity tag of the entity that | If any of the entity tags match the entity tag of the entity that | |||
would have been returned in the response to a similar GET request | would have been returned in the response to a similar GET request | |||
(without the If-None-Match header) on that resource, or if "*" is | (without the If-None-Match header) on that resource, or if "*" is | |||
given and any current entity exists for that resource, then the | given and any current entity exists for that resource, then the | |||
server MUST NOT perform the requested method, unless required to do | server MUST NOT perform the requested method, unless required to do | |||
so because the resource's modification date fails to match that | so because the resource's modification date fails to match that | |||
supplied in an If-Modified-Since header field in the request. | supplied in an If-Modified-Since header field in the request. | |||
Instead, if the request method was GET or HEAD, the server SHOULD | Instead, if the request method was GET or HEAD, the server SHOULD | |||
respond with a 304 (Not Modified) response, including the cache- | respond with a 304 (Not Modified) response, including the cache- | |||
skipping to change at page 144, line 40 ¶ | skipping to change at page 144, line 40 ¶ | |||
either or both of If-Unmodified-Since and If-Match.) However, if the | either or both of If-Unmodified-Since and If-Match.) However, if the | |||
condition fails because the entity has been modified, the client | condition fails because the entity has been modified, the client | |||
would then have to make a second request to obtain the entire current | would then have to make a second request to obtain the entire current | |||
entity-body. | entity-body. | |||
The If-Range header allows a client to "short-circuit" the second | The If-Range header allows a client to "short-circuit" the second | |||
request. Informally, its meaning is `if the entity is unchanged, | request. Informally, its meaning is `if the entity is unchanged, | |||
send me the part(s) that I am missing; otherwise, send me the entire | send me the part(s) that I am missing; otherwise, send me the entire | |||
new entity'. | new entity'. | |||
If-Range = "If-Range" ":" ( entity-tag | HTTP-date ) | If-Range = "If-Range" ":" ( entity-tag | HTTP-date ) | |||
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. | |||
If the requested variant has been modified since the specified time, | If the requested variant has been modified since the specified time, | |||
the server MUST NOT perform the requested operation, and MUST return | the server MUST NOT perform the requested operation, and MUST return | |||
a 412 (Precondition Failed). | a 412 (Precondition Failed). | |||
If-Unmodified-Since = "If-Unmodified-Since" ":" HTTP-date | If-Unmodified-Since = "If-Unmodified-Since" ":" HTTP-date | |||
An example of the field is: | An example of the field is: | |||
If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT | If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT | |||
If the request normally (i.e., without the If-Unmodified-Since | If the request normally (i.e., without the If-Unmodified-Since | |||
header) would result in anything other than a 2xx or 412 status, the | header) would result in anything other than a 2xx or 412 status, the | |||
If-Unmodified-Since header SHOULD be ignored. | If-Unmodified-Since header SHOULD be ignored. | |||
If the specified date is invalid, the header is ignored. | If the specified date is invalid, the header is ignored. | |||
The result of a request having both an If-Unmodified-Since header | The result of a request having both an If-Unmodified-Since header | |||
field and either an If-None-Match or an If-Modified-Since header | field and either an If-None-Match or an If-Modified-Since header | |||
fields is undefined by this specification. | fields is undefined by this specification. | |||
14.29. Last-Modified | 14.29. Last-Modified | |||
The Last-Modified entity-header field indicates the date and time at | The Last-Modified entity-header field indicates the date and time at | |||
which the origin server believes the variant was last modified. | which the origin server believes the variant was last modified. | |||
Last-Modified = "Last-Modified" ":" HTTP-date | Last-Modified = "Last-Modified" ":" HTTP-date | |||
An example of its use is | An example of its use is | |||
Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT | Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT | |||
The exact meaning of this header field depends on the implementation | The exact meaning of this header field depends on the implementation | |||
of the origin server and the nature of the original resource. For | of the origin server and the nature of the original resource. For | |||
files, it may be just the file system last-modified time. For | files, it may be just the file system last-modified time. For | |||
entities with dynamically included parts, it may be the most recent | entities with dynamically included parts, it may be the most recent | |||
of the set of last-modify times for its component parts. For | of the set of last-modify times for its component parts. For | |||
skipping to change at page 146, line 32 ¶ | skipping to change at page 146, line 32 ¶ | |||
14.30. Location | 14.30. Location | |||
The Location response-header field is used to redirect the recipient | The Location response-header field is used to redirect the recipient | |||
to a location other than the Request-URI for completion of the | to a location other than the Request-URI for completion of the | |||
request or identification of a new resource. For 201 (Created) | request or identification of a new resource. For 201 (Created) | |||
responses, the Location is that of the new resource which was created | responses, the Location is that of the new resource which was created | |||
by the request. For 3xx responses, the location SHOULD indicate the | by the request. For 3xx responses, the location SHOULD indicate the | |||
server's preferred URI for automatic redirection to the resource. | server's preferred URI for automatic redirection to the resource. | |||
The field value consists of a single absolute URI. | The field value consists of a single absolute URI. | |||
Location = "Location" ":" absoluteURI [ "#" fragment ] | Location = "Location" ":" absoluteURI [ "#" fragment ] | |||
An example is: | An example is: | |||
Location: http://www.example.org/pub/WWW/People.html | Location: http://www.example.org/pub/WWW/People.html | |||
Note: The Content-Location header field (Section 14.14) differs | Note: The Content-Location header field (Section 14.14) differs | |||
from Location in that the Content-Location identifies the original | from Location in that the Content-Location identifies the original | |||
location of the entity enclosed in the request. It is therefore | location of the entity enclosed in the request. It is therefore | |||
possible for a response to contain header fields for both Location | possible for a response to contain header fields for both Location | |||
and Content-Location. Also see Section 13.10 for cache | and Content-Location. Also see Section 13.10 for cache | |||
skipping to change at page 147, line 20 ¶ | skipping to change at page 147, line 20 ¶ | |||
14.31. Max-Forwards | 14.31. Max-Forwards | |||
The Max-Forwards request-header field provides a mechanism with the | The Max-Forwards request-header field provides a mechanism with the | |||
TRACE (Section 9.8) and OPTIONS (Section 9.2) methods to limit the | TRACE (Section 9.8) and OPTIONS (Section 9.2) methods to limit the | |||
number of proxies or gateways that can forward the request to the | number of proxies or gateways that can forward the request to the | |||
next inbound server. This can be useful when the client is | next inbound server. This can be useful when the client is | |||
attempting to trace a request chain which appears to be failing or | attempting to trace a request chain which appears to be failing or | |||
looping in mid-chain. | looping in mid-chain. | |||
Max-Forwards = "Max-Forwards" ":" 1*DIGIT | Max-Forwards = "Max-Forwards" ":" 1*DIGIT | |||
The Max-Forwards value is a decimal integer indicating the remaining | The Max-Forwards value is a decimal integer indicating the remaining | |||
number of times this request message may be forwarded. | number of times this request message may be forwarded. | |||
Each proxy or gateway recipient of a TRACE or OPTIONS request | Each proxy or gateway recipient of a TRACE or OPTIONS request | |||
containing a Max-Forwards header field MUST check and update its | containing a Max-Forwards header field MUST check and update its | |||
value prior to forwarding the request. If the received value is zero | value prior to forwarding the request. If the received value is zero | |||
(0), the recipient MUST NOT forward the request; instead, it MUST | (0), the recipient MUST NOT forward the request; instead, it MUST | |||
respond as the final recipient. If the received Max-Forwards value | respond as the final recipient. If the received Max-Forwards value | |||
is greater than zero, then the forwarded message MUST contain an | is greater than zero, then the forwarded message MUST contain an | |||
skipping to change at page 147, line 45 ¶ | skipping to change at page 147, line 45 ¶ | |||
it is not explicitly referred to as part of that method definition. | it is not explicitly referred to as part of that method definition. | |||
14.32. Pragma | 14.32. Pragma | |||
The Pragma general-header field is used to include implementation- | The Pragma general-header field is used to include implementation- | |||
specific directives that might apply to any recipient along the | specific directives that might apply to any recipient along the | |||
request/response chain. All pragma directives specify optional | request/response chain. All pragma directives specify optional | |||
behavior from the viewpoint of the protocol; however, some systems | behavior from the viewpoint of the protocol; however, some systems | |||
MAY require that behavior be consistent with the directives. | MAY require that behavior be consistent with the directives. | |||
Pragma = "Pragma" ":" 1#pragma-directive | Pragma = "Pragma" ":" 1#pragma-directive | |||
pragma-directive = "no-cache" | extension-pragma | pragma-directive = "no-cache" | extension-pragma | |||
extension-pragma = token [ "=" ( token | quoted-string ) ] | extension-pragma = token [ "=" ( token | quoted-string ) ] | |||
When the no-cache directive is present in a request message, an | When the no-cache directive is present in a request message, an | |||
application SHOULD forward the request toward the origin server even | application SHOULD forward the request toward the origin server even | |||
if it has a cached copy of what is being requested. This pragma | if it has a cached copy of what is being requested. This pragma | |||
directive has the same semantics as the no-cache cache-directive (see | directive has the same semantics as the no-cache cache-directive (see | |||
Section 14.9) and is defined here for backward compatibility with | Section 14.9) and is defined here for backward compatibility with | |||
HTTP/1.0. Clients SHOULD include both header fields when a no-cache | HTTP/1.0. Clients SHOULD include both header fields when a no-cache | |||
request is sent to a server not known to be HTTP/1.1 compliant. | request is sent to a server not known to be HTTP/1.1 compliant. | |||
Pragma directives MUST be passed through by a proxy or gateway | Pragma directives MUST be passed through by a proxy or gateway | |||
skipping to change at page 148, line 30 ¶ | skipping to change at page 148, line 30 ¶ | |||
header field is not actually specified, it does not provide a | header field is not actually specified, it does not provide a | |||
reliable replacement for "Cache-Control: no-cache" in a response | reliable replacement for "Cache-Control: no-cache" in a response | |||
14.33. Proxy-Authenticate | 14.33. Proxy-Authenticate | |||
The Proxy-Authenticate response-header field MUST be included as part | The Proxy-Authenticate response-header field MUST be included as part | |||
of a 407 (Proxy Authentication Required) response. The field value | of a 407 (Proxy Authentication Required) response. The field value | |||
consists of a challenge that indicates the authentication scheme and | consists of a challenge that indicates the authentication scheme and | |||
parameters applicable to the proxy for this Request-URI. | parameters applicable to the proxy for this Request-URI. | |||
Proxy-Authenticate = "Proxy-Authenticate" ":" 1#challenge | Proxy-Authenticate = "Proxy-Authenticate" ":" 1#challenge | |||
The HTTP access authentication process is described in "HTTP | The HTTP access authentication process is described in "HTTP | |||
Authentication: Basic and Digest Access Authentication" [RFC2617]. | Authentication: Basic and Digest Access Authentication" [RFC2617]. | |||
Unlike WWW-Authenticate, the Proxy-Authenticate header field applies | Unlike WWW-Authenticate, the Proxy-Authenticate header field applies | |||
only to the current connection and SHOULD NOT be passed on to | only to the current connection and SHOULD NOT be passed on to | |||
downstream clients. However, an intermediate proxy might need to | downstream clients. However, an intermediate proxy might need to | |||
obtain its own credentials by requesting them from the downstream | obtain its own credentials by requesting them from the downstream | |||
client, which in some circumstances will appear as if the proxy is | client, which in some circumstances will appear as if the proxy is | |||
forwarding the Proxy-Authenticate header field. | forwarding the Proxy-Authenticate header field. | |||
14.34. Proxy-Authorization | 14.34. Proxy-Authorization | |||
The Proxy-Authorization request-header field allows the client to | The Proxy-Authorization request-header field allows the client to | |||
identify itself (or its user) to a proxy which requires | identify itself (or its user) to a proxy which requires | |||
authentication. The Proxy-Authorization field value consists of | authentication. The Proxy-Authorization field value consists of | |||
credentials containing the authentication information of the user | credentials containing the authentication information of the user | |||
agent for the proxy and/or realm of the resource being requested. | agent for the proxy and/or realm of the resource being requested. | |||
Proxy-Authorization = "Proxy-Authorization" ":" credentials | Proxy-Authorization = "Proxy-Authorization" ":" credentials | |||
The HTTP access authentication process is described in "HTTP | The HTTP access authentication process is described in "HTTP | |||
Authentication: Basic and Digest Access Authentication" [RFC2617]. | Authentication: Basic and Digest Access Authentication" [RFC2617]. | |||
Unlike Authorization, the Proxy-Authorization header field applies | Unlike Authorization, the Proxy-Authorization header field applies | |||
only to the next outbound proxy that demanded authentication using | only to the next outbound proxy that demanded authentication using | |||
the Proxy-Authenticate field. When multiple proxies are used in a | the Proxy-Authenticate field. When multiple proxies are used in a | |||
chain, the Proxy-Authorization header field is consumed by the first | chain, the Proxy-Authorization header field is consumed by the first | |||
outbound proxy that was expecting to receive credentials. A proxy | outbound proxy that was expecting to receive credentials. A proxy | |||
MAY relay the credentials from the client request to the next proxy | MAY relay the credentials from the client request to the next proxy | |||
if that is the mechanism by which the proxies cooperatively | if that is the mechanism by which the proxies cooperatively | |||
skipping to change at page 149, line 29 ¶ | skipping to change at page 149, line 29 ¶ | |||
of bytes, the concept of a byte range is meaningful for any HTTP | of bytes, the concept of a byte range is meaningful for any HTTP | |||
entity. (However, not all clients and servers need to support byte- | entity. (However, not all clients and servers need to support byte- | |||
range operations.) | range operations.) | |||
Byte range specifications in HTTP apply to the sequence of bytes in | Byte range specifications in HTTP apply to the sequence of bytes in | |||
the entity-body (not necessarily the same as the message-body). | the entity-body (not necessarily the same as the message-body). | |||
A byte range operation MAY specify a single range of bytes, or a set | A byte range operation MAY specify a single range of bytes, or a set | |||
of ranges within a single entity. | of ranges within a single entity. | |||
ranges-specifier = byte-ranges-specifier | ranges-specifier = byte-ranges-specifier | |||
byte-ranges-specifier = bytes-unit "=" byte-range-set | byte-ranges-specifier = bytes-unit "=" byte-range-set | |||
byte-range-set = 1#( byte-range-spec | suffix-byte-range-spec ) | byte-range-set = 1#( byte-range-spec | suffix-byte-range-spec ) | |||
byte-range-spec = first-byte-pos "-" [last-byte-pos] | byte-range-spec = first-byte-pos "-" [last-byte-pos] | |||
first-byte-pos = 1*DIGIT | first-byte-pos = 1*DIGIT | |||
last-byte-pos = 1*DIGIT | last-byte-pos = 1*DIGIT | |||
The first-byte-pos value in a byte-range-spec gives the byte-offset | The first-byte-pos value in a byte-range-spec gives the byte-offset | |||
of the first byte in a range. The last-byte-pos value gives the | of the first byte in a range. The last-byte-pos value gives the | |||
byte-offset of the last byte in the range; that is, the byte | byte-offset of the last byte in the range; that is, the byte | |||
positions specified are inclusive. Byte offsets start at zero. | positions specified are inclusive. Byte offsets start at zero. | |||
If the last-byte-pos value is present, it MUST be greater than or | If the last-byte-pos value is present, it MUST be greater than or | |||
equal to the first-byte-pos in that byte-range-spec, or the byte- | equal to the first-byte-pos in that byte-range-spec, or the byte- | |||
range-spec is syntactically invalid. The recipient of a byte-range- | range-spec is syntactically invalid. The recipient of a byte-range- | |||
set that includes one or more syntactically invalid byte-range-spec | set that includes one or more syntactically invalid byte-range-spec | |||
skipping to change at page 150, line 8 ¶ | skipping to change at page 150, line 8 ¶ | |||
set. | set. | |||
If the last-byte-pos value is absent, or if the value is greater than | If the last-byte-pos value is absent, or if the value is greater than | |||
or equal to the current length of the entity-body, last-byte-pos is | or equal to the current length of the entity-body, last-byte-pos is | |||
taken to be equal to one less than the current length of the entity- | taken to be equal to one less than the current length of the entity- | |||
body in bytes. | body in bytes. | |||
By its choice of last-byte-pos, a client can limit the number of | By its choice of last-byte-pos, a client can limit the number of | |||
bytes retrieved without knowing the size of the entity. | bytes retrieved without knowing the size of the entity. | |||
suffix-byte-range-spec = "-" suffix-length | suffix-byte-range-spec = "-" suffix-length | |||
suffix-length = 1*DIGIT | suffix-length = 1*DIGIT | |||
A suffix-byte-range-spec is used to specify the suffix of the entity- | A suffix-byte-range-spec is used to specify the suffix of the entity- | |||
body, of a length given by the suffix-length value. (That is, this | body, of a length given by the suffix-length value. (That is, this | |||
form specifies the last N bytes of an entity-body.) If the entity is | form specifies the last N bytes of an entity-body.) If the entity is | |||
shorter than the specified suffix-length, the entire entity-body is | shorter than the specified suffix-length, the entire entity-body is | |||
used. | used. | |||
If a syntactically valid byte-range-set includes at least one byte- | If a syntactically valid byte-range-set includes at least one byte- | |||
range-spec whose first-byte-pos is less than the current length of | range-spec whose first-byte-pos is less than the current length of | |||
the entity-body, or at least one suffix-byte-range-spec with a non- | the entity-body, or at least one suffix-byte-range-spec with a non- | |||
skipping to change at page 151, line 5 ¶ | skipping to change at page 151, line 5 ¶ | |||
bytes=500-600,601-999 | bytes=500-600,601-999 | |||
bytes=500-700,601-999 | bytes=500-700,601-999 | |||
14.35.2. Range Retrieval Requests | 14.35.2. Range Retrieval Requests | |||
HTTP retrieval requests using conditional or unconditional GET | HTTP retrieval requests using conditional or unconditional GET | |||
methods MAY request one or more sub-ranges of the entity, instead of | methods MAY request one or more sub-ranges of the entity, instead of | |||
the entire entity, using the Range request header, which applies to | the entire entity, using the Range request header, which applies to | |||
the entity returned as the result of the request: | the entity returned as the result of the request: | |||
Range = "Range" ":" ranges-specifier | Range = "Range" ":" ranges-specifier | |||
A server MAY ignore the Range header. However, HTTP/1.1 origin | A server MAY ignore the Range header. However, HTTP/1.1 origin | |||
servers and intermediate caches ought to support byte ranges when | servers and intermediate caches ought to support byte ranges when | |||
possible, since Range supports efficient recovery from partially | possible, since Range supports efficient recovery from partially | |||
failed transfers, and supports efficient partial retrieval of large | failed transfers, and supports efficient partial retrieval of large | |||
entities. | entities. | |||
If the server supports the Range header and the specified range or | If the server supports the Range header and the specified range or | |||
ranges are appropriate for the entity: | ranges are appropriate for the entity: | |||
skipping to change at page 151, line 49 ¶ | skipping to change at page 151, line 49 ¶ | |||
The Referer[sic] request-header field allows the client to specify, | The Referer[sic] request-header field allows the client to specify, | |||
for the server's benefit, the address (URI) of the resource from | for the server's benefit, the address (URI) of the resource from | |||
which the Request-URI was obtained (the "referrer", although the | which the Request-URI was obtained (the "referrer", although the | |||
header field is misspelled.) The Referer request-header allows a | header field is misspelled.) The Referer request-header allows a | |||
server to generate lists of back-links to resources for interest, | server to generate lists of back-links to resources for interest, | |||
logging, optimized caching, etc. It also allows obsolete or mistyped | logging, optimized caching, etc. It also allows obsolete or mistyped | |||
links to be traced for maintenance. The Referer field MUST NOT be | links to be traced for maintenance. The Referer field MUST NOT be | |||
sent if the Request-URI was obtained from a source that does not have | sent if the Request-URI was obtained from a source that does not have | |||
its own URI, such as input from the user keyboard. | its own URI, such as input from the user keyboard. | |||
Referer = "Referer" ":" ( absoluteURI | relativeURI ) | Referer = "Referer" ":" ( absoluteURI | relativeURI ) | |||
Example: | Example: | |||
Referer: http://www.example.org/hypertext/Overview.html | Referer: http://www.example.org/hypertext/Overview.html | |||
If the field value is a relative URI, it SHOULD be interpreted | If the field value is a relative URI, it SHOULD be interpreted | |||
relative to the Request-URI. The URI MUST NOT include a fragment. | relative to the Request-URI. The URI MUST NOT include a fragment. | |||
See Section 15.1.3 for security considerations. | See Section 15.1.3 for security considerations. | |||
14.37. Retry-After | 14.37. Retry-After | |||
The Retry-After response-header field can be used with a 503 (Service | The Retry-After response-header field can be used with a 503 (Service | |||
Unavailable) response to indicate how long the service is expected to | Unavailable) response to indicate how long the service is expected to | |||
be unavailable to the requesting client. This field MAY also be used | be unavailable to the requesting client. This field MAY also be used | |||
with any 3xx (Redirection) response to indicate the minimum time the | with any 3xx (Redirection) response to indicate the minimum time the | |||
user-agent is asked wait before issuing the redirected request. The | user-agent is asked wait before issuing the redirected request. The | |||
value of this field can be either an HTTP-date or an integer number | value of this field can be either an HTTP-date or an integer number | |||
of seconds (in decimal) after the time of the response. | of seconds (in decimal) after the time of the response. | |||
Retry-After = "Retry-After" ":" ( HTTP-date | delta-seconds ) | Retry-After = "Retry-After" ":" ( HTTP-date | delta-seconds ) | |||
Two examples of its use are | Two examples of its use are | |||
Retry-After: Fri, 31 Dec 1999 23:59:59 GMT | Retry-After: Fri, 31 Dec 1999 23:59:59 GMT | |||
Retry-After: 120 | Retry-After: 120 | |||
In the latter example, the delay is 2 minutes. | In the latter example, the delay is 2 minutes. | |||
14.38. Server | 14.38. Server | |||
The Server response-header field contains information about the | The Server response-header field contains information about the | |||
software used by the origin server to handle the request. The field | software used by the origin server to handle the request. The field | |||
can contain multiple product tokens (Section 3.8) and comments | can contain multiple product tokens (Section 3.8) and comments | |||
identifying the server and any significant subproducts. The product | identifying the server and any significant subproducts. The product | |||
tokens are listed in order of their significance for identifying the | tokens are listed in order of their significance for identifying the | |||
application. | application. | |||
Server = "Server" ":" 1*( product | comment ) | Server = "Server" ":" 1*( product | comment ) | |||
Example: | Example: | |||
Server: CERN/3.0 libwww/2.17 | Server: CERN/3.0 libwww/2.17 | |||
If the response is being forwarded through a proxy, the proxy | If the response is being forwarded through a proxy, the proxy | |||
application MUST NOT modify the Server response-header. Instead, it | application MUST NOT modify the Server response-header. Instead, it | |||
MUST include a Via field (as described in Section 14.45). | MUST include a Via field (as described in Section 14.45). | |||
Note: Revealing the specific software version of the server might | Note: Revealing the specific software version of the server might | |||
skipping to change at page 153, line 15 ¶ | skipping to change at page 153, line 15 ¶ | |||
14.39. TE | 14.39. TE | |||
The TE request-header field indicates what extension transfer-codings | The TE request-header field indicates what extension transfer-codings | |||
it is willing to accept in the response and whether or not it is | it is willing to accept in the response and whether or not it is | |||
willing to accept trailer fields in a chunked transfer-coding. Its | willing to accept trailer fields in a chunked transfer-coding. Its | |||
value may consist of the keyword "trailers" and/or a comma-separated | value may consist of the keyword "trailers" and/or a comma-separated | |||
list of extension transfer-coding names with optional accept | list of extension transfer-coding names with optional accept | |||
parameters (as described in Section 3.6). | parameters (as described in Section 3.6). | |||
TE = "TE" ":" #( t-codings ) | TE = "TE" ":" #( t-codings ) | |||
t-codings = "trailers" | ( transfer-extension [ accept-params ] ) | t-codings = "trailers" | ( transfer-extension [ accept-params ] ) | |||
The presence of the keyword "trailers" indicates that the client is | The presence of the keyword "trailers" indicates that the client is | |||
willing to accept trailer fields in a chunked transfer-coding, as | willing to accept trailer fields in a chunked transfer-coding, as | |||
defined in Section 3.6.1. This keyword is reserved for use with | defined in Section 3.6.1. This keyword is reserved for use with | |||
transfer-coding values even though it does not itself represent a | transfer-coding values even though it does not itself represent a | |||
transfer-coding. | transfer-coding. | |||
Examples of its use are: | Examples of its use are: | |||
TE: deflate | TE: deflate | |||
skipping to change at page 154, line 21 ¶ | skipping to change at page 154, line 21 ¶ | |||
If the TE field-value is empty or if no TE field is present, the only | If the TE field-value is empty or if no TE field is present, the only | |||
transfer-coding is "chunked". A message with no transfer-coding is | transfer-coding is "chunked". A message with no transfer-coding is | |||
always acceptable. | always acceptable. | |||
14.40. Trailer | 14.40. Trailer | |||
The Trailer general field value indicates that the given set of | The Trailer general field value indicates that the given set of | |||
header fields is present in the trailer of a message encoded with | header fields is present in the trailer of a message encoded with | |||
chunked transfer-coding. | chunked transfer-coding. | |||
Trailer = "Trailer" ":" 1#field-name | Trailer = "Trailer" ":" 1#field-name | |||
An HTTP/1.1 message SHOULD include a Trailer header field in a | An HTTP/1.1 message SHOULD include a Trailer header field in a | |||
message using chunked transfer-coding with a non-empty trailer. | message using chunked transfer-coding with a non-empty trailer. | |||
Doing so allows the recipient to know which header fields to expect | Doing so allows the recipient to know which header fields to expect | |||
in the trailer. | in the trailer. | |||
If no Trailer header field is present, the trailer SHOULD NOT include | If no Trailer header field is present, the trailer SHOULD NOT include | |||
any header fields. See Section 3.6.1 for restrictions on the use of | any header fields. See Section 3.6.1 for restrictions on the use of | |||
trailer fields in a "chunked" transfer-coding. | trailer fields in a "chunked" transfer-coding. | |||
skipping to change at page 155, line 23 ¶ | skipping to change at page 155, line 23 ¶ | |||
Encoding header. | Encoding header. | |||
14.42. Upgrade | 14.42. Upgrade | |||
The Upgrade general-header allows the client to specify what | The Upgrade general-header allows the client to specify what | |||
additional communication protocols it supports and would like to use | additional communication protocols it supports and would like to use | |||
if the server finds it appropriate to switch protocols. The server | if the server finds it appropriate to switch protocols. The server | |||
MUST use the Upgrade header field within a 101 (Switching Protocols) | MUST use the Upgrade header field within a 101 (Switching Protocols) | |||
response to indicate which protocol(s) are being switched. | response to indicate which protocol(s) are being switched. | |||
Upgrade = "Upgrade" ":" 1#product | Upgrade = "Upgrade" ":" 1#product | |||
For example, | For example, | |||
Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 | Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 | |||
The Upgrade header field is intended to provide a simple mechanism | The Upgrade header field is intended to provide a simple mechanism | |||
for transition from HTTP/1.1 to some other, incompatible protocol. | for transition from HTTP/1.1 to some other, incompatible protocol. | |||
It does so by allowing the client to advertise its desire to use | It does so by allowing the client to advertise its desire to use | |||
another protocol, such as a later version of HTTP with a higher major | another protocol, such as a later version of HTTP with a higher major | |||
version number, even though the current request has been made using | version number, even though the current request has been made using | |||
skipping to change at page 156, line 30 ¶ | skipping to change at page 156, line 30 ¶ | |||
user agent originating the request. This is for statistical | user agent originating the request. This is for statistical | |||
purposes, the tracing of protocol violations, and automated | purposes, the tracing of protocol violations, and automated | |||
recognition of user agents for the sake of tailoring responses to | recognition of user agents for the sake of tailoring responses to | |||
avoid particular user agent limitations. User agents SHOULD include | avoid particular user agent limitations. User agents SHOULD include | |||
this field with requests. The field can contain multiple product | this field with requests. The field can contain multiple product | |||
tokens (Section 3.8) and comments identifying the agent and any | tokens (Section 3.8) and comments identifying the agent and any | |||
subproducts which form a significant part of the user agent. By | subproducts which form a significant part of the user agent. By | |||
convention, the product tokens are listed in order of their | convention, the product tokens are listed in order of their | |||
significance for identifying the application. | significance for identifying the application. | |||
User-Agent = "User-Agent" ":" 1*( product | comment ) | User-Agent = "User-Agent" ":" 1*( product | comment ) | |||
Example: | Example: | |||
User-Agent: CERN-LineMode/2.15 libwww/2.17b3 | User-Agent: CERN-LineMode/2.15 libwww/2.17b3 | |||
14.44. Vary | 14.44. Vary | |||
The Vary field value indicates the set of request-header fields that | The Vary field value indicates the set of request-header fields that | |||
fully determines, while the response is fresh, whether a cache is | fully determines, while the response is fresh, whether a cache is | |||
permitted to use the response to reply to a subsequent request | permitted to use the response to reply to a subsequent request | |||
without revalidation. For uncacheable or stale responses, the Vary | without revalidation. For uncacheable or stale responses, the Vary | |||
field value advises the user agent about the criteria that were used | field value advises the user agent about the criteria that were used | |||
to select the representation. A Vary field value of "*" implies that | to select the representation. A Vary field value of "*" implies that | |||
a cache cannot determine from the request headers of a subsequent | a cache cannot determine from the request headers of a subsequent | |||
request whether this response is the appropriate representation. See | request whether this response is the appropriate representation. See | |||
Section 13.6 for use of the Vary header field by caches. | Section 13.6 for use of the Vary header field by caches. | |||
Vary = "Vary" ":" ( "*" | 1#field-name ) | Vary = "Vary" ":" ( "*" | 1#field-name ) | |||
An HTTP/1.1 server SHOULD include a Vary header field with any | An HTTP/1.1 server SHOULD include a Vary header field with any | |||
cacheable response that is subject to server-driven negotiation. | cacheable response that is subject to server-driven negotiation. | |||
Doing so allows a cache to properly interpret future requests on that | Doing so allows a cache to properly interpret future requests on that | |||
resource and informs the user agent about the presence of negotiation | resource and informs the user agent about the presence of negotiation | |||
on that resource. A server MAY include a Vary header field with a | on that resource. A server MAY include a Vary header field with a | |||
non-cacheable response that is subject to server-driven negotiation, | non-cacheable response that is subject to server-driven negotiation, | |||
since this might provide the user agent with useful information about | since this might provide the user agent with useful information about | |||
the dimensions over which the response varies at the time of the | the dimensions over which the response varies at the time of the | |||
skipping to change at page 157, line 37 ¶ | skipping to change at page 157, 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 | |||
The received-protocol indicates the protocol version of the message | The received-protocol indicates the protocol version of the message | |||
received by the server or client along each segment of the request/ | received by the server or client along each segment of the request/ | |||
response chain. The received-protocol version is appended to the Via | response chain. The received-protocol version is appended to the Via | |||
field value when the message is forwarded so that information about | field value when the message is forwarded so that information about | |||
the protocol capabilities of upstream applications remains visible to | the protocol capabilities of upstream applications remains visible to | |||
all recipients. | all recipients. | |||
The protocol-name is optional if and only if it would be "HTTP". The | The protocol-name is optional if and only if it would be "HTTP". The | |||
received-by field is normally the host and optional port number of a | received-by field is normally the host and optional port number of a | |||
skipping to change at page 159, line 19 ¶ | skipping to change at page 159, line 19 ¶ | |||
The Warning general-header field is used to carry additional | The Warning general-header field is used to carry additional | |||
information about the status or transformation of a message which | information about the status or transformation of a message which | |||
might not be reflected in the message. This information is typically | might not be reflected in the message. This information is typically | |||
used to warn about a possible lack of semantic transparency from | used to warn about a possible lack of semantic transparency from | |||
caching operations or transformations applied to the entity body of | caching operations or transformations applied to the entity body of | |||
the message. | the message. | |||
Warning headers are sent with responses using: | Warning headers are sent with responses using: | |||
Warning = "Warning" ":" 1#warning-value | Warning = "Warning" ":" 1#warning-value | |||
warning-value = warn-code SP warn-agent SP warn-text | warning-value = warn-code SP warn-agent SP warn-text | |||
[SP warn-date] | [SP warn-date] | |||
warn-code = 3DIGIT | warn-code = 3DIGIT | |||
warn-agent = ( host [ ":" port ] ) | pseudonym | warn-agent = ( host [ ":" port ] ) | pseudonym | |||
; the name or pseudonym of the server adding | ; the name or pseudonym of the server adding | |||
; the Warning header, for use in debugging | ; the Warning header, for use in debugging | |||
warn-text = quoted-string | warn-text = quoted-string | |||
warn-date = <"> HTTP-date <"> | warn-date = <"> HTTP-date <"> | |||
A response MAY carry more than one Warning header. | A response MAY carry more than one Warning header. | |||
The warn-text SHOULD be in a natural language and character set that | The warn-text SHOULD be in a natural language and character set that | |||
is most likely to be intelligible to the human user receiving the | is most likely to be intelligible to the human user receiving the | |||
response. This decision MAY be based on any available knowledge, | response. This decision MAY be based on any available knowledge, | |||
such as the location of the cache or user, the Accept-Language field | such as the location of the cache or user, the Accept-Language field | |||
in a request, the Content-Language field in a response, etc. The | in a request, the Content-Language field in a response, etc. The | |||
default language is English and the default character set is ISO- | default language is English and the default character set is ISO- | |||
8859-1. | 8859-1. | |||
skipping to change at page 161, line 43 ¶ | skipping to change at page 161, line 43 ¶ | |||
of the warning-values are deleted for this reason, the Warning header | of the warning-values are deleted for this reason, the Warning header | |||
MUST be deleted as well. | MUST be deleted as well. | |||
14.47. WWW-Authenticate | 14.47. WWW-Authenticate | |||
The WWW-Authenticate response-header field MUST be included in 401 | The WWW-Authenticate response-header field MUST be included in 401 | |||
(Unauthorized) response messages. The field value consists of at | (Unauthorized) response messages. The field value consists of at | |||
least one challenge that indicates the authentication scheme(s) and | least one challenge that indicates the authentication scheme(s) and | |||
parameters applicable to the Request-URI. | parameters applicable to the Request-URI. | |||
WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge | WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge | |||
The HTTP access authentication process is described in "HTTP | The HTTP access authentication process is described in "HTTP | |||
Authentication: Basic and Digest Access Authentication" [RFC2617]. | Authentication: Basic and Digest Access Authentication" [RFC2617]. | |||
User agents are advised to take special care in parsing the WWW- | User agents are advised to take special care in parsing the WWW- | |||
Authenticate field value as it might contain more than one challenge, | Authenticate field value as it might contain more than one challenge, | |||
or if more than one WWW-Authenticate header field is provided, the | or if more than one WWW-Authenticate header field is provided, the | |||
contents of a challenge itself can contain a comma-separated list of | contents of a challenge itself can contain a comma-separated list of | |||
authentication parameters. | authentication parameters. | |||
15. Security Considerations | 15. Security Considerations | |||
skipping to change at page 168, line 10 ¶ | skipping to change at page 168, 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 169, line 23 ¶ | skipping to change at page 169, 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 181, line 8 ¶ | skipping to change at page 181, 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 181, line 35 ¶ | skipping to change at page 181, line 35 ¶ | |||
D.1. MIME-Version | D.1. MIME-Version | |||
HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages | HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages | |||
MAY include a single MIME-Version general-header field to indicate | MAY include a single MIME-Version general-header field to indicate | |||
what version of the MIME protocol was used to construct the message. | what version of the MIME protocol was used to construct the message. | |||
Use of the MIME-Version header field indicates that the message is in | Use of the MIME-Version header field indicates that the message is in | |||
full compliance with the MIME protocol (as defined in [RFC2045]). | full compliance with the MIME protocol (as defined in [RFC2045]). | |||
Proxies/gateways are responsible for ensuring full compliance (where | Proxies/gateways are responsible for ensuring full compliance (where | |||
possible) when exporting HTTP messages to strict MIME environments. | possible) when exporting HTTP messages to strict MIME environments. | |||
MIME-Version = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT | MIME-Version = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT | |||
MIME version "1.0" is the default for use in HTTP/1.1. However, | MIME version "1.0" is the default for use in HTTP/1.1. However, | |||
HTTP/1.1 message parsing and semantics are defined by this document | HTTP/1.1 message parsing and semantics are defined by this document | |||
and not the MIME specification. | and not the MIME specification. | |||
D.2. Conversion to Canonical Form | D.2. Conversion to Canonical Form | |||
[RFC2045] requires that an Internet mail entity be converted to | [RFC2045] requires that an Internet mail entity be converted to | |||
canonical form prior to being transferred, as described in Section 4 | canonical form prior to being transferred, as described in Section 4 | |||
of [RFC2049]. Section 3.7.1 of this document describes the forms | of [RFC2049]. Section 3.7.1 of this document describes the forms | |||
skipping to change at page 182, line 41 ¶ | skipping to change at page 182, 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 183, line 32 ¶ | skipping to change at page 183, 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 184, line 26 ¶ | skipping to change at page 184, line 26 ¶ | |||
A number of other headers, such as Content-Disposition and Title, | A number of other headers, such as Content-Disposition and Title, | |||
from SMTP and MIME are also often implemented (see [RFC2076]). | from SMTP and MIME are also often implemented (see [RFC2076]). | |||
E.1. Content-Disposition | E.1. Content-Disposition | |||
The Content-Disposition response-header field has been proposed as a | The Content-Disposition response-header field has been proposed as a | |||
means for the origin server to suggest a default filename if the user | means for the origin server to suggest a default filename if the user | |||
requests that the content is saved to a file. This usage is derived | requests that the content is saved to a file. This usage is derived | |||
from the definition of Content-Disposition in [RFC1806]. | from the definition of Content-Disposition in [RFC1806]. | |||
content-disposition = "Content-Disposition" ":" | content-disposition = "Content-Disposition" ":" | |||
disposition-type *( ";" disposition-parm ) | disposition-type *( ";" disposition-parm ) | |||
disposition-type = "attachment" | disp-extension-token | disposition-type = "attachment" | disp-extension-token | |||
disposition-parm = filename-parm | disp-extension-parm | disposition-parm = filename-parm | disp-extension-parm | |||
filename-parm = "filename" "=" quoted-string | filename-parm = "filename" "=" quoted-string | |||
disp-extension-token = token | disp-extension-token = token | |||
disp-extension-parm = token "=" ( token | quoted-string ) | disp-extension-parm = token "=" ( token | quoted-string ) | |||
An example is | An example is | |||
Content-Disposition: attachment; filename="fname.ext" | Content-Disposition: attachment; filename="fname.ext" | |||
The receiving user agent SHOULD NOT respect any directory path | The receiving user agent SHOULD NOT respect any directory path | |||
information present in the filename-parm parameter, which is the only | information present in the filename-parm parameter, which is the only | |||
parameter believed to apply to HTTP implementations at this time. | parameter believed to apply to HTTP implementations at this time. | |||
The filename SHOULD be treated as a terminal component only. | The filename SHOULD be treated as a terminal component only. | |||
skipping to change at page 187, line 20 ¶ | skipping to change at page 187, 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 189, line 33 ¶ | skipping to change at page 189, 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 189, line 48 ¶ | skipping to change at page 190, line 4 ¶ | |||
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) | |||
Clarification that the chunk length does not include the count of the | Clarification that the chunk length does not include the count of the | |||
octets in the chunk header and trailer. (Section 3.6.1) | octets in the chunk header and trailer. (Section 3.6.1) | |||
Fix BNF to add query, as the abs_path production in Section 3 of | Fix BNF to add query, as the abs_path production in Section 3 of | |||
[RFC2396] doesn't define it. (Section 5.1.2) | [RFC2396] doesn't define it. (Section 5.1.2) | |||
Clarify definition of POST. (Section 9.5) | Clarify definition of POST. (Section 9.5) | |||
Clarify that it's not ok to use a weak cache validator in a 206 | Clarify that it's not ok to use a weak cache validator in a 206 | |||
response. (Section 10.2.7) | response. (Section 10.2.7) | |||
Failed to consider that there are many other request methods that are | Failed to consider that there are many other request methods that are | |||
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 193, line 5 ¶ | skipping to change at page 192, 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 197, line 36 ¶ | skipping to change at page 204, 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: | ||||
"If the port is empty or not given, port 80 is assumed. The | 3.2.2 really doesn't say what identifies the resource: | |||
semantics are that the identified resource is located at the server | ||||
listening for TCP connections on that port of that host, and the | "If the port is empty or not given, port 80 is assumed. The | |||
Request-URI for the resource is abs_path (Section 5.1.2)." | semantics are that the identified resource is located at the | |||
But it *does* say what part of the HTTP URL becomes the Request-URI, | server listening for TCP connections on that port of that host, | |||
and the Request-URI for the resource is abs_path (Section 5.1.2)." | ||||
-- 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 | ||||