draft-ietf-httpbis-p1-messaging-07.txt | draft-ietf-httpbis-p1-messaging-08.txt | |||
---|---|---|---|---|
HTTPbis Working Group R. Fielding, Ed. | HTTPbis Working Group R. Fielding, Ed. | |||
Internet-Draft Day Software | Internet-Draft Day Software | |||
Obsoletes: 2616 (if approved) J. Gettys | Obsoletes: 2616 (if approved) J. Gettys | |||
Intended status: Standards Track One Laptop per Child | Updates: 2817 (if approved) One Laptop per Child | |||
Expires: January 14, 2010 J. Mogul | Intended status: Standards Track J. Mogul | |||
HP | Expires: April 29, 2010 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 | |||
July 13, 2009 | October 26, 2009 | |||
HTTP/1.1, part 1: URIs, Connections, and Message Parsing | HTTP/1.1, part 1: URIs, Connections, and Message Parsing | |||
draft-ietf-httpbis-p1-messaging-07 | draft-ietf-httpbis-p1-messaging-08 | |||
Status of this Memo | Status of this Memo | |||
This Internet-Draft is submitted to IETF in full conformance with the | This Internet-Draft is submitted to IETF in full conformance with the | |||
provisions of BCP 78 and BCP 79. This document may contain material | provisions of BCP 78 and BCP 79. This document may contain material | |||
from IETF Documents or IETF Contributions published or made publicly | from IETF Documents or IETF Contributions published or made publicly | |||
available before November 10, 2008. The person(s) controlling the | available before November 10, 2008. The person(s) controlling the | |||
copyright in some of this material may not have granted the IETF | copyright in some of this material may not have granted the IETF | |||
Trust the right to allow modifications of such material outside the | Trust the right to allow modifications of such material outside the | |||
IETF Standards Process. Without obtaining an adequate license from | IETF Standards Process. Without obtaining an adequate license from | |||
skipping to change at page 2, line 10 | skipping to change at page 2, line 10 | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
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 14, 2010. | This Internet-Draft will expire on April 29, 2010. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2009 IETF Trust and the persons identified as the | Copyright (c) 2009 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents in effect on the date of | Provisions Relating to IETF Documents in effect on the date of | |||
publication of this document (http://trustee.ietf.org/license-info). | publication of this document (http://trustee.ietf.org/license-info). | |||
Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
skipping to change at page 2, line 44 | skipping to change at page 2, line 44 | |||
frames, and describes general security concerns for implementations. | frames, and describes general security concerns for implementations. | |||
Editorial Note (To be removed by RFC Editor) | Editorial Note (To be removed by RFC Editor) | |||
Discussion of this draft should take place on the HTTPBIS working | Discussion of this draft should take place on the HTTPBIS working | |||
group mailing list (ietf-http-wg@w3.org). The current issues list is | group mailing list (ietf-http-wg@w3.org). The current issues list is | |||
at <http://tools.ietf.org/wg/httpbis/trac/report/11> and related | at <http://tools.ietf.org/wg/httpbis/trac/report/11> and related | |||
documents (including fancy diffs) can be found at | documents (including fancy diffs) can be found at | |||
<http://tools.ietf.org/wg/httpbis/>. | <http://tools.ietf.org/wg/httpbis/>. | |||
The changes in this draft are summarized in Appendix E.8. | The changes in this draft are summarized in Appendix D.9. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7 | 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7 | 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7 | |||
1.2.1. ABNF Extension: #rule . . . . . . . . . . . . . . . . 7 | 1.2.1. ABNF Extension: #rule . . . . . . . . . . . . . . . . 7 | |||
1.2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . 8 | 1.2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . 8 | |||
1.2.3. ABNF Rules defined in other Parts of the | 1.2.3. ABNF Rules defined in other Parts of the | |||
Specification . . . . . . . . . . . . . . . . . . . . 9 | Specification . . . . . . . . . . . . . . . . . . . . 9 | |||
2. HTTP architecture . . . . . . . . . . . . . . . . . . . . . . 10 | 2. HTTP architecture . . . . . . . . . . . . . . . . . . . . . . 10 | |||
2.1. Uniform Resource Identifiers . . . . . . . . . . . . . . . 10 | 2.1. Client/Server Operation . . . . . . . . . . . . . . . . . 10 | |||
2.1.1. http URI scheme . . . . . . . . . . . . . . . . . . . 11 | 2.2. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 11 | |||
2.1.2. https URI scheme . . . . . . . . . . . . . . . . . . . 11 | 2.3. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
2.1.3. URI Comparison . . . . . . . . . . . . . . . . . . . . 11 | 2.4. Transport Independence . . . . . . . . . . . . . . . . . . 13 | |||
2.1.4. Scheme aliases considered harmful . . . . . . . . . . 12 | 2.5. HTTP Version . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
2.2. Overall Operation . . . . . . . . . . . . . . . . . . . . 12 | 2.6. Uniform Resource Identifiers . . . . . . . . . . . . . . . 15 | |||
2.3. Use of HTTP for proxy communication . . . . . . . . . . . 14 | 2.6.1. http URI scheme . . . . . . . . . . . . . . . . . . . 16 | |||
2.4. Interception of HTTP for access control . . . . . . . . . 14 | 2.6.2. https URI scheme . . . . . . . . . . . . . . . . . . . 17 | |||
2.5. Use of HTTP by other protocols . . . . . . . . . . . . . . 14 | 2.6.3. http and https URI Normalization and Comparison . . . 17 | |||
2.6. Use of HTTP by media type specification . . . . . . . . . 14 | 3. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
3. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 14 | 3.1. Message Parsing Robustness . . . . . . . . . . . . . . . . 19 | |||
3.1. HTTP Version . . . . . . . . . . . . . . . . . . . . . . . 14 | 3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 19 | |||
3.2. Date/Time Formats: Full Date . . . . . . . . . . . . . . . 15 | 3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 21 | |||
3.3. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 18 | 3.4. Message Length . . . . . . . . . . . . . . . . . . . . . . 22 | |||
3.3.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 19 | 3.5. General Header Fields . . . . . . . . . . . . . . . . . . 23 | |||
3.4. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 21 | 4. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 | |||
3.5. Quality Values . . . . . . . . . . . . . . . . . . . . . . 22 | 4.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 24 | |||
4. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . . 22 | 4.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 24 | |||
4.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 22 | 4.1.2. request-target . . . . . . . . . . . . . . . . . . . . 24 | |||
4.2. Message Headers . . . . . . . . . . . . . . . . . . . . . 23 | 4.2. The Resource Identified by a Request . . . . . . . . . . . 26 | |||
4.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 24 | 5. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 | |||
4.4. Message Length . . . . . . . . . . . . . . . . . . . . . . 25 | 5.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 27 | |||
4.5. General Header Fields . . . . . . . . . . . . . . . . . . 27 | 5.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 28 | |||
5. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 | 6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 28 | |||
5.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 27 | 6.1. Date/Time Formats: Full Date . . . . . . . . . . . . . . . 28 | |||
5.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 28 | 6.2. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 31 | |||
5.1.2. request-target . . . . . . . . . . . . . . . . . . . . 28 | 6.2.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 32 | |||
5.2. The Resource Identified by a Request . . . . . . . . . . . 30 | 6.2.2. Compression Codings . . . . . . . . . . . . . . . . . 34 | |||
6. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 | 6.2.3. Transfer Coding Registry . . . . . . . . . . . . . . . 35 | |||
6.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 31 | 6.3. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 35 | |||
6.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 31 | 6.4. Quality Values . . . . . . . . . . . . . . . . . . . . . . 36 | |||
7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 32 | 7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 36 | |||
7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 32 | 7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 36 | |||
7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 32 | 7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 36 | |||
7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 32 | 7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 37 | |||
7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 34 | 7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 38 | |||
7.1.4. Practical Considerations . . . . . . . . . . . . . . . 34 | 7.1.4. Practical Considerations . . . . . . . . . . . . . . . 39 | |||
7.2. Message Transmission Requirements . . . . . . . . . . . . 35 | 7.2. Message Transmission Requirements . . . . . . . . . . . . 40 | |||
7.2.1. Persistent Connections and Flow Control . . . . . . . 35 | 7.2.1. Persistent Connections and Flow Control . . . . . . . 40 | |||
7.2.2. Monitoring Connections for Error Status Messages . . . 35 | 7.2.2. Monitoring Connections for Error Status Messages . . . 40 | |||
7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 36 | 7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 40 | |||
7.2.4. Client Behavior if Server Prematurely Closes | 7.2.4. Client Behavior if Server Prematurely Closes | |||
Connection . . . . . . . . . . . . . . . . . . . . . . 38 | Connection . . . . . . . . . . . . . . . . . . . . . . 42 | |||
8. Header Field Definitions . . . . . . . . . . . . . . . . . . . 38 | 8. Miscellaneous notes that may disappear . . . . . . . . . . . . 43 | |||
8.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 39 | 8.1. Scheme aliases considered harmful . . . . . . . . . . . . 43 | |||
8.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 40 | 8.2. Use of HTTP for proxy communication . . . . . . . . . . . 43 | |||
8.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 | 8.3. Interception of HTTP for access control . . . . . . . . . 43 | |||
8.3.1. Clockless Origin Server Operation . . . . . . . . . . 41 | 8.4. Use of HTTP by other protocols . . . . . . . . . . . . . . 44 | |||
8.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 | 8.5. Use of HTTP by media type specification . . . . . . . . . 44 | |||
8.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 | 9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 44 | |||
8.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 44 | 9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 44 | |||
8.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 44 | 9.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 45 | |||
8.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 45 | 9.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 | |||
8.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 | 9.3.1. Clockless Origin Server Operation . . . . . . . . . . 47 | |||
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 | 9.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 | |||
9.1. Message Header Registration . . . . . . . . . . . . . . . 47 | 9.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 | |||
9.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 48 | 9.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 49 | |||
9.3. Internet Media Type Registrations . . . . . . . . . . . . 48 | 9.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 49 | |||
9.3.1. Internet Media Type message/http . . . . . . . . . . . 48 | 9.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 50 | |||
9.3.2. Internet Media Type application/http . . . . . . . . . 49 | 9.8.1. Upgrade Token Registry . . . . . . . . . . . . . . . . 51 | |||
10. Security Considerations . . . . . . . . . . . . . . . . . . . 50 | 9.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 | |||
10.1. Personal Information . . . . . . . . . . . . . . . . . . . 51 | 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 | |||
10.2. Abuse of Server Log Information . . . . . . . . . . . . . 51 | 10.1. Message Header Registration . . . . . . . . . . . . . . . 53 | |||
10.3. Attacks Based On File and Path Names . . . . . . . . . . . 51 | 10.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 54 | |||
10.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 51 | 10.3. Internet Media Type Registrations . . . . . . . . . . . . 54 | |||
10.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 52 | 10.3.1. Internet Media Type message/http . . . . . . . . . . . 54 | |||
10.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 53 | 10.3.2. Internet Media Type application/http . . . . . . . . . 55 | |||
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53 | 10.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 56 | |||
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54 | 10.5. Upgrade Token Registration . . . . . . . . . . . . . . . . 57 | |||
12.1. Normative References . . . . . . . . . . . . . . . . . . . 54 | 11. Security Considerations . . . . . . . . . . . . . . . . . . . 57 | |||
12.2. Informative References . . . . . . . . . . . . . . . . . . 55 | 11.1. Personal Information . . . . . . . . . . . . . . . . . . . 57 | |||
Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 57 | 11.2. Abuse of Server Log Information . . . . . . . . . . . . . 58 | |||
Appendix B. Compatibility with Previous Versions . . . . . . . . 58 | 11.3. Attacks Based On File and Path Names . . . . . . . . . . . 58 | |||
B.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 59 | 11.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 58 | |||
11.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 59 | ||||
11.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 60 | ||||
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 60 | ||||
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 61 | ||||
13.1. Normative References . . . . . . . . . . . . . . . . . . . 61 | ||||
13.2. Informative References . . . . . . . . . . . . . . . . . . 62 | ||||
Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 64 | ||||
Appendix B. Compatibility with Previous Versions . . . . . . . . 65 | ||||
B.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 66 | ||||
B.1.1. Changes to Simplify Multi-homed Web Servers and | B.1.1. Changes to Simplify Multi-homed Web Servers and | |||
Conserve IP Addresses . . . . . . . . . . . . . . . . 59 | Conserve IP Addresses . . . . . . . . . . . . . . . . 66 | |||
B.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 59 | B.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 67 | |||
B.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 60 | B.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 67 | |||
B.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 61 | B.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 68 | |||
Appendix C. Terminology . . . . . . . . . . . . . . . . . . . . . 61 | Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 69 | |||
Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 64 | Appendix D. Change Log (to be removed by RFC Editor before | |||
Appendix E. Change Log (to be removed by RFC Editor before | publication) . . . . . . . . . . . . . . . . . . . . 73 | |||
publication) . . . . . . . . . . . . . . . . . . . . 69 | D.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 73 | |||
E.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 69 | D.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 73 | |||
E.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 69 | D.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 75 | |||
E.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 70 | D.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 76 | |||
E.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 71 | D.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 76 | |||
E.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 72 | D.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 77 | |||
E.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 72 | D.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 77 | |||
E.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 73 | D.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 78 | |||
E.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 74 | D.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 79 | |||
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 78 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 84 | |||
1. Introduction | 1. Introduction | |||
The Hypertext Transfer Protocol (HTTP) is an application-level | The Hypertext Transfer Protocol (HTTP) is an application-level | |||
request/response protocol that uses extensible semantics and MIME- | request/response protocol that uses extensible semantics and MIME- | |||
like message payloads for flexible interaction with network-based | like message payloads for flexible interaction with network-based | |||
hypertext information systems. HTTP relies upon the Uniform Resource | hypertext information systems. HTTP relies upon the Uniform Resource | |||
Identifier (URI) standard [RFC3986] to indicate request targets and | Identifier (URI) standard [RFC3986] to indicate request targets and | |||
relationships between resources. Messages are passed in a format | relationships between resources. Messages are passed in a format | |||
similar to that used by Internet mail [RFC5322] and the Multipurpose | similar to that used by Internet mail [RFC5322] and the Multipurpose | |||
skipping to change at page 6, line 47 | skipping to change at page 6, line 47 | |||
received communication, and the expected behavior of recipients. If | received communication, and the expected behavior of recipients. If | |||
the communication is considered in isolation, then successful actions | the communication is considered in isolation, then successful actions | |||
should be reflected in corresponding changes to the observable | should be reflected in corresponding changes to the observable | |||
interface provided by servers. However, since multiple clients may | interface provided by servers. However, since multiple clients may | |||
act in parallel and perhaps at cross-purposes, we cannot require that | act in parallel and perhaps at cross-purposes, we cannot require that | |||
such changes be observable beyond the scope of a single response. | such changes be observable beyond the scope of a single response. | |||
This document is Part 1 of the seven-part specification of HTTP, | This document is Part 1 of the seven-part specification of HTTP, | |||
defining the protocol referred to as "HTTP/1.1" and obsoleting | defining the protocol referred to as "HTTP/1.1" and obsoleting | |||
[RFC2616]. Part 1 describes the architectural elements that are used | [RFC2616]. Part 1 describes the architectural elements that are used | |||
or referred to in HTTP and defines the URI schemes specific to HTTP- | or referred to in HTTP, defines the "http" and "https" URI schemes, | |||
based resources, overall network operation, connection management, | describes overall network operation and connection management, and | |||
and HTTP message framing and forwarding requirements. Our goal is to | defines HTTP message framing and forwarding requirements. Our goal | |||
define all of the mechanisms necessary for HTTP message handling that | is to define all of the mechanisms necessary for HTTP message | |||
are independent of message semantics, thereby defining the complete | handling that are independent of message semantics, thereby defining | |||
set of requirements for message parsers and message-forwarding | the complete set of requirements for message parsers and message- | |||
intermediaries. | forwarding intermediaries. | |||
1.1. Requirements | 1.1. 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]. | |||
An implementation is not compliant if it fails to satisfy one or more | An implementation is not compliant if it fails to satisfy one or more | |||
of the MUST or REQUIRED level requirements for the protocols it | of the MUST or REQUIRED level requirements for the protocols it | |||
implements. An implementation that satisfies all the MUST or | implements. An implementation that satisfies all the MUST or | |||
skipping to change at page 8, line 17 | skipping to change at page 8, line 17 | |||
<n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element ) | <n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element ) | |||
For compatibility with legacy list rules, recipients SHOULD accept | For compatibility with legacy list rules, recipients SHOULD accept | |||
empty list elements. In other words, consumers would follow the list | empty list elements. In other words, consumers would follow the list | |||
productions: | productions: | |||
#element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ] | #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ] | |||
1#element => *( "," OWS ) element *( OWS "," [ OWS element ] ) | 1#element => *( "," OWS ) element *( OWS "," [ OWS element ] ) | |||
Appendix D shows the collected ABNF, with the list rules expanded as | Appendix C shows the collected ABNF, with the list rules expanded as | |||
explained above. | explained above. | |||
1.2.2. Basic Rules | 1.2.2. Basic Rules | |||
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 A for tolerant | protocol elements except the entity-body (see Appendix A 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 2.3 of | defined by its associated media type, as described in Section 2.3 of | |||
[Part3]. | [Part3]. | |||
skipping to change at page 9, line 12 | skipping to change at page 9, line 12 | |||
remove it before interpreting the field value or forwarding the | remove it before interpreting the field value or forwarding the | |||
message downstream. | message downstream. | |||
OWS = *( [ obs-fold ] WSP ) | OWS = *( [ obs-fold ] WSP ) | |||
; "optional" whitespace | ; "optional" whitespace | |||
RWS = 1*( [ obs-fold ] WSP ) | RWS = 1*( [ obs-fold ] WSP ) | |||
; "required" whitespace | ; "required" whitespace | |||
BWS = OWS | BWS = OWS | |||
; "bad" whitespace | ; "bad" whitespace | |||
obs-fold = CRLF | obs-fold = CRLF | |||
; see Section 4.2 | ; see Section 3.2 | |||
Many HTTP/1.1 header field values consist of words separated by | Many HTTP/1.1 header field values consist of words separated by | |||
whitespace or special characters. These special characters MUST be | whitespace or special characters. These special characters MUST be | |||
in a quoted string to be used within a parameter value (as defined in | in a quoted string to be used within a parameter value (as defined in | |||
Section 3.3). | Section 6.2). | |||
tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" | tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" | |||
/ "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" | / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" | |||
/ DIGIT / ALPHA | / DIGIT / ALPHA | |||
token = 1*tchar | token = 1*tchar | |||
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 = DQUOTE *( qdtext / quoted-pair ) DQUOTE | quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE | |||
qdtext = OWS / %x21 / %x23-5B / %x5D-7E / obs-text | qdtext = OWS / %x21 / %x23-5B / %x5D-7E / obs-text | |||
; OWS / <VCHAR except DQUOTE and "\"> / obs-text | ; OWS / <VCHAR except DQUOTE and "\"> / obs-text | |||
obs-text = %x80-FF | obs-text = %x80-FF | |||
The backslash character ("\") MAY be used as a single-character | The backslash character ("\") can be used as a single-character | |||
quoting mechanism only within quoted-string and comment constructs. | quoting mechanism within quoted-string constructs: | |||
quoted-text = %x01-09 / | quoted-pair = "\" ( WSP / VCHAR / obs-text ) | |||
%x0B-0C / | ||||
%x0E-FF ; Characters excluding NUL, CR and LF | Producers SHOULD NOT escape characters that do not require escaping | |||
quoted-pair = "\" quoted-text | (i.e., other than DQUOTE and the backslash character). | |||
1.2.3. ABNF Rules defined in other Parts of the Specification | 1.2.3. ABNF Rules defined in other Parts of the Specification | |||
The ABNF rules below are defined in other parts: | The ABNF rules below are defined in other parts: | |||
request-header = <request-header, defined in [Part2], Section 3> | request-header = <request-header, defined in [Part2], Section 3> | |||
response-header = <response-header, defined in [Part2], Section 5> | response-header = <response-header, defined in [Part2], Section 5> | |||
entity-body = <entity-body, defined in [Part3], Section 3.2> | entity-body = <entity-body, defined in [Part3], Section 3.2> | |||
entity-header = <entity-header, defined in [Part3], Section 3.1> | entity-header = <entity-header, defined in [Part3], Section 3.1> | |||
Cache-Control = <Cache-Control, defined in [Part6], Section 3.4> | Cache-Control = <Cache-Control, defined in [Part6], Section 3.4> | |||
Pragma = <Pragma, defined in [Part6], Section 3.4> | Pragma = <Pragma, defined in [Part6], Section 3.4> | |||
Warning = <Warning, defined in [Part6], Section 3.6> | Warning = <Warning, defined in [Part6], Section 3.6> | |||
2. HTTP architecture | 2. HTTP architecture | |||
HTTP was created with a specific architecture in mind, the World Wide | HTTP was created for the World Wide Web architecture and has evolved | |||
Web, and has evolved over time to support the scalability needs of a | over time to support the scalability needs of a worldwide hypertext | |||
worldwide hypertext system. Much of that architecture is reflected | system. Much of that architecture is reflected in the terminology | |||
in the terminology and syntax productions used to define HTTP. | and syntax productions used to define HTTP. | |||
2.1. Uniform Resource Identifiers | ||||
Uniform Resource Identifiers (URIs) [RFC3986] are used throughout | ||||
HTTP as the means for identifying resources. URI references are used | ||||
to target requests, redirect responses, and define relationships. | ||||
HTTP does not limit what a resource may be; it merely defines an | ||||
interface that can be used to interact with a resource via HTTP. | ||||
More information on the scope of URIs and resources can be found in | ||||
[RFC3986]. | ||||
This specification adopts the definitions of "URI-reference", | ||||
"absolute-URI", "relative-part", "fragment", "port", "host", "path- | ||||
abempty", "path-absolute", "query", and "authority" from [RFC3986]. | ||||
In addition, we define a partial-URI rule for protocol elements that | ||||
allow a relative URI without a fragment. | ||||
URI = <URI, defined in [RFC3986], Section 3> | ||||
URI-reference = <URI-reference, defined in [RFC3986], Section 4.1> | ||||
absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3> | ||||
relative-part = <relative-part, defined in [RFC3986], Section 4.2> | ||||
authority = <authority, defined in [RFC3986], Section 3.2> | ||||
fragment = <fragment, defined in [RFC3986], Section 3.5> | ||||
path-abempty = <path-abempty, defined in [RFC3986], Section 3.3> | ||||
path-absolute = <path-absolute, defined in [RFC3986], Section 3.3> | ||||
port = <port, defined in [RFC3986], Section 3.2.3> | ||||
query = <query, defined in [RFC3986], Section 3.4> | ||||
uri-host = <host, defined in [RFC3986], Section 3.2.2> | ||||
partial-URI = relative-part [ "?" query ] | ||||
Each protocol element in HTTP that allows a URI reference will | ||||
indicate in its ABNF production whether the element allows only a URI | ||||
in absolute form (absolute-URI), any relative reference (relative- | ||||
ref), or some other subset of the URI-reference grammar. Unless | ||||
otherwise indicated, URI references are parsed relative to the | ||||
request target (the default base URI for both the request and its | ||||
corresponding response). | ||||
2.1.1. http URI scheme | ||||
The "http" scheme is used to locate network resources via the HTTP | ||||
protocol. | ||||
http-URI = "http:" "//" authority path-abempty [ "?" query ] | ||||
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 | ||||
for TCP connections on that port of that host, and the request-target | ||||
for the resource is path-absolute (Section 5.1.2). The use of IP | ||||
addresses in URLs SHOULD be avoided whenever possible (see | ||||
[RFC1900]). If the path-absolute is not present in the URL, it MUST | ||||
be given as "/" when used as a request-target for a resource | ||||
(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 | ||||
it received. If a proxy receives a fully qualified domain name, the | ||||
proxy MUST NOT change the host name. | ||||
2.1.2. https URI scheme | ||||
[[anchor1: TBD: Define and explain purpose of https scheme.]] | ||||
Note: the "https" scheme is defined in [RFC2818]. | ||||
2.1.3. URI Comparison | 2.1. Client/Server Operation | |||
When comparing two URIs to decide if they match or not, a client | HTTP is a request/response protocol that operates by exchanging | |||
SHOULD use a case-sensitive octet-by-octet comparison of the entire | messages across a reliable transport or session-layer connection. An | |||
URIs, with these exceptions: | HTTP client is a program that establishes a connection to a server | |||
for the purpose of sending one or more HTTP requests. An HTTP server | ||||
is a program that accepts connections in order to service HTTP | ||||
requests by sending HTTP responses. | ||||
o A port that is empty or not given is equivalent to the default | Note that the terms "client" and "server" refer only to the roles | |||
port for that URI-reference; | that these programs perform for a particular connection. The same | |||
program may act as a client on some connections and a server on | ||||
others. We use the term "user agent" to refer to the program that | ||||
initiates a request, such as a WWW browser, editor, or spider (web- | ||||
traversing robot), and the term "origin server" to refer to the | ||||
program that can originate authoritative responses to a request. | ||||
o Comparisons of host names MUST be case-insensitive; | Most HTTP communication consists of a retrieval request (GET) for a | |||
representation of some resource identified by a URI. In the simplest | ||||
case, this may be accomplished via a single connection (v) between | ||||
the user agent (UA) and the origin server (O). | ||||
o Comparisons of scheme names MUST be case-insensitive; | request chain ------------------------> | |||
UA -------------------v------------------- O | ||||
<----------------------- response chain | ||||
o An empty path-absolute is equivalent to a path-absolute of "/". | A client sends an HTTP request to the server in the form of a request | |||
message (Section 4), beginning with a method, URI, and protocol | ||||
version, followed by MIME-like header fields containing request | ||||
modifiers, client information, and payload metadata, an empty line to | ||||
indicate the end of the header section, and finally the payload body | ||||
(if any). | ||||
o Characters other than those in the "reserved" set are equivalent | A server responds to the client's request by sending an HTTP response | |||
to their percent-encoded octets (see [RFC3986], Section 2.1). | message (Section 5), beginning with a status line that includes the | |||
protocol version, a success or error code, and textual reason phrase, | ||||
followed by MIME-like header fields containing server information, | ||||
resource metadata, and payload metadata, an empty line to indicate | ||||
the end of the header section, and finally the payload body (if any). | ||||
For example, the following three URIs are equivalent: | The following example illustrates a typical message exchange for a | |||
GET request on the URI "http://www.example.com/hello.txt": | ||||
http://example.com:80/~smith/home.html | client request: | |||
http://EXAMPLE.com/%7Esmith/home.html | ||||
http://EXAMPLE.com:/%7esmith/home.html | ||||
2.1.4. Scheme aliases considered harmful | GET /hello.txt HTTP/1.1 | |||
User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 | ||||
Host: www.example.com | ||||
Accept: */* | ||||
2.2. Overall Operation | server response: | |||
HTTP is a request/response protocol. A client sends a request to the | HTTP/1.1 200 OK | |||
server in the form of a request method, URI, and protocol version, | Date: Mon, 27 Jul 2009 12:28:53 GMT | |||
followed by a MIME-like message containing request modifiers, client | Server: Apache | |||
information, and possible body content over a connection with a | Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT | |||
server. The server responds with a status line, including the | ETag: "34aa387-d-1568eb00" | |||
message's protocol version and a success or error code, followed by a | Accept-Ranges: bytes | |||
MIME-like message containing server information, entity | Content-Length: 14 | |||
metainformation, and possible entity-body content. | Vary: Accept-Encoding | |||
Content-Type: text/plain | ||||
Most HTTP communication is initiated by a user agent and consists of | Hello World! | |||
a request to be applied to a resource on some origin server. In the | ||||
simplest case, this may be accomplished via a single connection (v) | ||||
between the user agent (UA) and the origin server (O). | ||||
request chain ------------------------> | 2.2. Intermediaries | |||
UA -------------------v------------------- O | ||||
<----------------------- response chain | ||||
A more complicated situation occurs when one or more intermediaries | A more complicated situation occurs when one or more intermediaries | |||
are present in the request/response chain. There are three common | are present in the request/response chain. There are three common | |||
forms of intermediary: proxy, gateway, and tunnel. A proxy is a | forms of intermediary: proxy, gateway, and tunnel. In some cases, a | |||
forwarding agent, receiving requests for a URI in its absolute form, | single intermediary may act as an origin server, proxy, gateway, or | |||
rewriting all or part of the message, and forwarding the reformatted | tunnel, switching behavior based on the nature of each request. | |||
request toward the server identified by the URI. A gateway is a | ||||
receiving agent, acting as a layer above some other server(s) and, if | ||||
necessary, translating the requests to the underlying server's | ||||
protocol. A tunnel acts as a relay point between two connections | ||||
without changing the messages; tunnels are used when the | ||||
communication needs to pass through an intermediary (such as a | ||||
firewall) even when the intermediary cannot understand the contents | ||||
of the messages. | ||||
request chain --------------------------------------> | request chain --------------------------------------> | |||
UA -----v----- A -----v----- B -----v----- C -----v----- O | UA -----v----- A -----v----- B -----v----- C -----v----- O | |||
<------------------------------------- response chain | <------------------------------------- response chain | |||
The figure above shows three intermediaries (A, B, and C) between the | The figure above shows three intermediaries (A, B, and C) between the | |||
user agent and origin server. A request or response message that | user agent and origin server. A request or response message that | |||
travels the whole chain will pass through four separate connections. | travels the whole chain will pass through four separate connections. | |||
This distinction is important because some HTTP communication options | Some HTTP communication options may apply only to the connection with | |||
may apply only to the connection with the nearest, non-tunnel | the nearest, non-tunnel neighbor, only to the end-points of the | |||
neighbor, only to the end-points of the chain, or to all connections | chain, or to all connections along the chain. Although the diagram | |||
along the chain. Although the diagram is linear, each participant | is linear, each participant may be engaged in multiple, simultaneous | |||
may be engaged in multiple, simultaneous communications. For | communications. For example, B may be receiving requests from many | |||
example, B may be receiving requests from many clients other than A, | clients other than A, and/or forwarding requests to servers other | |||
and/or forwarding requests to servers other than C, at the same time | than C, at the same time that it is handling A's request. | |||
that it is handling A's request. | ||||
Any party to the communication which is not acting as a tunnel may | We use the terms "upstream" and "downstream" to describe various | |||
employ an internal cache for handling requests. The effect of a | requirements in relation to the directional flow of a message: all | |||
cache is that the request/response chain is shortened if one of the | messages flow from upstream to downstream. Likewise, we use the | |||
participants along the chain has a cached response applicable to that | terms "inbound" and "outbound" to refer to directions in relation to | |||
request. The following illustrates the resulting chain if B has a | the request path: "inbound" means toward the origin server and | |||
cached copy of an earlier response from O (via C) for a request which | "outbound" means toward the user agent. | |||
has not been cached by UA or A. | ||||
A proxy is a message forwarding agent that is selected by the client, | ||||
usually via local configuration rules, to receive requests for some | ||||
type(s) of absolute URI and attempt to satisfy those requests via | ||||
translation through the HTTP interface. Some translations are | ||||
minimal, such as for proxy requests for "http" URIs, whereas other | ||||
requests may require translation to and from entirely different | ||||
application-layer protocols. Proxies are often used to group an | ||||
organization's HTTP requests through a common intermediary for the | ||||
sake of security, annotation services, or shared caching. | ||||
A gateway (a.k.a., reverse proxy) is a receiving agent that acts as a | ||||
layer above some other server(s) and translates the received requests | ||||
to the underlying server's protocol. Gateways are often used for | ||||
load balancing or partitioning HTTP services across multiple | ||||
machines. Unlike a proxy, a gateway receives requests as if it were | ||||
the origin server for the requested resource; the requesting client | ||||
will not be aware that it is communicating with a gateway. A gateway | ||||
communicates with the client as if the gateway is the origin server | ||||
and thus is subject to all of the requirements on origin servers for | ||||
that connection. A gateway communicates with inbound servers using | ||||
any protocol it desires, including private extensions to HTTP that | ||||
are outside the scope of this specification. | ||||
A tunnel acts as a blind relay between two connections without | ||||
changing the messages. Once active, a tunnel is not considered a | ||||
party to the HTTP communication, though the tunnel may have been | ||||
initiated by an HTTP request. A tunnel ceases to exist when both | ||||
ends of the relayed connection are closed. Tunnels are used to | ||||
extend a virtual connection through an intermediary, such as when | ||||
transport-layer security is used to establish private communication | ||||
through a shared firewall proxy. | ||||
2.3. Caches | ||||
Any party to HTTP communication that is not acting as a tunnel may | ||||
employ an internal cache for handling requests. A cache is a local | ||||
store of previous response messages and the subsystem that controls | ||||
its message storage, retrieval, and deletion. A cache stores | ||||
cacheable responses in order to reduce the response time and network | ||||
bandwidth consumption on future, equivalent requests. Any client or | ||||
server may include a cache, though a cache cannot be used by a server | ||||
while it is acting as a tunnel. | ||||
The effect of a cache is that the request/response chain is shortened | ||||
if one of the participants along the chain has a cached response | ||||
applicable to that request. The following illustrates the resulting | ||||
chain if B has a cached copy of an earlier response from O (via C) | ||||
for a request which has not been cached by UA or A. | ||||
request chain ----------> | request chain ----------> | |||
UA -----v----- A -----v----- B - - - - - - C - - - - - - O | UA -----v----- A -----v----- B - - - - - - C - - - - - - O | |||
<--------- response chain | <--------- response chain | |||
Not all responses are usefully cacheable, and some requests may | A response is cacheable if a cache is allowed to store a copy of the | |||
contain modifiers which place special requirements on cache behavior. | response message for use in answering subsequent requests. Even when | |||
HTTP requirements for cache behavior and cacheable responses are | a response is cacheable, there may be additional constraints placed | |||
defined in Section 1 of [Part6]. | by the client or by the origin server on when that cached response | |||
can be used for a particular request. HTTP requirements for cache | ||||
behavior and cacheable responses are defined in Section 2 of [Part6]. | ||||
In fact, there are a wide variety of architectures and configurations | There are a wide variety of architectures and configurations of | |||
of caches and proxies currently being experimented with or deployed | caches and proxies deployed across the World Wide Web and inside | |||
across the World Wide Web. These systems include national hierarchies | large organizations. These systems include national hierarchies of | |||
of proxy caches to save transoceanic bandwidth, systems that | proxy caches to save transoceanic bandwidth, systems that broadcast | |||
broadcast or multicast cache entries, organizations that distribute | or multicast cache entries, organizations that distribute subsets of | |||
subsets of cached data via CD-ROM, and so on. HTTP systems are used | cached data via optical media, and so on. | |||
in corporate intranets over high-bandwidth links, and for access via | ||||
PDAs with low-power radio links and intermittent connectivity. The | 2.4. Transport Independence | |||
goal of HTTP/1.1 is to support the wide diversity of configurations | ||||
already deployed while introducing protocol constructs that meet the | HTTP systems are used in a wide variety of environments, from | |||
needs of those who build web applications that require high | corporate intranets with high-bandwidth links to long-distance | |||
reliability and, failing that, at least reliable indications of | communication over low-power radio links and intermittent | |||
failure. | connectivity. | |||
HTTP communication usually takes place over TCP/IP connections. The | HTTP communication usually takes place over TCP/IP connections. The | |||
default port is TCP 80 | default port is TCP 80 | |||
(<http://www.iana.org/assignments/port-numbers>), but other ports can | (<http://www.iana.org/assignments/port-numbers>), but other ports can | |||
be used. This does not preclude HTTP from being implemented on top | be used. This does not preclude HTTP from being implemented on top | |||
of any other protocol on the Internet, or on other networks. HTTP | of any other protocol on the Internet, or on other networks. HTTP | |||
only presumes a reliable transport; any protocol that provides such | only presumes a reliable transport; any protocol that provides such | |||
guarantees can be used; the mapping of the HTTP/1.1 request and | guarantees can be used; the mapping of the HTTP/1.1 request and | |||
response structures onto the transport data units of the protocol in | response structures onto the transport data units of the protocol in | |||
question is outside the scope of this specification. | question is outside the scope of this specification. | |||
In HTTP/1.0, most implementations used a new connection for each | In HTTP/1.0, most implementations used a new connection for each | |||
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 7.1). | closed for a variety of reasons (see Section 7.1). | |||
2.3. Use of HTTP for proxy communication | 2.5. HTTP Version | |||
[[anchor2: TBD: Configured to use HTTP to proxy HTTP or other | ||||
protocols.]] | ||||
2.4. Interception of HTTP for access control | ||||
[[anchor3: TBD: Interception of HTTP traffic for initiating access | ||||
control.]] | ||||
2.5. Use of HTTP by other protocols | ||||
[[anchor4: TBD: Profiles of HTTP defined by other protocol. | ||||
Extensions of HTTP like WebDAV.]] | ||||
2.6. Use of HTTP by media type specification | ||||
[[anchor5: TBD: Instructions on composing HTTP requests via hypertext | ||||
formats.]] | ||||
3. Protocol Parameters | ||||
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 | |||
number for the addition of message components which do not affect | number for the addition of message components which do not affect | |||
communication behavior or which only add to extensible field values. | communication behavior or which only add to extensible field values. | |||
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 | |||
skipping to change at page 15, line 41 | skipping to change at page 15, line 17 | |||
Due to interoperability problems with HTTP/1.0 proxies discovered | Due to interoperability problems with HTTP/1.0 proxies discovered | |||
since the publication of [RFC2068], caching proxies MUST, gateways | since the publication of [RFC2068], caching proxies MUST, gateways | |||
MAY, and tunnels MUST NOT upgrade the request to the highest version | MAY, and tunnels MUST NOT upgrade the request to the highest version | |||
they support. The proxy/gateway's response to that request MUST be | they support. The proxy/gateway's response to that request MUST be | |||
in the same major version as the request. | in the same major version as the request. | |||
Note: Converting between versions of HTTP may involve modification | Note: Converting between versions of HTTP may involve modification | |||
of header fields required or forbidden by the versions involved. | of header fields required or forbidden by the versions involved. | |||
3.2. Date/Time Formats: Full Date | 2.6. Uniform Resource Identifiers | |||
HTTP applications have historically allowed three different formats | ||||
for the representation of date/time stamps: | ||||
Sun, 06 Nov 1994 08:49:37 GMT ; RFC 1123 | ||||
Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format | ||||
Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format | ||||
The first format is preferred as an Internet standard and represents | ||||
a fixed-length subset of that defined by [RFC1123]. The other | ||||
formats are described here only for compatibility with obsolete | ||||
implementations. HTTP/1.1 clients and servers that parse the date | ||||
value MUST accept all three formats (for compatibility with | ||||
HTTP/1.0), though they MUST only generate the RFC 1123 format for | ||||
representing HTTP-date values in header fields. See Appendix A for | ||||
further information. | ||||
All HTTP date/time stamps MUST be represented in Greenwich Mean Time | ||||
(GMT), without exception. For the purposes of HTTP, GMT is exactly | ||||
equal to UTC (Coordinated Universal Time). This is indicated in the | ||||
first two formats by the inclusion of "GMT" as the three-letter | ||||
abbreviation for time zone, and MUST be assumed when reading the | ||||
asctime format. HTTP-date is case sensitive and MUST NOT include | ||||
additional whitespace beyond that specifically included as SP in the | ||||
grammar. | ||||
HTTP-date = rfc1123-date / obs-date | ||||
Preferred format: | ||||
rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT | ||||
day-name = %x4D.6F.6E ; "Mon", case-sensitive | ||||
/ %x54.75.65 ; "Tue", case-sensitive | ||||
/ %x57.65.64 ; "Wed", case-sensitive | ||||
/ %x54.68.75 ; "Thu", case-sensitive | ||||
/ %x46.72.69 ; "Fri", case-sensitive | ||||
/ %x53.61.74 ; "Sat", case-sensitive | ||||
/ %x53.75.6E ; "Sun", case-sensitive | ||||
date1 = day SP month SP year | ||||
; e.g., 02 Jun 1982 | ||||
day = 2DIGIT | ||||
month = %x4A.61.6E ; "Jan", case-sensitive | ||||
/ %x46.65.62 ; "Feb", case-sensitive | ||||
/ %x4D.61.72 ; "Mar", case-sensitive | ||||
/ %x41.70.72 ; "Apr", case-sensitive | ||||
/ %x4D.61.79 ; "May", case-sensitive | ||||
/ %x4A.75.6E ; "Jun", case-sensitive | ||||
/ %x4A.75.6C ; "Jul", case-sensitive | ||||
/ %x41.75.67 ; "Aug", case-sensitive | ||||
/ %x53.65.70 ; "Sep", case-sensitive | ||||
/ %x4F.63.74 ; "Oct", case-sensitive | ||||
/ %x4E.6F.76 ; "Nov", case-sensitive | ||||
/ %x44.65.63 ; "Dec", case-sensitive | ||||
year = 4DIGIT | ||||
GMT = %x47.4D.54 ; "GMT", case-sensitive | ||||
time-of-day = hour ":" minute ":" second | ||||
; 00:00:00 - 23:59:59 | ||||
hour = 2DIGIT | ||||
minute = 2DIGIT | ||||
second = 2DIGIT | ||||
The semantics of day-name, day, month, year, and time-of-day are the | ||||
same as those defined for the RFC 5322 constructs with the | ||||
corresponding name ([RFC5322], Section 3.3). | ||||
Obsolete formats: | ||||
obs-date = rfc850-date / asctime-date | ||||
rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT | ||||
date2 = day "-" month "-" 2DIGIT | ||||
; day-month-year (e.g., 02-Jun-82) | ||||
day-name-l = %x4D.6F.6E.64.61.79 ; "Monday", case-sensitive | ||||
/ %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive | ||||
/ %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive | ||||
/ %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive | ||||
/ %x46.72.69.64.61.79 ; "Friday", case-sensitive | ||||
/ %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive | ||||
/ %x53.75.6E.64.61.79 ; "Sunday", case-sensitive | ||||
asctime-date = day-name SP date3 SP time-of-day SP year | ||||
date3 = month SP ( 2DIGIT / ( SP 1DIGIT )) | ||||
; month day (e.g., Jun 2) | ||||
Note: Recipients of date values are encouraged to be robust in | ||||
accepting date values that may have been sent by non-HTTP | ||||
applications, as is sometimes the case when retrieving or posting | ||||
messages via proxies/gateways to SMTP or NNTP. | ||||
Note: HTTP requirements for the date/time stamp format apply only | ||||
to their usage within the protocol stream. Clients and servers | ||||
are not required to use these formats for user presentation, | ||||
request logging, etc. | ||||
3.3. Transfer Codings | ||||
Transfer-coding values are used to indicate an encoding | ||||
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. | ||||
This differs from a content coding in that the transfer-coding is a | ||||
property of the message, not of the original entity. | ||||
transfer-coding = "chunked" / transfer-extension | ||||
transfer-extension = token *( OWS ";" OWS transfer-parameter ) | ||||
Parameters are in the form of attribute/value pairs. | ||||
transfer-parameter = attribute BWS "=" BWS value | ||||
attribute = token | ||||
value = token / quoted-string | ||||
All transfer-coding values are case-insensitive. HTTP/1.1 uses | ||||
transfer-coding values in the TE header field (Section 8.5) and in | ||||
the Transfer-Encoding header field (Section 8.7). | ||||
Whenever a transfer-coding is applied to a message-body, the set of | ||||
transfer-codings MUST include "chunked", unless the message indicates | ||||
it is terminated by closing the connection. When the "chunked" | ||||
transfer-coding is used, it MUST be the last transfer-coding applied | ||||
to the message-body. The "chunked" transfer-coding MUST NOT be | ||||
applied more than once to a message-body. These rules allow the | ||||
recipient to determine the transfer-length of the message | ||||
(Section 4.4). | ||||
Transfer-codings are analogous to the Content-Transfer-Encoding | ||||
values of MIME [RFC2045], which were designed to enable safe | ||||
transport of binary data over a 7-bit transport service. However, | ||||
safe transport has a different focus for an 8bit-clean transfer | ||||
protocol. In HTTP, the only unsafe characteristic of message-bodies | ||||
is the difficulty in determining the exact body length (Section 4.4), | ||||
or the desire to encrypt data over a shared transport. | ||||
The Internet Assigned Numbers Authority (IANA) acts as a registry for | ||||
transfer-coding value tokens. Initially, the registry contains the | ||||
following tokens: "chunked" (Section 3.3.1), "gzip", "compress", and | ||||
"deflate" (Section 2.2 of [Part3]). | ||||
New transfer-coding value tokens SHOULD be registered in the same way | ||||
as new content-coding value tokens (Section 2.2 of [Part3]). | ||||
A server which receives an entity-body with a transfer-coding it does | ||||
not understand SHOULD return 501 (Not Implemented), and close the | ||||
connection. A server MUST NOT send transfer-codings to an HTTP/1.0 | ||||
client. | ||||
3.3.1. Chunked Transfer Coding | ||||
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, | ||||
followed by an OPTIONAL trailer containing entity-header fields. | ||||
This allows dynamically produced content to be transferred along with | ||||
the information necessary for the recipient to verify that it has | ||||
received the full message. | ||||
Chunked-Body = *chunk | ||||
last-chunk | ||||
trailer-part | ||||
CRLF | ||||
chunk = chunk-size *WSP [ chunk-ext ] CRLF | Uniform Resource Identifiers (URIs) [RFC3986] are used throughout | |||
chunk-data CRLF | HTTP as the means for identifying resources. URI references are used | |||
chunk-size = 1*HEXDIG | to target requests, indicate redirects, and define relationships. | |||
last-chunk = 1*("0") *WSP [ chunk-ext ] CRLF | HTTP does not limit what a resource may be; it merely defines an | |||
interface that can be used to interact with a resource via HTTP. | ||||
More information on the scope of URIs and resources can be found in | ||||
[RFC3986]. | ||||
chunk-ext = *( ";" *WSP chunk-ext-name | This specification adopts the definitions of "URI-reference", | |||
[ "=" chunk-ext-val ] *WSP ) | "absolute-URI", "relative-part", "port", "host", "path-abempty", | |||
chunk-ext-name = token | "path-absolute", "query", and "authority" from [RFC3986]. In | |||
chunk-ext-val = token / quoted-string | addition, we define a partial-URI rule for protocol elements that | |||
chunk-data = 1*OCTET ; a sequence of chunk-size octets | allow a relative URI without a fragment. | |||
trailer-part = *( entity-header CRLF ) | ||||
The chunk-size field is a string of hex digits indicating the size of | URI = <URI, defined in [RFC3986], Section 3> | |||
the chunk-data in octets. The chunked encoding is ended by any chunk | URI-reference = <URI-reference, defined in [RFC3986], Section 4.1> | |||
whose size is zero, followed by the trailer, which is terminated by | absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3> | |||
an empty line. | relative-part = <relative-part, defined in [RFC3986], Section 4.2> | |||
authority = <authority, defined in [RFC3986], Section 3.2> | ||||
path-abempty = <path-abempty, defined in [RFC3986], Section 3.3> | ||||
path-absolute = <path-absolute, defined in [RFC3986], Section 3.3> | ||||
port = <port, defined in [RFC3986], Section 3.2.3> | ||||
query = <query, defined in [RFC3986], Section 3.4> | ||||
uri-host = <host, defined in [RFC3986], Section 3.2.2> | ||||
The trailer allows the sender to include additional HTTP header | partial-URI = relative-part [ "?" query ] | |||
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 | ||||
Section 8.6). | ||||
A server using chunked transfer-coding in a response MUST NOT use the | Each protocol element in HTTP that allows a URI reference will | |||
trailer for any header fields unless at least one of the following is | indicate in its ABNF production whether the element allows only a URI | |||
true: | in absolute form (absolute-URI), any relative reference (relative- | |||
ref), or some other subset of the URI-reference grammar. Unless | ||||
otherwise indicated, URI references are parsed relative to the | ||||
request target (the default base URI for both the request and its | ||||
corresponding response). | ||||
1. the request included a TE header field that indicates "trailers" | 2.6.1. http URI scheme | |||
is acceptable in the transfer-coding of the response, as | ||||
described in Section 8.5; or, | ||||
2. the server is the origin server for the response, the trailer | The "http" URI scheme is hereby defined for the purpose of minting | |||
fields consist entirely of optional metadata, and the recipient | identifiers according to their association with the hierarchical | |||
could use the message (in a manner acceptable to the origin | namespace governed by a potential HTTP origin server listening for | |||
server) without receiving this metadata. In other words, the | TCP connections on a given port. The HTTP server is identified via | |||
origin server is willing to accept the possibility that the | the generic syntax's authority component, which includes a host | |||
trailer fields might be silently discarded along the path to the | identifier and optional TCP port, and the remainder of the URI is | |||
client. | considered to be identifying data corresponding to a resource for | |||
which that server might provide an HTTP interface. | ||||
This requirement prevents an interoperability failure when the | http-URI = "http:" "//" authority path-abempty [ "?" query ] | |||
message is being received by an HTTP/1.1 (or later) proxy and | ||||
forwarded to an HTTP/1.0 recipient. It avoids a situation where | ||||
compliance with the protocol would have necessitated a possibly | ||||
infinite buffer on the proxy. | ||||
A process for decoding the "chunked" transfer-coding can be | The host identifier within an authority component is defined in | |||
represented in pseudo-code as: | [RFC3986], Section 3.2.2. If host is provided as an IP literal or | |||
IPv4 address, then the HTTP server is any listener on the indicated | ||||
TCP port at that IP address. If host is a registered name, then that | ||||
name is considered an indirect identifier and the recipient might use | ||||
a name resolution service, such as DNS, to find the address of a | ||||
listener for that host. The host MUST NOT be empty; if an "http" URI | ||||
is received with an empty host, then it MUST be rejected as invalid. | ||||
If the port subcomponent is empty or not given, then TCP port 80 is | ||||
assumed (the default reserved port for WWW services). | ||||
length := 0 | Regardless of the form of host identifier, access to that host is not | |||
read chunk-size, chunk-ext (if any) and CRLF | implied by the mere presence of its name or address. The host may or | |||
while (chunk-size > 0) { | may not exist and, even when it does exist, may or may not be running | |||
read chunk-data and CRLF | an HTTP server or listening to the indicated port. The "http" URI | |||
append chunk-data to entity-body | scheme makes use of the delegated nature of Internet names and | |||
length := length + chunk-size | addresses to establish a naming authority (whatever entity has the | |||
read chunk-size and CRLF | ability to place an HTTP server at that Internet name or address) and | |||
} | allows that authority to determine which names are valid and how they | |||
read entity-header | might be used. | |||
while (entity-header not empty) { | ||||
append entity-header to existing header fields | ||||
read entity-header | ||||
} | ||||
Content-Length := length | ||||
Remove "chunked" from Transfer-Encoding | ||||
All HTTP/1.1 applications MUST be able to receive and decode the | When an "http" URI is used within a context that calls for access to | |||
"chunked" transfer-coding, and MUST ignore chunk-ext extensions they | the indicated resource, a client MAY attempt access by resolving the | |||
do not understand. | host to an IP address, establishing a TCP connection to that address | |||
on the indicated port, and sending an HTTP request message to the | ||||
server containing the URI's identifying data as described in | ||||
Section 4. If the server responds to that request with a non-interim | ||||
HTTP response message, as described in Section 5, then that response | ||||
is considered an authoritative answer to the client's request. | ||||
3.4. Product Tokens | Although HTTP is independent of the transport protocol, the "http" | |||
scheme is specific to TCP-based services because the name delegation | ||||
process depends on TCP for establishing authority. An HTTP service | ||||
based on some other underlying connection protocol would presumably | ||||
be identified using a different URI scheme, just as the "https" | ||||
scheme (below) is used for servers that require an SSL/TLS transport | ||||
layer on a connection. Other protocols may also be used to provide | ||||
access to "http" identified resources --- it is only the | ||||
authoritative interface used for mapping the namespace that is | ||||
specific to TCP. | ||||
Product tokens are used to allow communicating applications to | 2.6.2. https URI scheme | |||
identify themselves by software name and version. Most fields using | ||||
product tokens also allow sub-products which form a significant part | ||||
of the application to be listed, separated by whitespace. By | ||||
convention, the products are listed in order of their significance | ||||
for identifying the application. | ||||
product = token ["/" product-version] | The "https" URI scheme is hereby defined for the purpose of minting | |||
product-version = token | identifiers according to their association with the hierarchical | |||
namespace governed by a potential HTTP origin server listening for | ||||
SSL/TLS-secured connections on a given TCP port. The host and port | ||||
are determined in the same way as for the "http" scheme, except that | ||||
a default TCP port of 443 is assumed if the port subcomponent is | ||||
empty or not given. | ||||
Examples: | https-URI = "https:" "//" authority path-abempty [ "?" query ] | |||
User-Agent: CERN-LineMode/2.15 libwww/2.17b3 | The primary difference between the "http" and "https" schemes is that | |||
Server: Apache/0.8.4 | interaction with the latter is required to be secured for privacy | |||
through the use of strong encryption. The URI cannot be sent in a | ||||
request until the connection is secure. Likewise, the default for | ||||
caching is that each response that would be considered "public" under | ||||
the "http" scheme is instead treated as "private" and thus not | ||||
eligible for shared caching. | ||||
Product tokens SHOULD be short and to the point. They MUST NOT be | The process for authoritative access to an "https" identified | |||
used for advertising or other non-essential information. Although | resource is defined in [RFC2818]. | |||
any token character MAY appear in a product-version, this token | ||||
SHOULD only be used for a version identifier (i.e., successive | ||||
versions of the same product SHOULD only differ in the product- | ||||
version portion of the product value). | ||||
3.5. Quality Values | 2.6.3. http and https URI Normalization and Comparison | |||
Both transfer codings (TE request header, Section 8.5) and content | Since the "http" and "https" schemes conform to the URI generic | |||
negotiation (Section 4 of [Part3]) use short "floating point" numbers | syntax, such URIs are normalized and compared according to the | |||
to indicate the relative importance ("weight") of various negotiable | algorithm defined in [RFC3986], Section 6, using the defaults | |||
parameters. A weight is normalized to a real number in the range 0 | described above for each scheme. | |||
through 1, where 0 is the minimum and 1 the maximum value. If a | ||||
parameter has a quality value of 0, then content with this parameter | ||||
is `not acceptable' for the client. HTTP/1.1 applications MUST NOT | ||||
generate more than three digits after the decimal point. User | ||||
configuration of these values SHOULD also be limited in this fashion. | ||||
qvalue = ( "0" [ "." 0*3DIGIT ] ) | If the port is equal to the default port for a scheme, the normal | |||
/ ( "1" [ "." 0*3("0") ] ) | form is to elide the port subcomponent. Likewise, an empty path | |||
component is equivalent to an absolute path of "/", so the normal | ||||
form is to provide a path of "/" instead. The scheme and host are | ||||
case-insensitive and normally provided in lowercase; all other | ||||
components are compared in a case-sensitive manner. Characters other | ||||
than those in the "reserved" set are equivalent to their percent- | ||||
encoded octets (see [RFC3986], Section 2.1): the normal form is to | ||||
not encode them. | ||||
Note: "Quality values" is a misnomer, since these values merely | For example, the following three URIs are equivalent: | |||
represent relative degradation in desired quality. | ||||
4. HTTP Message | http://example.com:80/~smith/home.html | |||
http://EXAMPLE.com/%7Esmith/home.html | ||||
http://EXAMPLE.com:/%7esmith/home.html | ||||
4.1. Message Types | [[anchor1: [[This paragraph does not belong here. --Roy]]]] If path- | |||
abempty is the empty string (i.e., there is no slash "/" path | ||||
separator following the authority), then the "http" URI MUST be given | ||||
as "/" when used as a request-target (Section 4.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 it received. If a proxy receives | ||||
a fully qualified domain name, the proxy MUST NOT change the host | ||||
name. | ||||
HTTP messages consist of requests from client to server and responses | 3. HTTP Message | |||
from server to client. | ||||
HTTP-message = Request / Response ; HTTP/1.1 messages | All HTTP/1.1 messages consist of a start-line followed by a sequence | |||
of characters in a format similar to the Internet Message Format | ||||
[RFC5322]: zero or more header fields (collectively referred to as | ||||
the "headers" or the "header section"), an empty line indicating the | ||||
end of the header section, and an optional message-body. | ||||
Request (Section 5) and Response (Section 6) messages use the generic | An HTTP message can either be a request from client to server or a | |||
message format of [RFC5322] for transferring entities (the payload of | response from server to client. Syntactically, the two types of | |||
the message). Both types of message consist of a start-line, zero or | message differ only in the start-line, which is either a Request-Line | |||
more header fields (also known as "headers"), an empty line (i.e., a | (for requests) or a Status-Line (for responses), and in the algorithm | |||
line with nothing preceding the CRLF) indicating the end of the | for determining the length of the message-body (Section 3.4). In | |||
header fields, and possibly a message-body. | theory, a client could receive requests and a server could receive | |||
responses, distinguishing them by their different start-line formats, | ||||
but in practice servers are implemented to only expect a request (a | ||||
response is interpreted as an unknown or invalid request method) and | ||||
clients are implemented to only expect a response. | ||||
generic-message = start-line | HTTP-message = start-line | |||
*( message-header CRLF ) | *( header-field 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 | ||||
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 | ||||
message and receives a CRLF first, it should ignore the CRLF. | ||||
Certain buggy HTTP/1.0 client implementations generate extra CRLF's | ||||
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 | ||||
extra CRLF. | ||||
Whitespace (WSP) MUST NOT be sent between the start-line and the | Whitespace (WSP) MUST NOT be sent between the start-line and the | |||
first header field. The presence of whitespace might be an attempt | first header field. The presence of whitespace might be an attempt | |||
to trick a noncompliant implementation of HTTP into ignoring that | to trick a noncompliant implementation of HTTP into ignoring that | |||
field or processing the next line as a new request, either of which | field or processing the next line as a new request, either of which | |||
may result in security issues when implementations within the request | may result in security issues when implementations within the request | |||
chain interpret the same message differently. HTTP/1.1 servers MUST | chain interpret the same message differently. HTTP/1.1 servers MUST | |||
reject such a message with a 400 (Bad Request) response. | reject such a message with a 400 (Bad Request) response. | |||
4.2. Message Headers | 3.1. Message Parsing Robustness | |||
HTTP header fields follow the same general format as Internet | In the interest of robustness, servers SHOULD ignore at least one | |||
messages in Section 2.1 of [RFC5322]. Each header field consists of | empty line received where a Request-Line is expected. In other | |||
a name followed by a colon (":"), optional whitespace, and the field | words, if the server is reading the protocol stream at the beginning | |||
value. Field names are case-insensitive. | of a message and receives a CRLF first, it should ignore the CRLF. | |||
message-header = field-name ":" OWS [ field-value ] OWS | Some old HTTP/1.0 client implementations generate an extra CRLF after | |||
a POST request as a lame workaround for some early server | ||||
applications that failed to read message-body content that was not | ||||
terminated by a line-ending. An HTTP/1.1 client MUST NOT preface or | ||||
follow a request with an extra CRLF. If terminating the request | ||||
message-body with a line-ending is desired, then the client MUST | ||||
include the terminating CRLF octets as part of the message-body | ||||
length. | ||||
The normal procedure for parsing an HTTP message is to read the | ||||
start-line into a structure, read each header field into a hash table | ||||
by field name until the empty line, and then use the parsed data to | ||||
determine if a message-body is expected. If a message-body has been | ||||
indicated, then it is read as a stream until an amount of OCTETs | ||||
equal to the message-length is read or the connection is closed. | ||||
Care must be taken to parse an HTTP message as a sequence of OCTETs | ||||
in an encoding that is a superset of US-ASCII. Attempting to parse | ||||
HTTP as a stream of Unicode characters in a character encoding like | ||||
UTF-16 may introduce security flaws due to the differing ways that | ||||
such parsers interpret invalid characters. | ||||
3.2. Header Fields | ||||
Each HTTP header field consists of a case-insensitive field name | ||||
followed by a colon (":"), optional whitespace, and the field value. | ||||
header-field = field-name ":" OWS [ field-value ] OWS | ||||
field-name = token | field-name = token | |||
field-value = *( field-content / OWS ) | field-value = *( field-content / OWS ) | |||
field-content = *( WSP / VCHAR / obs-text ) | field-content = *( WSP / VCHAR / obs-text ) | |||
Historically, HTTP has allowed field-content with text in the ISO- | No whitespace is allowed between the header field name and colon. | |||
8859-1 [ISO-8859-1] character encoding (allowing other character sets | ||||
through use of [RFC2047] encoding). In practice, most HTTP header | ||||
field-values use only a subset of the US-ASCII charset [USASCII]. | ||||
Newly defined header fields SHOULD constrain their field-values to | ||||
US-ASCII characters. Recipients SHOULD treat other (obs-text) octets | ||||
in field-content as opaque data. | ||||
No whitespace is allowed between the header field-name and colon. | ||||
For security reasons, any request message received containing such | For security reasons, any request message received containing such | |||
whitespace MUST be rejected with a response code of 400 (Bad Request) | whitespace MUST be rejected with a response code of 400 (Bad | |||
and any such whitespace in a response message MUST be removed. | Request). A proxy MUST remove any such whitespace from a response | |||
message before forwarding the message downstream. | ||||
The field value MAY be preceded by optional whitespace; a single SP | A field value MAY be preceded by optional whitespace (OWS); a single | |||
is preferred. The field-value does not include any leading or | SP is preferred. The field value does not include any leading or | |||
trailing white space: OWS occurring before the first non-whitespace | trailing white space: OWS 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 is ignored and MAY be removed without | character of the field value is ignored and SHOULD be removed without | |||
changing the meaning of the header field. | changing the meaning of the header field. | |||
The order in which header fields with differing field names are | ||||
received is not significant. However, it is "good practice" to send | ||||
header fields that contain control data first, such as Host on | ||||
requests and Date on responses, so that implementations can decide | ||||
when not to handle a message as early as possible. A server MUST | ||||
wait until the entire header section is received before interpreting | ||||
a request message, since later header fields might include | ||||
conditionals, authentication credentials, or deliberately misleading | ||||
duplicate header fields that would impact request processing. | ||||
Multiple header fields with the same field name MUST NOT be sent in a | ||||
message unless the entire field value for that header field is | ||||
defined as a comma-separated list [i.e., #(values)]. Multiple header | ||||
fields with the same field name can be combined into one "field-name: | ||||
field-value" pair, without changing the semantics of the message, by | ||||
appending each subsequent field value to the combined field value in | ||||
order, separated by a comma. The order in which header fields with | ||||
the same field name are received is therefore significant to the | ||||
interpretation of the combined field value; a proxy MUST NOT change | ||||
the order of these field values when forwarding a message. | ||||
Note: the "Set-Cookie" header as implemented in practice (as | ||||
opposed to how it is specified in [RFC2109]) can occur multiple | ||||
times, but does not use the list syntax, and thus cannot be | ||||
combined into a single line. (See Appendix A.2.3 of [Kri2001] for | ||||
details.) Also note that the Set-Cookie2 header specified in | ||||
[RFC2965] does not share this problem. | ||||
Historically, HTTP header field values could be extended over | Historically, HTTP header field values could be extended over | |||
multiple lines by preceding each extra line with at least one space | multiple lines by preceding each extra line with at least one space | |||
or horizontal tab character (line folding). This specification | or horizontal tab character (line folding). This specification | |||
deprecates such line folding except within the message/http media | deprecates such line folding except within the message/http media | |||
type (Section 9.3.1). HTTP/1.1 senders MUST NOT produce messages | type (Section 10.3.1). HTTP/1.1 senders MUST NOT produce messages | |||
that include line folding (i.e., that contain any field-content that | that include line folding (i.e., that contain any field-content that | |||
matches the obs-fold rule) unless the message is intended for | matches the obs-fold rule) unless the message is intended for | |||
packaging within the message/http media type. HTTP/1.1 recipients | packaging within the message/http media type. HTTP/1.1 recipients | |||
SHOULD accept line folding and replace any embedded obs-fold | SHOULD accept line folding and replace any embedded obs-fold | |||
whitespace with a single SP prior to interpreting the field value or | whitespace with a single SP prior to interpreting the field value or | |||
forwarding the message downstream. | forwarding the message downstream. | |||
Historically, HTTP has allowed field content with text in the ISO- | ||||
8859-1 [ISO-8859-1] character encoding and supported other character | ||||
sets only through use of [RFC2047] encoding. In practice, most HTTP | ||||
header field values use only a subset of the US-ASCII character | ||||
encoding [USASCII]. Newly defined header fields SHOULD limit their | ||||
field values to US-ASCII characters. Recipients SHOULD treat other | ||||
(obs-text) octets in field content as opaque data. | ||||
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 | ||||
value. | ||||
comment = "(" *( ctext / quoted-pair / comment ) ")" | comment = "(" *( ctext / quoted-cpair / comment ) ")" | |||
ctext = OWS / %x21-27 / %x2A-5B / %x5D-7E / obs-text | ctext = OWS / %x21-27 / %x2A-5B / %x5D-7E / obs-text | |||
; OWS / <VCHAR except "(", ")", and "\"> / obs-text | ; OWS / <VCHAR except "(", ")", and "\"> / obs-text | |||
The order in which header fields with differing field names are | The backslash character ("\") can be used as a single-character | |||
received is not significant. However, it is "good practice" to send | quoting mechanism within comment constructs: | |||
general-header fields first, followed by request-header or response- | ||||
header fields, and ending with the entity-header fields. | ||||
Multiple message-header fields with the same field-name MAY be | quoted-cpair = "\" ( WSP / VCHAR / obs-text ) | |||
present in a message if and only if the entire field-value for that | ||||
header field is defined as a comma-separated list [i.e., #(values)]. | ||||
It MUST be possible to combine the multiple header fields into one | ||||
"field-name: field-value" pair, without changing the semantics of the | ||||
message, by appending each subsequent field-value to the first, each | ||||
separated by a comma. The order in which header fields with the same | ||||
field-name are received is therefore significant to the | ||||
interpretation of the combined field value, and thus a proxy MUST NOT | ||||
change the order of these field values when a message is forwarded. | ||||
Note: the "Set-Cookie" header as implemented in practice (as | Producers SHOULD NOT escape characters that do not require escaping | |||
opposed to how it is specified in [RFC2109]) can occur multiple | (i.e., other than the backslash character "\" and the parentheses "(" | |||
times, but does not use the list syntax, and thus cannot be | and ")"). | |||
combined into a single line. (See Appendix A.2.3 of [Kri2001] for | ||||
details.) Also note that the Set-Cookie2 header specified in | ||||
[RFC2965] does not share this problem. | ||||
4.3. Message Body | 3.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 8.7). | (Section 9.7). | |||
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.3 places restrictions on | request/response chain. (However, Section 6.2 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. | |||
The presence of a message-body in a request is signaled by the | The presence of a message-body in a request is signaled by the | |||
inclusion of a Content-Length or Transfer-Encoding header field in | inclusion of a Content-Length or Transfer-Encoding header field in | |||
the request's message-headers. When a request message contains both | the request's header fields. When a request message contains both a | |||
a message-body of non-zero length and a method that does not define | message-body of non-zero length and a method that does not define any | |||
any semantics for that request message-body, then an origin server | semantics for that request message-body, then an origin server SHOULD | |||
SHOULD either ignore the message-body or respond with an appropriate | either ignore the message-body or respond with an appropriate error | |||
error message (e.g., 413). A proxy or gateway, when presented the | message (e.g., 413). A proxy or gateway, when presented the same | |||
same request, SHOULD either forward the request inbound with the | request, SHOULD either forward the request inbound with the message- | |||
message-body or ignore the message-body when determining a response. | body or ignore the message-body when determining a response. | |||
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 5.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 | 3.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): | |||
1. Any response message which "MUST NOT" include a message-body | 1. Any response message which "MUST NOT" include a message-body | |||
(such as the 1xx, 204, and 304 responses and any response to a | (such as the 1xx, 204, and 304 responses and any response to a | |||
HEAD request) is always terminated by the first empty line after | HEAD request) is always terminated by the first empty line after | |||
the header fields, regardless of the entity-header fields present | the header fields, regardless of the entity-header fields present | |||
in the message. | in the message. | |||
2. If a Transfer-Encoding header field (Section 8.7) is present and | 2. If a Transfer-Encoding header field (Section 9.7) is present and | |||
the "chunked" transfer-coding (Section 3.3) is used, the | the "chunked" transfer-coding (Section 6.2) is used, the | |||
transfer-length is defined by the use of this transfer-coding. | transfer-length is defined by the use of this transfer-coding. | |||
If a Transfer-Encoding header field is present and the "chunked" | If a Transfer-Encoding header field is present and the "chunked" | |||
transfer-coding is not present, the transfer-length is defined by | transfer-coding is not present, the transfer-length is defined by | |||
the sender closing the connection. | the sender closing the connection. | |||
3. If a Content-Length header field (Section 8.2) is present, its | 3. If a Content-Length header field (Section 9.2) is present, its | |||
value in OCTETs represents both the entity-length and the | value in OCTETs represents both the entity-length and the | |||
transfer-length. The Content-Length header field MUST NOT be | transfer-length. The Content-Length header field MUST NOT be | |||
sent if these two lengths are different (i.e., if a Transfer- | sent if these two lengths are different (i.e., if a Transfer- | |||
Encoding header field is present). If a message is received with | Encoding header field is present). If a message is received with | |||
both a Transfer-Encoding header field and a Content-Length header | both a Transfer-Encoding header field and a Content-Length header | |||
field, the latter MUST be ignored. | field, the latter MUST be ignored. | |||
4. If the message uses the media type "multipart/byteranges", and | 4. If the message uses the media type "multipart/byteranges", and | |||
the transfer-length is not otherwise specified, then this self- | the transfer-length is not otherwise specified, then this self- | |||
delimiting media type defines the transfer-length. This media | delimiting media type defines the transfer-length. This media | |||
skipping to change at page 26, line 44 | skipping to change at page 23, line 24 | |||
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.3), thus allowing this mechanism | "chunked" transfer-coding (Section 6.2), 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. | |||
When a Content-Length is given in a message where a message-body is | When a Content-Length is given in a message where a message-body is | |||
allowed, its field value MUST exactly match the number of OCTETs in | allowed, its field value MUST exactly match the number of OCTETs in | |||
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 | 3.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 ; [Part6], Section 3.2 | general-header = Cache-Control ; [Part6], Section 3.2 | |||
/ Connection ; Section 8.1 | / Connection ; Section 9.1 | |||
/ Date ; Section 8.3 | / Date ; Section 9.3 | |||
/ Pragma ; [Part6], Section 3.4 | / Pragma ; [Part6], Section 3.4 | |||
/ Trailer ; Section 8.6 | / Trailer ; Section 9.6 | |||
/ Transfer-Encoding ; Section 8.7 | / Transfer-Encoding ; Section 9.7 | |||
/ Upgrade ; Section 8.8 | / Upgrade ; Section 9.8 | |||
/ Via ; Section 8.9 | / Via ; Section 9.9 | |||
/ Warning ; [Part6], Section 3.6 | / Warning ; [Part6], Section 3.6 | |||
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 | 4. 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 4.1 | |||
*(( general-header ; Section 4.5 | *(( general-header ; Section 3.5 | |||
/ request-header ; [Part2], Section 3 | / request-header ; [Part2], Section 3 | |||
/ entity-header ) CRLF ) ; [Part3], Section 3.1 | / entity-header ) CRLF ) ; [Part3], Section 3.1 | |||
CRLF | CRLF | |||
[ message-body ] ; Section 4.3 | [ message-body ] ; Section 3.3 | |||
5.1. Request-Line | 4.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- | |||
target and the protocol version, and ending with CRLF. The elements | target and the protocol version, and ending with CRLF. The elements | |||
are separated by SP characters. No CR or LF is allowed except in the | are separated by SP characters. No CR or LF is allowed except in the | |||
final CRLF sequence. | final CRLF sequence. | |||
Request-Line = Method SP request-target SP HTTP-Version CRLF | Request-Line = Method SP request-target SP HTTP-Version CRLF | |||
5.1.1. Method | 4.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-target. The method is case-sensitive. | identified by the request-target. The method is case-sensitive. | |||
Method = token | Method = token | |||
5.1.2. request-target | 4.1.2. request-target | |||
The request-target identifies the resource upon which to apply the | The request-target identifies the resource upon which to apply the | |||
request. | request. | |||
request-target = "*" | request-target = "*" | |||
/ absolute-URI | / absolute-URI | |||
/ ( path-absolute [ "?" query ] ) | / ( path-absolute [ "?" query ] ) | |||
/ authority | / authority | |||
The four options for request-target are dependent on the nature of | The four options for request-target are dependent on the nature of | |||
skipping to change at page 29, line 7 | skipping to change at page 25, line 32 | |||
To allow for transition to absolute-URIs in all requests in future | To allow for transition to absolute-URIs in all requests in future | |||
versions of HTTP, all HTTP/1.1 servers MUST accept the absolute-URI | versions of HTTP, all HTTP/1.1 servers MUST accept the absolute-URI | |||
form in requests, even though HTTP/1.1 clients will only generate | form in requests, even though HTTP/1.1 clients will only generate | |||
them in requests to proxies. | them in requests to proxies. | |||
The authority form is only used by the CONNECT method (Section 7.9 of | The authority form is only used by the CONNECT method (Section 7.9 of | |||
[Part2]). | [Part2]). | |||
The most common form of request-target is that used to identify a | The most common form of request-target is that used to identify a | |||
resource on an origin server or gateway. In this case the absolute | resource on an origin server or gateway. In this case the absolute | |||
path of the URI MUST be transmitted (see Section 2.1.1, path- | path of the URI MUST be transmitted (see Section 2.6.1, path- | |||
absolute) as the request-target, and the network location of the URI | absolute) as the request-target, and the network location of the URI | |||
(authority) MUST be transmitted in a Host header field. For example, | (authority) MUST be transmitted in a Host header field. For example, | |||
a client wishing to retrieve the resource above directly from the | a client wishing to retrieve the resource above directly from the | |||
origin server would create a TCP connection to port 80 of the host | origin server would create a TCP connection to port 80 of the host | |||
"www.example.org" and send the lines: | "www.example.org" and send the lines: | |||
GET /pub/WWW/TheProject.html HTTP/1.1 | GET /pub/WWW/TheProject.html HTTP/1.1 | |||
Host: www.example.org | Host: www.example.org | |||
followed by the remainder of the Request. Note that the absolute | followed by the remainder of the Request. Note that the absolute | |||
skipping to change at page 29, line 38 | skipping to change at page 26, line 17 | |||
OPTIONS http://www.example.org:8001 HTTP/1.1 | OPTIONS http://www.example.org:8001 HTTP/1.1 | |||
would be forwarded by the proxy as | would be forwarded by the proxy as | |||
OPTIONS * HTTP/1.1 | OPTIONS * HTTP/1.1 | |||
Host: www.example.org:8001 | Host: www.example.org:8001 | |||
after connecting to port 8001 of host "www.example.org". | after connecting to port 8001 of host "www.example.org". | |||
The request-target is transmitted in the format specified in | The request-target is transmitted in the format specified in | |||
Section 2.1.1. If the request-target is percent-encoded ([RFC3986], | Section 2.6.1. If the request-target is percent-encoded ([RFC3986], | |||
Section 2.1), the origin server MUST decode the request-target in | Section 2.1), the origin server MUST decode the request-target in | |||
order to properly interpret the request. Servers SHOULD respond to | order to properly interpret the request. Servers SHOULD respond to | |||
invalid request-targets with an appropriate status code. | invalid request-targets with an appropriate status code. | |||
A transparent proxy MUST NOT rewrite the "path-absolute" part of the | A transparent proxy MUST NOT rewrite the "path-absolute" part of the | |||
received request-target when forwarding it to the next inbound | received request-target when forwarding it to the next inbound | |||
server, except as noted above to replace a null path-absolute with | server, except as noted above to replace a null path-absolute with | |||
"/". | "/". | |||
Note: The "no rewrite" rule prevents the proxy from changing the | Note: The "no rewrite" rule prevents the proxy from changing the | |||
skipping to change at page 30, line 15 | skipping to change at page 26, line 43 | |||
HTTP does not place a pre-defined limit on the length of a request- | HTTP does not place a pre-defined limit on the length of a request- | |||
target. A server MUST be prepared to receive URIs of unbounded | target. A server MUST be prepared to receive URIs of unbounded | |||
length and respond with the 414 (URI Too Long) status if the received | length and respond with the 414 (URI Too Long) status if the received | |||
request-target would be longer than the server wishes to handle (see | request-target would be longer than the server wishes to handle (see | |||
Section 8.4.15 of [Part2]). | Section 8.4.15 of [Part2]). | |||
Various ad-hoc limitations on request-target length are found in | Various ad-hoc limitations on request-target length are found in | |||
practice. It is RECOMMENDED that all HTTP senders and recipients | practice. It is RECOMMENDED that all HTTP senders and recipients | |||
support request-target lengths of 8000 or more OCTETs. | support request-target lengths of 8000 or more OCTETs. | |||
5.2. The Resource Identified by a Request | 4.2. The Resource Identified by a Request | |||
The exact resource identified by an Internet request is determined by | The exact resource identified by an Internet request is determined by | |||
examining both the request-target and the Host header field. | examining both the request-target and the Host header field. | |||
An origin server that does not allow resources to differ by the | An origin server that does not allow resources to differ by the | |||
requested host MAY ignore the Host header field value when | requested host MAY ignore the Host header field value when | |||
determining the resource identified by an HTTP/1.1 request. (But see | determining the resource identified by an HTTP/1.1 request. (But see | |||
Appendix B.1.1 for other requirements on Host support in HTTP/1.1.) | Appendix B.1.1 for other requirements on Host support in HTTP/1.1.) | |||
An origin server that does differentiate resources based on the host | An origin server that does differentiate resources based on the host | |||
requested (sometimes referred to as virtual hosts or vanity host | requested (sometimes referred to as virtual hosts or vanity host | |||
names) MUST use the following rules for determining the requested | names) MUST use the following rules for determining the requested | |||
resource on an HTTP/1.1 request: | resource on an HTTP/1.1 request: | |||
1. If request-target is an absolute-URI, the host is part of the | 1. If request-target is an absolute-URI, the host is part of the | |||
request-target. Any Host header field value in the request MUST | request-target. Any Host header field value in the request MUST | |||
be ignored. | be ignored. | |||
2. If the request-target is not an absolute-URI, and the request | 2. If the request-target is not an absolute-URI, and the request | |||
skipping to change at page 30, line 47 | skipping to change at page 27, line 26 | |||
3. If the host as determined by rule 1 or 2 is not a valid host on | 3. If the host as determined by rule 1 or 2 is not a valid host on | |||
the server, the response MUST be a 400 (Bad Request) error | the server, the response MUST be a 400 (Bad Request) error | |||
message. | message. | |||
Recipients of an HTTP/1.0 request that lacks a Host header field MAY | Recipients of an HTTP/1.0 request that lacks a Host header field MAY | |||
attempt to use heuristics (e.g., examination of the URI path for | attempt to use heuristics (e.g., examination of the URI path for | |||
something unique to a particular host) in order to determine what | something unique to a particular host) in order to determine what | |||
exact resource is being requested. | exact resource is being requested. | |||
6. Response | 5. 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 5.1 | |||
*(( general-header ; Section 4.5 | *(( general-header ; Section 3.5 | |||
/ response-header ; [Part2], Section 5 | / response-header ; [Part2], Section 5 | |||
/ entity-header ) CRLF ) ; [Part3], Section 3.1 | / entity-header ) CRLF ) ; [Part3], Section 3.1 | |||
CRLF | CRLF | |||
[ message-body ] ; Section 4.3 | [ message-body ] ; Section 3.3 | |||
6.1. Status-Line | 5.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 | 5.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 8 of [Part2]. The Reason Phrase exists for the | defined in Section 8 of [Part2]. The Reason Phrase exists for the | |||
sole purpose of providing a textual description associated with the | sole purpose of providing a textual description associated with the | |||
numeric status code, out of deference to earlier Internet application | numeric status code, out of deference to earlier Internet application | |||
protocols that were more frequently used with interactive text | protocols that were more frequently used with interactive text | |||
clients. A client SHOULD ignore the content of the Reason Phrase. | clients. A client SHOULD ignore the content of the Reason Phrase. | |||
The first digit of the Status-Code defines the class of response. | The first digit of the Status-Code defines the class of response. | |||
skipping to change at page 32, line 5 | skipping to change at page 28, line 36 | |||
o 4xx: Client Error - The request contains bad syntax or cannot be | o 4xx: Client Error - The request contains bad syntax or cannot be | |||
fulfilled | fulfilled | |||
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 | |||
Status-Code = 3DIGIT | Status-Code = 3DIGIT | |||
Reason-Phrase = *( WSP / VCHAR / obs-text ) | Reason-Phrase = *( WSP / VCHAR / obs-text ) | |||
6. Protocol Parameters | ||||
6.1. Date/Time Formats: Full Date | ||||
HTTP applications have historically allowed three different formats | ||||
for the representation of date/time stamps: | ||||
Sun, 06 Nov 1994 08:49:37 GMT ; RFC 1123 | ||||
Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format | ||||
Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format | ||||
The first format is preferred as an Internet standard and represents | ||||
a fixed-length subset of that defined by [RFC1123]. The other | ||||
formats are described here only for compatibility with obsolete | ||||
implementations. HTTP/1.1 clients and servers that parse the date | ||||
value MUST accept all three formats (for compatibility with | ||||
HTTP/1.0), though they MUST only generate the RFC 1123 format for | ||||
representing HTTP-date values in header fields. See Appendix A for | ||||
further information. | ||||
All HTTP date/time stamps MUST be represented in Greenwich Mean Time | ||||
(GMT), without exception. For the purposes of HTTP, GMT is exactly | ||||
equal to UTC (Coordinated Universal Time). This is indicated in the | ||||
first two formats by the inclusion of "GMT" as the three-letter | ||||
abbreviation for time zone, and MUST be assumed when reading the | ||||
asctime format. HTTP-date is case sensitive and MUST NOT include | ||||
additional whitespace beyond that specifically included as SP in the | ||||
grammar. | ||||
HTTP-date = rfc1123-date / obs-date | ||||
Preferred format: | ||||
rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT | ||||
day-name = %x4D.6F.6E ; "Mon", case-sensitive | ||||
/ %x54.75.65 ; "Tue", case-sensitive | ||||
/ %x57.65.64 ; "Wed", case-sensitive | ||||
/ %x54.68.75 ; "Thu", case-sensitive | ||||
/ %x46.72.69 ; "Fri", case-sensitive | ||||
/ %x53.61.74 ; "Sat", case-sensitive | ||||
/ %x53.75.6E ; "Sun", case-sensitive | ||||
date1 = day SP month SP year | ||||
; e.g., 02 Jun 1982 | ||||
day = 2DIGIT | ||||
month = %x4A.61.6E ; "Jan", case-sensitive | ||||
/ %x46.65.62 ; "Feb", case-sensitive | ||||
/ %x4D.61.72 ; "Mar", case-sensitive | ||||
/ %x41.70.72 ; "Apr", case-sensitive | ||||
/ %x4D.61.79 ; "May", case-sensitive | ||||
/ %x4A.75.6E ; "Jun", case-sensitive | ||||
/ %x4A.75.6C ; "Jul", case-sensitive | ||||
/ %x41.75.67 ; "Aug", case-sensitive | ||||
/ %x53.65.70 ; "Sep", case-sensitive | ||||
/ %x4F.63.74 ; "Oct", case-sensitive | ||||
/ %x4E.6F.76 ; "Nov", case-sensitive | ||||
/ %x44.65.63 ; "Dec", case-sensitive | ||||
year = 4DIGIT | ||||
GMT = %x47.4D.54 ; "GMT", case-sensitive | ||||
time-of-day = hour ":" minute ":" second | ||||
; 00:00:00 - 23:59:59 | ||||
hour = 2DIGIT | ||||
minute = 2DIGIT | ||||
second = 2DIGIT | ||||
The semantics of day-name, day, month, year, and time-of-day are the | ||||
same as those defined for the RFC 5322 constructs with the | ||||
corresponding name ([RFC5322], Section 3.3). | ||||
Obsolete formats: | ||||
obs-date = rfc850-date / asctime-date | ||||
rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT | ||||
date2 = day "-" month "-" 2DIGIT | ||||
; day-month-year (e.g., 02-Jun-82) | ||||
day-name-l = %x4D.6F.6E.64.61.79 ; "Monday", case-sensitive | ||||
/ %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive | ||||
/ %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive | ||||
/ %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive | ||||
/ %x46.72.69.64.61.79 ; "Friday", case-sensitive | ||||
/ %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive | ||||
/ %x53.75.6E.64.61.79 ; "Sunday", case-sensitive | ||||
asctime-date = day-name SP date3 SP time-of-day SP year | ||||
date3 = month SP ( 2DIGIT / ( SP 1DIGIT )) | ||||
; month day (e.g., Jun 2) | ||||
Note: Recipients of date values are encouraged to be robust in | ||||
accepting date values that may have been sent by non-HTTP | ||||
applications, as is sometimes the case when retrieving or posting | ||||
messages via proxies/gateways to SMTP or NNTP. | ||||
Note: HTTP requirements for the date/time stamp format apply only | ||||
to their usage within the protocol stream. Clients and servers | ||||
are not required to use these formats for user presentation, | ||||
request logging, etc. | ||||
6.2. Transfer Codings | ||||
Transfer-coding values are used to indicate an encoding | ||||
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. | ||||
This differs from a content coding in that the transfer-coding is a | ||||
property of the message, not of the original entity. | ||||
transfer-coding = "chunked" ; Section 6.2.1 | ||||
/ "compress" ; Section 6.2.2.1 | ||||
/ "deflate" ; Section 6.2.2.2 | ||||
/ "gzip" ; Section 6.2.2.3 | ||||
/ transfer-extension | ||||
transfer-extension = token *( OWS ";" OWS transfer-parameter ) | ||||
Parameters are in the form of attribute/value pairs. | ||||
transfer-parameter = attribute BWS "=" BWS value | ||||
attribute = token | ||||
value = token / quoted-string | ||||
All transfer-coding values are case-insensitive. HTTP/1.1 uses | ||||
transfer-coding values in the TE header field (Section 9.5) and in | ||||
the Transfer-Encoding header field (Section 9.7). | ||||
Whenever a transfer-coding is applied to a message-body, the set of | ||||
transfer-codings MUST include "chunked", unless the message indicates | ||||
it is terminated by closing the connection. When the "chunked" | ||||
transfer-coding is used, it MUST be the last transfer-coding applied | ||||
to the message-body. The "chunked" transfer-coding MUST NOT be | ||||
applied more than once to a message-body. These rules allow the | ||||
recipient to determine the transfer-length of the message | ||||
(Section 3.4). | ||||
Transfer-codings are analogous to the Content-Transfer-Encoding | ||||
values of MIME, which were designed to enable safe transport of | ||||
binary data over a 7-bit transport service ([RFC2045], Section 6). | ||||
However, safe transport has a different focus for an 8bit-clean | ||||
transfer protocol. In HTTP, the only unsafe characteristic of | ||||
message-bodies is the difficulty in determining the exact body length | ||||
(Section 3.4), or the desire to encrypt data over a shared transport. | ||||
A server which receives an entity-body with a transfer-coding it does | ||||
not understand SHOULD return 501 (Not Implemented), and close the | ||||
connection. A server MUST NOT send transfer-codings to an HTTP/1.0 | ||||
client. | ||||
6.2.1. Chunked Transfer Coding | ||||
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, | ||||
followed by an OPTIONAL trailer containing entity-header fields. | ||||
This allows dynamically produced content to be transferred along with | ||||
the information necessary for the recipient to verify that it has | ||||
received the full message. | ||||
Chunked-Body = *chunk | ||||
last-chunk | ||||
trailer-part | ||||
CRLF | ||||
chunk = chunk-size *WSP [ chunk-ext ] CRLF | ||||
chunk-data CRLF | ||||
chunk-size = 1*HEXDIG | ||||
last-chunk = 1*("0") *WSP [ chunk-ext ] CRLF | ||||
chunk-ext = *( ";" *WSP chunk-ext-name | ||||
[ "=" chunk-ext-val ] *WSP ) | ||||
chunk-ext-name = token | ||||
chunk-ext-val = token / quoted-str-nf | ||||
chunk-data = 1*OCTET ; a sequence of chunk-size octets | ||||
trailer-part = *( entity-header CRLF ) | ||||
quoted-str-nf = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE | ||||
; like quoted-string, but disallowing line folding | ||||
qdtext-nf = WSP / %x21 / %x23-5B / %x5D-7E / obs-text | ||||
; WSP / <VCHAR except DQUOTE and "\"> / obs-text | ||||
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 | ||||
whose size is zero, followed by the trailer, which is terminated by | ||||
an empty line. | ||||
The trailer allows the sender to include additional HTTP header | ||||
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 | ||||
Section 9.6). | ||||
A server using chunked transfer-coding in a response MUST NOT use the | ||||
trailer for any header fields unless at least one of the following is | ||||
true: | ||||
1. the request included a TE header field that indicates "trailers" | ||||
is acceptable in the transfer-coding of the response, as | ||||
described in Section 9.5; or, | ||||
2. the server is the origin server for the response, the trailer | ||||
fields consist entirely of optional metadata, and the recipient | ||||
could use the message (in a manner acceptable to the origin | ||||
server) without receiving this metadata. In other words, the | ||||
origin server is willing to accept the possibility that the | ||||
trailer fields might be silently discarded along the path to the | ||||
client. | ||||
This requirement prevents an interoperability failure when the | ||||
message is being received by an HTTP/1.1 (or later) proxy and | ||||
forwarded to an HTTP/1.0 recipient. It avoids a situation where | ||||
compliance with the protocol would have necessitated a possibly | ||||
infinite buffer on the proxy. | ||||
A process for decoding the "chunked" transfer-coding can be | ||||
represented in pseudo-code as: | ||||
length := 0 | ||||
read chunk-size, chunk-ext (if any) and CRLF | ||||
while (chunk-size > 0) { | ||||
read chunk-data and CRLF | ||||
append chunk-data to entity-body | ||||
length := length + chunk-size | ||||
read chunk-size and CRLF | ||||
} | ||||
read entity-header | ||||
while (entity-header not empty) { | ||||
append entity-header to existing header fields | ||||
read entity-header | ||||
} | ||||
Content-Length := length | ||||
Remove "chunked" from Transfer-Encoding | ||||
All HTTP/1.1 applications MUST be able to receive and decode the | ||||
"chunked" transfer-coding, and MUST ignore chunk-ext extensions they | ||||
do not understand. | ||||
6.2.2. Compression Codings | ||||
The codings defined below can be used to compress the payload of a | ||||
message. | ||||
Note: Use of program names for the identification of encoding | ||||
formats is not desirable and is discouraged for future encodings. | ||||
Their use here is representative of historical practice, not good | ||||
design. | ||||
Note: For compatibility with previous implementations of HTTP, | ||||
applications SHOULD consider "x-gzip" and "x-compress" to be | ||||
equivalent to "gzip" and "compress" respectively. | ||||
6.2.2.1. Compress Coding | ||||
The "compress" format is produced by the common UNIX file compression | ||||
program "compress". This format is an adaptive Lempel-Ziv-Welch | ||||
coding (LZW). | ||||
6.2.2.2. Deflate Coding | ||||
The "zlib" format is defined in [RFC1950] in combination with the | ||||
"deflate" compression mechanism described in [RFC1951]. | ||||
6.2.2.3. Gzip Coding | ||||
The "gzip" format is produced by the file compression program "gzip" | ||||
(GNU zip), as described in [RFC1952]. This format is a Lempel-Ziv | ||||
coding (LZ77) with a 32 bit CRC. | ||||
6.2.3. Transfer Coding Registry | ||||
The HTTP Transfer Coding Registry defines the name space for the | ||||
transfer coding names. | ||||
Registrations MUST include the following fields: | ||||
o Name | ||||
o Description | ||||
o Pointer to specification text | ||||
Values to be added to this name space require expert review and a | ||||
specification (see "Expert Review" and "Specification Required" in | ||||
Section 4.1 of [RFC5226]), and MUST conform to the purpose of | ||||
transfer coding defined in this section. | ||||
The registry itself is maintained at | ||||
<http://www.iana.org/assignments/http-parameters>. | ||||
6.3. Product Tokens | ||||
Product tokens are used to allow communicating applications to | ||||
identify themselves by software name and version. Most fields using | ||||
product tokens also allow sub-products which form a significant part | ||||
of the application to be listed, separated by whitespace. By | ||||
convention, the products are listed in order of their significance | ||||
for identifying the application. | ||||
product = token ["/" product-version] | ||||
product-version = token | ||||
Examples: | ||||
User-Agent: CERN-LineMode/2.15 libwww/2.17b3 | ||||
Server: Apache/0.8.4 | ||||
Product tokens SHOULD be short and to the point. They MUST NOT be | ||||
used for advertising or other non-essential information. Although | ||||
any token character MAY appear in a product-version, this token | ||||
SHOULD only be used for a version identifier (i.e., successive | ||||
versions of the same product SHOULD only differ in the product- | ||||
version portion of the product value). | ||||
6.4. Quality Values | ||||
Both transfer codings (TE request header, Section 9.5) and content | ||||
negotiation (Section 4 of [Part3]) use short "floating point" numbers | ||||
to indicate the relative importance ("weight") of various 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 value. If a | ||||
parameter has a quality value of 0, then content with this parameter | ||||
is `not acceptable' for the client. HTTP/1.1 applications MUST NOT | ||||
generate more than three digits after the decimal point. User | ||||
configuration of these values SHOULD also be limited in this fashion. | ||||
qvalue = ( "0" [ "." 0*3DIGIT ] ) | ||||
/ ( "1" [ "." 0*3("0") ] ) | ||||
Note: "Quality values" is a misnomer, since these values merely | ||||
represent relative degradation in desired quality. | ||||
7. Connections | 7. Connections | |||
7.1. Persistent Connections | 7.1. Persistent Connections | |||
7.1.1. Purpose | 7.1.1. Purpose | |||
Prior to persistent connections, a separate TCP connection was | Prior to persistent connections, a separate TCP connection was | |||
established to fetch each URL, increasing the load on HTTP servers | established to fetch each URL, increasing the load on HTTP servers | |||
and causing congestion on the Internet. The use of inline images and | and causing congestion on the Internet. The use of inline images and | |||
other associated data often require a client to make multiple | other associated data often require a client to make multiple | |||
skipping to change at page 33, line 10 | skipping to change at page 37, line 36 | |||
7.1.2. Overall Operation | 7.1.2. Overall Operation | |||
A significant difference between HTTP/1.1 and earlier versions of | A significant difference between HTTP/1.1 and earlier versions of | |||
HTTP is that persistent connections are the default behavior of any | HTTP is that persistent connections are the default behavior of any | |||
HTTP connection. That is, unless otherwise indicated, the client | HTTP connection. That is, unless otherwise indicated, the client | |||
SHOULD assume that the server will maintain a persistent connection, | SHOULD assume that the server will maintain a persistent connection, | |||
even after error responses from the server. | even after error responses from the server. | |||
Persistent connections provide a mechanism by which a client and a | Persistent connections provide a mechanism by which a client and a | |||
server can signal the close of a TCP connection. This signaling | server can signal the close of a TCP connection. This signaling | |||
takes place using the Connection header field (Section 8.1). Once a | takes place using the Connection header field (Section 9.1). Once a | |||
close has been signaled, the client MUST NOT send any more requests | close has been signaled, the client MUST NOT send any more requests | |||
on that connection. | on that connection. | |||
7.1.2.1. Negotiation | 7.1.2.1. Negotiation | |||
An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to | An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to | |||
maintain a persistent connection unless a Connection header including | maintain a persistent connection unless a Connection header including | |||
the connection-token "close" was sent in the request. If the server | the connection-token "close" was sent in the request. If the server | |||
chooses to close the connection immediately after sending the | chooses to close the connection immediately after sending the | |||
response, it SHOULD send a Connection header including the | response, it SHOULD send a Connection header including the | |||
skipping to change at page 33, line 41 | skipping to change at page 38, line 19 | |||
Connection header, that request becomes the last one for the | Connection header, that request becomes the last one for the | |||
connection. | connection. | |||
Clients and servers SHOULD NOT assume that a persistent connection is | Clients and servers SHOULD NOT assume that a persistent connection is | |||
maintained for HTTP versions less than 1.1 unless it is explicitly | maintained for HTTP versions less than 1.1 unless it is explicitly | |||
signaled. See Appendix B.2 for more information on backward | signaled. See Appendix B.2 for more information on backward | |||
compatibility with HTTP/1.0 clients. | compatibility with HTTP/1.0 clients. | |||
In order to remain persistent, all messages on the connection MUST | In order to remain persistent, all messages on the connection MUST | |||
have a self-defined message length (i.e., one not defined by closure | have a self-defined message length (i.e., one not defined by closure | |||
of the connection), as described in Section 4.4. | of the connection), as described in Section 3.4. | |||
7.1.2.2. Pipelining | 7.1.2.2. Pipelining | |||
A client that supports persistent connections MAY "pipeline" its | A client that supports persistent connections MAY "pipeline" its | |||
requests (i.e., send multiple requests without waiting for each | requests (i.e., send multiple requests without waiting for each | |||
response). A server MUST send its responses to those requests in the | response). A server MUST send its responses to those requests in the | |||
same order that the requests were received. | same order that the requests were received. | |||
Clients which assume persistent connections and pipeline immediately | Clients which assume persistent connections and pipeline immediately | |||
after connection establishment SHOULD be prepared to retry their | after connection establishment SHOULD be prepared to retry their | |||
skipping to change at page 34, line 21 | skipping to change at page 38, line 47 | |||
non-idempotent sequences of methods (see Section 7.1.2 of [Part2]). | non-idempotent sequences of methods (see Section 7.1.2 of [Part2]). | |||
Otherwise, a premature termination of the transport connection could | Otherwise, a premature termination of the transport connection could | |||
lead to indeterminate results. A client wishing to send a non- | lead to indeterminate results. A client wishing to send a non- | |||
idempotent request SHOULD wait to send that request until it has | idempotent request SHOULD wait to send that request until it has | |||
received the response status for the previous request. | received the response status for the previous request. | |||
7.1.3. Proxy Servers | 7.1.3. Proxy Servers | |||
It is especially important that proxies correctly implement the | It is especially important that proxies correctly implement the | |||
properties of the Connection header field as specified in | properties of the Connection header field as specified in | |||
Section 8.1. | Section 9.1. | |||
The proxy server MUST signal persistent connections separately with | The proxy server MUST signal persistent connections separately with | |||
its clients and the origin servers (or other proxy servers) that it | its clients and the origin servers (or other proxy servers) that it | |||
connects to. Each persistent connection applies to only one | connects to. Each persistent connection applies to only one | |||
transport link. | transport link. | |||
A proxy server MUST NOT establish a HTTP/1.1 persistent connection | A proxy server MUST NOT establish a HTTP/1.1 persistent connection | |||
with an HTTP/1.0 client (but see Section 19.7.1 of [RFC2068] for | with an HTTP/1.0 client (but see Section 19.7.1 of [RFC2068] for | |||
information and discussion of the problems with the Keep-Alive header | information and discussion of the problems with the Keep-Alive header | |||
implemented by many HTTP/1.0 clients). | implemented by many HTTP/1.0 clients). | |||
skipping to change at page 35, line 25 | skipping to change at page 39, line 51 | |||
Confirmation by user-agent software with semantic understanding of | Confirmation by user-agent software with semantic understanding of | |||
the application MAY substitute for user confirmation. The automatic | the application MAY substitute for user confirmation. The automatic | |||
retry SHOULD NOT be repeated if the second sequence of requests | retry SHOULD NOT be repeated if the second sequence of requests | |||
fails. | fails. | |||
Servers SHOULD always respond to at least one request per connection, | Servers SHOULD always respond to at least one request per connection, | |||
if at all possible. Servers SHOULD NOT close a connection in the | if at all possible. Servers SHOULD NOT close a connection in the | |||
middle of transmitting a response, unless a network or client failure | middle of transmitting a response, unless a network or client failure | |||
is suspected. | is suspected. | |||
Clients that use persistent connections SHOULD limit the number of | Clients (including proxies) SHOULD limit the number of simultaneous | |||
simultaneous connections that they maintain to a given server. A | connections that they maintain to a given server (including proxies). | |||
single-user client SHOULD NOT maintain more than 2 connections with | ||||
any server or proxy. A proxy SHOULD use up to 2*N connections to | Previous revisions of HTTP gave a specific number of connections as a | |||
another server or proxy, where N is the number of simultaneously | ceiling, but this was found to be impractical for many applications. | |||
active users. These guidelines are intended to improve HTTP response | As a result, this specification does not mandate a particular maximum | |||
times and avoid congestion. | number of connections, but instead encourages clients to be | |||
conservative when opening multiple connections. | ||||
In particular, while using multiple connections avoids the "head-of- | ||||
line blocking" problem (whereby a request that takes significant | ||||
server-side processing and/or has a large payload can block | ||||
subsequent requests on the same connection), each connection used | ||||
consumes server resources (sometimes significantly), and furthermore | ||||
using multiple connections can cause undesirable side effects in | ||||
congested networks. | ||||
Note that servers might reject traffic that they deem abusive, | ||||
including an excessive number of connections from a client. | ||||
7.2. Message Transmission Requirements | 7.2. Message Transmission Requirements | |||
7.2.1. Persistent Connections and Flow Control | 7.2.1. Persistent Connections and Flow Control | |||
HTTP/1.1 servers SHOULD maintain persistent connections and use TCP's | HTTP/1.1 servers SHOULD maintain persistent connections and use TCP's | |||
flow control mechanisms to resolve temporary overloads, rather than | flow control mechanisms to resolve temporary overloads, rather than | |||
terminating connections with the expectation that clients will retry. | terminating connections with the expectation that clients will retry. | |||
The latter technique can exacerbate network congestion. | The latter technique can exacerbate network congestion. | |||
7.2.2. Monitoring Connections for Error Status Messages | 7.2.2. Monitoring Connections for Error Status Messages | |||
An HTTP/1.1 (or later) client sending a message-body SHOULD monitor | An HTTP/1.1 (or later) client sending a message-body SHOULD monitor | |||
the network connection for an error status while it is transmitting | the network connection for an error status while it is transmitting | |||
the request. If the client sees an error status, it SHOULD | the request. If the client sees an error status, it SHOULD | |||
immediately cease transmitting the body. If the body is being sent | immediately cease transmitting the body. If the body is being sent | |||
using a "chunked" encoding (Section 3.3), a zero length chunk and | using a "chunked" encoding (Section 6.2), a zero length chunk and | |||
empty trailer MAY be used to prematurely mark the end of the message. | empty trailer MAY be used to prematurely mark the end of the message. | |||
If the body was preceded by a Content-Length header, the client MUST | If the body was preceded by a Content-Length header, the client MUST | |||
close the connection. | close the connection. | |||
7.2.3. Use of the 100 (Continue) Status | 7.2.3. Use of the 100 (Continue) Status | |||
The purpose of the 100 (Continue) status (see Section 8.1.1 of | The purpose of the 100 (Continue) status (see Section 8.1.1 of | |||
[Part2]) is to allow a client that is sending a request message with | [Part2]) is to allow a client that is sending a request message with | |||
a request body to determine if the origin server is willing to accept | a request body to determine if the origin server is willing to accept | |||
the request (based on the request headers) before the client sends | the request (based on the request headers) before the client sends | |||
skipping to change at page 38, line 46 | skipping to change at page 43, line 35 | |||
received, or the user becomes impatient and terminates the retry | received, or the user becomes impatient and terminates the retry | |||
process. | process. | |||
If at any point an error status is received, the client | If at any point an error status is received, the client | |||
o SHOULD NOT continue and | o SHOULD NOT continue and | |||
o SHOULD close the connection if it has not completed sending the | o SHOULD close the connection if it has not completed sending the | |||
request message. | request message. | |||
8. Header Field Definitions | 8. Miscellaneous notes that may disappear | |||
8.1. Scheme aliases considered harmful | ||||
[[anchor2: TBS: describe why aliases like webcal are harmful.]] | ||||
8.2. Use of HTTP for proxy communication | ||||
[[anchor3: TBD: Configured to use HTTP to proxy HTTP or other | ||||
protocols.]] | ||||
8.3. Interception of HTTP for access control | ||||
[[anchor4: TBD: Interception of HTTP traffic for initiating access | ||||
control.]] | ||||
8.4. Use of HTTP by other protocols | ||||
[[anchor5: TBD: Profiles of HTTP defined by other protocol. | ||||
Extensions of HTTP like WebDAV.]] | ||||
8.5. Use of HTTP by media type specification | ||||
[[anchor6: TBD: Instructions on composing HTTP requests via hypertext | ||||
formats.]] | ||||
9. Header Field Definitions | ||||
This section defines the syntax and semantics of HTTP/1.1 header | This section defines the syntax and semantics of HTTP/1.1 header | |||
fields related to message framing and transport protocols. | fields related to message framing and transport protocols. | |||
For entity-header fields, both sender and recipient refer to either | For entity-header fields, both sender and recipient refer to either | |||
the client or the server, depending on who sends and who receives the | the client or the server, depending on who sends and who receives the | |||
entity. | entity. | |||
8.1. Connection | 9.1. Connection | |||
The general-header field "Connection" 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's value has the following grammar: | The Connection header's value has the following grammar: | |||
Connection = "Connection" ":" OWS Connection-v | Connection = "Connection" ":" OWS Connection-v | |||
Connection-v = 1#connection-token | Connection-v = 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 | |||
skipping to change at page 40, line 7 | skipping to change at page 45, line 24 | |||
include the "close" connection option in every response message that | include the "close" connection option in every response message that | |||
does not have a 1xx (informational) status code. | does not have a 1xx (informational) status code. | |||
A system receiving an HTTP/1.0 (or lower-version) message that | A system receiving an HTTP/1.0 (or lower-version) message that | |||
includes a Connection header MUST, for each connection-token in this | includes a Connection header MUST, for each connection-token in this | |||
field, remove and ignore any header field(s) from the message with | field, remove and ignore any header field(s) from the message with | |||
the same name as the connection-token. This protects against | the same name as the connection-token. This protects against | |||
mistaken forwarding of such header fields by pre-HTTP/1.1 proxies. | mistaken forwarding of such header fields by pre-HTTP/1.1 proxies. | |||
See Appendix B.2. | See Appendix B.2. | |||
8.2. Content-Length | 9.2. Content-Length | |||
The entity-header field "Content-Length" indicates the size of the | The "Content-Length" entity-header field indicates the size of the | |||
entity-body, in number of OCTETs, sent to the recipient or, in the | entity-body, in number of OCTETs. In the case of responses to the | |||
case of the HEAD method, the size of the entity-body that would have | HEAD method, it indicates the size of the entity-body that would have | |||
been sent had the request been a GET. | been sent had the request been a GET. | |||
Content-Length = "Content-Length" ":" OWS 1*Content-Length-v | Content-Length = "Content-Length" ":" OWS 1*Content-Length-v | |||
Content-Length-v = 1*DIGIT | Content-Length-v = 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 3.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. | |||
Section 4.4 describes how to determine the length of a message-body | Section 3.4 describes how to determine the length of a message-body | |||
if a Content-Length is not given. | if a Content-Length is not given. | |||
Note that the meaning of this field is significantly different from | Note that the meaning of this field is significantly different from | |||
the corresponding definition in MIME, where it is an optional field | the corresponding definition in MIME, where it is an optional field | |||
used within the "message/external-body" content-type. In HTTP, it | used within the "message/external-body" content-type. In HTTP, it | |||
SHOULD be sent whenever the message's length can be determined prior | SHOULD be sent whenever the message's length can be determined prior | |||
to being transferred, unless this is prohibited by the rules in | to being transferred, unless this is prohibited by the rules in | |||
Section 4.4. | Section 3.4. | |||
8.3. Date | 9.3. Date | |||
The general-header field "Date" 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 | |||
Section 3.6.1 of [RFC5322]. The field value is an HTTP-date, as | Section 3.6.1 of [RFC5322]. The field value is an HTTP-date, as | |||
described in Section 3.2; it MUST be sent in rfc1123-date format. | described in Section 6.1; it MUST be sent in rfc1123-date format. | |||
Date = "Date" ":" OWS Date-v | Date = "Date" ":" OWS Date-v | |||
Date-v = HTTP-date | Date-v = HTTP-date | |||
An example is | An example is | |||
Date: Tue, 15 Nov 1994 08:12:31 GMT | Date: Tue, 15 Nov 1994 08:12:31 GMT | |||
Origin servers MUST include a Date header field in all responses, | Origin servers MUST include a Date header field in all responses, | |||
except in these cases: | except in these cases: | |||
skipping to change at page 41, line 15 | skipping to change at page 46, line 32 | |||
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 8.3.1 | a Date header field. In this case, the rules in Section 9.3.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 | |||
recipient or gatewayed via a protocol which requires a Date. An HTTP | recipient or gatewayed via a protocol which requires a Date. An HTTP | |||
implementation without a clock MUST NOT cache responses without | implementation without a clock MUST NOT cache responses without | |||
revalidating them on every use. An HTTP cache, especially a shared | revalidating them on every use. An HTTP cache, especially a shared | |||
cache, SHOULD use a mechanism, such as NTP [RFC1305], to synchronize | cache, SHOULD use a mechanism, such as NTP [RFC1305], to synchronize | |||
its clock with a reliable external standard. | its clock with a reliable external standard. | |||
skipping to change at page 41, line 40 | skipping to change at page 47, line 8 | |||
The HTTP-date sent in a Date header SHOULD NOT represent a date and | The HTTP-date sent in a Date header SHOULD NOT represent a date and | |||
time subsequent to the generation of the message. It SHOULD | time subsequent to the generation of the message. It SHOULD | |||
represent the best available approximation of the date and time of | represent the best available approximation of the date and time of | |||
message generation, unless the implementation has no means of | message generation, unless the implementation has no means of | |||
generating a reasonably accurate date and time. In theory, the date | generating a reasonably accurate date and time. In theory, the date | |||
ought to represent the moment just before the entity is generated. | ought to represent the moment just before the entity is generated. | |||
In practice, the date can be generated at any time during the message | In practice, the date can be generated at any time during the message | |||
origination without affecting its semantic value. | origination without affecting its semantic value. | |||
8.3.1. Clockless Origin Server Operation | 9.3.1. Clockless Origin Server Operation | |||
Some origin server implementations might not have a clock available. | Some origin server implementations might not have a clock available. | |||
An origin server without a clock MUST NOT assign Expires or Last- | An origin server without a clock MUST NOT assign Expires or Last- | |||
Modified values to a response, unless these values were associated | Modified values to a response, unless these values were associated | |||
with the resource by a system or user with a reliable clock. It MAY | with the resource by a system or user with a reliable clock. It MAY | |||
assign an Expires value that is known, at or before server | assign an Expires value that is known, at or before server | |||
configuration time, to be in the past (this allows "pre-expiration" | configuration time, to be in the past (this allows "pre-expiration" | |||
of responses without storing separate Expires values for each | of responses without storing separate Expires values for each | |||
resource). | resource). | |||
8.4. Host | 9.4. Host | |||
The request-header field "Host" 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, allowing the origin server or | |||
URI given by the user or referring resource (generally an http URI, | gateway to differentiate between internally-ambiguous URLs, such as | |||
as described in Section 2.1.1). The Host field value MUST represent | the root "/" URL of a server for multiple host names on a single IP | |||
the naming authority of the origin server or gateway given by the | address. | |||
original URL. This allows the origin server or gateway to | ||||
differentiate between internally-ambiguous URLs, such as the root "/" | The Host field value MUST represent the naming authority of the | |||
URL of a server for multiple host names on a single IP address. | origin server or gateway given by the original URL obtained from the | |||
user or referring resource (generally an http URI, as described in | ||||
Section 2.6.1). | ||||
Host = "Host" ":" OWS Host-v | Host = "Host" ":" OWS Host-v | |||
Host-v = uri-host [ ":" port ] ; Section 2.1.1 | Host-v = uri-host [ ":" port ] ; Section 2.6.1 | |||
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 | |||
messages. If the requested URI does not include an Internet host | messages. If the requested URI does not include an Internet host | |||
name for the service being requested, then the Host header field MUST | name for the service being requested, then the Host header field MUST | |||
be given with an empty value. An HTTP/1.1 proxy MUST ensure that any | be given with an empty value. An HTTP/1.1 proxy MUST ensure that any | |||
request message it forwards does contain an appropriate Host header | request message it forwards does contain an appropriate Host header | |||
field that identifies the service being requested by the proxy. All | field that identifies the service being requested by the proxy. All | |||
Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request) | Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request) | |||
status code to any HTTP/1.1 request message which lacks a Host header | status code to any HTTP/1.1 request message which lacks a Host header | |||
field. | field. | |||
See Sections 5.2 and B.1.1 for other requirements relating to Host. | See Sections 4.2 and B.1.1 for other requirements relating to Host. | |||
8.5. TE | 9.5. TE | |||
The "TE" request-header field indicates what extension transfer- | ||||
codings it is willing to accept in the response, and whether or not | ||||
it is willing to accept trailer fields in a chunked transfer-coding. | ||||
The request-header field "TE" indicates what extension transfer- | ||||
codings 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 value may consist of the keyword "trailers" and/or a comma- | Its value may consist of the keyword "trailers" and/or a comma- | |||
separated list of extension transfer-coding names with optional | separated list of extension transfer-coding names with optional | |||
accept parameters (as described in Section 3.3). | accept parameters (as described in Section 6.2). | |||
TE = "TE" ":" OWS TE-v | TE = "TE" ":" OWS TE-v | |||
TE-v = #t-codings | TE-v = #t-codings | |||
t-codings = "trailers" / ( transfer-extension [ te-params ] ) | t-codings = "trailers" / ( transfer-extension [ te-params ] ) | |||
te-params = OWS ";" OWS "q=" qvalue *( te-ext ) | te-params = OWS ";" OWS "q=" qvalue *( te-ext ) | |||
te-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ] | te-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ] | |||
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.3.1. This keyword is reserved for use with | defined in Section 6.2.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 | |||
TE: | TE: | |||
TE: trailers, deflate;q=0.5 | TE: trailers, deflate;q=0.5 | |||
The TE header field only applies to the immediate connection. | The TE header field only applies to the immediate connection. | |||
Therefore, the keyword MUST be supplied within a Connection header | Therefore, the keyword MUST be supplied within a Connection header | |||
field (Section 8.1) whenever TE is present in an HTTP/1.1 message. | field (Section 9.1) whenever TE is present in an HTTP/1.1 message. | |||
A server tests whether a transfer-coding is acceptable, according to | A server tests whether a transfer-coding is acceptable, according to | |||
a TE field, using these rules: | a TE field, using these rules: | |||
1. The "chunked" transfer-coding is always acceptable. If the | 1. The "chunked" transfer-coding is always acceptable. If the | |||
keyword "trailers" is listed, the client indicates that it is | keyword "trailers" is listed, the client indicates that it is | |||
willing to accept trailer fields in the chunked response on | willing to accept trailer fields in the chunked response on | |||
behalf of itself and any downstream clients. The implication is | behalf of itself and any downstream clients. The implication is | |||
that, if given, the client is stating that either all downstream | that, if given, the client is stating that either all downstream | |||
clients are willing to accept trailer fields in the forwarded | clients are willing to accept trailer fields in the forwarded | |||
response, or that it will attempt to buffer the response on | response, or that it will attempt to buffer the response on | |||
behalf of downstream recipients. | behalf of downstream recipients. | |||
Note: HTTP/1.1 does not define any means to limit the size of a | Note: HTTP/1.1 does not define any means to limit the size of a | |||
chunked response such that a client can be assured of buffering | chunked response such that a client can be assured of buffering | |||
the entire response. | the entire response. | |||
2. If the transfer-coding being tested is one of the transfer- | 2. If the transfer-coding being tested is one of the transfer- | |||
codings listed in the TE field, then it is acceptable unless it | codings listed in the TE field, then it is acceptable unless it | |||
is accompanied by a qvalue of 0. (As defined in Section 3.5, a | is accompanied by a qvalue of 0. (As defined in Section 6.4, a | |||
qvalue of 0 means "not acceptable.") | qvalue of 0 means "not acceptable.") | |||
3. If multiple transfer-codings are acceptable, then the acceptable | 3. If multiple transfer-codings are acceptable, then the acceptable | |||
transfer-coding with the highest non-zero qvalue is preferred. | transfer-coding with the highest non-zero qvalue is preferred. | |||
The "chunked" transfer-coding always has a qvalue of 1. | The "chunked" transfer-coding always has a qvalue of 1. | |||
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. | |||
8.6. Trailer | 9.6. Trailer | |||
The general field "Trailer" indicates that the given set of header | The "Trailer" general-header field indicates that the given set of | |||
fields is present in the trailer of a message encoded with chunked | header fields is present in the trailer of a message encoded with | |||
transfer-coding. | chunked transfer-coding. | |||
Trailer = "Trailer" ":" OWS Trailer-v | Trailer = "Trailer" ":" OWS Trailer-v | |||
Trailer-v = 1#field-name | Trailer-v = 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.3.1 for restrictions on the use of | any header fields. See Section 6.2.1 for restrictions on the use of | |||
trailer fields in a "chunked" transfer-coding. | trailer fields in a "chunked" transfer-coding. | |||
Message header fields listed in the Trailer header field MUST NOT | Message header fields listed in the Trailer header field MUST NOT | |||
include the following header fields: | include the following header fields: | |||
o Transfer-Encoding | o Transfer-Encoding | |||
o Content-Length | o Content-Length | |||
o Trailer | o Trailer | |||
8.7. Transfer-Encoding | 9.7. Transfer-Encoding | |||
The general-header "Transfer-Encoding" field indicates what (if any) | The "Transfer-Encoding" general-header field indicates what transfer- | |||
type of transformation has been applied to the message body in order | codings (if any) have been applied to the message body. It differs | |||
to safely transfer it between the sender and the recipient. This | from Content-Encoding (Section 2.2 of [Part3]) in that transfer- | |||
differs from the content-coding in that the transfer-coding is a | codings are a property of the message (and therefore are removed by | |||
property of the message, not of the entity. | intermediaries), whereas content-codings are not. | |||
Transfer-Encoding = "Transfer-Encoding" ":" OWS | Transfer-Encoding = "Transfer-Encoding" ":" OWS | |||
Transfer-Encoding-v | Transfer-Encoding-v | |||
Transfer-Encoding-v = 1#transfer-coding | Transfer-Encoding-v = 1#transfer-coding | |||
Transfer-codings are defined in Section 3.3. An example is: | Transfer-codings are defined in Section 6.2. An example is: | |||
Transfer-Encoding: chunked | Transfer-Encoding: chunked | |||
If multiple encodings have been applied to an entity, the transfer- | If multiple encodings have been applied to an entity, the transfer- | |||
codings MUST be listed in the order in which they were applied. | codings MUST be listed in the order in which they were applied. | |||
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. | |||
Many older HTTP/1.0 applications do not understand the Transfer- | Many older HTTP/1.0 applications do not understand the Transfer- | |||
Encoding header. | Encoding header. | |||
8.8. Upgrade | 9.8. Upgrade | |||
The general-header "Upgrade" allows the client to specify what | The "Upgrade" general-header field allows the client to specify what | |||
additional communication protocols it supports and would like to use | additional communication protocols it would like to use, if the | |||
if the server finds it appropriate to switch protocols. The server | server chooses to switch protocols. Additionally, the server MUST | |||
MUST use the Upgrade header field within a 101 (Switching Protocols) | 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 to. | |||
Upgrade = "Upgrade" ":" OWS Upgrade-v | Upgrade = "Upgrade" ":" OWS Upgrade-v | |||
Upgrade-v = 1#product | Upgrade-v = 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. | |||
skipping to change at page 45, line 46 | skipping to change at page 51, line 12 | |||
protocols upon the existing transport-layer connection. Upgrade | protocols upon the existing transport-layer connection. Upgrade | |||
cannot be used to insist on a protocol change; its acceptance and use | cannot be used to insist on a protocol change; its acceptance and use | |||
by the server is optional. The capabilities and nature of the | by the server is optional. The capabilities and nature of the | |||
application-layer communication after the protocol change is entirely | application-layer communication after the protocol change is entirely | |||
dependent upon the new protocol chosen, although the first action | dependent upon the new protocol chosen, although the first action | |||
after changing the protocol MUST be a response to the initial HTTP | after changing the protocol MUST be a response to the initial HTTP | |||
request containing the Upgrade header field. | request containing the Upgrade header field. | |||
The Upgrade header field only applies to the immediate connection. | The Upgrade header field only applies to the immediate connection. | |||
Therefore, the upgrade keyword MUST be supplied within a Connection | Therefore, the upgrade keyword MUST be supplied within a Connection | |||
header field (Section 8.1) whenever Upgrade is present in an HTTP/1.1 | header field (Section 9.1) whenever Upgrade is present in an HTTP/1.1 | |||
message. | message. | |||
The Upgrade header field cannot be used to indicate a switch to a | The Upgrade header field cannot be used to indicate a switch to a | |||
protocol on a different connection. For that purpose, it is more | protocol on a different connection. For that purpose, it is more | |||
appropriate to use a 301, 302, 303, or 305 redirection response. | appropriate to use a 301, 302, 303, or 305 redirection response. | |||
This specification only defines the protocol name "HTTP" for use by | This specification only defines the protocol name "HTTP" for use by | |||
the family of Hypertext Transfer Protocols, as defined by the HTTP | the family of Hypertext Transfer Protocols, as defined by the HTTP | |||
version rules of Section 3.1 and future updates to this | version rules of Section 2.5 and future updates to this | |||
specification. Any token can be used as a protocol name; however, it | specification. Additional tokens can be registered with IANA using | |||
will only be useful if both the client and server associate the name | the registration procedure defined below. | |||
with the same protocol. | ||||
8.9. Via | 9.8.1. Upgrade Token Registry | |||
The general-header field "Via" MUST be used by gateways and proxies | The HTTP Upgrade Token Registry defines the name space for product | |||
tokens used to identify protocols in the Upgrade header field. Each | ||||
registered token should be associated with one or a set of | ||||
specifications, and with contact information. | ||||
Registrations should be allowed on a First Come First Served basis as | ||||
described in Section 4.1 of [RFC5226]. These specifications need not | ||||
be IETF documents or be subject to IESG review, but should obey the | ||||
following rules: | ||||
1. A token, once registered, stays registered forever. | ||||
2. The registration MUST name a responsible party for the | ||||
registration. | ||||
3. The registration MUST name a point of contact. | ||||
4. The registration MAY name the documentation required for the | ||||
token. | ||||
5. The responsible party MAY change the registration at any time. | ||||
The IANA will keep a record of all such changes, and make them | ||||
available upon request. | ||||
6. The responsible party for the first registration of a "product" | ||||
token MUST approve later registrations of a "version" token | ||||
together with that "product" token before they can be registered. | ||||
7. If absolutely required, the IESG MAY reassign the responsibility | ||||
for a token. This will normally only be used in the case when a | ||||
responsible party cannot be contacted. | ||||
It is not required that specifications for upgrade tokens be made | ||||
publicly available, but the contact information for the registration | ||||
should be. | ||||
9.9. Via | ||||
The "Via" general-header field MUST be used by gateways and proxies | ||||
to indicate the intermediate protocols and recipients between the | to indicate the intermediate protocols and recipients between the | |||
user agent and the server on requests, and between the origin server | user agent and the server on requests, and between the origin server | |||
and the client on responses. It is analogous to the "Received" field | and the client on responses. It is analogous to the "Received" field | |||
defined in Section 3.6.7 of [RFC5322] and is intended to be used for | defined in Section 3.6.7 of [RFC5322] and is intended to be used for | |||
tracking message forwards, avoiding request loops, and identifying | tracking message forwards, avoiding request loops, and identifying | |||
the protocol capabilities of all senders along the request/response | the protocol capabilities of all senders along the request/response | |||
chain. | chain. | |||
Via = "Via" ":" OWS Via-v | Via = "Via" ":" OWS Via-v | |||
Via-v = 1#( received-protocol RWS received-by | Via-v = 1#( received-protocol RWS received-by | |||
skipping to change at page 47, line 40 | skipping to change at page 53, line 45 | |||
could be collapsed to | could be collapsed to | |||
Via: 1.0 ricky, 1.1 mertz, 1.0 lucy | Via: 1.0 ricky, 1.1 mertz, 1.0 lucy | |||
Applications SHOULD NOT combine multiple entries unless they are all | Applications SHOULD NOT combine multiple entries unless they are all | |||
under the same organizational control and the hosts have already been | under the same organizational control and the hosts have already been | |||
replaced by pseudonyms. Applications MUST NOT combine entries which | replaced by pseudonyms. Applications MUST NOT combine entries which | |||
have different received-protocol values. | have different received-protocol values. | |||
9. IANA Considerations | 10. IANA Considerations | |||
9.1. Message Header Registration | 10.1. Message Header Registration | |||
The Message Header Registry located at <http://www.iana.org/ | The Message Header Registry located at <http://www.iana.org/ | |||
assignments/message-headers/message-header-index.html> should be | assignments/message-headers/message-header-index.html> should be | |||
updated with the permanent registrations below (see [RFC3864]): | updated with the permanent registrations below (see [RFC3864]): | |||
+-------------------+----------+----------+-------------+ | +-------------------+----------+----------+-------------+ | |||
| Header Field Name | Protocol | Status | Reference | | | Header Field Name | Protocol | Status | Reference | | |||
+-------------------+----------+----------+-------------+ | +-------------------+----------+----------+-------------+ | |||
| Connection | http | standard | Section 8.1 | | | Connection | http | standard | Section 9.1 | | |||
| Content-Length | http | standard | Section 8.2 | | | Content-Length | http | standard | Section 9.2 | | |||
| Date | http | standard | Section 8.3 | | | Date | http | standard | Section 9.3 | | |||
| Host | http | standard | Section 8.4 | | | Host | http | standard | Section 9.4 | | |||
| TE | http | standard | Section 8.5 | | | TE | http | standard | Section 9.5 | | |||
| Trailer | http | standard | Section 8.6 | | | Trailer | http | standard | Section 9.6 | | |||
| Transfer-Encoding | http | standard | Section 8.7 | | | Transfer-Encoding | http | standard | Section 9.7 | | |||
| Upgrade | http | standard | Section 8.8 | | | Upgrade | http | standard | Section 9.8 | | |||
| Via | http | standard | Section 8.9 | | | Via | http | standard | Section 9.9 | | |||
+-------------------+----------+----------+-------------+ | +-------------------+----------+----------+-------------+ | |||
The change controller is: "IETF (iesg@ietf.org) - Internet | The change controller is: "IETF (iesg@ietf.org) - Internet | |||
Engineering Task Force". | Engineering Task Force". | |||
9.2. URI Scheme Registration | 10.2. URI Scheme Registration | |||
The entry for the "http" URI Scheme in the registry located at | The entries for the "http" and "https" URI Schemes in the registry | |||
<http://www.iana.org/assignments/uri-schemes.html> should be updated | located at <http://www.iana.org/assignments/uri-schemes.html> should | |||
to point to Section 2.1.1 of this document (see [RFC4395]). | be updated to point to Sections 2.6.1 and 2.6.2 of this document (see | |||
[RFC4395]). | ||||
9.3. Internet Media Type Registrations | 10.3. Internet Media Type Registrations | |||
This document serves as the specification for the Internet media | This document serves as the specification for the Internet media | |||
types "message/http" and "application/http". The following is to be | types "message/http" and "application/http". The following is to be | |||
registered with IANA (see [RFC4288]). | registered with IANA (see [RFC4288]). | |||
9.3.1. Internet Media Type message/http | 10.3.1. Internet Media Type message/http | |||
The message/http type can be used to enclose a single HTTP request or | The message/http type can be used to enclose a single HTTP request or | |||
response message, provided that it obeys the MIME restrictions for | response message, provided that it obeys the MIME restrictions for | |||
all "message" types regarding line length and encodings. | all "message" types regarding line length and encodings. | |||
Type name: message | Type name: message | |||
Subtype name: http | Subtype name: http | |||
Required parameters: none | Required parameters: none | |||
skipping to change at page 49, line 16 | skipping to change at page 55, line 19 | |||
present, the type can be determined from the first line of the | present, the type can be determined from the first line of the | |||
body. | body. | |||
Encoding considerations: only "7bit", "8bit", or "binary" are | Encoding considerations: only "7bit", "8bit", or "binary" are | |||
permitted | permitted | |||
Security considerations: none | Security considerations: none | |||
Interoperability considerations: none | Interoperability considerations: none | |||
Published specification: This specification (see Section 9.3.1). | Published specification: This specification (see Section 10.3.1). | |||
Applications that use this media type: | Applications that use this media type: | |||
Additional information: | Additional information: | |||
Magic number(s): none | Magic number(s): none | |||
File extension(s): none | File extension(s): none | |||
Macintosh file type code(s): none | Macintosh file type code(s): none | |||
Person and email address to contact for further information: See | Person and email address to contact for further information: See | |||
Authors Section. | Authors Section. | |||
Intended usage: COMMON | Intended usage: COMMON | |||
Restrictions on usage: none | Restrictions on usage: none | |||
Author/Change controller: IESG | Author/Change controller: IESG | |||
9.3.2. Internet Media Type application/http | 10.3.2. Internet Media Type application/http | |||
The application/http type can be used to enclose a pipeline of one or | The application/http type can be used to enclose a pipeline of one or | |||
more HTTP request or response messages (not intermixed). | more HTTP request or response messages (not intermixed). | |||
Type name: application | Type name: application | |||
Subtype name: http | 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 messages (e.g., | version: The HTTP-Version number of the enclosed messages (e.g., | |||
"1.1"). If not present, the version can be determined from the | "1.1"). If not present, the version can be determined from the | |||
first line of the body. | first line of the body. | |||
msgtype: The message type -- "request" or "response". If not | msgtype: The message type -- "request" or "response". If not | |||
present, the type can be determined from the first line of the | present, the type can be determined from the first line of the | |||
body. | body. | |||
Encoding considerations: HTTP messages enclosed by this type are in | Encoding considerations: HTTP messages enclosed by this type are in | |||
"binary" format; use of an appropriate Content-Transfer-Encoding | "binary" format; use of an appropriate Content-Transfer-Encoding | |||
skipping to change at page 50, line 20 | skipping to change at page 56, line 24 | |||
body. | body. | |||
Encoding considerations: HTTP messages enclosed by this type are in | Encoding considerations: HTTP messages enclosed by this type are in | |||
"binary" format; use of an appropriate Content-Transfer-Encoding | "binary" format; use of an appropriate Content-Transfer-Encoding | |||
is required when transmitted via E-mail. | is required when transmitted via E-mail. | |||
Security considerations: none | Security considerations: none | |||
Interoperability considerations: none | Interoperability considerations: none | |||
Published specification: This specification (see Section 9.3.2). | Published specification: This specification (see Section 10.3.2). | |||
Applications that use this media type: | Applications that use this media type: | |||
Additional information: | Additional information: | |||
Magic number(s): none | Magic number(s): none | |||
File extension(s): none | File extension(s): none | |||
Macintosh file type code(s): none | Macintosh file type code(s): none | |||
Person and email address to contact for further information: See | Person and email address to contact for further information: See | |||
Authors Section. | Authors Section. | |||
Intended usage: COMMON | Intended usage: COMMON | |||
Restrictions on usage: none | Restrictions on usage: none | |||
Author/Change controller: IESG | Author/Change controller: IESG | |||
10. Security Considerations | 10.4. Transfer Coding Registry | |||
The registration procedure for HTTP Transfer Codings is now defined | ||||
by Section 6.2.3 of this document. | ||||
The HTTP Transfer Codings Registry located at | ||||
<http://www.iana.org/assignments/http-parameters> should be updated | ||||
with the registrations below: | ||||
+----------+--------------------------------------+-----------------+ | ||||
| Name | Description | Reference | | ||||
+----------+--------------------------------------+-----------------+ | ||||
| chunked | Transfer in a series of chunks | Section 6.2.1 | | ||||
| compress | UNIX "compress" program method | Section 6.2.2.1 | | ||||
| deflate | "zlib" format [RFC1950] with | Section 6.2.2.2 | | ||||
| | "deflate" compression | | | ||||
| gzip | Same as GNU zip [RFC1952] | Section 6.2.2.3 | | ||||
+----------+--------------------------------------+-----------------+ | ||||
10.5. Upgrade Token Registration | ||||
The registration procedure for HTTP Upgrade Tokens -- previously | ||||
defined in Section 7.2 of [RFC2817] -- is now defined by | ||||
Section 9.8.1 of this document. | ||||
The HTTP Status Code Registry located at | ||||
<http://www.iana.org/assignments/http-upgrade-tokens/> should be | ||||
updated with the registration below: | ||||
+-------+---------------------------+-------------------------------+ | ||||
| Value | Description | Reference | | ||||
+-------+---------------------------+-------------------------------+ | ||||
| HTTP | Hypertext Transfer | Section 2.5 of this | | ||||
| | Protocol | specification | | ||||
+-------+---------------------------+-------------------------------+ | ||||
11. Security Considerations | ||||
This section is meant to inform application developers, information | This section is meant to inform application developers, information | |||
providers, and users of the security limitations in HTTP/1.1 as | providers, and users of the security limitations in HTTP/1.1 as | |||
described by this document. The discussion does not include | described by this document. The discussion does not include | |||
definitive solutions to the problems revealed, though it does make | definitive solutions to the problems revealed, though it does make | |||
some suggestions for reducing security risks. | some suggestions for reducing security risks. | |||
10.1. Personal Information | 11.1. Personal Information | |||
HTTP clients are often privy to large amounts of personal information | HTTP clients are often privy to large amounts of personal information | |||
(e.g. the user's name, location, mail address, passwords, encryption | (e.g. the user's name, location, mail address, passwords, encryption | |||
keys, etc.), and SHOULD be very careful to prevent unintentional | keys, etc.), and SHOULD be very careful to prevent unintentional | |||
leakage of this information. We very strongly recommend that a | leakage of this information. We very strongly recommend that a | |||
convenient interface be provided for the user to control | convenient interface be provided for the user to control | |||
dissemination of such information, and that designers and | dissemination of such information, and that designers and | |||
implementors be particularly careful in this area. History shows | implementors be particularly careful in this area. History shows | |||
that errors in this area often create serious security and/or privacy | that errors in this area often create serious security and/or privacy | |||
problems and generate highly adverse publicity for the implementor's | problems and generate highly adverse publicity for the implementor's | |||
company. | company. | |||
10.2. Abuse of Server Log Information | 11.2. Abuse of Server Log Information | |||
A server is in the position to save personal data about a user's | A server is in the position to save personal data about a user's | |||
requests which might identify their reading patterns or subjects of | requests which might identify their reading patterns or subjects of | |||
interest. This information is clearly confidential in nature and its | interest. This information is clearly confidential in nature and its | |||
handling can be constrained by law in certain countries. People | handling can be constrained by law in certain countries. People | |||
using HTTP to provide data are responsible for ensuring that such | using HTTP to provide data are responsible for ensuring that such | |||
material is not distributed without the permission of any individuals | material is not distributed without the permission of any individuals | |||
that are identifiable by the published results. | that are identifiable by the published results. | |||
10.3. Attacks Based On File and Path Names | 11.3. Attacks Based On File and Path Names | |||
Implementations of HTTP origin servers SHOULD be careful to restrict | Implementations of HTTP origin servers SHOULD be careful to restrict | |||
the documents returned by HTTP requests to be only those that were | the documents returned by HTTP requests to be only those that were | |||
intended by the server administrators. If an HTTP server translates | intended by the server administrators. If an HTTP server translates | |||
HTTP URIs directly into file system calls, the server MUST take | HTTP URIs directly into file system calls, the server MUST take | |||
special care not to serve files that were not intended to be | special care not to serve files that were not intended to be | |||
delivered to HTTP clients. For example, UNIX, Microsoft Windows, and | delivered to HTTP clients. For example, UNIX, Microsoft Windows, and | |||
other operating systems use ".." as a path component to indicate a | other operating systems use ".." as a path component to indicate a | |||
directory level above the current one. On such a system, an HTTP | directory level above the current one. On such a system, an HTTP | |||
server MUST disallow any such construct in the request-target if it | server MUST disallow any such construct in the request-target if it | |||
would otherwise allow access to a resource outside those intended to | would otherwise allow access to a resource outside those intended to | |||
be accessible via the HTTP server. Similarly, files intended for | be accessible via the HTTP server. Similarly, files intended for | |||
reference only internally to the server (such as access control | reference only internally to the server (such as access control | |||
files, configuration files, and script code) MUST be protected from | files, configuration files, and script code) MUST be protected from | |||
inappropriate retrieval, since they might contain sensitive | inappropriate retrieval, since they might contain sensitive | |||
information. Experience has shown that minor bugs in such HTTP | information. Experience has shown that minor bugs in such HTTP | |||
server implementations have turned into security risks. | server implementations have turned into security risks. | |||
10.4. DNS Spoofing | 11.4. DNS Spoofing | |||
Clients using HTTP rely heavily on the Domain Name Service, and are | Clients using HTTP rely heavily on the Domain Name Service, and are | |||
thus generally prone to security attacks based on the deliberate mis- | thus generally prone to security attacks based on the deliberate mis- | |||
association of IP addresses and DNS names. Clients need to be | association of IP addresses and DNS names. Clients need to be | |||
cautious in assuming the continuing validity of an IP number/DNS name | cautious in assuming the continuing validity of an IP number/DNS name | |||
association. | association. | |||
In particular, HTTP clients SHOULD rely on their name resolver for | In particular, HTTP clients SHOULD rely on their name resolver for | |||
confirmation of an IP number/DNS name association, rather than | confirmation of an IP number/DNS name association, rather than | |||
caching the result of previous host name lookups. Many platforms | caching the result of previous host name lookups. Many platforms | |||
skipping to change at page 52, line 30 | skipping to change at page 59, line 20 | |||
a previously-accessed server's IP address changes. As network | a previously-accessed server's IP address changes. As network | |||
renumbering is expected to become increasingly common [RFC1900], the | renumbering is expected to become increasingly common [RFC1900], the | |||
possibility of this form of attack will grow. Observing this | possibility of this form of attack will grow. Observing this | |||
requirement thus reduces this potential security vulnerability. | requirement thus reduces this potential security vulnerability. | |||
This requirement also improves the load-balancing behavior of clients | This requirement also improves the load-balancing behavior of clients | |||
for replicated servers using the same DNS name and reduces the | for replicated servers using the same DNS name and reduces the | |||
likelihood of a user's experiencing failure in accessing sites which | likelihood of a user's experiencing failure in accessing sites which | |||
use that strategy. | use that strategy. | |||
10.5. Proxies and Caching | 11.5. Proxies and Caching | |||
By their very nature, HTTP proxies are men-in-the-middle, and | By their very nature, HTTP proxies are men-in-the-middle, and | |||
represent an opportunity for man-in-the-middle attacks. Compromise | represent an opportunity for man-in-the-middle attacks. Compromise | |||
of the systems on which the proxies run can result in serious | of the systems on which the proxies run can result in serious | |||
security and privacy problems. Proxies have access to security- | security and privacy problems. Proxies have access to security- | |||
related information, personal information about individual users and | related information, personal information about individual users and | |||
organizations, and proprietary information belonging to users and | organizations, and proprietary information belonging to users and | |||
content providers. A compromised proxy, or a proxy implemented or | content providers. A compromised proxy, or a proxy implemented or | |||
configured without regard to security and privacy considerations, | configured without regard to security and privacy considerations, | |||
might be used in the commission of a wide range of potential attacks. | might be used in the commission of a wide range of potential attacks. | |||
Proxy operators should protect the systems on which proxies run as | Proxy operators should protect the systems on which proxies run as | |||
they would protect any system that contains or transports sensitive | they would protect any system that contains or transports sensitive | |||
information. In particular, log information gathered at proxies | information. In particular, log information gathered at proxies | |||
often contains highly sensitive personal information, and/or | often contains highly sensitive personal information, and/or | |||
information about organizations. Log information should be carefully | information about organizations. Log information should be carefully | |||
guarded, and appropriate guidelines for use developed and followed. | guarded, and appropriate guidelines for use developed and followed. | |||
(Section 10.2). | (Section 11.2). | |||
Proxy implementors should consider the privacy and security | Proxy implementors should consider the privacy and security | |||
implications of their design and coding decisions, and of the | implications of their design and coding decisions, and of the | |||
configuration options they provide to proxy operators (especially the | configuration options they provide to proxy operators (especially the | |||
default configuration). | default configuration). | |||
Users of a proxy need to be aware that they are no trustworthier than | Users of a proxy need to be aware that they are no trustworthier than | |||
the people who run the proxy; HTTP itself cannot solve this problem. | the people who run the proxy; HTTP itself cannot solve this problem. | |||
The judicious use of cryptography, when appropriate, may suffice to | The judicious use of cryptography, when appropriate, may suffice to | |||
protect against a broad range of security and privacy attacks. Such | protect against a broad range of security and privacy attacks. Such | |||
cryptography is beyond the scope of the HTTP/1.1 specification. | cryptography is beyond the scope of the HTTP/1.1 specification. | |||
10.6. Denial of Service Attacks on Proxies | 11.6. 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. | |||
11. Acknowledgments | 12. Acknowledgments | |||
HTTP has evolved considerably over the years. It has benefited from | HTTP has evolved considerably over the years. It has benefited from | |||
a large and active developer community--the many people who have | a large and active developer community--the many people who have | |||
participated on the www-talk mailing list--and it is that community | participated on the www-talk mailing list--and it is that community | |||
which has been most responsible for the success of HTTP and of the | which has been most responsible for the success of HTTP and of the | |||
World-Wide Web in general. Marc Andreessen, Robert Cailliau, Daniel | World-Wide Web in general. Marc Andreessen, Robert Cailliau, Daniel | |||
W. Connolly, Bob Denny, John Franks, Jean-Francois Groff, Phillip M. | W. Connolly, Bob Denny, John Franks, Jean-Francois Groff, Phillip M. | |||
Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Lou Montulli, | Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Lou Montulli, | |||
Dave Raggett, Tony Sanders, and Marc VanHeyningen deserve special | Dave Raggett, Tony Sanders, and Marc VanHeyningen deserve special | |||
recognition for their efforts in defining early aspects of the | recognition for their efforts in defining early aspects of the | |||
skipping to change at page 54, line 24 | skipping to change at page 61, line 14 | |||
discovery of many of the problems that this document attempts to | discovery of many of the problems that this document attempts to | |||
rectify. | rectify. | |||
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 [RFC5234]. Similarly, it | constructs defined by David H. Crocker for [RFC5234]. Similarly, it | |||
reuses many of the definitions provided by Nathaniel Borenstein and | reuses many of the definitions provided by Nathaniel Borenstein and | |||
Ned Freed for MIME [RFC2045]. We hope that their inclusion in this | Ned Freed for MIME [RFC2045]. We hope that their inclusion in this | |||
specification will help reduce past confusion over the relationship | specification will help reduce past confusion over the relationship | |||
between HTTP and Internet mail message formats. | between HTTP and Internet mail message formats. | |||
12. References | 13. References | |||
12.1. Normative References | 13.1. 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 -- Part 1: Latin alphabet No. 1", ISO/ | character sets -- Part 1: Latin alphabet No. 1", ISO/ | |||
IEC 8859-1:1998, 1998. | IEC 8859-1:1998, 1998. | |||
[Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | |||
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | |||
and J. Reschke, Ed., "HTTP/1.1, part 2: Message | and J. Reschke, Ed., "HTTP/1.1, part 2: Message | |||
Semantics", draft-ietf-httpbis-p2-semantics-07 (work in | Semantics", draft-ietf-httpbis-p2-semantics-08 (work in | |||
progress), July 2009. | progress), October 2009. | |||
[Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | |||
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | |||
and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload | and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload | |||
and Content Negotiation", draft-ietf-httpbis-p3-payload-07 | and Content Negotiation", draft-ietf-httpbis-p3-payload-08 | |||
(work in progress), July 2009. | (work in progress), October 2009. | |||
[Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | |||
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | |||
and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and | and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and | |||
Partial Responses", draft-ietf-httpbis-p5-range-07 (work | Partial Responses", draft-ietf-httpbis-p5-range-08 (work | |||
in progress), July 2009. | in progress), October 2009. | |||
[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | |||
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | |||
Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part | Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part | |||
6: Caching", draft-ietf-httpbis-p6-cache-07 (work in | 6: Caching", draft-ietf-httpbis-p6-cache-08 (work in | |||
progress), July 2009. | progress), October 2009. | |||
[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format | ||||
Specification version 3.3", RFC 1950, May 1996. | ||||
RFC 1950 is an Informational RFC, thus it may be less | ||||
stable than this specification. On the other hand, this | ||||
downward reference was present since the publication of | ||||
RFC 2068 in 1997 ([RFC2068]), therefore it is unlikely to | ||||
cause problems in practice. See also [BCP97]. | ||||
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification | ||||
version 1.3", RFC 1951, May 1996. | ||||
RFC 1951 is an Informational RFC, thus it may be less | ||||
stable than this specification. On the other hand, this | ||||
downward reference was present since the publication of | ||||
RFC 2068 in 1997 ([RFC2068]), therefore it is unlikely to | ||||
cause problems in practice. See also [BCP97]. | ||||
[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. | ||||
RFC 1952 is an Informational RFC, thus it may be less | ||||
stable than this specification. On the other hand, this | ||||
downward reference was present since the publication of | ||||
RFC 2068 in 1997 ([RFC2068]), therefore it is unlikely to | ||||
cause problems in practice. See also [BCP97]. | ||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform | [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform | |||
Resource Identifier (URI): Generic Syntax", RFC 3986, | Resource Identifier (URI): Generic Syntax", RFC 3986, | |||
STD 66, January 2005. | STD 66, January 2005. | |||
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax | [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax | |||
Specifications: ABNF", STD 68, RFC 5234, January 2008. | Specifications: ABNF", STD 68, RFC 5234, January 2008. | |||
[USASCII] American National Standards Institute, "Coded Character | [USASCII] American National Standards Institute, "Coded Character | |||
Set -- 7-bit American Standard Code for Information | Set -- 7-bit American Standard Code for Information | |||
Interchange", ANSI X3.4, 1986. | Interchange", ANSI X3.4, 1986. | |||
12.2. Informative References | 13.2. Informative References | |||
[BCP97] Klensin, J. and S. Hartman, "Handling Normative References | ||||
to Standards-Track Documents", BCP 97, RFC 4897, | ||||
June 2007. | ||||
[Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and | [Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and | |||
Politics", ACM Transactions on Internet Technology Vol. 1, | Politics", ACM Transactions on Internet Technology Vol. 1, | |||
#2, November 2001, <http://arxiv.org/abs/cs.SE/0105018>. | #2, November 2001, <http://arxiv.org/abs/cs.SE/0105018>. | |||
[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", ACM Proceedings of the ACM SIGCOMM '97 | and PNG", ACM Proceedings of the ACM SIGCOMM '97 | |||
conference on Applications, technologies, architectures, | conference on Applications, technologies, architectures, | |||
and protocols for computer communication SIGCOMM '97, | and protocols for computer communication SIGCOMM '97, | |||
skipping to change at page 56, line 31 | skipping to change at page 64, line 5 | |||
Mechanism", RFC 2109, February 1997. | Mechanism", RFC 2109, February 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. | |||
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., | [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., | |||
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext | Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext | |||
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. | Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. | |||
[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within | ||||
HTTP/1.1", RFC 2817, May 2000. | ||||
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. | [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. | |||
[RFC2965] Kristol, D. and L. Montulli, "HTTP State Management | [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management | |||
Mechanism", RFC 2965, October 2000. | Mechanism", RFC 2965, October 2000. | |||
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration | [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration | |||
Procedures for Message Header Fields", BCP 90, RFC 3864, | Procedures for Message Header Fields", BCP 90, RFC 3864, | |||
September 2004. | September 2004. | |||
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and | [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and | |||
Registration Procedures", BCP 13, RFC 4288, December 2005. | Registration Procedures", BCP 13, RFC 4288, December 2005. | |||
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and | [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and | |||
Registration Procedures for New URI Schemes", BCP 115, | Registration Procedures for New URI Schemes", BCP 115, | |||
RFC 4395, February 2006. | RFC 4395, February 2006. | |||
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an | ||||
IANA Considerations Section in RFCs", BCP 26, RFC 5226, | ||||
May 2008. | ||||
[RFC5322] Resnick, P., "Internet Message Format", RFC 5322, | [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, | |||
October 2008. | October 2008. | |||
[Spe] Spero, S., "Analysis of HTTP Performance Problems", | [Spe] 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", ISI Research Report ISI/RR-98-463, | |||
Aug 1998, <http://www.isi.edu/touch/pubs/http-perf96/>. | Aug 1998, <http://www.isi.edu/touch/pubs/http-perf96/>. | |||
skipping to change at page 57, line 24 | skipping to change at page 65, line 5 | |||
of HTTP/1.1 messages, not all applications will be correct in their | of HTTP/1.1 messages, not all applications will be correct in their | |||
implementation. We therefore recommend that operational applications | implementation. We therefore recommend that operational applications | |||
be tolerant of deviations whenever those deviations can be | be tolerant of deviations whenever those deviations can be | |||
interpreted unambiguously. | interpreted unambiguously. | |||
Clients SHOULD be tolerant in parsing the Status-Line and servers | Clients SHOULD be tolerant in parsing the Status-Line and servers | |||
tolerant when parsing the Request-Line. In particular, they SHOULD | tolerant when parsing the Request-Line. In particular, they SHOULD | |||
accept any amount of WSP characters between fields, even though only | accept any amount of WSP characters between fields, even though only | |||
a single SP is required. | a single SP is required. | |||
The line terminator for message-header fields is the sequence CRLF. | The line terminator for header fields is the sequence CRLF. However, | |||
However, we recommend that applications, when parsing such headers, | we recommend that applications, when parsing such headers, recognize | |||
recognize a single LF as a line terminator and ignore the leading CR. | a single LF as a line terminator and ignore the leading CR. | |||
The character set of an entity-body SHOULD be labeled as the lowest | The character set of an entity-body SHOULD be labeled as the lowest | |||
common denominator of the character codes used within that body, with | common denominator of the character codes used within that body, with | |||
the exception that not labeling the entity is preferred over labeling | the exception that not labeling the entity is preferred over labeling | |||
the entity with the labels US-ASCII or ISO-8859-1. See [Part3]. | the entity with the labels US-ASCII or ISO-8859-1. See [Part3]. | |||
Additional rules for requirements on parsing and encoding of dates | Additional rules for requirements on parsing and encoding of dates | |||
and other potential problems with date encodings include: | and other potential problems with date encodings include: | |||
o HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date | o HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date | |||
skipping to change at page 58, line 30 | skipping to change at page 66, line 11 | |||
HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent | HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent | |||
requirements that enable reliable implementations, adding only those | requirements that enable reliable implementations, adding only those | |||
new features that will either be safely ignored by an HTTP/1.0 | new features that will either be safely ignored by an HTTP/1.0 | |||
recipient or only sent when communicating with a party advertising | recipient or only sent when communicating with a party advertising | |||
compliance with HTTP/1.1. | compliance with HTTP/1.1. | |||
It is beyond the scope of a protocol specification to mandate | It is beyond the scope of a protocol specification to mandate | |||
compliance with previous versions. HTTP/1.1 was deliberately | compliance with previous versions. HTTP/1.1 was deliberately | |||
designed, however, to make supporting previous versions easy. It is | designed, however, to make supporting previous versions easy. It is | |||
worth noting that, at the time of composing this specification | worth noting that, at the time of composing this specification, we | |||
(1996), we would expect commercial HTTP/1.1 servers to: | would expect general-purpose HTTP/1.1 servers to: | |||
o recognize the format of the Request-Line for HTTP/0.9, 1.0, and | ||||
1.1 requests; | ||||
o understand any valid request in the format of HTTP/0.9, 1.0, or | o understand any valid request in the format of HTTP/1.0 and 1.1; | |||
1.1; | ||||
o respond appropriately with a message in the same major version | o respond appropriately with a message in the same major version | |||
used by the client. | used by the client. | |||
And we would expect HTTP/1.1 clients to: | And we would expect HTTP/1.1 clients to: | |||
o recognize the format of the Status-Line for HTTP/1.0 and 1.1 | o understand any valid response in the format of HTTP/1.0 or 1.1. | |||
responses; | ||||
o understand any valid response in the format of HTTP/0.9, 1.0, or | ||||
1.1. | ||||
For most implementations of HTTP/1.0, each connection is established | For most implementations of HTTP/1.0, each connection is established | |||
by the client prior to the request and closed by the server after | by the client prior to the request and closed by the server after | |||
sending the response. Some implementations implement the Keep-Alive | sending the response. Some implementations implement the Keep-Alive | |||
version of persistent connections described in Section 19.7.1 of | version of persistent connections described in Section 19.7.1 of | |||
[RFC2068]. | [RFC2068]. | |||
B.1. Changes from HTTP/1.0 | B.1. Changes from HTTP/1.0 | |||
This section summarizes major differences between versions HTTP/1.0 | This section summarizes major differences between versions HTTP/1.0 | |||
and HTTP/1.1. | and HTTP/1.1. | |||
B.1.1. Changes to Simplify Multi-homed Web Servers and Conserve IP | B.1.1. Changes to Simplify Multi-homed Web Servers and Conserve IP | |||
Addresses | Addresses | |||
The requirements that clients and servers support the Host request- | The requirements that clients and servers support the Host request- | |||
header, report an error if the Host request-header (Section 8.4) is | header, report an error if the Host request-header (Section 9.4) is | |||
missing from an HTTP/1.1 request, and accept absolute URIs | missing from an HTTP/1.1 request, and accept absolute URIs | |||
(Section 5.1.2) are among the most important changes defined by this | (Section 4.1.2) are among the most important changes defined by this | |||
specification. | specification. | |||
Older HTTP/1.0 clients assumed a one-to-one relationship of IP | Older HTTP/1.0 clients assumed a one-to-one relationship of IP | |||
addresses and servers; there was no other established mechanism for | addresses and servers; there was no other established mechanism for | |||
distinguishing the intended server of a request than the IP address | distinguishing the intended server of a request than the IP address | |||
to which that request was directed. The changes outlined above will | to which that request was directed. The changes outlined above will | |||
allow the Internet, once older HTTP clients are no longer common, to | allow the Internet, once older HTTP clients are no longer common, to | |||
support multiple Web sites from a single IP address, greatly | support multiple Web sites from a single IP address, greatly | |||
simplifying large operational Web servers, where allocation of many | simplifying large operational Web servers, where allocation of many | |||
IP addresses to a single host has created serious problems. The | IP addresses to a single host has created serious problems. The | |||
skipping to change at page 60, line 20 | skipping to change at page 67, line 42 | |||
result in a hung HTTP/1.0 proxy waiting for the close on the | result in a hung HTTP/1.0 proxy waiting for the close on the | |||
response. The result is that HTTP/1.0 clients must be prevented from | response. The result is that HTTP/1.0 clients must be prevented from | |||
using Keep-Alive when talking to proxies. | using Keep-Alive when talking to proxies. | |||
However, talking to proxies is the most important use of persistent | However, talking to proxies is the most important use of persistent | |||
connections, so that prohibition is clearly unacceptable. Therefore, | connections, so that prohibition is clearly unacceptable. Therefore, | |||
we need some other mechanism for indicating a persistent connection | we need some other mechanism for indicating a persistent connection | |||
is desired, which is safe to use even when talking to an old proxy | is desired, which is safe to use even when talking to an old proxy | |||
that ignores Connection. Persistent connections are the default for | that ignores Connection. Persistent connections are the default for | |||
HTTP/1.1 messages; we introduce a new keyword (Connection: close) for | HTTP/1.1 messages; we introduce a new keyword (Connection: close) for | |||
declaring non-persistence. See Section 8.1. | declaring non-persistence. See Section 9.1. | |||
The original HTTP/1.0 form of persistent connections (the Connection: | The original HTTP/1.0 form of persistent connections (the Connection: | |||
Keep-Alive and Keep-Alive header) is documented in Section 19.7.1 of | Keep-Alive and Keep-Alive header) is documented in Section 19.7.1 of | |||
[RFC2068]. | [RFC2068]. | |||
B.3. Changes from RFC 2068 | B.3. Changes from RFC 2068 | |||
This specification has been carefully audited to correct and | This specification has been carefully audited to correct and | |||
disambiguate key word usage; RFC 2068 had many problems in respect to | disambiguate key word usage; RFC 2068 had many problems in respect to | |||
the conventions laid out in [RFC2119]. | the conventions laid out in [RFC2119]. | |||
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.3, 4.4, 8.2, see also [Part3], [Part5] and [Part6]) | (Sections 6.2, 3.4, 9.2, see also [Part3], [Part5] and [Part6]) | |||
The use and interpretation of HTTP version numbers has been clarified | The use and interpretation of HTTP version numbers has been clarified | |||
by [RFC2145]. Require proxies to upgrade requests to highest | by [RFC2145]. Require proxies to upgrade requests to highest | |||
protocol version they support to deal with problems discovered in | protocol version they support to deal with problems discovered in | |||
HTTP/1.0 implementations (Section 3.1) | HTTP/1.0 implementations (Section 2.5) | |||
Quality Values of zero should indicate that "I don't want something" | Quality Values of zero should indicate that "I don't want something" | |||
to allow clients to refuse a representation. (Section 3.5) | to allow clients to refuse a representation. (Section 6.4) | |||
Transfer-coding had significant problems, particularly with | Transfer-coding had significant problems, particularly with | |||
interactions with chunked encoding. The solution is that transfer- | interactions with chunked encoding. The solution is that transfer- | |||
codings become as full fledged as content-codings. This involves | codings become as full fledged as content-codings. This involves | |||
adding an IANA registry for transfer-codings (separate from content | adding an IANA registry for transfer-codings (separate from content | |||
codings), a new header field (TE) and enabling trailer headers in the | codings), a new header field (TE) and enabling trailer headers in the | |||
future. Transfer encoding is a major performance benefit, so it was | future. Transfer encoding is a major performance benefit, so it was | |||
worth fixing [Nie1997]. TE also solves another, obscure, downward | worth fixing [Nie1997]. TE also solves another, obscure, downward | |||
interoperability problem that could have occurred due to interactions | interoperability problem that could have occurred due to interactions | |||
between authentication trailers, chunked encoding and HTTP/1.0 | between authentication trailers, chunked encoding and HTTP/1.0 | |||
clients.(Section 3.3, 3.3.1, and 8.5) | clients.(Section 6.2, 6.2.1, and 9.5) | |||
B.4. Changes from RFC 2616 | B.4. Changes from RFC 2616 | |||
Empty list elements in list productions have been deprecated. | Empty list elements in list productions have been deprecated. | |||
(Section 1.2.1) | (Section 1.2.1) | |||
Rules about implicit linear whitespace between certain grammar | Rules about implicit linear whitespace between certain grammar | |||
productions have been removed; now it's only allowed when | productions have been removed; now it's only allowed when | |||
specifically pointed out in the ABNF. The NUL character is no longer | specifically pointed out in the ABNF. The NUL character is no longer | |||
allowed in comment and quoted-string text. The quoted-pair rule no | allowed in comment and quoted-string text. The quoted-pair rule no | |||
longer allows escaping NUL, CR or LF. Non-ASCII content in header | longer allows escaping control characters other than HTAB. Non-ASCII | |||
fields and reason phrase has been obsoleted and made opaque (the TEXT | content in header fields and reason phrase has been obsoleted and | |||
rule was removed) (Section 1.2.2) | made opaque (the TEXT rule was removed) (Section 1.2.2) | |||
Clarify that HTTP-Version is case sensitive. (Section 3.1) | Clarify that HTTP-Version is case sensitive. (Section 2.5) | |||
Remove reference to non-existant identity transfer-coding value | Remove reference to non-existant identity transfer-coding value | |||
tokens. (Sections 3.3 and 4.4) | tokens. (Sections 6.2 and 3.4) | |||
Clarification that the chunk length does not include the count of the | ||||
octets in the chunk header and trailer. (Section 3.3.1) | ||||
Require that invalid whitespace around field-names be rejected. | Require that invalid whitespace around field-names be rejected. | |||
(Section 4.2) | (Section 3.2) | |||
Update use of abs_path production from RFC1808 to the path-absolute + | Update use of abs_path production from RFC1808 to the path-absolute + | |||
query components of RFC3986. (Section 5.1.2) | query components of RFC3986. (Section 4.1.2) | |||
Clarify exactly when close connection options must be sent. | ||||
(Section 8.1) | ||||
Appendix C. Terminology | ||||
This specification uses a number of terms to refer to the roles | ||||
played by participants in, and objects of, the HTTP communication. | ||||
cache | ||||
A program's local store of response messages and the subsystem | ||||
that controls its message storage, retrieval, and deletion. A | ||||
cache stores cacheable responses in order to reduce the response | ||||
time and network bandwidth consumption on future, equivalent | ||||
requests. Any client or server may include a cache, though a | ||||
cache cannot be used by a server that is acting as a tunnel. | ||||
cacheable | ||||
A response is cacheable if a cache is allowed to store a copy of | ||||
the response message for use in answering subsequent requests. | ||||
The rules for determining the cacheability of HTTP responses are | ||||
defined in Section 1 of [Part6]. Even if a resource is cacheable, | ||||
there may be additional constraints on whether a cache can use the | ||||
cached copy for a particular request. | ||||
client | ||||
A program that establishes connections for the purpose of sending | ||||
requests. | ||||
connection | ||||
A transport layer virtual circuit established between two programs | ||||
for the purpose of communication. | ||||
content negotiation | ||||
The mechanism for selecting the appropriate representation when | ||||
servicing a request, as described in Section 4 of [Part3]. The | ||||
representation of entities in any response can be negotiated | ||||
(including error responses). | ||||
entity | ||||
The information transferred as the payload of a request or | ||||
response. An entity consists of metainformation in the form of | ||||
entity-header fields and content in the form of an entity-body, as | ||||
described in Section 3 of [Part3]. | ||||
gateway | ||||
A server which acts as an intermediary for some other server. | ||||
Unlike a proxy, a gateway receives requests as if it were the | ||||
origin server for the requested resource; the requesting client | ||||
may not be aware that it is communicating with a gateway. | ||||
inbound/outbound | ||||
Inbound and outbound refer to the request and response paths for | ||||
messages: "inbound" means "traveling toward the origin server", | ||||
and "outbound" means "traveling toward the user agent" | ||||
message | ||||
The basic unit of HTTP communication, consisting of a structured | ||||
sequence of octets matching the syntax defined in Section 4 and | ||||
transmitted via the connection. | ||||
origin server | ||||
The server on which a given resource resides or is to be created. | ||||
proxy | ||||
An intermediary program which acts as both a server and a client | ||||
for the purpose of making requests on behalf of other clients. | ||||
Requests are serviced internally or by passing them on, with | ||||
possible translation, to other servers. A proxy MUST implement | ||||
both the client and server requirements of this specification. A | ||||
"transparent proxy" is a proxy that does not modify the request or | ||||
response beyond what is required for proxy authentication and | ||||
identification. A "non-transparent proxy" is a proxy that | ||||
modifies the request or response in order to provide some added | ||||
service to the user agent, such as group annotation services, | ||||
media type transformation, protocol reduction, or anonymity | ||||
filtering. Except where either transparent or non-transparent | ||||
behavior is explicitly stated, the HTTP proxy requirements apply | ||||
to both types of proxies. | ||||
request | ||||
An HTTP request message, as defined in Section 5. | ||||
resource | ||||
A network data object or service that can be identified by a URI, | ||||
as defined in Section 2.1. Resources may be available in multiple | ||||
representations (e.g. multiple languages, data formats, size, and | ||||
resolutions) or vary in other ways. | ||||
response | ||||
An HTTP response message, as defined in Section 6. | ||||
representation | ||||
An entity included with a response that is subject to content | ||||
negotiation, as described in Section 4 of [Part3]. There may | ||||
exist multiple representations associated with a particular | ||||
response status. | ||||
server | ||||
An application program that accepts connections in order to | ||||
service requests by sending back responses. Any given program may | ||||
be capable of being both a client and a server; our use of these | ||||
terms refers only to the role being performed by the program for a | ||||
particular connection, rather than to the program's capabilities | ||||
in general. Likewise, any server may act as an origin server, | ||||
proxy, gateway, or tunnel, switching behavior based on the nature | ||||
of each request. | ||||
tunnel | ||||
An intermediary program which is acting as a blind relay between | ||||
two connections. Once active, a tunnel is not considered a party | ||||
to the HTTP communication, though the tunnel may have been | ||||
initiated by an HTTP request. The tunnel ceases to exist when | ||||
both ends of the relayed connections are closed. | ||||
upstream/downstream | ||||
Upstream and downstream describe the flow of a message: all | ||||
messages flow from upstream to downstream. | ||||
user agent | ||||
The client which initiates a request. These are often browsers, | Clarification that the chunk length does not include the count of the | |||
editors, spiders (web-traversing robots), or other end user tools. | octets in the chunk header and trailer. Furthermore disallowed line | |||
folding in chunk extensions. (Section 6.2.1) | ||||
variant | Remove hard limit of two connections per server. (Section 7.1.4) | |||
A resource may have one, or more than one, representation(s) | Clarify exactly when close connection options must be sent. | |||
associated with it at any given instant. Each of these | (Section 9.1) | |||
representations is termed a `variant'. Use of the term `variant' | ||||
does not necessarily imply that the resource is subject to content | ||||
negotiation. | ||||
Appendix D. Collected ABNF | Appendix C. Collected ABNF | |||
BWS = OWS | BWS = OWS | |||
Cache-Control = <Cache-Control, defined in [Part6], Section 3.4> | Cache-Control = <Cache-Control, defined in [Part6], Section 3.4> | |||
Chunked-Body = *chunk last-chunk trailer-part CRLF | Chunked-Body = *chunk last-chunk trailer-part CRLF | |||
Connection = "Connection:" OWS Connection-v | Connection = "Connection:" OWS Connection-v | |||
Connection-v = *( "," OWS ) connection-token *( OWS "," [ OWS | Connection-v = *( "," OWS ) connection-token *( OWS "," [ OWS | |||
connection-token ] ) | connection-token ] ) | |||
Content-Length = "Content-Length:" OWS 1*Content-Length-v | Content-Length = "Content-Length:" OWS 1*Content-Length-v | |||
Content-Length-v = 1*DIGIT | Content-Length-v = 1*DIGIT | |||
Date = "Date:" OWS Date-v | Date = "Date:" OWS Date-v | |||
Date-v = HTTP-date | Date-v = HTTP-date | |||
GMT = %x47.4D.54 ; GMT | GMT = %x47.4D.54 ; GMT | |||
HTTP-Prot-Name = %x48.54.54.50 ; HTTP | HTTP-Prot-Name = %x48.54.54.50 ; HTTP | |||
HTTP-Version = HTTP-Prot-Name "/" 1*DIGIT "." 1*DIGIT | HTTP-Version = HTTP-Prot-Name "/" 1*DIGIT "." 1*DIGIT | |||
HTTP-date = rfc1123-date / obs-date | HTTP-date = rfc1123-date / obs-date | |||
HTTP-message = Request / Response | HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body | |||
] | ||||
Host = "Host:" OWS Host-v | Host = "Host:" OWS Host-v | |||
Host-v = uri-host [ ":" port ] | Host-v = uri-host [ ":" port ] | |||
Method = token | Method = token | |||
OWS = *( [ obs-fold ] WSP ) | OWS = *( [ obs-fold ] WSP ) | |||
Pragma = <Pragma, defined in [Part6], Section 3.4> | Pragma = <Pragma, defined in [Part6], Section 3.4> | |||
RWS = 1*( [ obs-fold ] WSP ) | RWS = 1*( [ obs-fold ] WSP ) | |||
skipping to change at page 66, line 16 | skipping to change at page 70, line 41 | |||
absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3> | absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3> | |||
asctime-date = day-name SP date3 SP time-of-day SP year | asctime-date = day-name SP date3 SP time-of-day SP year | |||
attribute = token | attribute = token | |||
authority = <authority, defined in [RFC3986], Section 3.2> | authority = <authority, defined in [RFC3986], Section 3.2> | |||
chunk = chunk-size *WSP [ chunk-ext ] CRLF chunk-data CRLF | chunk = chunk-size *WSP [ chunk-ext ] CRLF chunk-data CRLF | |||
chunk-data = 1*OCTET | chunk-data = 1*OCTET | |||
chunk-ext = *( ";" *WSP chunk-ext-name [ "=" chunk-ext-val ] *WSP ) | chunk-ext = *( ";" *WSP chunk-ext-name [ "=" chunk-ext-val ] *WSP ) | |||
chunk-ext-name = token | chunk-ext-name = token | |||
chunk-ext-val = token / quoted-string | chunk-ext-val = token / quoted-str-nf | |||
chunk-size = 1*HEXDIG | chunk-size = 1*HEXDIG | |||
comment = "(" *( ctext / quoted-pair / comment ) ")" | comment = "(" *( ctext / quoted-cpair / comment ) ")" | |||
connection-token = token | connection-token = token | |||
ctext = OWS / %x21-27 ; '!'-''' | ctext = OWS / %x21-27 ; '!'-''' | |||
/ %x2A-5B ; '*'-'[' | / %x2A-5B ; '*'-'[' | |||
/ %x5D-7E ; ']'-'~' | / %x5D-7E ; ']'-'~' | |||
/ obs-text | / obs-text | |||
date1 = day SP month SP year | date1 = day SP month SP year | |||
date2 = day "-" month "-" 2DIGIT | date2 = day "-" month "-" 2DIGIT | |||
date3 = month SP ( 2DIGIT / ( SP DIGIT ) ) | date3 = month SP ( 2DIGIT / ( SP DIGIT ) ) | |||
day = 2DIGIT | day = 2DIGIT | |||
skipping to change at page 66, line 50 | skipping to change at page 71, line 26 | |||
/ %x46.72.69.64.61.79 ; Friday | / %x46.72.69.64.61.79 ; Friday | |||
/ %x53.61.74.75.72.64.61.79 ; Saturday | / %x53.61.74.75.72.64.61.79 ; Saturday | |||
/ %x53.75.6E.64.61.79 ; Sunday | / %x53.75.6E.64.61.79 ; Sunday | |||
entity-body = <entity-body, defined in [Part3], Section 3.2> | entity-body = <entity-body, defined in [Part3], Section 3.2> | |||
entity-header = <entity-header, defined in [Part3], Section 3.1> | entity-header = <entity-header, defined in [Part3], Section 3.1> | |||
field-content = *( WSP / VCHAR / obs-text ) | field-content = *( WSP / VCHAR / obs-text ) | |||
field-name = token | field-name = token | |||
field-value = *( field-content / OWS ) | field-value = *( field-content / OWS ) | |||
fragment = <fragment, defined in [RFC3986], Section 3.5> | ||||
general-header = Cache-Control / Connection / Date / Pragma / Trailer | general-header = Cache-Control / Connection / Date / Pragma / Trailer | |||
/ Transfer-Encoding / Upgrade / Via / Warning | / Transfer-Encoding / Upgrade / Via / Warning | |||
generic-message = start-line *( message-header CRLF ) CRLF [ | ||||
message-body ] | ||||
header-field = field-name ":" OWS [ field-value ] OWS | ||||
hour = 2DIGIT | hour = 2DIGIT | |||
http-URI = "http://" authority path-abempty [ "?" query ] | http-URI = "http://" authority path-abempty [ "?" query ] | |||
https-URI = "https://" authority path-abempty [ "?" query ] | ||||
last-chunk = 1*"0" *WSP [ chunk-ext ] CRLF | last-chunk = 1*"0" *WSP [ chunk-ext ] CRLF | |||
message-body = entity-body / | message-body = entity-body / | |||
<entity-body encoded as per Transfer-Encoding> | <entity-body encoded as per Transfer-Encoding> | |||
message-header = field-name ":" OWS [ field-value ] OWS | ||||
minute = 2DIGIT | minute = 2DIGIT | |||
month = %x4A.61.6E ; Jan | month = %x4A.61.6E ; Jan | |||
/ %x46.65.62 ; Feb | / %x46.65.62 ; Feb | |||
/ %x4D.61.72 ; Mar | / %x4D.61.72 ; Mar | |||
/ %x41.70.72 ; Apr | / %x41.70.72 ; Apr | |||
/ %x4D.61.79 ; May | / %x4D.61.79 ; May | |||
/ %x4A.75.6E ; Jun | / %x4A.75.6E ; Jun | |||
/ %x4A.75.6C ; Jul | / %x4A.75.6C ; Jul | |||
/ %x41.75.67 ; Aug | / %x41.75.67 ; Aug | |||
/ %x53.65.70 ; Sep | / %x53.65.70 ; Sep | |||
skipping to change at page 67, line 48 | skipping to change at page 72, line 22 | |||
port = <port, defined in [RFC3986], Section 3.2.3> | port = <port, defined in [RFC3986], Section 3.2.3> | |||
product = token [ "/" product-version ] | product = token [ "/" product-version ] | |||
product-version = token | product-version = token | |||
protocol-name = token | protocol-name = token | |||
protocol-version = token | protocol-version = token | |||
pseudonym = token | pseudonym = token | |||
qdtext = OWS / "!" / %x23-5B ; '#'-'[' | qdtext = OWS / "!" / %x23-5B ; '#'-'[' | |||
/ %x5D-7E ; ']'-'~' | / %x5D-7E ; ']'-'~' | |||
/ obs-text | / obs-text | |||
qdtext-nf = WSP / "!" / %x23-5B ; '#'-'[' | ||||
/ %x5D-7E ; ']'-'~' | ||||
/ obs-text | ||||
query = <query, defined in [RFC3986], Section 3.4> | query = <query, defined in [RFC3986], Section 3.4> | |||
quoted-pair = "\" quoted-text | quoted-cpair = "\" ( WSP / VCHAR / obs-text ) | |||
quoted-pair = "\" ( WSP / VCHAR / obs-text ) | ||||
quoted-str-nf = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE | ||||
quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE | quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE | |||
quoted-text = %x01-09 / %x0B-0C / %x0E-FF | ||||
qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] ) | qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] ) | |||
received-by = ( uri-host [ ":" port ] ) / pseudonym | received-by = ( uri-host [ ":" port ] ) / pseudonym | |||
received-protocol = [ protocol-name "/" ] protocol-version | received-protocol = [ protocol-name "/" ] protocol-version | |||
relative-part = <relative-part, defined in [RFC3986], Section 4.2> | relative-part = <relative-part, defined in [RFC3986], Section 4.2> | |||
request-header = <request-header, defined in [Part2], Section 3> | request-header = <request-header, defined in [Part2], Section 3> | |||
request-target = "*" / absolute-URI / ( path-absolute [ "?" query ] ) | request-target = "*" / absolute-URI / ( path-absolute [ "?" query ] ) | |||
/ authority | / authority | |||
response-header = <response-header, defined in [Part2], Section 5> | response-header = <response-header, defined in [Part2], Section 5> | |||
rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT | rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT | |||
skipping to change at page 68, line 27 | skipping to change at page 73, line 4 | |||
start-line = Request-Line / Status-Line | start-line = Request-Line / Status-Line | |||
t-codings = "trailers" / ( transfer-extension [ te-params ] ) | t-codings = "trailers" / ( transfer-extension [ te-params ] ) | |||
tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." / | tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." / | |||
"^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA | "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA | |||
te-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ] | te-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ] | |||
te-params = OWS ";" OWS "q=" qvalue *te-ext | te-params = OWS ";" OWS "q=" qvalue *te-ext | |||
time-of-day = hour ":" minute ":" second | time-of-day = hour ":" minute ":" second | |||
token = 1*tchar | token = 1*tchar | |||
trailer-part = *( entity-header CRLF ) | trailer-part = *( entity-header CRLF ) | |||
transfer-coding = "chunked" / transfer-extension | transfer-coding = "chunked" / "compress" / "deflate" / "gzip" / | |||
transfer-extension | ||||
transfer-extension = token *( OWS ";" OWS transfer-parameter ) | transfer-extension = token *( OWS ";" OWS transfer-parameter ) | |||
transfer-parameter = attribute BWS "=" BWS value | transfer-parameter = attribute BWS "=" BWS value | |||
uri-host = <host, defined in [RFC3986], Section 3.2.2> | uri-host = <host, defined in [RFC3986], Section 3.2.2> | |||
value = token / quoted-string | value = token / quoted-string | |||
year = 4DIGIT | year = 4DIGIT | |||
ABNF diagnostics: | ABNF diagnostics: | |||
; Chunked-Body defined but not used | ; Chunked-Body defined but not used | |||
; Content-Length defined but not used | ; Content-Length defined but not used | |||
; HTTP-message defined but not used | ; HTTP-message defined but not used | |||
; Host defined but not used | ; Host defined but not used | |||
; Request defined but not used | ||||
; Response defined but not used | ||||
; TE defined but not used | ; TE defined but not used | |||
; URI defined but not used | ; URI defined but not used | |||
; URI-reference defined but not used | ; URI-reference defined but not used | |||
; fragment defined but not used | ||||
; generic-message defined but not used | ||||
; http-URI defined but not used | ; http-URI defined but not used | |||
; https-URI defined but not used | ||||
; partial-URI defined but not used | ; partial-URI defined but not used | |||
Appendix E. Change Log (to be removed by RFC Editor before publication) | Appendix D. Change Log (to be removed by RFC Editor before publication) | |||
E.1. Since RFC2616 | D.1. Since RFC2616 | |||
Extracted relevant partitions from [RFC2616]. | Extracted relevant partitions from [RFC2616]. | |||
E.2. Since draft-ietf-httpbis-p1-messaging-00 | D.2. Since draft-ietf-httpbis-p1-messaging-00 | |||
Closed issues: | Closed issues: | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/1>: "HTTP Version | o <http://tools.ietf.org/wg/httpbis/trac/ticket/1>: "HTTP Version | |||
should be case sensitive" | should be case sensitive" | |||
(<http://purl.org/NET/http-errata#verscase>) | (<http://purl.org/NET/http-errata#verscase>) | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/2>: "'unsafe' | o <http://tools.ietf.org/wg/httpbis/trac/ticket/2>: "'unsafe' | |||
characters" (<http://purl.org/NET/http-errata#unsafe-uri>) | characters" (<http://purl.org/NET/http-errata#unsafe-uri>) | |||
skipping to change at page 70, line 34 | skipping to change at page 75, line 13 | |||
to-date references" | to-date references" | |||
Other changes: | Other changes: | |||
o Update media type registrations to use RFC4288 template. | o Update media type registrations to use RFC4288 template. | |||
o Use names of RFC4234 core rules DQUOTE and WSP, fix broken ABNF | o Use names of RFC4234 core rules DQUOTE and WSP, fix broken ABNF | |||
for chunk-data (work in progress on | for chunk-data (work in progress on | |||
<http://tools.ietf.org/wg/httpbis/trac/ticket/36>) | <http://tools.ietf.org/wg/httpbis/trac/ticket/36>) | |||
E.3. Since draft-ietf-httpbis-p1-messaging-01 | D.3. Since draft-ietf-httpbis-p1-messaging-01 | |||
Closed issues: | Closed issues: | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/19>: "Bodies on GET | o <http://tools.ietf.org/wg/httpbis/trac/ticket/19>: "Bodies on GET | |||
(and other) requests" | (and other) requests" | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/55>: "Updating to | o <http://tools.ietf.org/wg/httpbis/trac/ticket/55>: "Updating to | |||
RFC4288" | RFC4288" | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/57>: "Status Code | o <http://tools.ietf.org/wg/httpbis/trac/ticket/57>: "Status Code | |||
skipping to change at page 71, line 31 | skipping to change at page 76, line 11 | |||
o Move "Product Tokens" section (back) into Part 1, as "token" is | o Move "Product Tokens" section (back) into Part 1, as "token" is | |||
used in the definition of the Upgrade header. | used in the definition of the Upgrade header. | |||
o Add explicit references to BNF syntax and rules imported from | o Add explicit references to BNF syntax and rules imported from | |||
other parts of the specification. | other parts of the specification. | |||
o Rewrite prose rule "token" in terms of "tchar", rewrite prose rule | o Rewrite prose rule "token" in terms of "tchar", rewrite prose rule | |||
"TEXT". | "TEXT". | |||
E.4. Since draft-ietf-httpbis-p1-messaging-02 | D.4. Since draft-ietf-httpbis-p1-messaging-02 | |||
Closed issues: | Closed issues: | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/51>: "HTTP-date vs. | o <http://tools.ietf.org/wg/httpbis/trac/ticket/51>: "HTTP-date vs. | |||
rfc1123-date" | rfc1123-date" | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/64>: "WS in quoted- | o <http://tools.ietf.org/wg/httpbis/trac/ticket/64>: "WS in quoted- | |||
pair" | pair" | |||
Ongoing work on IANA Message Header Registration | Ongoing work on IANA Message Header Registration | |||
skipping to change at page 72, line 5 | skipping to change at page 76, line 33 | |||
o Reference RFC 3984, and update header registrations for headers | o Reference RFC 3984, and update header registrations for headers | |||
defined in this document. | defined in this document. | |||
Ongoing work on ABNF conversion | Ongoing work on ABNF conversion | |||
(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): | (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): | |||
o Replace string literals when the string really is case-sensitive | o Replace string literals when the string really is case-sensitive | |||
(HTTP-Version). | (HTTP-Version). | |||
E.5. Since draft-ietf-httpbis-p1-messaging-03 | D.5. Since draft-ietf-httpbis-p1-messaging-03 | |||
Closed issues: | Closed issues: | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/28>: "Connection | o <http://tools.ietf.org/wg/httpbis/trac/ticket/28>: "Connection | |||
closing" | closing" | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/97>: "Move | o <http://tools.ietf.org/wg/httpbis/trac/ticket/97>: "Move | |||
registrations and registry information to IANA Considerations" | registrations and registry information to IANA Considerations" | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/120>: "need new URL | o <http://tools.ietf.org/wg/httpbis/trac/ticket/120>: "need new URL | |||
skipping to change at page 72, line 36 | skipping to change at page 77, line 17 | |||
Ongoing work on ABNF conversion | Ongoing work on ABNF conversion | |||
(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): | (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): | |||
o Replace string literals when the string really is case-sensitive | o Replace string literals when the string really is case-sensitive | |||
(HTTP-Date). | (HTTP-Date). | |||
o Replace HEX by HEXDIG for future consistence with RFC 5234's core | o Replace HEX by HEXDIG for future consistence with RFC 5234's core | |||
rules. | rules. | |||
E.6. Since draft-ietf-httpbis-p1-messaging-04 | D.6. Since draft-ietf-httpbis-p1-messaging-04 | |||
Closed issues: | Closed issues: | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/34>: "Out-of-date | o <http://tools.ietf.org/wg/httpbis/trac/ticket/34>: "Out-of-date | |||
reference for URIs" | reference for URIs" | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/132>: "RFC 2822 is | o <http://tools.ietf.org/wg/httpbis/trac/ticket/132>: "RFC 2822 is | |||
updated by RFC 5322" | updated by RFC 5322" | |||
Ongoing work on ABNF conversion | Ongoing work on ABNF conversion | |||
skipping to change at page 73, line 13 | skipping to change at page 77, line 42 | |||
o Get rid of RFC822 dependency; use RFC5234 plus extensions instead. | o Get rid of RFC822 dependency; use RFC5234 plus extensions instead. | |||
o Only reference RFC 5234's core rules. | o Only reference RFC 5234's core rules. | |||
o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional | o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional | |||
whitespace ("OWS") and required whitespace ("RWS"). | whitespace ("OWS") and required whitespace ("RWS"). | |||
o Rewrite ABNFs to spell out whitespace rules, factor out header | o Rewrite ABNFs to spell out whitespace rules, factor out header | |||
value format definitions. | value format definitions. | |||
E.7. Since draft-ietf-httpbis-p1-messaging-05 | D.7. Since draft-ietf-httpbis-p1-messaging-05 | |||
Closed issues: | Closed issues: | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/30>: "Header LWS" | o <http://tools.ietf.org/wg/httpbis/trac/ticket/30>: "Header LWS" | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/52>: "Sort 1.3 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/52>: "Sort 1.3 | |||
Terminology" | Terminology" | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/63>: "RFC2047 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/63>: "RFC2047 | |||
encoded words" | encoded words" | |||
skipping to change at page 74, line 11 | skipping to change at page 78, line 39 | |||
o Add appendix containing collected and expanded ABNF. | o Add appendix containing collected and expanded ABNF. | |||
Other changes: | Other changes: | |||
o Rewrite introduction; add mostly new Architecture Section. | o Rewrite introduction; add mostly new Architecture Section. | |||
o Move definition of quality values from Part 3 into Part 1; make TE | o Move definition of quality values from Part 3 into Part 1; make TE | |||
request header grammar independent of accept-params (defined in | request header grammar independent of accept-params (defined in | |||
Part 3). | Part 3). | |||
E.8. Since draft-ietf-httpbis-p1-messaging-06 | D.8. Since draft-ietf-httpbis-p1-messaging-06 | |||
Closed issues: | Closed issues: | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/161>: "base for | o <http://tools.ietf.org/wg/httpbis/trac/ticket/161>: "base for | |||
numeric protocol elements" | numeric protocol elements" | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/162>: "comment ABNF" | o <http://tools.ietf.org/wg/httpbis/trac/ticket/162>: "comment ABNF" | |||
Partly resolved issues: | Partly resolved issues: | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/88>: "205 Bodies" | o <http://tools.ietf.org/wg/httpbis/trac/ticket/88>: "205 Bodies" | |||
(took out language that implied that there may be methods for | (took out language that implied that there may be methods for | |||
which a request body MUST NOT be included) | which a request body MUST NOT be included) | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/163>: "editorial | o <http://tools.ietf.org/wg/httpbis/trac/ticket/163>: "editorial | |||
improvements around HTTP-date" | improvements around HTTP-date" | |||
D.9. Since draft-ietf-httpbis-p1-messaging-07 | ||||
Closed issues: | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/93>: "Repeating | ||||
single-value headers" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/131>: "increase | ||||
connection limit" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/157>: "IP addresses | ||||
in URLs" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/172>: "take over | ||||
HTTP Upgrade Token Registry" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/173>: "CR and LF in | ||||
chunk extension values" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/184>: "HTTP/0.9 | ||||
support" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/188>: "pick IANA | ||||
policy (RFC5226) for Transfer Coding / Content Coding" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/189>: "move | ||||
definitions of gzip/deflate/compress to part 1" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/194>: "disallow | ||||
control characters in quoted-pair" | ||||
Partly resolved issues: | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/148>: "update IANA | ||||
requirements wrt Transfer-Coding values" (add the IANA | ||||
Considerations subsection) | ||||
Index | Index | |||
A | A | |||
application/http Media Type 49 | application/http Media Type 55 | |||
C | C | |||
cache 61 | cache 12 | |||
cacheable 62 | cacheable 13 | |||
client 62 | chunked (Coding Format) 32 | |||
connection 62 | client 10 | |||
Connection header 39 | Coding Format | |||
content negotiation 62 | chunked 32 | |||
Content-Length header 40 | compress 34 | |||
deflate 35 | ||||
gzip 35 | ||||
compress (Coding Format) 34 | ||||
connection 10 | ||||
Connection header 44 | ||||
Content-Length header 45 | ||||
D | D | |||
Date header 40 | Date header 46 | |||
downstream 64 | deflate (Coding Format) 35 | |||
downstream 12 | ||||
E | ||||
entity 62 | ||||
G | G | |||
gateway 62 | gateway 12 | |||
Grammar | Grammar | |||
absolute-URI 10 | absolute-URI 15 | |||
ALPHA 7 | ALPHA 7 | |||
asctime-date 18 | asctime-date 31 | |||
attribute 18 | attribute 31 | |||
authority 10 | authority 15 | |||
BWS 9 | BWS 9 | |||
chunk 20 | chunk 33 | |||
chunk-data 20 | chunk-data 33 | |||
chunk-ext 20 | chunk-ext 33 | |||
chunk-ext-name 20 | chunk-ext-name 33 | |||
chunk-ext-val 20 | chunk-ext-val 33 | |||
chunk-size 20 | chunk-size 33 | |||
Chunked-Body 20 | Chunked-Body 33 | |||
comment 24 | comment 21 | |||
Connection 39 | Connection 44 | |||
connection-token 39 | connection-token 44 | |||
Connection-v 39 | Connection-v 44 | |||
Content-Length 40 | Content-Length 45 | |||
Content-Length-v 40 | Content-Length-v 45 | |||
CR 7 | CR 7 | |||
CRLF 7 | CRLF 7 | |||
ctext 24 | ctext 21 | |||
CTL 7 | CTL 7 | |||
Date 40 | Date 46 | |||
Date-v 40 | Date-v 46 | |||
date1 17 | date1 30 | |||
date2 18 | date2 31 | |||
date3 18 | date3 31 | |||
day 17 | day 30 | |||
day-name 17 | day-name 30 | |||
day-name-l 17 | day-name-l 30 | |||
DIGIT 7 | DIGIT 7 | |||
DQUOTE 7 | DQUOTE 7 | |||
extension-code 31 | extension-code 28 | |||
extension-method 28 | extension-method 24 | |||
field-content 23 | field-content 19 | |||
field-name 23 | field-name 19 | |||
field-value 23 | field-value 19 | |||
general-header 27 | general-header 23 | |||
generic-message 22 | GMT 30 | |||
GMT 17 | header-field 19 | |||
HEXDIG 7 | HEXDIG 7 | |||
Host 42 | Host 47 | |||
Host-v 42 | Host-v 47 | |||
hour 17 | hour 30 | |||
HTTP-date 16 | HTTP-date 29 | |||
HTTP-message 22 | HTTP-message 18 | |||
HTTP-Prot-Name 14 | HTTP-Prot-Name 14 | |||
http-URI 11 | http-URI 16 | |||
HTTP-Version 14 | HTTP-Version 14 | |||
last-chunk 20 | https-URI 17 | |||
last-chunk 33 | ||||
LF 7 | LF 7 | |||
message-body 25 | message-body 21 | |||
message-header 23 | Method 24 | |||
Method 28 | minute 30 | |||
minute 17 | month 30 | |||
month 17 | obs-date 30 | |||
obs-date 17 | ||||
obs-text 9 | obs-text 9 | |||
OCTET 7 | OCTET 7 | |||
OWS 9 | OWS 9 | |||
path-absolute 10 | path-absolute 15 | |||
port 10 | port 15 | |||
product 21 | product 35 | |||
product-version 21 | product-version 35 | |||
protocol-name 46 | protocol-name 52 | |||
protocol-version 46 | protocol-version 52 | |||
pseudonym 46 | pseudonym 52 | |||
qdtext 9 | qdtext 9 | |||
query 10 | qdtext-nf 33 | |||
query 15 | ||||
quoted-cpair 21 | ||||
quoted-pair 9 | quoted-pair 9 | |||
quoted-str-nf 33 | ||||
quoted-string 9 | quoted-string 9 | |||
quoted-text 9 | qvalue 36 | |||
qvalue 22 | Reason-Phrase 28 | |||
Reason-Phrase 31 | received-by 52 | |||
received-by 46 | received-protocol 52 | |||
received-protocol 46 | Request 24 | |||
Request 27 | Request-Line 24 | |||
Request-Line 28 | request-target 24 | |||
request-target 28 | Response 27 | |||
Response 31 | rfc850-date 31 | |||
rfc850-date 18 | rfc1123-date 30 | |||
rfc1123-date 17 | ||||
RWS 9 | RWS 9 | |||
second 17 | second 30 | |||
SP 7 | SP 7 | |||
start-line 22 | Status-Code 28 | |||
Status-Code 31 | Status-Line 27 | |||
Status-Line 31 | t-codings 48 | |||
t-codings 42 | ||||
tchar 9 | tchar 9 | |||
TE 42 | TE 48 | |||
te-ext 42 | te-ext 48 | |||
te-params 42 | te-params 48 | |||
TE-v 42 | TE-v 48 | |||
time-of-day 17 | time-of-day 30 | |||
token 9 | token 9 | |||
Trailer 44 | Trailer 49 | |||
trailer-part 20 | trailer-part 33 | |||
Trailer-v 44 | Trailer-v 49 | |||
transfer-coding 18 | transfer-coding 31 | |||
Transfer-Encoding 44 | Transfer-Encoding 50 | |||
Transfer-Encoding-v 44 | Transfer-Encoding-v 50 | |||
transfer-extension 18 | transfer-extension 31 | |||
transfer-parameter 18 | transfer-parameter 31 | |||
Upgrade 45 | Upgrade 50 | |||
Upgrade-v 45 | Upgrade-v 50 | |||
uri-host 10 | uri-host 15 | |||
URI-reference 10 | URI-reference 15 | |||
value 18 | value 31 | |||
VCHAR 7 | VCHAR 7 | |||
Via 46 | Via 52 | |||
Via-v 46 | Via-v 52 | |||
WSP 7 | WSP 7 | |||
year 17 | year 30 | |||
gzip (Coding Format) 35 | ||||
H | H | |||
header field 18 | ||||
header section 18 | ||||
Headers | Headers | |||
Connection 39 | Connection 44 | |||
Content-Length 40 | Content-Length 45 | |||
Date 40 | Date 46 | |||
Host 42 | Host 47 | |||
TE 42 | TE 48 | |||
Trailer 44 | Trailer 49 | |||
Transfer-Encoding 44 | Transfer-Encoding 49 | |||
Upgrade 45 | Upgrade 50 | |||
Via 46 | Via 52 | |||
Host header 42 | headers 18 | |||
http URI scheme 11 | Host header 47 | |||
https URI scheme 11 | http URI scheme 16 | |||
https URI scheme 17 | ||||
I | I | |||
inbound 62 | inbound 12 | |||
M | M | |||
Media Type | Media Type | |||
application/http 49 | application/http 55 | |||
message/http 48 | message/http 54 | |||
message 63 | message 10 | |||
message/http Media Type 48 | message/http Media Type 54 | |||
O | O | |||
origin server 63 | origin server 10 | |||
outbound 62 | outbound 12 | |||
P | P | |||
proxy 63 | proxy 12 | |||
R | R | |||
representation 63 | request 10 | |||
request 63 | resource 15 | |||
resource 63 | response 10 | |||
response 63 | reverse proxy 12 | |||
S | S | |||
server 64 | server 10 | |||
T | T | |||
TE header 42 | TE header 48 | |||
Trailer header 44 | Trailer header 49 | |||
Transfer-Encoding header 44 | Transfer-Encoding header 49 | |||
tunnel 64 | tunnel 12 | |||
U | U | |||
Upgrade header 45 | Upgrade header 50 | |||
upstream 64 | upstream 12 | |||
URI scheme | URI scheme | |||
http 11 | http 16 | |||
https 11 | https 17 | |||
user agent 64 | user agent 10 | |||
V | V | |||
variant 64 | Via header 52 | |||
Via header 46 | ||||
Authors' Addresses | Authors' Addresses | |||
Roy T. Fielding (editor) | Roy T. Fielding (editor) | |||
Day Software | Day Software | |||
23 Corporate Plaza DR, Suite 280 | 23 Corporate Plaza DR, Suite 280 | |||
Newport Beach, CA 92660 | Newport Beach, CA 92660 | |||
USA | USA | |||
Phone: +1-949-706-5300 | Phone: +1-949-706-5300 | |||
End of changes. 260 change blocks. | ||||
1096 lines changed or deleted | 1366 lines changed or added | |||
This html diff was produced by rfcdiff 1.37a. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |