draft-ietf-httpbis-p1-messaging-14.txt   draft-ietf-httpbis-p1-messaging-15.txt 
HTTPbis Working Group R. Fielding, Ed. HTTPbis Working Group R. Fielding, Ed.
Internet-Draft Adobe Internet-Draft Adobe
Obsoletes: 2145,2616 (if approved) J. Gettys Obsoletes: 2145,2616 (if approved) J. Gettys
Updates: 2817 (if approved) Alcatel-Lucent Updates: 2817 (if approved) Alcatel-Lucent
Intended status: Standards Track J. Mogul Intended status: Standards Track J. Mogul
Expires: October 20, 2011 HP Expires: January 12, 2012 HP
H. Frystyk H. Frystyk
Microsoft Microsoft
L. Masinter L. Masinter
Adobe Adobe
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
April 18, 2011 July 11, 2011
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-14 draft-ietf-httpbis-p1-messaging-15
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is an application-level The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypertext information protocol for distributed, collaborative, hypertext information
systems. HTTP has been in use by the World Wide Web global systems. HTTP has been in use by the World Wide Web global
information initiative since 1990. This document is Part 1 of the information initiative since 1990. This document is Part 1 of the
seven-part specification that defines the protocol referred to as seven-part specification that defines the protocol referred to as
"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides
an overview of HTTP and its associated terminology, defines the an overview of HTTP and its associated terminology, defines the
skipping to change at page 2, line 5 skipping to change at page 2, line 5
Discussion of this draft should take place on the HTTPBIS working Discussion of this draft should take place on the HTTPBIS working
group mailing list (ietf-http-wg@w3.org), which is archived at group mailing list (ietf-http-wg@w3.org), which is archived at
<http://lists.w3.org/Archives/Public/ietf-http-wg/>. <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
The current issues list is at The current issues list is at
<http://tools.ietf.org/wg/httpbis/trac/report/3> and related <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
documents (including fancy diffs) can be found at documents (including fancy diffs) can be found at
<http://tools.ietf.org/wg/httpbis/>. <http://tools.ietf.org/wg/httpbis/>.
The changes in this draft are summarized in Appendix D.15. The changes in this draft are summarized in Appendix D.16.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 20, 2011. This Internet-Draft will expire on January 12, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 11 skipping to change at page 3, line 11
than English. than English.
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
2. HTTP-related architecture . . . . . . . . . . . . . . . . . . 10 2. HTTP-related architecture . . . . . . . . . . . . . . . . . . 10
2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 10 2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 10
2.2. Connections and Transport Independence . . . . . . . . . . 12 2.2. Message Orientation and Buffering . . . . . . . . . . . . 12
2.3. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 12 2.3. Connections and Transport Independence . . . . . . . . . . 12
2.4. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.4. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 13
2.5. Protocol Versioning . . . . . . . . . . . . . . . . . . . 15 2.5. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.6. Uniform Resource Identifiers . . . . . . . . . . . . . . . 17 2.6. Protocol Versioning . . . . . . . . . . . . . . . . . . . 15
2.6.1. http URI scheme . . . . . . . . . . . . . . . . . . . 18 2.7. Uniform Resource Identifiers . . . . . . . . . . . . . . . 18
2.6.2. https URI scheme . . . . . . . . . . . . . . . . . . . 19 2.7.1. http URI scheme . . . . . . . . . . . . . . . . . . . 18
2.6.3. http and https URI Normalization and Comparison . . . 20 2.7.2. https URI scheme . . . . . . . . . . . . . . . . . . . 20
3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 20 2.7.3. http and https URI Normalization and Comparison . . . 20
3.1. Message Parsing Robustness . . . . . . . . . . . . . . . . 21 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1. Message Parsing Robustness . . . . . . . . . . . . . . . . 22
3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 22 3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 22
3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 24 3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 25
3.4. General Header Fields . . . . . . . . . . . . . . . . . . 27 3.4. General Header Fields . . . . . . . . . . . . . . . . . . 28
4. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 4. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 28 4.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 29
4.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 28 4.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 29
4.1.2. request-target . . . . . . . . . . . . . . . . . . . . 28 4.1.2. request-target . . . . . . . . . . . . . . . . . . . . 29
4.2. The Resource Identified by a Request . . . . . . . . . . . 30 4.2. The Resource Identified by a Request . . . . . . . . . . . 31
4.3. Effective Request URI . . . . . . . . . . . . . . . . . . 31 4.3. Effective Request URI . . . . . . . . . . . . . . . . . . 32
5. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 5. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 33 5.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 33
5.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 33 5.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 34
6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 33 6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 34
6.1. Date/Time Formats: Full Date . . . . . . . . . . . . . . . 33 6.1. Date/Time Formats: Full Date . . . . . . . . . . . . . . . 34
6.2. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 36 6.2. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 37
6.2.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 37 6.2.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 38
6.2.2. Compression Codings . . . . . . . . . . . . . . . . . 39 6.2.2. Compression Codings . . . . . . . . . . . . . . . . . 40
6.2.3. Transfer Coding Registry . . . . . . . . . . . . . . . 40 6.2.3. Transfer Coding Registry . . . . . . . . . . . . . . . 41
6.3. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 41 6.3. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 42
6.4. Quality Values . . . . . . . . . . . . . . . . . . . . . . 41 6.4. Quality Values . . . . . . . . . . . . . . . . . . . . . . 42
7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 41 7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 42
7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 42 7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 43
7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 42 7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 43
7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 42 7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 43
7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 44 7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 45
7.1.4. Practical Considerations . . . . . . . . . . . . . . . 46 7.1.4. Practical Considerations . . . . . . . . . . . . . . . 47
7.2. Message Transmission Requirements . . . . . . . . . . . . 47 7.2. Message Transmission Requirements . . . . . . . . . . . . 48
7.2.1. Persistent Connections and Flow Control . . . . . . . 47 7.2.1. Persistent Connections and Flow Control . . . . . . . 48
7.2.2. Monitoring Connections for Error Status Messages . . . 48 7.2.2. Monitoring Connections for Error Status Messages . . . 49
7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 48 7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 49
7.2.4. Client Behavior if Server Prematurely Closes 7.2.4. Client Behavior if Server Prematurely Closes
Connection . . . . . . . . . . . . . . . . . . . . . . 50 Connection . . . . . . . . . . . . . . . . . . . . . . 51
8. Miscellaneous notes that might disappear . . . . . . . . . . . 51 8. Miscellaneous notes that might disappear . . . . . . . . . . . 52
8.1. Scheme aliases considered harmful . . . . . . . . . . . . 51 8.1. Scheme aliases considered harmful . . . . . . . . . . . . 52
8.2. Use of HTTP for proxy communication . . . . . . . . . . . 51 8.2. Use of HTTP for proxy communication . . . . . . . . . . . 52
8.3. Interception of HTTP for access control . . . . . . . . . 51 8.3. Interception of HTTP for access control . . . . . . . . . 52
8.4. Use of HTTP by other protocols . . . . . . . . . . . . . . 51 8.4. Use of HTTP by other protocols . . . . . . . . . . . . . . 52
8.5. Use of HTTP by media type specification . . . . . . . . . 51 8.5. Use of HTTP by media type specification . . . . . . . . . 52
9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 51 9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 52
9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 51 9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 52
9.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 53 9.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 54
9.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 9.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
9.3.1. Clockless Origin Server Operation . . . . . . . . . . 54 9.3.1. Clockless Origin Server Operation . . . . . . . . . . 55
9.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 9.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
9.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 9.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
9.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 57 9.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 58
9.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 57 9.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 58
9.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 58 9.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 59
9.8.1. Upgrade Token Registry . . . . . . . . . . . . . . . . 59 9.8.1. Upgrade Token Registry . . . . . . . . . . . . . . . . 60
9.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 9.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62
10.1. Header Field Registration . . . . . . . . . . . . . . . . 61 10.1. Header Field Registration . . . . . . . . . . . . . . . . 62
10.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 62 10.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 63
10.3. Internet Media Type Registrations . . . . . . . . . . . . 62 10.3. Internet Media Type Registrations . . . . . . . . . . . . 63
10.3.1. Internet Media Type message/http . . . . . . . . . . . 62 10.3.1. Internet Media Type message/http . . . . . . . . . . . 63
10.3.2. Internet Media Type application/http . . . . . . . . . 63 10.3.2. Internet Media Type application/http . . . . . . . . . 64
10.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 64 10.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 65
10.5. Upgrade Token Registration . . . . . . . . . . . . . . . . 65 10.5. Upgrade Token Registration . . . . . . . . . . . . . . . . 66
11. Security Considerations . . . . . . . . . . . . . . . . . . . 65 11. Security Considerations . . . . . . . . . . . . . . . . . . . 66
11.1. Personal Information . . . . . . . . . . . . . . . . . . . 65 11.1. Personal Information . . . . . . . . . . . . . . . . . . . 66
11.2. Abuse of Server Log Information . . . . . . . . . . . . . 66 11.2. Abuse of Server Log Information . . . . . . . . . . . . . 67
11.3. Attacks Based On File and Path Names . . . . . . . . . . . 66 11.3. Attacks Based On File and Path Names . . . . . . . . . . . 67
11.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 66 11.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 67
11.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 67 11.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 68
11.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 68 11.6. Protocol Element Size Overflows . . . . . . . . . . . . . 69
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 68 11.7. Denial of Service Attacks on Proxies . . . . . . . . . . . 69
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 69 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 69
13.1. Normative References . . . . . . . . . . . . . . . . . . . 69 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 70
13.2. Informative References . . . . . . . . . . . . . . . . . . 71 13.1. Normative References . . . . . . . . . . . . . . . . . . . 70
Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 73 13.2. Informative References . . . . . . . . . . . . . . . . . . 72
Appendix B. HTTP Version History . . . . . . . . . . . . . . . . 74 Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 74
B.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 75 Appendix B. HTTP Version History . . . . . . . . . . . . . . . . 75
B.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 75 B.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 76
B.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 76
B.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 76 B.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 76
B.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 76 B.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 77
Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 77 Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 78
Appendix D. Change Log (to be removed by RFC Editor before Appendix D. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 81 publication) . . . . . . . . . . . . . . . . . . . . 82
D.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 81 D.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 82
D.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 81 D.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 82
D.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 83 D.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 84
D.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 84 D.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 85
D.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 84 D.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 85
D.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 85 D.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 86
D.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 85 D.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 86
D.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 86 D.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 87
D.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 87 D.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 88
D.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 87 D.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 88
D.11. Since draft-ietf-httpbis-p1-messaging-09 . . . . . . . . . 88 D.11. Since draft-ietf-httpbis-p1-messaging-09 . . . . . . . . . 89
D.12. Since draft-ietf-httpbis-p1-messaging-10 . . . . . . . . . 88 D.12. Since draft-ietf-httpbis-p1-messaging-10 . . . . . . . . . 89
D.13. Since draft-ietf-httpbis-p1-messaging-11 . . . . . . . . . 89 D.13. Since draft-ietf-httpbis-p1-messaging-11 . . . . . . . . . 90
D.14. Since draft-ietf-httpbis-p1-messaging-12 . . . . . . . . . 89 D.14. Since draft-ietf-httpbis-p1-messaging-12 . . . . . . . . . 90
D.15. Since draft-ietf-httpbis-p1-messaging-13 . . . . . . . . . 90 D.15. Since draft-ietf-httpbis-p1-messaging-13 . . . . . . . . . 91
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 D.16. Since draft-ietf-httpbis-p1-messaging-14 . . . . . . . . . 91
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
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 the target resource Identifier (URI) standard [RFC3986] to indicate the target resource
and relationships between resources. Messages are passed in a format and 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 12, line 5 skipping to change at page 12, line 5
Server: Apache Server: Apache
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00" ETag: "34aa387-d-1568eb00"
Accept-Ranges: bytes Accept-Ranges: bytes
Content-Length: 14 Content-Length: 14
Vary: Accept-Encoding Vary: Accept-Encoding
Content-Type: text/plain Content-Type: text/plain
Hello World! Hello World!
2.2. Connections and Transport Independence 2.2. Message Orientation and Buffering
Fundamentally, HTTP is a message-based protocol. Although message
bodies can be chunked (Section 6.2.1) and implementations often make
parts of a message available progressively, this is not required, and
some widely-used implementations only make a message available when
it is complete. Furthermore, while most proxies will progressively
stream messages, some amount of buffering will take place, and some
proxies might buffer messages to perform transformations, check
content or provide other services.
Therefore, extensions to and uses of HTTP cannot rely on the
availability of a partial message, or assume that messages will not
be buffered. There are strategies that can be used to test for
buffering in a given connection, but it should be understood that
behaviors can differ across connections, and between requests and
responses.
Recipients MUST consider every message in a connection in isolation;
because HTTP is a stateless protocol, it cannot be assumed that two
requests on the same connection are from the same client or share any
other common attributes. In particular, intermediaries might mix
requests from different clients into a single server connection.
Note that some existing HTTP extensions (e.g., [RFC4559]) violate
this requirement, thereby potentially causing interoperability and
security problems.
2.3. Connections and Transport Independence
HTTP messaging is independent of the underlying transport or session- HTTP messaging is independent of the underlying transport or session-
layer connection protocol(s). HTTP only presumes a reliable layer connection protocol(s). HTTP only presumes a reliable
transport with in-order delivery of requests and the corresponding transport with in-order delivery of requests and the corresponding
in-order delivery of responses. The mapping of HTTP request and in-order delivery of responses. The mapping of HTTP request and
response structures onto the data units of the underlying transport response structures onto the data units of the underlying transport
protocol is outside the scope of this specification. protocol is outside the scope of this specification.
The specific connection protocols to be used for an interaction are The specific connection protocols to be used for an interaction are
determined by client configuration and the target resource's URI. determined by client configuration and the target resource's URI.
For example, the "http" URI scheme (Section 2.6.1) indicates a For example, the "http" URI scheme (Section 2.7.1) indicates a
default connection of TCP over IP, with a default TCP port of 80, but default connection of TCP over IP, with a default TCP port of 80, but
the client might be configured to use a proxy via some other the client might be configured to use a proxy via some other
connection port or protocol instead of using the defaults. connection port or protocol instead of using the defaults.
A connection might be used for multiple HTTP request/response A connection might be used for multiple HTTP request/response
exchanges, as defined in Section 7.1. exchanges, as defined in Section 7.1.
2.3. Intermediaries 2.4. Intermediaries
HTTP enables the use of intermediaries to satisfy requests through a HTTP enables the use of intermediaries to satisfy requests through a
chain of connections. There are three common forms of HTTP chain of connections. There are three common forms of HTTP
intermediary: proxy, gateway, and tunnel. In some cases, a single intermediary: proxy, gateway, and tunnel. In some cases, a single
intermediary might act as an origin server, proxy, gateway, or intermediary might act as an origin server, proxy, gateway, or
tunnel, switching behavior based on the nature of each request. tunnel, switching behavior based on the nature of each request.
> > > > > > > >
UA =========== A =========== B =========== C =========== O UA =========== A =========== B =========== C =========== O
< < < < < < < <
skipping to change at page 13, line 30 skipping to change at page 14, line 11
that would be significant to the original sender or potentially that would be significant to the original sender or potentially
significant to downstream recipients). For example, a transforming significant to downstream recipients). For example, a transforming
proxy might be acting as a shared annotation server (modifying proxy might be acting as a shared annotation server (modifying
responses to include references to a local annotation database), a responses to include references to a local annotation database), a
malware filter, a format transcoder, or an intranet-to-Internet malware filter, a format transcoder, or an intranet-to-Internet
privacy filter. Such transformations are presumed to be desired by privacy filter. Such transformations are presumed to be desired by
the client (or client organization) that selected the proxy and are the client (or client organization) that selected the proxy and are
beyond the scope of this specification. However, when a proxy is not beyond the scope of this specification. However, when a proxy is not
intended to transform a given message, we use the term "non- intended to transform a given message, we use the term "non-
transforming proxy" to target requirements that preserve HTTP message transforming proxy" to target requirements that preserve HTTP message
semantics. semantics. See Section 8.2.4 of [Part2] and Section 3.6 of [Part6]
for status and warning codes related to transformations.
A "gateway" (a.k.a., "reverse proxy") is a receiving agent that acts 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 as a layer above some other server(s) and translates the received
requests to the underlying server's protocol. Gateways are often requests to the underlying server's protocol. Gateways are often
used to encapsulate legacy or untrusted information services, to used to encapsulate legacy or untrusted information services, to
improve server performance through "accelerator" caching, and to improve server performance through "accelerator" caching, and to
enable partitioning or load-balancing of HTTP services across enable partitioning or load-balancing of HTTP services across
multiple machines. multiple machines.
A gateway behaves as an origin server on its outbound connection and A gateway behaves as an origin server on its outbound connection and
skipping to change at page 14, line 29 skipping to change at page 15, line 10
proxy" [RFC3040], "transparent proxy" [RFC1919], or "captive portal", proxy" [RFC3040], "transparent proxy" [RFC1919], or "captive portal",
differs from an HTTP proxy because it has not been selected by the differs from an HTTP proxy because it has not been selected by the
client. Instead, the network intermediary redirects outgoing TCP client. Instead, the network intermediary redirects outgoing TCP
port 80 packets (and occasionally other common port traffic) to an port 80 packets (and occasionally other common port traffic) to an
internal HTTP server. Interception proxies are commonly found on internal HTTP server. Interception proxies are commonly found on
public network access points, as a means of enforcing account public network access points, as a means of enforcing account
subscription prior to allowing use of non-local Internet services, subscription prior to allowing use of non-local Internet services,
and within corporate firewalls to enforce network usage policies. and within corporate firewalls to enforce network usage policies.
They are indistinguishable from a man-in-the-middle attack. They are indistinguishable from a man-in-the-middle attack.
2.4. Caches 2.5. Caches
A "cache" is a local store of previous response messages and the A "cache" is a local store of previous response messages and the
subsystem that controls its message storage, retrieval, and deletion. subsystem that controls its message storage, retrieval, and deletion.
A cache stores cacheable responses in order to reduce the response A cache stores cacheable responses in order to reduce the response
time and network bandwidth consumption on future, equivalent time and network bandwidth consumption on future, equivalent
requests. Any client or server MAY employ a cache, though a cache requests. Any client or server MAY employ a cache, though a cache
cannot be used by a server while it is acting as a tunnel. 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 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 if one of the participants along the chain has a cached response
skipping to change at page 15, line 14 skipping to change at page 15, line 44
cache behavior and cacheable responses are defined in Section 2 of cache behavior and cacheable responses are defined in Section 2 of
[Part6]. [Part6].
There are a wide variety of architectures and configurations of There are a wide variety of architectures and configurations of
caches and proxies deployed across the World Wide Web and inside caches and proxies deployed across the World Wide Web and inside
large organizations. These systems include national hierarchies of large organizations. These systems include national hierarchies of
proxy caches to save transoceanic bandwidth, systems that broadcast proxy caches to save transoceanic bandwidth, systems that broadcast
or multicast cache entries, organizations that distribute subsets of or multicast cache entries, organizations that distribute subsets of
cached data via optical media, and so on. cached data via optical media, and so on.
2.5. Protocol Versioning 2.6. Protocol Versioning
HTTP uses a "<major>.<minor>" numbering scheme to indicate versions HTTP uses a "<major>.<minor>" numbering scheme to indicate versions
of the protocol. This specification defines version "1.1". The of the protocol. This specification defines version "1.1". The
protocol version as a whole indicates the sender's compliance with protocol version as a whole indicates the sender's compliance with
the set of requirements laid out in that version's corresponding the set of requirements laid out in that version's corresponding
specification of HTTP. specification of HTTP.
The version of an HTTP message is indicated by an HTTP-Version field The version of an HTTP message is indicated by an HTTP-Version field
in the first line of the message. HTTP-Version is case-sensitive. in the first line of the message. HTTP-Version is case-sensitive.
HTTP-Version = HTTP-Prot-Name "/" 1*DIGIT "." 1*DIGIT HTTP-Version = HTTP-Prot-Name "/" DIGIT "." DIGIT
HTTP-Prot-Name = %x48.54.54.50 ; "HTTP", case-sensitive HTTP-Prot-Name = %x48.54.54.50 ; "HTTP", case-sensitive
The HTTP version number consists of two non-negative decimal integers The HTTP version number consists of two decimal digits separated by a
separated by a "." (period or decimal point). The first number "." (period or decimal point). The first digit ("major version")
("major version") indicates the HTTP messaging syntax, whereas the indicates the HTTP messaging syntax, whereas the second digit ("minor
second number ("minor version") indicates the highest minor version version") indicates the highest minor version to which the sender is
to which the sender is at least conditionally compliant and able to at least conditionally compliant and able to understand for future
understand for future communication. The minor version advertises communication. The minor version advertises the sender's
the sender's communication capabilities even when the sender is only communication capabilities even when the sender is only using a
using a backwards-compatible subset of the protocol, thereby letting backwards-compatible subset of the protocol, thereby letting the
the recipient know that more advanced features can be used in recipient know that more advanced features can be used in response
response (by servers) or in future requests (by clients). (by servers) or in future requests (by clients).
When comparing HTTP versions, the numbers MUST be compared
numerically rather than lexically. For example, HTTP/2.4 is a lower
version than HTTP/2.13, which in turn is lower than HTTP/12.3.
Leading zeros MUST be ignored by recipients and MUST NOT be sent.
When an HTTP/1.1 message is sent to an HTTP/1.0 recipient [RFC1945] When an HTTP/1.1 message is sent to an HTTP/1.0 recipient [RFC1945]
or a recipient whose version is unknown, the HTTP/1.1 message is or a recipient whose version is unknown, the HTTP/1.1 message is
constructed such that it can be interpreted as a valid HTTP/1.0 constructed such that it can be interpreted as a valid HTTP/1.0
message if all of the newer features are ignored. This specification message if all of the newer features are ignored. This specification
places recipient-version requirements on some new features so that a places recipient-version requirements on some new features so that a
compliant sender will only use compatible features until it has compliant sender will only use compatible features until it has
determined, through configuration or the receipt of a message, that determined, through configuration or the receipt of a message, that
the recipient supports HTTP/1.1. the recipient supports HTTP/1.1.
skipping to change at page 17, line 26 skipping to change at page 18, line 5
The intention of HTTP's versioning design is that the major number The intention of HTTP's versioning design is that the major number
will only be incremented if an incompatible message syntax is will only be incremented if an incompatible message syntax is
introduced, and that the minor number will only be incremented when introduced, and that the minor number will only be incremented when
changes made to the protocol have the effect of adding to the message changes made to the protocol have the effect of adding to the message
semantics or implying additional capabilities of the sender. semantics or implying additional capabilities of the sender.
However, the minor version was not incremented for the changes However, the minor version was not incremented for the changes
introduced between [RFC2068] and [RFC2616], and this revision is introduced between [RFC2068] and [RFC2616], and this revision is
specifically avoiding any such changes to the protocol. specifically avoiding any such changes to the protocol.
2.6. Uniform Resource Identifiers 2.7. Uniform Resource Identifiers
Uniform Resource Identifiers (URIs) [RFC3986] are used throughout Uniform Resource Identifiers (URIs) [RFC3986] are used throughout
HTTP as the means for identifying resources. URI references are used HTTP as the means for identifying resources. URI references are used
to target requests, indicate redirects, and define relationships. to target requests, indicate redirects, and define relationships.
HTTP does not limit what a resource might be; it merely defines an HTTP does not limit what a resource might be; it merely defines an
interface that can be used to interact with a resource via HTTP. 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 More information on the scope of URIs and resources can be found in
[RFC3986]. [RFC3986].
This specification adopts the definitions of "URI-reference", This specification adopts the definitions of "URI-reference",
skipping to change at page 18, line 15 skipping to change at page 18, line 42
Each protocol element in HTTP that allows a URI reference will Each protocol element in HTTP that allows a URI reference will
indicate in its ABNF production whether the element allows any form indicate in its ABNF production whether the element allows any form
of reference (URI-reference), only a URI in absolute form (absolute- of reference (URI-reference), only a URI in absolute form (absolute-
URI), only the path and optional query components, or some URI), only the path and optional query components, or some
combination of the above. Unless otherwise indicated, URI references combination of the above. Unless otherwise indicated, URI references
are parsed relative to the effective request URI, which defines the are parsed relative to the effective request URI, which defines the
default base URI for references in both the request and its default base URI for references in both the request and its
corresponding response. corresponding response.
2.6.1. http URI scheme 2.7.1. http URI scheme
The "http" URI scheme is hereby defined for the purpose of minting The "http" URI scheme is hereby defined for the purpose of minting
identifiers according to their association with the hierarchical identifiers according to their association with the hierarchical
namespace governed by a potential HTTP origin server listening for namespace governed by a potential HTTP origin server listening for
TCP connections on a given port. TCP connections on a given port.
http-URI = "http:" "//" authority path-abempty [ "?" query ] http-URI = "http:" "//" authority path-abempty [ "?" query ]
The HTTP origin server is identified by the generic syntax's The HTTP origin server is identified by the generic syntax's
authority component, which includes a host identifier and optional authority component, which includes a host identifier and optional
skipping to change at page 19, line 36 skipping to change at page 20, line 14
authentication information, such as within command invocation authentication information, such as within command invocation
options, configuration files, or bookmark lists, even though such options, configuration files, or bookmark lists, even though such
usage might expose a user identifier or password. Senders MUST NOT usage might expose a user identifier or password. Senders MUST NOT
include a userinfo subcomponent (and its "@" delimiter) when include a userinfo subcomponent (and its "@" delimiter) when
transmitting an "http" URI in a message. Recipients of HTTP messages transmitting an "http" URI in a message. Recipients of HTTP messages
that contain a URI reference SHOULD parse for the existence of that contain a URI reference SHOULD parse for the existence of
userinfo and treat its presence as an error, likely indicating that userinfo and treat its presence as an error, likely indicating that
the deprecated subcomponent is being used to obscure the authority the deprecated subcomponent is being used to obscure the authority
for the sake of phishing attacks. for the sake of phishing attacks.
2.6.2. https URI scheme 2.7.2. https URI scheme
The "https" URI scheme is hereby defined for the purpose of minting The "https" URI scheme is hereby defined for the purpose of minting
identifiers according to their association with the hierarchical identifiers according to their association with the hierarchical
namespace governed by a potential HTTP origin server listening for namespace governed by a potential HTTP origin server listening for
SSL/TLS-secured connections on a given TCP port. SSL/TLS-secured connections on a given TCP port.
All of the requirements listed above for the "http" scheme are also All of the requirements listed above for the "http" scheme are also
requirements for the "https" scheme, except that a default TCP port requirements for the "https" scheme, except that a default TCP port
of 443 is assumed if the port subcomponent is empty or not given, and of 443 is assumed if the port subcomponent is empty or not given, and
the TCP connection MUST be secured for privacy through the use of the TCP connection MUST be secured for privacy through the use of
skipping to change at page 20, line 15 skipping to change at page 20, line 41
They can, however, be reused in a private cache if the message is They can, however, be reused in a private cache if the message is
cacheable by default in HTTP or specifically indicated as such by the cacheable by default in HTTP or specifically indicated as such by the
Cache-Control header field (Section 3.2 of [Part6]). Cache-Control header field (Section 3.2 of [Part6]).
Resources made available via the "https" scheme have no shared Resources made available via the "https" scheme have no shared
identity with the "http" scheme even if their resource identifiers identity with the "http" scheme even if their resource identifiers
indicate the same authority (the same host listening to the same TCP indicate the same authority (the same host listening to the same TCP
port). They are distinct name spaces and are considered to be port). They are distinct name spaces and are considered to be
distinct origin servers. However, an extension to HTTP that is distinct origin servers. However, an extension to HTTP that is
defined to apply to entire host domains, such as the Cookie protocol defined to apply to entire host domains, such as the Cookie protocol
[draft-ietf-httpstate-cookie], can allow information set by one [RFC6265], can allow information set by one service to impact
service to impact communication with other services within a matching communication with other services within a matching group of host
group of host domains. domains.
The process for authoritative access to an "https" identified The process for authoritative access to an "https" identified
resource is defined in [RFC2818]. resource is defined in [RFC2818].
2.6.3. http and https URI Normalization and Comparison 2.7.3. http and https URI Normalization and Comparison
Since the "http" and "https" schemes conform to the URI generic Since the "http" and "https" schemes conform to the URI generic
syntax, such URIs are normalized and compared according to the syntax, such URIs are normalized and compared according to the
algorithm defined in [RFC3986], Section 6, using the defaults algorithm defined in [RFC3986], Section 6, using the defaults
described above for each scheme. described above for each scheme.
If the port is equal to the default port for a scheme, the normal If the port is equal to the default port for a scheme, the normal
form is to elide the port subcomponent. Likewise, an empty path form is to elide the port subcomponent. Likewise, an empty path
component is equivalent to an absolute path of "/", so the normal component is equivalent to an absolute path of "/", so the normal
form is to provide a path of "/" instead. The scheme and host are form is to provide a path of "/" instead. The scheme and host are
skipping to change at page 23, line 19 skipping to change at page 23, line 46
fields with the same field name can be combined into one "field-name: fields with the same field name can be combined into one "field-name:
field-value" pair, without changing the semantics of the message, by field-value" pair, without changing the semantics of the message, by
appending each subsequent field value to the combined field value in appending each subsequent field value to the combined field value in
order, separated by a comma. The order in which header fields with order, separated by a comma. The order in which header fields with
the same field name are received is therefore significant to the the same field name are received is therefore significant to the
interpretation of the combined field value; a proxy MUST NOT change interpretation of the combined field value; a proxy MUST NOT change
the order of these field values when forwarding a message. the order of these field values when forwarding a message.
Note: The "Set-Cookie" header field as implemented in practice can Note: The "Set-Cookie" header field as implemented in practice can
occur multiple times, but does not use the list syntax, and thus occur multiple times, but does not use the list syntax, and thus
cannot be combined into a single line cannot be combined into a single line ([RFC6265]). (See Appendix
([draft-ietf-httpstate-cookie]). (See Appendix A.2.3 of [Kri2001] A.2.3 of [Kri2001] for details.) Also note that the Set-Cookie2
for details.) Also note that the Set-Cookie2 header field header field specified in [RFC2965] does not share this problem.
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 octet (line folding). This specification or horizontal tab octet (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 10.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
skipping to change at page 24, line 13 skipping to change at page 24, line 37
; OWS / <VCHAR except "(", ")", and "\"> / obs-text ; OWS / <VCHAR except "(", ")", and "\"> / obs-text
The backslash octet ("\") can be used as a single-octet quoting The backslash octet ("\") can be used as a single-octet quoting
mechanism within comment constructs: mechanism within comment constructs:
quoted-cpair = "\" ( WSP / VCHAR / obs-text ) quoted-cpair = "\" ( WSP / VCHAR / obs-text )
Senders SHOULD NOT escape octets that do not require escaping (i.e., Senders SHOULD NOT escape octets that do not require escaping (i.e.,
other than the backslash octet "\" and the parentheses "(" and ")"). other than the backslash octet "\" and the parentheses "(" and ")").
HTTP does not place a pre-defined limit on the length of header
fields, either in isolation or as a set. A server MUST be prepared
to receive request header fields of unbounded length and respond with
a 4xx status code if the received header field(s) would be longer
than the server wishes to handle.
A client that receives response headers that are longer than it
wishes to handle can only treat it as a server error.
Various ad-hoc limitations on header length are found in practice.
It is RECOMMENDED that all HTTP senders and recipients support
messages whose combined header fields have 4000 or more octets.
3.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
payload body associated with the request or response. payload body associated with the request or response.
message-body = *OCTET message-body = *OCTET
The message-body differs from the payload body only when a transfer- The message-body differs from the payload body only when a transfer-
coding has been applied, as indicated by the Transfer-Encoding header coding has been applied, as indicated by the Transfer-Encoding header
field (Section 9.7). If more than one Transfer-Encoding header field field (Section 9.7). If more than one Transfer-Encoding header field
skipping to change at page 30, line 17 skipping to change at page 31, line 13
OPTIONS http://www.example.org:8001 HTTP/1.1 OPTIONS http://www.example.org:8001 HTTP/1.1
would be forwarded by the final proxy as would be forwarded by the final 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.6.1. If the request-target is percent-encoded ([RFC3986], Section 2.7.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 non-transforming proxy MUST NOT rewrite the "path-absolute" part of A non-transforming proxy MUST NOT rewrite the "path-absolute" part of
the received request-target when forwarding it to the next inbound the 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
"/" or "*". "/" or "*".
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 32, line 37 skipping to change at page 33, line 35
Example 2: the effective request URI for the message Example 2: the effective request URI for the message
GET * HTTP/1.1 GET * HTTP/1.1
Host: www.example.org Host: www.example.org
(received over an SSL/TLS secured TCP connection) is "https", plus (received over an SSL/TLS secured TCP connection) is "https", plus
"://", plus the authority component "www.example.org", thus "://", plus the authority component "www.example.org", thus
"https://www.example.org". "https://www.example.org".
Effective request URIs are compared using the rules described in Effective request URIs are compared using the rules described in
Section 2.6.3, except that empty path components MUST NOT be treated Section 2.7.3, except that empty path components MUST NOT be treated
as equivalent to an absolute path of "/". as equivalent to an absolute path of "/".
5. 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 5.1 Response = Status-Line ; Section 5.1
*( header-field CRLF ) ; Section 3.2 *( header-field CRLF ) ; Section 3.2
CRLF CRLF
skipping to change at page 55, line 14 skipping to change at page 56, line 14
9.4. Host 9.4. Host
The "Host" header field in a request provides the host and port The "Host" header field in a request provides the host and port
information from the target resource's URI, enabling the origin information from the target resource's URI, enabling the origin
server to distinguish between resources while servicing requests for server to distinguish between resources while servicing requests for
multiple host names on a single IP address. Since the Host field- multiple host names on a single IP address. Since the Host field-
value is critical information for handling a request, it SHOULD be value is critical information for handling a request, it SHOULD be
sent as the first header field following the Request-Line. sent as the first header field following the Request-Line.
Host = uri-host [ ":" port ] ; Section 2.6.1 Host = uri-host [ ":" port ] ; Section 2.7.1
A client MUST send a Host header field in all HTTP/1.1 request A client MUST send a Host header field in all HTTP/1.1 request
messages. If the target resource's URI includes an authority messages. If the target resource's URI includes an authority
component, then the Host field-value MUST be identical to that component, then the Host field-value MUST be identical to that
authority component after excluding any userinfo (Section 2.6.1). If authority component after excluding any userinfo (Section 2.7.1). If
the authority component is missing or undefined for the target the authority component is missing or undefined for the target
resource's URI, then the Host header field MUST be sent with an empty resource's URI, then the Host header field MUST be sent with an empty
field-value. field-value.
For example, a GET request to the origin server for For example, a GET request to the origin server for
<http://www.example.org/pub/WWW/> would begin with: <http://www.example.org/pub/WWW/> would begin with:
GET /pub/WWW/ HTTP/1.1 GET /pub/WWW/ HTTP/1.1
Host: www.example.org Host: www.example.org
skipping to change at page 59, line 26 skipping to change at page 60, line 26
Servers MUST include the "Upgrade" header field in 101 (Switching Servers MUST include the "Upgrade" header field in 101 (Switching
Protocols) responses to indicate which protocol(s) are being switched Protocols) responses to indicate which protocol(s) are being switched
to, and MUST include it in 426 (Upgrade Required) responses to to, and MUST include it in 426 (Upgrade Required) responses to
indicate acceptable protocols to upgrade to. Servers MAY include it indicate acceptable protocols to upgrade to. Servers MAY include it
in any other response to indicate that they are willing to upgrade to in any other response to indicate that they are willing to upgrade to
one of the specified protocols. one of the specified protocols.
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 2.5 and future updates to this version rules of Section 2.6 and future updates to this
specification. Additional tokens can be registered with IANA using specification. Additional tokens can be registered with IANA using
the registration procedure defined below. the registration procedure defined below.
9.8.1. Upgrade Token Registry 9.8.1. Upgrade Token Registry
The HTTP Upgrade Token Registry defines the name space for product The HTTP Upgrade Token Registry defines the name space for product
tokens used to identify protocols in the Upgrade header field. Each tokens used to identify protocols in the Upgrade header field. Each
registered token is associated with contact information and an registered token is associated with contact information and an
optional set of specifications that details how the connection will optional set of specifications that details how the connection will
be processed after it has been upgraded. be processed after it has been upgraded.
skipping to change at page 62, line 26 skipping to change at page 63, line 26
| Via | http | standard | Section 9.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".
10.2. URI Scheme Registration 10.2. URI Scheme Registration
The entries for the "http" and "https" URI Schemes in the registry The entries for the "http" and "https" URI Schemes in the registry
located at <http://www.iana.org/assignments/uri-schemes.html> shall located at <http://www.iana.org/assignments/uri-schemes.html> shall
be updated to point to Sections 2.6.1 and 2.6.2 of this document (see be updated to point to Sections 2.7.1 and 2.7.2 of this document (see
[RFC4395]). [RFC4395]).
10.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]).
10.3.1. Internet Media Type message/http 10.3.1. Internet Media Type message/http
skipping to change at page 65, line 29 skipping to change at page 66, line 29
defined in Section 7.2 of [RFC2817] -- is now defined by defined in Section 7.2 of [RFC2817] -- is now defined by
Section 9.8.1 of this document. Section 9.8.1 of this document.
The HTTP Status Code Registry located at The HTTP Status Code Registry located at
<http://www.iana.org/assignments/http-upgrade-tokens/> shall be <http://www.iana.org/assignments/http-upgrade-tokens/> shall be
updated with the registration below: updated with the registration below:
+-------+---------------------------+-------------------------------+ +-------+---------------------------+-------------------------------+
| Value | Description | Reference | | Value | Description | Reference |
+-------+---------------------------+-------------------------------+ +-------+---------------------------+-------------------------------+
| HTTP | Hypertext Transfer | Section 2.5 of this | | HTTP | Hypertext Transfer | Section 2.6 of this |
| | Protocol | specification | | | Protocol | specification |
+-------+---------------------------+-------------------------------+ +-------+---------------------------+-------------------------------+
11. Security Considerations 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.
skipping to change at page 68, line 5 skipping to change at page 69, line 5
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 proxies are no trustworthier Users of a proxy need to be aware that proxies are no trustworthier
than the people who run them; HTTP itself cannot solve this problem. than the people who run them; HTTP itself cannot solve this problem.
The judicious use of cryptography, when appropriate, might suffice to The judicious use of cryptography, when appropriate, might 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.
11.6. Denial of Service Attacks on Proxies 11.6. Protocol Element Size Overflows
Because HTTP uses mostly textual, character-delimited fields,
attackers can overflow buffers in implementations, and/or perform a
Denial of Service against implementations that accept fields with
unlimited lengths.
To promote interoperability, this specification makes specific
recommendations for size limits on request-targets (Section 4.1.2)
and blocks of header fields (Section 3.2). These are minimum
recommendations, chosen to be supportable even by implementations
with limited resources; it is expected that most implementations will
choose substantially higher limits.
This specification also provides a way for servers to reject messages
that have request-targets that are too long (Section 8.4.15 of
[Part2]) or request entities that are too large (Section 8.4 of
[Part2]).
Other fields (including but not limited to request methods, response
status phrases, header field-names, and body chunks) SHOULD be
limited by implementations carefully, so as to not impede
interoperability.
11.7. 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.
12. 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
skipping to change at page 69, line 17 skipping to change at page 70, line 41
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.
13. References 13. References
13.1. Normative References 13.1. Normative References
[ISO-8859-1] International Organization for [ISO-8859-1] International Organization for Standardization,
Standardization, "Information "Information technology -- 8-bit single-byte coded
technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No.
graphic character sets -- Part 1: 1", ISO/IEC 8859-1:1998, 1998.
Latin alphabet No. 1", ISO/
IEC 8859-1:1998, 1998.
[Part2] Fielding, R., Ed., Gettys, J., Mogul, [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
J., Frystyk, H., Masinter, L., Leach, Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
P., Berners-Lee, T., Lafon, Y., Ed., Ed., and J. Reschke, Ed., "HTTP/1.1, part 2: Message
and J. Reschke, Ed., "HTTP/1.1, part Semantics", draft-ietf-httpbis-p2-semantics-15 (work in
2: Message Semantics", progress), July 2011.
draft-ietf-httpbis-p2-semantics-14
(work in progress), April 2011.
[Part3] Fielding, R., Ed., Gettys, J., Mogul, [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
J., Frystyk, H., Masinter, L., Leach, Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
P., Berners-Lee, T., Lafon, Y., Ed., Ed., and J. Reschke, Ed., "HTTP/1.1, part 3: Message
and J. Reschke, Ed., "HTTP/1.1, part Payload and Content Negotiation",
3: Message Payload and Content draft-ietf-httpbis-p3-payload-15 (work in progress),
Negotiation", July 2011.
draft-ietf-httpbis-p3-payload-14 (work
in progress), April 2011.
[Part6] Fielding, R., Ed., Gettys, J., Mogul, [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
J., Frystyk, H., Masinter, L., Leach, Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
P., Berners-Lee, T., Lafon, Y., Ed., Ed., Nottingham, M., Ed., and J. Reschke, Ed.,
Nottingham, M., Ed., and J. Reschke, "HTTP/1.1, part 6: Caching",
Ed., "HTTP/1.1, part 6: Caching", draft-ietf-httpbis-p6-cache-15 (work in progress),
draft-ietf-httpbis-p6-cache-14 (work July 2011.
in progress), April 2011.
[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
Compressed Data Format Specification Format Specification version 3.3", RFC 1950, May 1996.
version 3.3", RFC 1950, May 1996.
RFC 1950 is an Informational RFC, thus RFC 1950 is an Informational RFC, thus it might be less
it might be less stable than this stable than this specification. On the other hand,
specification. On the other hand, this downward reference was present since the
this downward reference was present publication of RFC 2068 in 1997 ([RFC2068]), therefore
since the publication of RFC 2068 in it is unlikely to cause problems in practice. See also
1997 ([RFC2068]), therefore it is [BCP97].
unlikely to cause problems in
practice. See also [BCP97].
[RFC1951] Deutsch, P., "DEFLATE Compressed Data [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format
Format Specification version 1.3", Specification version 1.3", RFC 1951, May 1996.
RFC 1951, May 1996.
RFC 1951 is an Informational RFC, thus RFC 1951 is an Informational RFC, thus it might be less
it might be less stable than this stable than this specification. On the other hand,
specification. On the other hand, this downward reference was present since the
this downward reference was present publication of RFC 2068 in 1997 ([RFC2068]), therefore
since the publication of RFC 2068 in it is unlikely to cause problems in practice. See also
1997 ([RFC2068]), therefore it is [BCP97].
unlikely to cause problems in
practice. See also [BCP97].
[RFC1952] Deutsch, P., Gailly, J-L., Adler, M., [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and
Deutsch, L., and G. Randers-Pehrson, G. Randers-Pehrson, "GZIP file format specification
"GZIP file format specification version 4.3", RFC 1952, May 1996.
version 4.3", RFC 1952, May 1996.
RFC 1952 is an Informational RFC, thus RFC 1952 is an Informational RFC, thus it might be less
it might be less stable than this stable than this specification. On the other hand,
specification. On the other hand, this downward reference was present since the
this downward reference was present publication of RFC 2068 in 1997 ([RFC2068]), therefore
since the publication of RFC 2068 in it is unlikely to cause problems in practice. See also
1997 ([RFC2068]), therefore it is [BCP97].
unlikely to cause problems in
practice. See also [BCP97].
[RFC2119] Bradner, S., "Key words for use in [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
RFCs to Indicate Requirement Levels", Requirement Levels", BCP 14, RFC 2119, March 1997.
BCP 14, RFC 2119, March 1997.
[RFC3986] Berners-Lee, T., Fielding, R., and L. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
Masinter, "Uniform Resource Identifier "Uniform Resource Identifier (URI): Generic Syntax",
(URI): Generic Syntax", STD 66, STD 66, RFC 3986, January 2005.
RFC 3986, January 2005.
[RFC5234] Crocker, D., Ed. and P. Overell, [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for
"Augmented BNF for Syntax Syntax Specifications: ABNF", STD 68, RFC 5234,
Specifications: ABNF", STD 68, January 2008.
RFC 5234, January 2008.
[USASCII] American National Standards Institute, [USASCII] American National Standards Institute, "Coded Character
"Coded Character Set -- 7-bit American Set -- 7-bit American Standard Code for Information
Standard Code for Information Interchange", ANSI X3.4, 1986.
Interchange", ANSI X3.4, 1986.
13.2. Informative References 13.2. Informative References
[BCP97] Klensin, J. and S. Hartman, "Handling [BCP97] Klensin, J. and S. Hartman, "Handling Normative
Normative References to Standards- References to Standards-Track Documents", BCP 97,
Track Documents", BCP 97, RFC 4897, RFC 4897, June 2007.
June 2007.
[Kri2001] Kristol, D., "HTTP Cookies: Standards, [Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and
Privacy, and Politics", ACM Politics", ACM Transactions on Internet Technology Vol.
Transactions on Internet 1, #2, November 2001,
Technology Vol. 1, #2, November 2001, <http://arxiv.org/abs/cs.SE/0105018>.
<http://arxiv.org/abs/cs.SE/0105018>.
[Nie1997] Frystyk, H., Gettys, J., [Nie1997] Frystyk, H., Gettys, J., Prud'hommeaux, E., Lie, H.,
Prud'hommeaux, E., Lie, H., and C. and C. Lilley, "Network Performance Effects of
Lilley, "Network Performance Effects HTTP/1.1, CSS1, and PNG", ACM Proceedings of the ACM
of HTTP/1.1, CSS1, and PNG", SIGCOMM '97 conference on Applications, technologies,
ACM Proceedings of the ACM SIGCOMM '97 architectures, and protocols for computer communication
conference on Applications, SIGCOMM '97, September 1997,
technologies, architectures, and <http://doi.acm.org/10.1145/263105.263157>.
protocols for computer communication
SIGCOMM '97, September 1997, <http://
doi.acm.org/10.1145/263105.263157>.
[Pad1995] Padmanabhan, V. and J. Mogul, [Pad1995] Padmanabhan, V. and J. Mogul, "Improving HTTP Latency",
"Improving HTTP Latency", Computer Computer Networks and ISDN Systems v. 28, pp. 25-35,
Networks and ISDN Systems v. 28, pp. December 1995,
25-35, December 1995, <http:// <http://portal.acm.org/citation.cfm?id=219094>.
portal.acm.org/
citation.cfm?id=219094>.
[RFC1123] Braden, R., "Requirements for Internet [RFC1123] Braden, R., "Requirements for Internet Hosts -
Hosts - Application and Support", Application and Support", STD 3, RFC 1123,
STD 3, RFC 1123, October 1989. October 1989.
[RFC1900] Carpenter, B. and Y. Rekhter, [RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work",
"Renumbering Needs Work", RFC 1900, RFC 1900, February 1996.
February 1996.
[RFC1919] Chatel, M., "Classical versus [RFC1919] Chatel, M., "Classical versus Transparent IP Proxies",
Transparent IP Proxies", RFC 1919, RFC 1919, March 1996.
March 1996.
[RFC1945] Berners-Lee, T., Fielding, R., and H. [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen,
Nielsen, "Hypertext Transfer Protocol "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945,
-- HTTP/1.0", RFC 1945, May 1996. May 1996.
[RFC2045] Freed, N. and N. Borenstein, [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet
"Multipurpose Internet Mail Extensions Mail Extensions (MIME) Part One: Format of Internet
(MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
Message Bodies", RFC 2045,
November 1996.
[RFC2047] Moore, K., "MIME (Multipurpose [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail
Internet Mail Extensions) Part Three: Extensions) Part Three: Message Header Extensions for
Message Header Extensions for Non- Non-ASCII Text", RFC 2047, November 1996.
ASCII Text", RFC 2047, November 1996.
[RFC2068] Fielding, R., Gettys, J., Mogul, J., [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and
Nielsen, H., and T. Berners-Lee, T. Berners-Lee, "Hypertext Transfer Protocol --
"Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.
HTTP/1.1", RFC 2068, January 1997.
[RFC2145] Mogul, J., Fielding, R., Gettys, J., [RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen,
and H. Nielsen, "Use and "Use and Interpretation of HTTP Version Numbers",
Interpretation of HTTP Version RFC 2145, May 1997.
Numbers", RFC 2145, May 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Frystyk, H., Masinter, L., Leach, P., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
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 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within
to TLS Within HTTP/1.1", RFC 2817, HTTP/1.1", RFC 2817, May 2000.
May 2000.
[RFC2818] Rescorla, E., "HTTP Over TLS", [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
RFC 2818, May 2000.
[RFC2965] Kristol, D. and L. Montulli, "HTTP [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management
State Management Mechanism", RFC 2965, Mechanism", RFC 2965, October 2000.
October 2000.
[RFC3040] Cooper, I., Melve, I., and G. [RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web
Tomlinson, "Internet Web Replication Replication and Caching Taxonomy", RFC 3040,
and Caching Taxonomy", RFC 3040, January 2001.
January 2001.
[RFC3864] Klyne, G., Nottingham, M., and J. [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Mogul, "Registration Procedures for Procedures for Message Header Fields", BCP 90,
Message Header Fields", BCP 90, RFC 3864, September 2004.
RFC 3864, September 2004.
[RFC4288] Freed, N. and J. Klensin, "Media Type [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications
Specifications and Registration and Registration Procedures", BCP 13, RFC 4288,
Procedures", BCP 13, RFC 4288, December 2005.
December 2005.
[RFC4395] Hansen, T., Hardie, T., and L. [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines
Masinter, "Guidelines and Registration and Registration Procedures for New URI Schemes",
Procedures for New URI Schemes", BCP 115, RFC 4395, February 2006.
BCP 115, RFC 4395, February 2006.
[RFC5226] Narten, T. and H. Alvestrand, [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based
"Guidelines for Writing an IANA Kerberos and NTLM HTTP Authentication in Microsoft
Considerations Section in RFCs", Windows", RFC 4559, June 2006.
BCP 26, RFC 5226, May 2008.
[RFC5322] Resnick, P., "Internet Message [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing
Format", RFC 5322, October 2008. an IANA Considerations Section in RFCs", BCP 26,
RFC 5226, May 2008.
[Spe] Spero, S., "Analysis of HTTP [RFC5322] Resnick, P., "Internet Message Format", RFC 5322,
Performance Problems", <http:// October 2008.
sunsite.unc.edu/mdma-release/
http-prob.html>.
[Tou1998] Touch, J., Heidemann, J., and K. [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
Obraczka, "Analysis of HTTP April 2011.
Performance", ISI Research Report ISI/
RR-98-463, Aug 1998, <http://
www.isi.edu/touch/pubs/http-perf96/>.
(original report dated Aug. 1996) [Spe] Spero, S., "Analysis of HTTP Performance Problems",
<http://sunsite.unc.edu/mdma-release/http-prob.html>.
[draft-ietf-httpstate-cookie] Barth, A., "HTTP State Management [Tou1998] Touch, J., Heidemann, J., and K. Obraczka, "Analysis of
Mechanism", HTTP Performance", ISI Research Report ISI/RR-98-463,
draft-ietf-httpstate-cookie-23 (work Aug 1998, <http://www.isi.edu/touch/pubs/http-perf96/>.
in progress), March 2011.
(original report dated Aug. 1996)
Appendix A. Tolerant Applications Appendix A. Tolerant Applications
Although this document specifies the requirements for the generation Although this document specifies the requirements for the generation
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.
The line terminator for header fields is the sequence CRLF. However, The line terminator for header fields is the sequence CRLF. However,
skipping to change at page 76, line 49 skipping to change at page 77, line 30
(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 octet is no longer specifically pointed out in the ABNF. The NUL octet 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 control characters other than HTAB. Non-ASCII longer allows escaping control characters other than HTAB. Non-ASCII
content in header fields and reason phrase has been obsoleted and content in header fields and reason phrase has been obsoleted and
made opaque (the TEXT 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 2.5) Clarify that the string "HTTP" in the HTTP-Version ABFN production is
case sensitive. Restrict the version numbers to be single digits due
to the fact that implementations are known to handle multi-digit
version numbers incorrectly. (Section 2.6)
Require that invalid whitespace around field-names be rejected. Require that invalid whitespace around field-names be rejected.
(Section 3.2) (Section 3.2)
Require recipients to handle bogus Content-Length header fields as Require recipients to handle bogus Content-Length header fields as
errors. (Section 3.3) errors. (Section 3.3)
Remove reference to non-existent identity transfer-coding value Remove reference to non-existent identity transfer-coding value
tokens. (Sections 3.3 and 6.2) tokens. (Sections 3.3 and 6.2)
Update use of abs_path production from RFC 1808 to the path-absolute Update use of abs_path production from RFC 1808 to the path-absolute
+ query components of RFC 3986. State that the asterisk form is + query components of RFC 3986. State that the asterisk form is
skipping to change at page 77, line 46 skipping to change at page 78, line 29
Chunked-Body = *chunk last-chunk trailer-part CRLF Chunked-Body = *chunk last-chunk trailer-part CRLF
Connection = *( "," OWS ) connection-token *( OWS "," [ OWS Connection = *( "," OWS ) connection-token *( OWS "," [ OWS
connection-token ] ) connection-token ] )
Content-Length = 1*DIGIT Content-Length = 1*DIGIT
Date = HTTP-date Date = 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 "/" DIGIT "." DIGIT
HTTP-date = rfc1123-date / obs-date HTTP-date = rfc1123-date / obs-date
HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body
] ]
Host = uri-host [ ":" port ] Host = uri-host [ ":" port ]
Method = token Method = token
OWS = *( [ obs-fold ] WSP ) OWS = *( [ obs-fold ] WSP )
RWS = 1*( [ obs-fold ] WSP ) RWS = 1*( [ obs-fold ] WSP )
Reason-Phrase = *( WSP / VCHAR / obs-text ) Reason-Phrase = *( WSP / VCHAR / obs-text )
Request = Request-Line *( header-field CRLF ) CRLF [ message-body ] Request = Request-Line *( header-field CRLF ) CRLF [ message-body ]
Request-Line = Method SP request-target SP HTTP-Version CRLF Request-Line = Method SP request-target SP HTTP-Version CRLF
Response = Status-Line *( header-field CRLF ) CRLF [ message-body ] Response = Status-Line *( header-field CRLF ) CRLF [ message-body ]
Status-Code = 3DIGIT Status-Code = 3DIGIT
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
skipping to change at page 90, line 27 skipping to change at page 91, line 24
o <http://tools.ietf.org/wg/httpbis/trac/ticket/53>: "Allow is not o <http://tools.ietf.org/wg/httpbis/trac/ticket/53>: "Allow is not
in 13.5.2" in 13.5.2"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle
ABNFs for header fields" ABNFs for header fields"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/286>: "Content- o <http://tools.ietf.org/wg/httpbis/trac/ticket/286>: "Content-
Length ABNF broken" Length ABNF broken"
D.16. Since draft-ietf-httpbis-p1-messaging-14
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/273>: "HTTP-Version
should be redefined as fixed length pair of DIGIT . DIGIT"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/282>: "Recommend
minimum sizes for protocol elements"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/283>: "Set
expectations around buffering"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/288>: "Considering
messages in isolation"
Index Index
A A
absolute-URI form (of request-target) 29 absolute-URI form (of request-target) 29
accelerator 13 accelerator 14
application/http Media Type 63 application/http Media Type 64
asterisk form (of request-target) 28 asterisk form (of request-target) 29
authority form (of request-target) 29 authority form (of request-target) 30
B B
browser 10 browser 10
C C
cache 14 cache 15
cacheable 14 cacheable 15
captive portal 14 captive portal 14
chunked (Coding Format) 37 chunked (Coding Format) 38
client 10 client 10
Coding Format Coding Format
chunked 37 chunked 38
compress 40 compress 41
deflate 40 deflate 41
gzip 40 gzip 41
compress (Coding Format) 40 compress (Coding Format) 41
connection 10 connection 10
Connection header field 51 Connection header field 52
Content-Length header field 53 Content-Length header field 54
D D
Date header field 53 Date header field 54
deflate (Coding Format) 40 deflate (Coding Format) 41
downstream 12 downstream 13
E E
effective request URI 31 effective request URI 32
G G
gateway 13 gateway 14
Grammar Grammar
absolute-URI 17 absolute-URI 18
ALPHA 7 ALPHA 7
asctime-date 36 asctime-date 37
attribute 36 attribute 37
authority 17 authority 18
BWS 9 BWS 9
chunk 37 chunk 38
chunk-data 37 chunk-data 38
chunk-ext 37 chunk-ext 38
chunk-ext-name 37 chunk-ext-name 38
chunk-ext-val 37 chunk-ext-val 38
chunk-size 37 chunk-size 38
Chunked-Body 37 Chunked-Body 38
comment 23 comment 24
Connection 52 Connection 53
connection-token 52 connection-token 53
Content-Length 53 Content-Length 54
CR 7 CR 7
CRLF 7 CRLF 7
ctext 23 ctext 24
CTL 7 CTL 7
Date 53 Date 54
date1 35 date1 36
date2 36 date2 37
date3 36 date3 37
day 35 day 36
day-name 35 day-name 36
day-name-l 35 day-name-l 36
DIGIT 7 DIGIT 7
DQUOTE 7 DQUOTE 7
field-content 22 field-content 23
field-name 22 field-name 23
field-value 22 field-value 23
GMT 35 GMT 36
header-field 22 header-field 23
HEXDIG 7 HEXDIG 7
Host 55 Host 56
hour 35 hour 36
HTTP-date 34 HTTP-date 35
HTTP-message 21 HTTP-message 21
HTTP-Prot-Name 15 HTTP-Prot-Name 16
http-URI 18 http-URI 18
HTTP-Version 15 HTTP-Version 16
https-URI 19 https-URI 20
last-chunk 37 last-chunk 38
LF 7 LF 7
message-body 24 message-body 25
Method 28 Method 29
minute 35 minute 36
month 35 month 36
obs-date 35 obs-date 36
obs-text 10 obs-text 10
OCTET 7 OCTET 7
OWS 9 OWS 9
path-absolute 17 path-absolute 18
port 17 port 18
product 41 product 42
product-version 41 product-version 42
protocol-name 60 protocol-name 61
protocol-version 60 protocol-version 61
pseudonym 60 pseudonym 61
qdtext 10 qdtext 10
qdtext-nf 37 qdtext-nf 38
query 17 query 18
quoted-cpair 24 quoted-cpair 24
quoted-pair 10 quoted-pair 10
quoted-str-nf 37 quoted-str-nf 38
quoted-string 10 quoted-string 10
qvalue 41 qvalue 42
Reason-Phrase 33 Reason-Phrase 34
received-by 60 received-by 61
received-protocol 60 received-protocol 61
Request 28 Request 29
Request-Line 28 Request-Line 29
request-target 28 request-target 29
Response 32 Response 33
rfc850-date 36 rfc850-date 37
rfc1123-date 35 rfc1123-date 36
RWS 9 RWS 9
second 35 second 36
SP 7 SP 7
special 9 special 9
Status-Code 33 Status-Code 34
Status-Line 33 Status-Line 34
t-codings 56 t-codings 57
tchar 9 tchar 9
TE 56 TE 57
te-ext 56 te-ext 57
te-params 56 te-params 57
time-of-day 35 time-of-day 36
token 9 token 9
Trailer 57 Trailer 58
trailer-part 37 trailer-part 38
transfer-coding 36 transfer-coding 37
Transfer-Encoding 58 Transfer-Encoding 59
transfer-extension 36 transfer-extension 37
transfer-parameter 36 transfer-parameter 37
Upgrade 58 Upgrade 59
uri-host 17 uri-host 18
URI-reference 17 URI-reference 18
value 36 value 37
VCHAR 7 VCHAR 7
Via 60 Via 61
word 9 word 9
WSP 7 WSP 7
year 35 year 36
gzip (Coding Format) 40 gzip (Coding Format) 41
H H
header field 20 header field 21
Header Fields Header Fields
Connection 51 Connection 52
Content-Length 53 Content-Length 54
Date 53 Date 54
Host 55 Host 56
TE 56 TE 57
Trailer 57 Trailer 58
Transfer-Encoding 57 Transfer-Encoding 58
Upgrade 58 Upgrade 59
Via 60 Via 61
header section 20 header section 21
headers 20 headers 21
Host header field 55 Host header field 56
http URI scheme 18 http URI scheme 18
https URI scheme 19 https URI scheme 20
I I
inbound 12 inbound 13
interception proxy 14 interception proxy 14
intermediary 12 intermediary 13
M M
Media Type Media Type
application/http 63 application/http 64
message/http 62 message/http 63
message 11 message 11
message/http Media Type 62 message/http Media Type 63
N N
non-transforming proxy 13 non-transforming proxy 13
O O
origin form (of request-target) 29 origin form (of request-target) 30
origin server 10 origin server 10
outbound 12 outbound 13
P P
proxy 13 proxy 13
R R
recipient 10 recipient 10
request 11 request 11
resource 17 resource 18
response 11 response 11
reverse proxy 13 reverse proxy 14
S S
sender 10 sender 10
server 10 server 10
spider 10 spider 10
T T
target resource 31 target resource 32
TE header field 56 TE header field 57
Trailer header field 57 Trailer header field 58
Transfer-Encoding header field 57 Transfer-Encoding header field 58
transforming proxy 13 transforming proxy 13
transparent proxy 14 transparent proxy 14
tunnel 14 tunnel 14
U U
Upgrade header field 58 Upgrade header field 59
upstream 12 upstream 13
URI scheme URI scheme
http 18 http 18
https 19 https 20
user agent 10 user agent 10
V V
Via header field 60 Via header field 61
Authors' Addresses Authors' Addresses
Roy T. Fielding (editor) Roy T. Fielding (editor)
Adobe Systems Incorporated Adobe Systems Incorporated
345 Park Ave 345 Park Ave
San Jose, CA 95110 San Jose, CA 95110
USA USA
EMail: fielding@gbiv.com EMail: fielding@gbiv.com
 End of changes. 123 change blocks. 
458 lines changed or deleted 493 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/