draft-ietf-httpbis-p1-messaging-10.txt   draft-ietf-httpbis-p1-messaging-11.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
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: January 13, 2011 HP Expires: February 5, 2011 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 12, 2010 August 4, 2010
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-10 draft-ietf-httpbis-p1-messaging-11
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 1, line 47 skipping to change at page 1, line 47
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/3> and related at <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.11. The changes in this draft are summarized in Appendix D.12.
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 January 13, 2011. This Internet-Draft will expire on February 5, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 7 skipping to change at page 3, line 7
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 . . . . . . . . . . . . . . . . . . . . 10 Specification . . . . . . . . . . . . . . . . . . . . 10
2. HTTP architecture . . . . . . . . . . . . . . . . . . . . . . 11 2. HTTP-related architecture . . . . . . . . . . . . . . . . . . 10
2.1. Client/Server Operation . . . . . . . . . . . . . . . . . 11 2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 10
2.2. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 12 2.2. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 12
2.3. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4. Transport Independence . . . . . . . . . . . . . . . . . . 14 2.4. Transport Independence . . . . . . . . . . . . . . . . . . 14
2.5. HTTP Version . . . . . . . . . . . . . . . . . . . . . . . 15 2.5. HTTP Version . . . . . . . . . . . . . . . . . . . . . . . 14
2.6. Uniform Resource Identifiers . . . . . . . . . . . . . . . 16 2.6. Uniform Resource Identifiers . . . . . . . . . . . . . . . 16
2.6.1. http URI scheme . . . . . . . . . . . . . . . . . . . 17 2.6.1. http URI scheme . . . . . . . . . . . . . . . . . . . 16
2.6.2. https URI scheme . . . . . . . . . . . . . . . . . . . 18 2.6.2. https URI scheme . . . . . . . . . . . . . . . . . . . 18
2.6.3. http and https URI Normalization and Comparison . . . 18 2.6.3. http and https URI Normalization and Comparison . . . 18
3. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . . 19 3. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1. Message Parsing Robustness . . . . . . . . . . . . . . . . 20 3.1. Message Parsing Robustness . . . . . . . . . . . . . . . . 20
3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 20 3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 20
3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 22 3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 22
3.4. Message Length . . . . . . . . . . . . . . . . . . . . . . 23 3.4. General Header Fields . . . . . . . . . . . . . . . . . . 25
3.5. General Header Fields . . . . . . . . . . . . . . . . . . 24 4. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 26
4.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 25 4.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 25 4.1.2. request-target . . . . . . . . . . . . . . . . . . . . 27
4.1.2. request-target . . . . . . . . . . . . . . . . . . . . 26 4.2. The Resource Identified by a Request . . . . . . . . . . . 29
4.2. The Resource Identified by a Request . . . . . . . . . . . 28 4.3. Effective Request URI . . . . . . . . . . . . . . . . . . 29
4.3. Effective Request URI . . . . . . . . . . . . . . . . . . 28 5. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 5.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 31
5.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 30 5.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 31
5.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 30 6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 32
6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 31 6.1. Date/Time Formats: Full Date . . . . . . . . . . . . . . . 32
6.1. Date/Time Formats: Full Date . . . . . . . . . . . . . . . 31 6.2. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 34
6.2. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 33 6.2.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 35
6.2.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 34 6.2.2. Compression Codings . . . . . . . . . . . . . . . . . 37
6.2.2. Compression Codings . . . . . . . . . . . . . . . . . 36 6.2.3. Transfer Coding Registry . . . . . . . . . . . . . . . 38
6.2.3. Transfer Coding Registry . . . . . . . . . . . . . . . 37 6.3. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 39
6.3. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 37 6.4. Quality Values . . . . . . . . . . . . . . . . . . . . . . 39
6.4. Quality Values . . . . . . . . . . . . . . . . . . . . . . 38 7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 39
7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 38 7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 39
7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 38 7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 40
7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 38 7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 40
7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 39 7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 42
7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 41 7.1.4. Practical Considerations . . . . . . . . . . . . . . . 44
7.1.4. Practical Considerations . . . . . . . . . . . . . . . 43 7.2. Message Transmission Requirements . . . . . . . . . . . . 45
7.2. Message Transmission Requirements . . . . . . . . . . . . 44 7.2.1. Persistent Connections and Flow Control . . . . . . . 45
7.2.1. Persistent Connections and Flow Control . . . . . . . 44 7.2.2. Monitoring Connections for Error Status Messages . . . 45
7.2.2. Monitoring Connections for Error Status Messages . . . 44 7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 46
7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 45
7.2.4. Client Behavior if Server Prematurely Closes 7.2.4. Client Behavior if Server Prematurely Closes
Connection . . . . . . . . . . . . . . . . . . . . . . 47 Connection . . . . . . . . . . . . . . . . . . . . . . 48
8. Miscellaneous notes that might disappear . . . . . . . . . . . 49
8. Miscellaneous notes that may disappear . . . . . . . . . . . . 47 8.1. Scheme aliases considered harmful . . . . . . . . . . . . 49
8.1. Scheme aliases considered harmful . . . . . . . . . . . . 47 8.2. Use of HTTP for proxy communication . . . . . . . . . . . 49
8.2. Use of HTTP for proxy communication . . . . . . . . . . . 48 8.3. Interception of HTTP for access control . . . . . . . . . 49
8.3. Interception of HTTP for access control . . . . . . . . . 48 8.4. Use of HTTP by other protocols . . . . . . . . . . . . . . 49
8.4. Use of HTTP by other protocols . . . . . . . . . . . . . . 48 8.5. Use of HTTP by media type specification . . . . . . . . . 49
8.5. Use of HTTP by media type specification . . . . . . . . . 48 9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 49
9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 48 9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 49
9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 48 9.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 50
9.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 49 9.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
9.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 9.3.1. Clockless Origin Server Operation . . . . . . . . . . 52
9.3.1. Clockless Origin Server Operation . . . . . . . . . . 51 9.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
9.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 9.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
9.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 9.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 54
9.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 53 9.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 55
9.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 54 9.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 55
9.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 54 9.8.1. Upgrade Token Registry . . . . . . . . . . . . . . . . 56
9.8.1. Upgrade Token Registry . . . . . . . . . . . . . . . . 55 9.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
9.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58 10.1. Header Field Registration . . . . . . . . . . . . . . . . 59
10.1. Message Header Registration . . . . . . . . . . . . . . . 58 10.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 59
10.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 58 10.3. Internet Media Type Registrations . . . . . . . . . . . . 59
10.3. Internet Media Type Registrations . . . . . . . . . . . . 58 10.3.1. Internet Media Type message/http . . . . . . . . . . . 59
10.3.1. Internet Media Type message/http . . . . . . . . . . . 58 10.3.2. Internet Media Type application/http . . . . . . . . . 61
10.3.2. Internet Media Type application/http . . . . . . . . . 60 10.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 62
10.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 61 10.5. Upgrade Token Registration . . . . . . . . . . . . . . . . 62
10.5. Upgrade Token Registration . . . . . . . . . . . . . . . . 61 11. Security Considerations . . . . . . . . . . . . . . . . . . . 62
11. Security Considerations . . . . . . . . . . . . . . . . . . . 61 11.1. Personal Information . . . . . . . . . . . . . . . . . . . 63
11.1. Personal Information . . . . . . . . . . . . . . . . . . . 62 11.2. Abuse of Server Log Information . . . . . . . . . . . . . 63
11.2. Abuse of Server Log Information . . . . . . . . . . . . . 62 11.3. Attacks Based On File and Path Names . . . . . . . . . . . 63
11.3. Attacks Based On File and Path Names . . . . . . . . . . . 62 11.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 63
11.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 62 11.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 64
11.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 63 11.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 65
11.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 64 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 65
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 64 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 66
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 65 13.1. Normative References . . . . . . . . . . . . . . . . . . . 66
13.1. Normative References . . . . . . . . . . . . . . . . . . . 65 13.2. Informative References . . . . . . . . . . . . . . . . . . 68
13.2. Informative References . . . . . . . . . . . . . . . . . . 67 Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 70
Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 69 Appendix B. Compatibility with Previous Versions . . . . . . . . 71
Appendix B. Compatibility with Previous Versions . . . . . . . . 70
B.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 71 B.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 71
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 . . . . . . . . . . . . . . . . 71 Conserve IP Addresses . . . . . . . . . . . . . . . . 72
B.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 71 B.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 72
B.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 72 B.3. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 73
B.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 73 Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 74
Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 73
Appendix D. Change Log (to be removed by RFC Editor before Appendix D. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 78 publication) . . . . . . . . . . . . . . . . . . . . 78
D.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 78 D.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 78
D.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 78 D.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 78
D.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 80 D.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 80
D.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 81 D.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 81
D.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 81 D.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 81
D.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 82 D.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 82
D.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 82 D.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 82
D.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 83 D.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 83
D.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 84 D.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 84
D.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 84 D.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 84
skipping to change at page 5, line 16 skipping to change at page 5, line 13
D.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 78 D.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 78
D.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 80 D.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 80
D.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 81 D.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 81
D.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 81 D.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 81
D.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 82 D.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 82
D.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 82 D.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 82
D.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 83 D.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 83
D.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 84 D.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 84
D.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 84 D.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 84
D.11. Since draft-ietf-httpbis-p1-messaging-09 . . . . . . . . . 85 D.11. Since draft-ietf-httpbis-p1-messaging-09 . . . . . . . . . 85
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 D.12. Since draft-ietf-httpbis-p1-messaging-10 . . . . . . . . . 85
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
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 27 skipping to change at page 6, line 27
HTTP is a generic interface protocol for information systems. It is HTTP is a generic interface protocol for information systems. It is
designed to hide the details of how a service is implemented by designed to hide the details of how a service is implemented by
presenting a uniform interface to clients that is independent of the presenting a uniform interface to clients that is independent of the
types of resources provided. Likewise, servers do not need to be types of resources provided. Likewise, servers do not need to be
aware of each client's purpose: an HTTP request can be considered in aware of each client's purpose: an HTTP request can be considered in
isolation rather than being associated with a specific type of client isolation rather than being associated with a specific type of client
or a predetermined sequence of application steps. The result is a or a predetermined sequence of application steps. The result is a
protocol that can be used effectively in many different contexts and protocol that can be used effectively in many different contexts and
for which implementations can evolve independently over time. for which implementations can evolve independently over time.
HTTP is also designed for use as a generic protocol for translating HTTP is also designed for use as an intermediation protocol for
communication to and from other Internet information systems. HTTP translating communication to and from non-HTTP information systems.
proxies and gateways provide access to alternative information HTTP proxies and gateways can provide access to alternative
services by translating their diverse protocols into a hypertext information services by translating their diverse protocols into a
format that can be viewed and manipulated by clients in the same way hypertext format that can be viewed and manipulated by clients in the
as HTTP services. same way as HTTP services.
One consequence of HTTP flexibility is that the protocol cannot be One consequence of HTTP flexibility is that the protocol cannot be
defined in terms of what occurs behind the interface. Instead, we defined in terms of what occurs behind the interface. Instead, we
are limited to defining the syntax of communication, the intent of are limited to defining the syntax of communication, the intent of
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 ought to 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 might
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, defines the "http" and "https" URI schemes, or referred to in HTTP, defines the "http" and "https" URI schemes,
describes overall network operation and connection management, and describes overall network operation and connection management, and
defines HTTP message framing and forwarding requirements. Our goal defines HTTP message framing and forwarding requirements. Our goal
is to define all of the mechanisms necessary for HTTP message is to define all of the mechanisms necessary for HTTP message
skipping to change at page 7, line 33 skipping to change at page 7, line 33
This specification uses the Augmented Backus-Naur Form (ABNF) This specification uses the Augmented Backus-Naur Form (ABNF)
notation of [RFC5234]. notation of [RFC5234].
The following core rules are included by reference, as defined in The following core rules are included by reference, as defined in
[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
(CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit
sequence of data), SP (space), VCHAR (any visible [USASCII] sequence of data), SP (space), VCHAR (any visible [USASCII]
character), and WSP (whitespace). character), and WSP (whitespace).
As a syntactical convention, ABNF rule names prefixed with "obs-" As a syntactic convention, ABNF rule names prefixed with "obs-"
denote "obsolete" grammar rules that appear for historical reasons. denote "obsolete" grammar rules that appear for historical reasons.
1.2.1. ABNF Extension: #rule 1.2.1. ABNF Extension: #rule
The #rule extension to the ABNF rules of [RFC5234] is used to improve The #rule extension to the ABNF rules of [RFC5234] is used to improve
readability. readability.
A construct "#" is defined, similar to "*", for defining comma- A construct "#" is defined, similar to "*", for defining comma-
delimited lists of elements. The full form is "<n>#<m>element" delimited lists of elements. The full form is "<n>#<m>element"
indicating at least <n> and at most <m> elements, each separated by a indicating at least <n> and at most <m> elements, each separated by a
skipping to change at page 8, line 50 skipping to change at page 8, line 50
"" ""
"," ","
", ," ", ,"
Appendix C 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 other than the message-body (see Appendix A for
applications). The end-of-line marker within an entity-body is tolerant applications).
defined by its associated media type, as described in Section 2.3 of
[Part3].
This specification uses three rules to denote the use of linear This specification uses three rules to denote the use of linear
whitespace: OWS (optional whitespace), RWS (required whitespace), and whitespace: OWS (optional whitespace), RWS (required whitespace), and
BWS ("bad" whitespace). BWS ("bad" whitespace).
The OWS rule is used where zero or more linear whitespace characters The OWS rule is used where zero or more linear whitespace characters
may appear. OWS SHOULD either not be produced or be produced as a might appear. OWS SHOULD either not be produced or be produced as a
single SP character. Multiple OWS characters that occur within single SP character. Multiple OWS characters that occur within
field-content SHOULD be replaced with a single SP before interpreting field-content SHOULD be replaced with a single SP before interpreting
the field value or forwarding the message downstream. the field value or forwarding the message downstream.
RWS is used when at least one linear whitespace character is required RWS is used when at least one linear whitespace character is required
to separate field tokens. RWS SHOULD be produced as a single SP to separate field tokens. RWS SHOULD be produced as a single SP
character. Multiple RWS characters that occur within field-content character. Multiple RWS characters that occur within field-content
SHOULD be replaced with a single SP before interpreting the field SHOULD be replaced with a single SP before interpreting the field
value or forwarding the message downstream. value or forwarding the message downstream.
skipping to change at page 10, line 41 skipping to change at page 10, line 29
Producers SHOULD NOT escape characters that do not require escaping Producers SHOULD NOT escape characters that do not require escaping
(i.e., other than DQUOTE and the backslash character). (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> MIME-Version = <MIME-Version, defined in [Part3], Appendix A.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-related architecture
HTTP was created for the World Wide Web architecture and has evolved HTTP was created for the World Wide Web architecture and has evolved
over time to support the scalability needs of a worldwide hypertext over time to support the scalability needs of a worldwide hypertext
system. Much of that architecture is reflected in the terminology system. Much of that architecture is reflected in the terminology
and syntax productions used to define HTTP. and syntax productions used to define HTTP.
2.1. Client/Server Operation 2.1. Client/Server Messaging
HTTP is a request/response protocol that operates by exchanging HTTP is a stateless request/response protocol that operates by
messages across a reliable transport or session-layer connection. An exchanging messages across a reliable transport or session-layer
HTTP client is a program that establishes a connection to a server connection. An HTTP "client" is a program that establishes a
for the purpose of sending one or more HTTP requests. An HTTP server connection to a server for the purpose of sending one or more HTTP
is a program that accepts connections in order to service HTTP requests. An HTTP "server" is a program that accepts connections in
requests by sending HTTP responses. order to service HTTP requests by sending HTTP responses.
Note that the terms "client" and "server" refer only to the roles Note that the terms client and server refer only to the roles that
that these programs perform for a particular connection. The same these programs perform for a particular connection. The same program
program may act as a client on some connections and a server on might act as a client on some connections and a server on others. We
others. We use the term "user agent" to refer to the program that use the term "user agent" to refer to the program that initiates a
initiates a request, such as a WWW browser, editor, or spider (web- request, such as a WWW browser, editor, or spider (web-traversing
traversing robot), and the term "origin server" to refer to the robot), and the term "origin server" to refer to the program that can
program that can originate authoritative responses to a request. originate authoritative responses to a request. For general
requirements, we use the term "sender" to refer to whichever
component sent a given message and the term "recipient" to refer to
any component that receives the message.
Most HTTP communication consists of a retrieval request (GET) for a Most HTTP communication consists of a retrieval request (GET) for a
representation of some resource identified by a URI. In the simplest representation of some resource identified by a URI. In the simplest
case, this may be accomplished via a single connection (v) between case, this might be accomplished via a single bidirectional
the user agent (UA) and the origin server (O). connection (===) between the user agent (UA) and the origin server
(O).
request chain ------------------------> request >
UA -------------------v------------------- O UA ======================================= O
<----------------------- response chain < response
A client sends an HTTP request to the server in the form of a request 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 message (Section 4), beginning with a method, URI, and protocol
version, followed by MIME-like header fields containing request version, followed by MIME-like header fields containing request
modifiers, client information, and payload metadata, an empty line to modifiers, client information, and payload metadata, an empty line to
indicate the end of the header section, and finally the payload body indicate the end of the header section, and finally the payload body
(if any). (if any).
A server responds to the client's request by sending an HTTP response A server responds to the client's request by sending an HTTP response
message (Section 5), beginning with a status line that includes the message (Section 5), beginning with a status line that includes the
skipping to change at page 12, line 32 skipping to change at page 12, line 24
Vary: Accept-Encoding Vary: Accept-Encoding
Content-Type: text/plain Content-Type: text/plain
Hello World! Hello World!
2.2. Intermediaries 2.2. Intermediaries
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. In some cases, a forms of intermediary: proxy, gateway, and tunnel. In some cases, a
single intermediary may act as an origin server, proxy, gateway, or single 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.
request chain --------------------------------------> > > > >
UA -----v----- A -----v----- B -----v----- C -----v----- O UA =========== A =========== B =========== C =========== O
<------------------------------------- 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.
Some HTTP communication options may apply only to the connection with Some HTTP communication options might apply only to the connection
the nearest, non-tunnel neighbor, only to the end-points of the with the nearest, non-tunnel neighbor, only to the end-points of the
chain, or to all connections along the chain. Although the diagram chain, or to all connections along the chain. Although the diagram
is linear, each participant may be engaged in multiple, simultaneous is linear, each participant might be engaged in multiple,
communications. For example, B may be receiving requests from many simultaneous communications. For example, B might be receiving
clients other than A, and/or forwarding requests to servers other requests from many clients other than A, and/or forwarding requests
than C, at the same time that it is handling A's request. to servers other than C, at the same time that it is handling A's
request.
We use the terms "upstream" and "downstream" to describe various We use the terms "upstream" and "downstream" to describe various
requirements in relation to the directional flow of a message: all requirements in relation to the directional flow of a message: all
messages flow from upstream to downstream. Likewise, we use the messages flow from upstream to downstream. Likewise, we use the
terms "inbound" and "outbound" to refer to directions in relation to terms "inbound" and "outbound" to refer to directions in relation to
the request path: "inbound" means toward the origin server and the request path: "inbound" means toward the origin server and
"outbound" means toward the user agent. "outbound" means toward the user agent.
A proxy is a message forwarding agent that is selected by the client, A "proxy" is a message forwarding agent that is selected by the
usually via local configuration rules, to receive requests for some client, usually via local configuration rules, to receive requests
type(s) of absolute URI and attempt to satisfy those requests via for some type(s) of absolute URI and attempt to satisfy those
translation through the HTTP interface. Some translations are requests via translation through the HTTP interface. Some
minimal, such as for proxy requests for "http" URIs, whereas other translations are minimal, such as for proxy requests for "http" URIs,
requests may require translation to and from entirely different whereas other requests might require translation to and from entirely
application-layer protocols. Proxies are often used to group an different application-layer protocols. Proxies are often used to
organization's HTTP requests through a common intermediary for the group an organization's HTTP requests through a common intermediary
sake of security, annotation services, or shared caching. 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 A "gateway" (a.k.a., "reverse proxy") is a receiving agent that acts
layer above some other server(s) and translates the received requests as a layer above some other server(s) and translates the received
to the underlying server's protocol. Gateways are often used for requests to the underlying server's protocol. Gateways are often
load balancing or partitioning HTTP services across multiple used for load balancing or partitioning HTTP services across multiple
machines. Unlike a proxy, a gateway receives requests as if it were machines. Unlike a proxy, a gateway receives requests as if it were
the origin server for the requested resource; the requesting client the origin server for the target resource; the requesting client will
will not be aware that it is communicating with a gateway. A gateway not be aware that it is communicating with a gateway. A gateway
communicates with the client as if the gateway is the origin server 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 and thus is subject to all of the requirements on origin servers for
that connection. A gateway communicates with inbound servers using that connection. A gateway communicates with inbound servers using
any protocol it desires, including private extensions to HTTP that any protocol it desires, including private extensions to HTTP that
are outside the scope of this specification. are outside the scope of this specification.
A tunnel acts as a blind relay between two connections without A "tunnel" acts as a blind relay between two connections without
changing the messages. Once active, a tunnel is not considered a changing the messages. Once active, a tunnel is not considered a
party to the HTTP communication, though the tunnel may have been party to the HTTP communication, though the tunnel might have been
initiated by an HTTP request. A tunnel ceases to exist when both initiated by an HTTP request. A tunnel ceases to exist when both
ends of the relayed connection are closed. Tunnels are used to ends of the relayed connection are closed. Tunnels are used to
extend a virtual connection through an intermediary, such as when extend a virtual connection through an intermediary, such as when
transport-layer security is used to establish private communication transport-layer security is used to establish private communication
through a shared firewall proxy. through a shared firewall proxy.
2.3. Caches 2.3. Caches
Any party to HTTP communication that is not acting as a tunnel may A "cache" is a local store of previous response messages and the
employ an internal cache for handling requests. A cache is a local subsystem that controls its message storage, retrieval, and deletion.
store of previous response messages and the subsystem that controls A cache stores cacheable responses in order to reduce the response
its message storage, retrieval, and deletion. A cache stores time and network bandwidth consumption on future, equivalent
cacheable responses in order to reduce the response time and network requests. Any client or server MAY employ a cache, though a cache
bandwidth consumption on future, equivalent requests. Any client or cannot be used by a server while it is acting as a tunnel.
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 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
applicable to that request. The following illustrates the resulting applicable to that request. The following illustrates the resulting
chain if B has a cached copy of an earlier response from O (via C) 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. for a request which has not been cached by UA or A.
request chain ----------> > >
UA -----v----- A -----v----- B - - - - - - C - - - - - - O UA =========== A =========== B - - - - - - C - - - - - - O
<--------- response chain < <
A response is cacheable if a cache is allowed to store a copy of the A response is "cacheable" if a cache is allowed to store a copy of
response message for use in answering subsequent requests. Even when the response message for use in answering subsequent requests. Even
a response is cacheable, there may be additional constraints placed when a response is cacheable, there might be additional constraints
by the client or by the origin server on when that cached response placed by the client or by the origin server on when that cached
can be used for a particular request. HTTP requirements for cache response can be used for a particular request. HTTP requirements for
behavior and cacheable responses are defined in Section 2 of [Part6]. cache behavior and cacheable responses are defined in Section 2 of
[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.4. Transport Independence 2.4. Transport Independence
skipping to change at page 14, line 47 skipping to change at page 14, line 38
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 might be used
one or more request/response exchanges, although connections may be for one or more request/response exchanges, although connections
closed for a variety of reasons (see Section 7.1). might be closed for a variety of reasons (see Section 7.1).
2.5. HTTP Version 2.5. 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
algorithm, but which may add to the message semantics and imply algorithm, but which might add to the message semantics and imply
additional capabilities of the sender. The <major> number is additional capabilities of the sender. The <major> number is
incremented when the format of a message within the protocol is incremented when the format of a message within the protocol is
changed. See [RFC2145] for a fuller explanation. changed. See [RFC2145] for a fuller explanation.
The version of an HTTP message is indicated by an HTTP-Version field The version of an HTTP message is indicated by an HTTP-Version field
in the first line of the message. 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 "/" 1*DIGIT "." 1*DIGIT
HTTP-Prot-Name = %x48.54.54.50 ; "HTTP", case-sensitive HTTP-Prot-Name = %x48.54.54.50 ; "HTTP", case-sensitive
skipping to change at page 16, line 11 skipping to change at page 15, line 47
version request is received, the proxy/gateway MUST either downgrade version request is received, the proxy/gateway MUST either downgrade
the request version, or respond with an error, or switch to tunnel the request version, or respond with an error, or switch to tunnel
behavior. behavior.
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 might involve
of header fields required or forbidden by the versions involved. modification of header fields required or forbidden by the
versions involved.
2.6. Uniform Resource Identifiers 2.6. 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 may 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",
"absolute-URI", "relative-part", "port", "host", "path-abempty", "absolute-URI", "relative-part", "port", "host", "path-abempty",
"path-absolute", "query", and "authority" from [RFC3986]. In "path-absolute", "query", and "authority" from [RFC3986]. In
addition, we define a partial-URI rule for protocol elements that addition, we define a partial-URI rule for protocol elements that
allow a relative URI without a fragment. allow a relative URI without a fragment.
skipping to change at page 17, line 30 skipping to change at page 17, line 17
IPv4 address, then the HTTP server is any listener on the indicated 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 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 name is considered an indirect identifier and the recipient might use
a name resolution service, such as DNS, to find the address of a 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 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. 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 If the port subcomponent is empty or not given, then TCP port 80 is
assumed (the default reserved port for WWW services). assumed (the default reserved port for WWW services).
Regardless of the form of host identifier, access to that host is not Regardless of the form of host identifier, access to that host is not
implied by the mere presence of its name or address. The host may or implied by the mere presence of its name or address. The host might
may not exist and, even when it does exist, may or may not be running or might not exist and, even when it does exist, might or might not
an HTTP server or listening to the indicated port. The "http" URI be running an HTTP server or listening to the indicated port. The
scheme makes use of the delegated nature of Internet names and "http" URI scheme makes use of the delegated nature of Internet names
addresses to establish a naming authority (whatever entity has the and addresses to establish a naming authority (whatever entity has
ability to place an HTTP server at that Internet name or address) and the ability to place an HTTP server at that Internet name or address)
allows that authority to determine which names are valid and how they and allows that authority to determine which names are valid and how
might be used. they might be used.
When an "http" URI is used within a context that calls for access to When an "http" URI is used within a context that calls for access to
the indicated resource, a client MAY attempt access by resolving the the indicated resource, a client MAY attempt access by resolving the
host to an IP address, establishing a TCP connection to that address host to an IP address, establishing a TCP connection to that address
on the indicated port, and sending an HTTP request message to the on the indicated port, and sending an HTTP request message to the
server containing the URI's identifying data as described in server containing the URI's identifying data as described in
Section 4. If the server responds to that request with a non-interim Section 4. If the server responds to that request with a non-interim
HTTP response message, as described in Section 5, then that response HTTP response message, as described in Section 5, then that response
is considered an authoritative answer to the client's request. is considered an authoritative answer to the client's request.
Although HTTP is independent of the transport protocol, the "http" Although HTTP is independent of the transport protocol, the "http"
scheme is specific to TCP-based services because the name delegation scheme is specific to TCP-based services because the name delegation
process depends on TCP for establishing authority. An HTTP service process depends on TCP for establishing authority. An HTTP service
based on some other underlying connection protocol would presumably based on some other underlying connection protocol would presumably
be identified using a different URI scheme, just as the "https" be identified using a different URI scheme, just as the "https"
scheme (below) is used for servers that require an SSL/TLS transport scheme (below) is used for servers that require an SSL/TLS transport
layer on a connection. Other protocols may also be used to provide layer on a connection. Other protocols might also be used to provide
access to "http" identified resources --- it is only the access to "http" identified resources --- it is only the
authoritative interface used for mapping the namespace that is authoritative interface used for mapping the namespace that is
specific to TCP. specific to TCP.
The URI generic syntax for authority also includes a deprecated
userinfo subcomponent ([RFC3986], Section 3.2.1) for including user
authentication information in the URI. The userinfo subcomponent
(and its "@" delimiter) MUST NOT be used in an "http" URI. URI
reference recipients SHOULD parse for the existence of userinfo and
treat its presence as an error, likely indicating that the deprecated
subcomponent is being used to obscure the authority for the sake of
phishing attacks.
2.6.2. https URI scheme 2.6.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. The host and port SSL/TLS-secured connections on a given TCP 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 All of the requirements listed above for the "http" scheme are also
empty or not given. 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
the TCP connection MUST be secured for privacy through the use of
strong encryption prior to sending the first HTTP request.
https-URI = "https:" "//" authority path-abempty [ "?" query ] https-URI = "https:" "//" authority path-abempty [ "?" query ]
The primary difference between the "http" and "https" schemes is that Unlike the "http" scheme, responses to "https" identified requests
interaction with the latter is required to be secured for privacy are never "public" and thus are ineligible for shared caching. Their
through the use of strong encryption. The URI cannot be sent in a default is "private" and might be further constrained via use of the
request until the connection is secure. Likewise, the default for Cache-Control header field.
caching is that each response that would be considered "public" under
the "http" scheme is instead treated as "private" and thus not Resources made available via the "https" scheme have no shared
eligible for shared caching. identity with the "http" scheme even if their resource identifiers
only differ by the single "s" in the scheme name. They are different
services governed by different authorities. However, some extensions
to HTTP that apply to entire host domains, such as the Cookie
protocol, do allow one service to effect communication with the other
services based on host domain matching.
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.6.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.
skipping to change at page 19, line 30 skipping to change at page 19, line 33
All HTTP/1.1 messages consist of a start-line followed by a sequence 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 of characters in a format similar to the Internet Message Format
[RFC5322]: zero or more header fields (collectively referred to as [RFC5322]: zero or more header fields (collectively referred to as
the "headers" or the "header section"), an empty line indicating the the "headers" or the "header section"), an empty line indicating the
end of the header section, and an optional message-body. end of the header section, and an optional message-body.
An HTTP message can either be a request from client to server or a An HTTP message can either be a request from client to server or a
response from server to client. Syntactically, the two types of response from server to client. Syntactically, the two types of
message differ only in the start-line, which is either a Request-Line message differ only in the start-line, which is either a Request-Line
(for requests) or a Status-Line (for responses), and in the algorithm (for requests) or a Status-Line (for responses), and in the algorithm
for determining the length of the message-body (Section 3.4). In for determining the length of the message-body (Section 3.3). In
theory, a client could receive requests and a server could receive theory, a client could receive requests and a server could receive
responses, distinguishing them by their different start-line formats, responses, distinguishing them by their different start-line formats,
but in practice servers are implemented to only expect a request (a but in practice servers are implemented to only expect a request (a
response is interpreted as an unknown or invalid request method) and response is interpreted as an unknown or invalid request method) and
clients are implemented to only expect a response. clients are implemented to only expect a response.
HTTP-message = start-line HTTP-message = start-line
*( header-field CRLF ) *( header-field CRLF )
CRLF CRLF
[ message-body ] [ message-body ]
start-line = Request-Line / Status-Line start-line = Request-Line / Status-Line
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 might result in security issues when implementations within the
chain interpret the same message differently. HTTP/1.1 servers MUST request chain interpret the same message differently. HTTP/1.1
reject such a message with a 400 (Bad Request) response. servers MUST reject such a message with a 400 (Bad Request) response.
3.1. Message Parsing Robustness 3.1. Message Parsing Robustness
In the interest of robustness, servers SHOULD ignore at least one In the interest of robustness, servers SHOULD ignore at least one
empty line received where a Request-Line is expected. In other empty line received where a Request-Line is expected. In other
words, if the server is reading the protocol stream at the beginning 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. of a message and receives a CRLF first, it SHOULD ignore the CRLF.
Some old HTTP/1.0 client implementations generate an extra CRLF after Some old HTTP/1.0 client implementations generate an extra CRLF after
a POST request as a lame workaround for some early server a POST request as a lame workaround for some early server
applications that failed to read message-body content that was not 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 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 follow a request with an extra CRLF. If terminating the request
message-body with a line-ending is desired, then the client MUST message-body with a line-ending is desired, then the client MUST
include the terminating CRLF octets as part of the message-body include the terminating CRLF octets as part of the message-body
length. length.
The normal procedure for parsing an HTTP message is to read the 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 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 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 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 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. equal to the message-body length is read or the connection is closed.
Care must be taken to parse an HTTP message as a sequence of OCTETs 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 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 HTTP as a stream of Unicode characters in a character encoding like
UTF-16 may introduce security flaws due to the differing ways that UTF-16 might introduce security flaws due to the differing ways that
such parsers interpret invalid characters. such parsers interpret invalid characters.
HTTP allows the set of defined header fields to be extended without
changing the protocol version (see Section 10.1). However, such
fields might not be recognized by a downstream recipient and might be
stripped by non-transparent intermediaries. Unrecognized header
fields MUST be forwarded by transparent proxies and SHOULD be ignored
by a recipient.
3.2. Header Fields 3.2. Header Fields
Each HTTP header field consists of a case-insensitive field name Each HTTP header field consists of a case-insensitive field name
followed by a colon (":"), optional whitespace, and the field value. followed by a colon (":"), optional whitespace, and the field value.
header-field = field-name ":" OWS [ field-value ] OWS 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 )
skipping to change at page 22, line 28 skipping to change at page 22, line 37
quoted-cpair = "\" ( WSP / VCHAR / obs-text ) quoted-cpair = "\" ( WSP / VCHAR / obs-text )
Producers SHOULD NOT escape characters that do not require escaping Producers SHOULD NOT escape characters that do not require escaping
(i.e., other than the backslash character "\" and the parentheses "(" (i.e., other than the backslash character "\" and the parentheses "("
and ")"). and ")").
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
entity-body associated with the request or response. The message- payload body associated with the request or response.
body differs from the entity-body only when a transfer-coding has
been applied, as indicated by the Transfer-Encoding header field
(Section 9.7).
message-body = entity-body message-body = *OCTET
/ <entity-body encoded as per Transfer-Encoding>
Transfer-Encoding MUST be used to indicate any transfer-codings The message-body differs from the payload body only when a transfer-
applied by an application to ensure safe and proper transfer of the coding has been applied, as indicated by the Transfer-Encoding header
message. Transfer-Encoding is a property of the message, not of the field (Section 9.7). When one or more transfer-codings are applied
entity, and thus MAY be added or removed by any application along the to a payload in order to form the message-body, the Transfer-Encoding
request/response chain. (However, Section 6.2 places restrictions on header field MUST contain the list of transfer-codings applied.
when certain transfer-codings may be used.) Transfer-Encoding is a property of the message, not of the payload,
and thus MAY be added or removed by any implementation along the
request/response chain under the constraints found in Section 6.2.
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 header fields. When a request message contains both a the request's header fields, even if the request method does not
message-body of non-zero length and a method that does not define any define any use for a message-body. This allows the request message
semantics for that request message-body, then an origin server SHOULD framing algorithm to be independent of method semantics.
either ignore the message-body or respond with an appropriate error
message (e.g., 413). A proxy or gateway, when presented the same
request, SHOULD either forward the request inbound with the message-
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 5.1.1). All responses to the HEAD request status code (Section 5.1.1). Responses to the HEAD request method
method MUST NOT include a message-body, even though the presence of never include a message-body because the associated response header
entity-header fields might lead one to believe they do. All 1xx fields (e.g., Transfer-Encoding, Content-Length, etc.) only indicate
(Informational), 204 (No Content), and 304 (Not Modified) responses what their values would have been if the method had been GET. All
MUST NOT include a message-body. All other responses do include a 1xx (Informational), 204 (No Content), and 304 (Not Modified)
message-body, although it MAY be of zero length. responses MUST NOT include a message-body. All other responses do
include a message-body, although the body MAY be of zero length.
3.4. Message Length
The transfer-length of a message is the length of the message-body as The length of the message-body is determined by one of the following
it appears in the message; that is, after any transfer-codings have
been applied. When a message-body is included with a message, the
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 to a HEAD request and any response with a status
(such as the 1xx, 204, and 304 responses and any response to a code of 100-199, 204, or 304 is always terminated by the first
HEAD request) is always terminated by the first empty line after empty line after the header fields, regardless of the header
the header fields, regardless of the entity-header fields present fields present in the message, and thus cannot contain a message-
in the message. body.
2. If a Transfer-Encoding header field (Section 9.7) is present and 2. If a Transfer-Encoding header field (Section 9.7) is present and
the "chunked" transfer-coding (Section 6.2) is used, the the "chunked" transfer-coding (Section 6.2) is the final
transfer-length is defined by the use of this transfer-coding. encoding, the message-body length is determined by reading and
If a Transfer-Encoding header field is present and the "chunked" decoding the chunked data until the transfer-coding indicates the
transfer-coding is not present, the transfer-length is defined by data is complete.
the sender closing the connection.
3. If a Content-Length header field (Section 9.2) is present, its If a Transfer-Encoding header field is present in a response and
value in OCTETs represents both the entity-length and the the "chunked" transfer-coding is not the final encoding, the
transfer-length. The Content-Length header field MUST NOT be message-body length is determined by reading the connection until
sent if these two lengths are different (i.e., if a Transfer- it is closed by the server. If a Transfer-Encoding header field
Encoding header field is present). If a message is received with is present in a request and the "chunked" transfer-coding is not
both a Transfer-Encoding header field and a Content-Length header the final encoding, the message-body length cannot be determined
field, the latter MUST be ignored. reliably; the server MUST respond with the 400 (Bad Request)
status code and then close the connection.
4. If the message uses the media type "multipart/byteranges", and If a message is received with both a Transfer-Encoding header
the transfer-length is not otherwise specified, then this self- field and a Content-Length header field, the Transfer-Encoding
delimiting media type defines the transfer-length. This media overrides the Content-Length. Such a message might indicate an
type MUST NOT be used unless the sender knows that the recipient attempt to perform request or response smuggling (bypass of
can parse it; the presence in a request of a Range header with security-related checks on message routing or content) and thus
multiple byte-range specifiers from a HTTP/1.1 client implies ought to be handled as an error. The provided Content-Length
that the client can parse multipart/byteranges responses. MUST be removed, prior to forwarding the message downstream, or
replaced with the real message-body length after the transfer-
coding is decoded.
A range header might be forwarded by a HTTP/1.0 proxy that 3. If a message is received without Transfer-Encoding and with
does not understand multipart/byteranges; in this case the either multiple Content-Length header fields or a single Content-
server MUST delimit the message using methods defined in items Length header field with an invalid value, then the message
1, 3 or 5 of this section. framing is invalid and MUST be treated as an error to prevent
request or response smuggling. If this is a request message, the
server MUST respond with a 400 (Bad Request) status code and then
close the connection. If this is a response message received by
a proxy or gateway, the proxy or gateway MUST discard the
received response, send a 502 (Bad Gateway) status code as its
downstream response, and then close the connection. If this is a
response message received by a user-agent, the message-body
length is determined by reading the connection until it is
closed; an error SHOULD be indicated to the user.
5. By the server closing the connection. (Closing the connection 4. If a valid Content-Length header field (Section 9.2) is present
cannot be used to indicate the end of a request body, since that without Transfer-Encoding, its decimal value defines the message-
would leave no possibility for the server to send back a body length in octets. If the actual number of octets sent in
response.) the message is less than the indicated Content-Length, the
recipient MUST consider the message to be incomplete and treat
the connection as no longer usable. If the actual number of
octets sent in the message is more than the indicated Content-
Length, the recipient MUST only process the message-body up to
the field value's number of octets; the remainder of the message
MUST either be discarded or treated as the next message in a
pipeline. For the sake of robustness, a user-agent MAY attempt
to detect and correct such an error in message framing if it is
parsing the response to the last request on on a connection and
the connection has been closed by the server.
For compatibility with HTTP/1.0 applications, HTTP/1.1 requests 5. If this is a request message and none of the above are true, then
containing a message-body MUST include a valid Content-Length header the message-body length is zero (no message-body is present).
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,
the server SHOULD respond with 400 (Bad Request) if it cannot
determine the length of the message, or with 411 (Length Required) if
it wishes to insist on receiving a valid Content-Length.
All HTTP/1.1 applications that receive entities MUST accept the 6. Otherwise, this is a response message without a declared message-
"chunked" transfer-coding (Section 6.2), thus allowing this mechanism body length, so the message-body length is determined by the
to be used for messages when the message length cannot be determined number of octets received prior to the server closing the
in advance. connection.
Messages MUST NOT include both a Content-Length header field and a Since there is no way to distinguish a successfully completed, close-
transfer-coding. If the message does include a transfer-coding, the delimited message from a partially-received message interrupted by
Content-Length MUST be ignored. network failure, implementations SHOULD use encoding or length-
delimited messages whenever possible. The close-delimiting feature
exists primarily for backwards compatibility with HTTP/1.0.
When a Content-Length is given in a message where a message-body is A server MAY reject a request that contains a message-body but not a
allowed, its field value MUST exactly match the number of OCTETs in Content-Length by responding with 411 (Length Required).
the message-body. HTTP/1.1 user agents MUST notify the user when an
invalid length is received and detected.
3.5. General Header Fields Unless a transfer-coding other than "chunked" has been applied, a
client that sends a request containing a message-body SHOULD use a
valid Content-Length header field if the message-body length is known
in advance, rather than the "chunked" encoding, since some existing
services respond to "chunked" with a 411 (Length Required) status
code even though they understand the chunked encoding. This is
typically because such services are implemented via a gateway that
requires a content-length in advance of being called and the server
is unable or unwilling to buffer the entire request before
processing.
A client that sends a request containing a message-body MUST include
a valid Content-Length header field if it does not know the server
will handle HTTP/1.1 (or later) requests; such knowledge can be in
the form of specific user configuration or by remembering the version
of a prior received response.
Request messages that are prematurely terminated, possibly due to a
cancelled connection or a server-imposed time-out exception, MUST
result in closure of the connection; sending an HTTP/1.1 error
response prior to closing the connection is OPTIONAL. Response
messages that are prematurely terminated, usually by closure of the
connection prior to receiving the expected number of octets or by
failure to decode a transfer-encoded message-body, MUST be recorded
as incomplete. A user agent MUST NOT render an incomplete response
message-body as if it were complete (i.e., some indication must be
given to the user that an error occurred). Cache requirements for
incomplete responses are defined in Section 2.1.1 of [Part6].
A server MUST read the entire request message-body or close the
connection after sending its response, since otherwise the remaining
data on a persistent connection would be misinterpreted as the next
request. Likewise, a client MUST read the entire response message-
body if it intends to reuse the same connection for a subsequent
request. Pipelining multiple requests on a connection is described
in Section 7.1.2.2.
3.4. 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 payload 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 9.1 / Connection ; Section 9.1
/ Date ; Section 9.3 / Date ; Section 9.3
/ Pragma ; [Part6], Section 3.4 / Pragma ; [Part6], Section 3.4
/ Trailer ; Section 9.6 / Trailer ; Section 9.6
/ Transfer-Encoding ; Section 9.7 / Transfer-Encoding ; Section 9.7
/ Upgrade ; Section 9.8 / Upgrade ; Section 9.8
/ Via ; Section 9.9 / Via ; Section 9.9
/ Warning ; [Part6], Section 3.6 / Warning ; [Part6], Section 3.6
/ MIME-Version ; [Part3], Appendix A.1
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 might 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.
entity-header fields.
4. 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 4.1 Request = Request-Line ; Section 4.1
*(( general-header ; Section 3.5 *( header-field CRLF ) ; Section 3.2
/ request-header ; [Part2], Section 3
/ entity-header ) CRLF ) ; [Part3], Section 3.1
CRLF CRLF
[ message-body ] ; Section 3.3 [ message-body ] ; Section 3.3
4.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.
skipping to change at page 27, line 42 skipping to change at page 28, line 42
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
"/" or "*". "/" or "*".
Note: The "no rewrite" rule prevents the proxy from changing the Note: The "no rewrite" rule prevents the proxy from changing the
meaning of the request when the origin server is improperly using meaning of the request when the origin server is improperly using
a non-reserved URI character for a reserved purpose. Implementors a non-reserved URI character for a reserved purpose. Implementors
should be aware that some pre-HTTP/1.1 proxies have been known to need to be aware that some pre-HTTP/1.1 proxies have been known to
rewrite the request-target. rewrite the request-target.
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 code if the
request-target would be longer than the server wishes to handle (see received request-target would be longer than the server wishes to
Section 8.4.15 of [Part2]). handle (see 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.
Note: Fragments ([RFC3986], Section 3.5) are not part of the Note: Fragments ([RFC3986], Section 3.5) are not part of the
request-target and thus will not be transmitted in an HTTP request-target and thus will not be transmitted in an HTTP
request. request.
4.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.
skipping to change at page 28, line 45 skipping to change at page 29, line 45
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.
4.3. Effective Request URI 4.3. Effective Request URI
HTTP requests often do not carry the absolute URI ([RFC3986], Section HTTP requests often do not carry the absolute URI ([RFC3986], Section
4.3) for the resource they are intended for; instead, the value needs 4.3) for the target resource; instead, the URI needs to be inferred
to be inferred from the request-target, Host header and other from the request-target, Host header field, and connection context.
context. The result of this process is the "Effective Request URI". The result of this process is called the "effective request URI".
The "target resource" is the resource identified by the effective
request URI.
If the request-target is an absolute-URI, then the Effective Request If the request-target is an absolute-URI, then the effective request
URI is the request-target. URI is the request-target.
If the request-target uses the path-absolute (plus optional query) If the request-target uses the path-absolute (plus optional query)
syntax or if it is just the asterisk "*", then the Effective Request syntax or if it is just the asterisk "*", then the effective request
URI is constructed by concatenating URI is constructed by concatenating
o the scheme name: "http" if the request was received over an o the scheme name: "http" if the request was received over an
insecure TCP connection, or "https" when received over SSL/ insecure TCP connection, or "https" when received over a SSL/
TLS-secured TCP connection, TLS-secured TCP connection,
o the character sequence "://", o the character sequence "://",
o the authority component, as specified in the Host header o the authority component, as specified in the Host header
(Section 9.4) and determined by the rules in Section 4.2, (Section 9.4) and determined by the rules in Section 4.2,
[[effrequri-nohost: Do we need to include the handling of missing [[effrequri-nohost: Do we need to include the handling of missing
hosts in HTTP/1.0 messages, as described in Section 4.2? --jre]] hosts in HTTP/1.0 messages, as described in Section 4.2? -- See
and <http://tools.ietf.org/wg/httpbis/trac/ticket/221> --jre]] and
o the request-target obtained from the Request-Line, unless the o the request-target obtained from the Request-Line, unless the
request-target is just the asterisk "*". request-target is just the asterisk "*".
Otherwise, when request-target uses the authority form, the Effective Otherwise, when request-target uses the authority form, the effective
Request URI is undefined. Request URI is undefined.
Example 1: the Effective Request URI for the message Example 1: the effective request URI for the message
GET /pub/WWW/TheProject.html HTTP/1.1 GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.example.org:8080 Host: www.example.org:8080
(received over an insecure TCP connection) is "http", plus "://", (received over an insecure TCP connection) is "http", plus "://",
plus the authority component "www.example.org:8080", plus the plus the authority component "www.example.org:8080", plus the
request-target "/pub/WWW/TheProject.html", thus request-target "/pub/WWW/TheProject.html", thus
"http://www.example.org:8080/pub/WWW/TheProject.html". "http://www.example.org:8080/pub/WWW/TheProject.html".
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.6.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
*(( general-header ; Section 3.5 *( header-field CRLF ) ; Section 3.2
/ response-header ; [Part2], Section 5
/ entity-header ) CRLF ) ; [Part3], Section 3.1
CRLF CRLF
[ message-body ] ; Section 3.3 [ message-body ] ; Section 3.3
5.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.
skipping to change at page 31, line 16 skipping to change at page 32, line 13
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. Protocol Parameters
6.1. Date/Time Formats: Full Date 6.1. Date/Time Formats: Full Date
HTTP applications have historically allowed three different formats HTTP applications have historically allowed three different formats
for the representation of date/time stamps. for date/time stamps. However, the preferred format is a fixed-
length subset of that defined by [RFC1123]:
The first format is preferred as an Internet standard and represents
a fixed-length subset of that defined by [RFC1123]:
Sun, 06 Nov 1994 08:49:37 GMT ; RFC 1123 Sun, 06 Nov 1994 08:49:37 GMT ; RFC 1123
The other formats are described here only for compatibility with The other formats are described here only for compatibility with
obsolete implementations. obsolete implementations.
Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format
Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
HTTP/1.1 clients and servers that parse the date value MUST accept HTTP/1.1 clients and servers that parse a date value MUST accept all
all three formats (for compatibility with HTTP/1.0), though they MUST three formats (for compatibility with HTTP/1.0), though they MUST
only generate the RFC 1123 format for representing HTTP-date values only generate the RFC 1123 format for representing HTTP-date values
in header fields. See Appendix A for further information. in header fields. See Appendix A for further information.
All HTTP date/time stamps MUST be represented in Greenwich Mean Time All HTTP date/time stamps MUST be represented in Greenwich Mean Time
(GMT), without exception. For the purposes of HTTP, GMT is exactly (GMT), without exception. For the purposes of HTTP, GMT is exactly
equal to UTC (Coordinated Universal Time). This is indicated in the equal to UTC (Coordinated Universal Time). This is indicated in the
first two formats by the inclusion of "GMT" as the three-letter first two formats by the inclusion of "GMT" as the three-letter
abbreviation for time zone, and MUST be assumed when reading the abbreviation for time zone, and MUST be assumed when reading the
asctime format. HTTP-date is case sensitive and MUST NOT include asctime format. HTTP-date is case sensitive and MUST NOT include
additional whitespace beyond that specifically included as SP in the additional whitespace beyond that specifically included as SP in the
skipping to change at page 33, line 21 skipping to change at page 34, line 21
/ %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive / %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive
/ %x46.72.69.64.61.79 ; "Friday", case-sensitive / %x46.72.69.64.61.79 ; "Friday", case-sensitive
/ %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive / %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive
/ %x53.75.6E.64.61.79 ; "Sunday", case-sensitive / %x53.75.6E.64.61.79 ; "Sunday", case-sensitive
asctime-date = day-name SP date3 SP time-of-day SP year asctime-date = day-name SP date3 SP time-of-day SP year
date3 = month SP ( 2DIGIT / ( SP 1DIGIT )) date3 = month SP ( 2DIGIT / ( SP 1DIGIT ))
; month day (e.g., Jun 2) ; month day (e.g., Jun 2)
Note: Recipients of date values are encouraged to be robust in Note: Recipients of date values are encouraged to be robust in
accepting date values that may have been sent by non-HTTP accepting date values that might have been sent by non-HTTP
applications, as is sometimes the case when retrieving or posting applications, as is sometimes the case when retrieving or posting
messages via proxies/gateways to SMTP or NNTP. messages via proxies/gateways to SMTP or NNTP.
Note: HTTP requirements for the date/time stamp format apply only Note: HTTP requirements for the date/time stamp format apply only
to their usage within the protocol stream. Clients and servers to their usage within the protocol stream. Clients and servers
are not required to use these formats for user presentation, are not required to use these formats for user presentation,
request logging, etc. request logging, etc.
6.2. Transfer Codings 6.2. Transfer Codings
Transfer-coding values are used to indicate an encoding Transfer-coding values are used to indicate an encoding
transformation that has been, can be, or may need to be applied to an transformation that has been, can be, or might need to be applied to
entity-body in order to ensure "safe transport" through the network. a payload body in order to ensure "safe transport" through the
This differs from a content coding in that the transfer-coding is a network. This differs from a content coding in that the transfer-
property of the message, not of the original entity. coding is a property of the message rather than a property of the
representation that is being transferred.
transfer-coding = "chunked" ; Section 6.2.1 transfer-coding = "chunked" ; Section 6.2.1
/ "compress" ; Section 6.2.2.1 / "compress" ; Section 6.2.2.1
/ "deflate" ; Section 6.2.2.2 / "deflate" ; Section 6.2.2.2
/ "gzip" ; Section 6.2.2.3 / "gzip" ; Section 6.2.2.3
/ transfer-extension / transfer-extension
transfer-extension = token *( OWS ";" OWS transfer-parameter ) transfer-extension = token *( OWS ";" OWS transfer-parameter )
Parameters are in the form of attribute/value pairs. Parameters are in the form of attribute/value pairs.
transfer-parameter = attribute BWS "=" BWS value transfer-parameter = attribute BWS "=" BWS value
attribute = token attribute = token
value = word value = word
All transfer-coding values are case-insensitive. HTTP/1.1 uses All transfer-coding values are case-insensitive. HTTP/1.1 uses
transfer-coding values in the TE header field (Section 9.5) and in transfer-coding values in the TE header field (Section 9.5) and in
the Transfer-Encoding header field (Section 9.7). 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 Transfer-codings are analogous to the Content-Transfer-Encoding
values of MIME, which were designed to enable safe transport of values of MIME, which were designed to enable safe transport of
binary data over a 7-bit transport service ([RFC2045], Section 6). binary data over a 7-bit transport service ([RFC2045], Section 6).
However, safe transport has a different focus for an 8bit-clean However, safe transport has a different focus for an 8bit-clean
transfer protocol. In HTTP, the only unsafe characteristic of transfer protocol. In HTTP, the only unsafe characteristic of
message-bodies is the difficulty in determining the exact body length message-bodies is the difficulty in determining the exact message
(Section 3.4), or the desire to encrypt data over a shared transport. body length (Section 3.3), or the desire to encrypt data over a
shared transport.
A server which receives an entity-body with a transfer-coding it does A server that receives a request message with a transfer-coding it
not understand SHOULD return 501 (Not Implemented), and close the does not understand SHOULD respond with 501 (Not Implemented) and
connection. A server MUST NOT send transfer-codings to an HTTP/1.0 then close the connection. A server MUST NOT send transfer-codings
client. to an HTTP/1.0 client.
6.2.1. Chunked Transfer Coding 6.2.1. Chunked Transfer Coding
The chunked encoding modifies the body of a message in order to The chunked encoding modifies the body of a message in order to
transfer it as a series of chunks, each with its own size indicator, transfer it as a series of chunks, each with its own size indicator,
followed by an OPTIONAL trailer containing entity-header fields. followed by an OPTIONAL trailer containing header fields. This
This allows dynamically produced content to be transferred along with allows dynamically produced content to be transferred along with the
the information necessary for the recipient to verify that it has information necessary for the recipient to verify that it has
received the full message. received the full message.
Chunked-Body = *chunk Chunked-Body = *chunk
last-chunk last-chunk
trailer-part trailer-part
CRLF CRLF
chunk = chunk-size *WSP [ chunk-ext ] CRLF chunk = chunk-size *WSP [ chunk-ext ] CRLF
chunk-data CRLF chunk-data CRLF
chunk-size = 1*HEXDIG chunk-size = 1*HEXDIG
last-chunk = 1*("0") *WSP [ chunk-ext ] CRLF last-chunk = 1*("0") *WSP [ chunk-ext ] CRLF
chunk-ext = *( ";" *WSP chunk-ext-name chunk-ext = *( ";" *WSP chunk-ext-name
[ "=" chunk-ext-val ] *WSP ) [ "=" chunk-ext-val ] *WSP )
chunk-ext-name = token chunk-ext-name = token
chunk-ext-val = token / quoted-str-nf chunk-ext-val = token / quoted-str-nf
chunk-data = 1*OCTET ; a sequence of chunk-size octets chunk-data = 1*OCTET ; a sequence of chunk-size octets
trailer-part = *( entity-header CRLF ) trailer-part = *( header-field CRLF )
quoted-str-nf = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE quoted-str-nf = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE
; like quoted-string, but disallowing line folding ; like quoted-string, but disallowing line folding
qdtext-nf = WSP / %x21 / %x23-5B / %x5D-7E / obs-text qdtext-nf = WSP / %x21 / %x23-5B / %x5D-7E / obs-text
; WSP / <VCHAR except DQUOTE and "\"> / 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-size field is a string of hex digits indicating the size of
the chunk-data in octets. The chunked encoding is ended by any chunk the chunk-data in octets. The chunked encoding is ended by any chunk
whose size is zero, followed by the trailer, which is terminated by whose size is zero, followed by the trailer, which is terminated by
an empty line. an empty line.
skipping to change at page 36, line 18 skipping to change at page 37, line 9
compliance with the protocol would have necessitated a possibly compliance with the protocol would have necessitated a possibly
infinite buffer on the proxy. infinite buffer on the proxy.
A process for decoding the "chunked" transfer-coding can be A process for decoding the "chunked" transfer-coding can be
represented in pseudo-code as: represented in pseudo-code as:
length := 0 length := 0
read chunk-size, chunk-ext (if any) and CRLF read chunk-size, chunk-ext (if any) and CRLF
while (chunk-size > 0) { while (chunk-size > 0) {
read chunk-data and CRLF read chunk-data and CRLF
append chunk-data to entity-body append chunk-data to decoded-body
length := length + chunk-size length := length + chunk-size
read chunk-size and CRLF read chunk-size and CRLF
} }
read entity-header read header-field
while (entity-header not empty) { while (header-field not empty) {
append entity-header to existing header fields append header-field to existing header fields
read entity-header read header-field
} }
Content-Length := length Content-Length := length
Remove "chunked" from Transfer-Encoding Remove "chunked" from Transfer-Encoding
All HTTP/1.1 applications MUST be able to receive and decode the All HTTP/1.1 applications MUST be able to receive and decode the
"chunked" transfer-coding, and MUST ignore chunk-ext extensions they "chunked" transfer-coding and MUST ignore chunk-ext extensions they
do not understand. do not understand.
Since "chunked" is the only transfer-coding required to be understood
by HTTP/1.1 recipients, it plays a crucial role in delimiting
messages on a persistent connection. Whenever a transfer-coding is
applied to a payload body in a request, the final transfer-coding
applied MUST be "chunked". If a transfer-coding is applied to a
response payload body, then either the final transfer-coding applied
MUST be "chunked" or the message MUST be terminated by closing the
connection. When the "chunked" transfer-coding is used, it MUST be
the last transfer-coding applied to form the message-body. The
"chunked" transfer-coding MUST NOT be applied more than once in a
message-body.
6.2.2. Compression Codings 6.2.2. Compression Codings
The codings defined below can be used to compress the payload of a The codings defined below can be used to compress the payload of a
message. message.
Note: Use of program names for the identification of encoding Note: Use of program names for the identification of encoding
formats is not desirable and is discouraged for future encodings. formats is not desirable and is discouraged for future encodings.
Their use here is representative of historical practice, not good Their use here is representative of historical practice, not good
design. design.
skipping to change at page 37, line 38 skipping to change at page 38, line 44
o Description o Description
o Pointer to specification text o Pointer to specification text
Names of transfer codings MUST NOT overlap with names of content Names of transfer codings MUST NOT overlap with names of content
codings (Section 2.2 of [Part3]), unless the encoding transformation codings (Section 2.2 of [Part3]), unless the encoding transformation
is identical (as it is the case for the compression codings defined is identical (as it is the case for the compression codings defined
in Section 6.2.2). in Section 6.2.2).
Values to be added to this name space require expert review and a Values to be added to this name space require a specification (see
specification (see "Expert Review" and "Specification Required" in "Specification Required" in Section 4.1 of [RFC5226]), and MUST
Section 4.1 of [RFC5226]), and MUST conform to the purpose of conform to the purpose of transfer coding defined in this section.
transfer coding defined in this section.
The registry itself is maintained at The registry itself is maintained at
<http://www.iana.org/assignments/http-parameters>. <http://www.iana.org/assignments/http-parameters>.
6.3. Product Tokens 6.3. Product Tokens
Product tokens are used to allow communicating applications to Product tokens are used to allow communicating applications to
identify themselves by software name and version. Most fields using identify themselves by software name and version. Most fields using
product tokens also allow sub-products which form a significant part product tokens also allow sub-products which form a significant part
of the application to be listed, separated by whitespace. By of the application to be listed, separated by whitespace. By
skipping to change at page 38, line 24 skipping to change at page 39, line 32
Product tokens SHOULD be short and to the point. They MUST NOT be Product tokens SHOULD be short and to the point. They MUST NOT be
used for advertising or other non-essential information. Although used for advertising or other non-essential information. Although
any token character MAY appear in a product-version, this token any token character MAY appear in a product-version, this token
SHOULD only be used for a version identifier (i.e., successive SHOULD only be used for a version identifier (i.e., successive
versions of the same product SHOULD only differ in the product- versions of the same product SHOULD only differ in the product-
version portion of the product value). version portion of the product value).
6.4. Quality Values 6.4. Quality Values
Both transfer codings (TE request header, Section 9.5) and content Both transfer codings (TE request header, Section 9.5) and content
negotiation (Section 4 of [Part3]) use short "floating point" numbers negotiation (Section 5 of [Part3]) use short "floating point" numbers
to indicate the relative importance ("weight") of various negotiable to indicate the relative importance ("weight") of various negotiable
parameters. A weight is normalized to a real number in the range 0 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 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 parameter has a quality value of 0, then content with this parameter
is "not acceptable" for the client. HTTP/1.1 applications MUST NOT is "not acceptable" for the client. HTTP/1.1 applications MUST NOT
generate more than three digits after the decimal point. User generate more than three digits after the decimal point. User
configuration of these values SHOULD also be limited in this fashion. configuration of these values SHOULD also be limited in this fashion.
qvalue = ( "0" [ "." 0*3DIGIT ] ) qvalue = ( "0" [ "." 0*3DIGIT ] )
/ ( "1" [ "." 0*3("0") ] ) / ( "1" [ "." 0*3("0") ] )
skipping to change at page 40, line 32 skipping to change at page 41, line 38
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 3.4. of the connection), as described in Section 3.3.
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 41, line 5 skipping to change at page 42, line 11
such a retry, it MUST NOT pipeline before it knows the connection is such a retry, it MUST NOT pipeline before it knows the connection is
persistent. Clients MUST also be prepared to resend their requests persistent. Clients MUST also be prepared to resend their requests
if the server closes the connection before sending all of the if the server closes the connection before sending all of the
corresponding responses. corresponding responses.
Clients SHOULD NOT pipeline requests using non-idempotent methods or Clients SHOULD NOT pipeline requests using non-idempotent methods or
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 line 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 9.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
skipping to change at page 43, line 14 skipping to change at page 44, line 22
that does not include no-transform, but if it does so, it MUST add a that does not include no-transform, but if it does so, it MUST add a
Warning 214 (Transformation applied) if one does not already appear Warning 214 (Transformation applied) if one does not already appear
in the message (see Section 3.6 of [Part6]). in the message (see Section 3.6 of [Part6]).
Warning: Unnecessary modification of end-to-end headers might Warning: Unnecessary modification of end-to-end headers might
cause authentication failures if stronger authentication cause authentication failures if stronger authentication
mechanisms are introduced in later versions of HTTP. Such mechanisms are introduced in later versions of HTTP. Such
authentication mechanisms MAY rely on the values of header fields authentication mechanisms MAY rely on the values of header fields
not listed here. not listed here.
The Content-Length field of a request or response is added or deleted A transparent proxy MUST preserve the message payload ([Part3]),
according to the rules in Section 3.4. A transparent proxy MUST though it MAY change the message-body through application or removal
preserve the entity-length (Section 3.2.2 of [Part3]) of the entity- of a transfer-coding (Section 6.2).
body, although it MAY change the transfer-length (Section 3.4).
7.1.4. Practical Considerations 7.1.4. Practical Considerations
Servers will usually have some time-out value beyond which they will Servers will usually have some time-out value beyond which they will
no longer maintain an inactive connection. Proxy servers might make no longer maintain an inactive connection. Proxy servers might make
this a higher value since it is likely that the client will be making this a higher value since it is likely that the client will be making
more connections through the same server. The use of persistent more connections through the same server. The use of persistent
connections places no requirements on the length (or existence) of connections places no requirements on the length (or existence) of
this time-out for either the client or the server. this time-out for either the client or the server.
skipping to change at page 44, line 43 skipping to change at page 45, line 49
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 code while it is
the request. If the client sees an error status, it SHOULD transmitting the request. If the client sees an error status code,
immediately cease transmitting the body. If the body is being sent it SHOULD immediately cease transmitting the body. If the body is
using a "chunked" encoding (Section 6.2), a zero length chunk and being sent using a "chunked" encoding (Section 6.2), a zero length
empty trailer MAY be used to prematurely mark the end of the message. chunk and empty trailer MAY be used to prematurely mark the end of
If the body was preceded by a Content-Length header, the client MUST the message. If the body was preceded by a Content-Length header,
close the connection. the client MUST 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 code (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
the request body. In some cases, it might either be inappropriate or the request body. In some cases, it might either be inappropriate or
highly inefficient for the client to send the body if the server will highly inefficient for the client to send the body if the server will
reject the message without looking at the body. reject the message without looking at the body.
Requirements for HTTP/1.1 clients: Requirements for HTTP/1.1 clients:
o If a client will wait for a 100 (Continue) response before sending o If a client will wait for a 100 (Continue) response before sending
the request body, it MUST send an Expect request-header field the request body, it MUST send an Expect request-header field
(Section 9.2 of [Part2]) with the "100-continue" expectation. (Section 9.2 of [Part2]) with the "100-continue" expectation.
o A client MUST NOT send an Expect request-header field (Section 9.2 o A client MUST NOT send an Expect request-header field (Section 9.2
of [Part2]) with the "100-continue" expectation if it does not of [Part2]) with the "100-continue" expectation if it does not
intend to send a request body. intend to send a request body.
Because of the presence of older implementations, the protocol allows Because of the presence of older implementations, the protocol allows
ambiguous situations in which a client may send "Expect: 100- ambiguous situations in which a client might send "Expect: 100-
continue" without receiving either a 417 (Expectation Failed) status continue" without receiving either a 417 (Expectation Failed) or a
or a 100 (Continue) status. Therefore, when a client sends this 100 (Continue) status code. Therefore, when a client sends this
header field to an origin server (possibly via a proxy) from which it header field to an origin server (possibly via a proxy) from which it
has never seen a 100 (Continue) status, the client SHOULD NOT wait has never seen a 100 (Continue) status code, the client SHOULD NOT
for an indefinite period before sending the request body. wait for an indefinite period before sending the request body.
Requirements for HTTP/1.1 origin servers: Requirements for HTTP/1.1 origin servers:
o Upon receiving a request which includes an Expect request-header o Upon receiving a request which includes an Expect request-header
field with the "100-continue" expectation, an origin server MUST field with the "100-continue" expectation, an origin server MUST
either respond with 100 (Continue) status and continue to read either respond with 100 (Continue) status code and continue to
from the input stream, or respond with a final status code. The read from the input stream, or respond with a final status code.
origin server MUST NOT wait for the request body before sending The origin server MUST NOT wait for the request body before
the 100 (Continue) response. If it responds with a final status sending the 100 (Continue) response. If it responds with a final
code, it MAY close the transport connection or it MAY continue to status code, it MAY close the transport connection or it MAY
read and discard the rest of the request. It MUST NOT perform the continue to read and discard the rest of the request. It MUST NOT
requested method if it returns a final status code. perform the requested method if it returns a final status code.
o An origin server SHOULD NOT send a 100 (Continue) response if the o An origin server SHOULD NOT send a 100 (Continue) response if the
request message does not include an Expect request-header field request message does not include an Expect request-header field
with the "100-continue" expectation, and MUST NOT send a 100 with the "100-continue" expectation, and MUST NOT send a 100
(Continue) response if such a request comes from an HTTP/1.0 (or (Continue) response if such a request comes from an HTTP/1.0 (or
earlier) client. There is an exception to this rule: for earlier) client. There is an exception to this rule: for
compatibility with [RFC2068], a server MAY send a 100 (Continue) compatibility with [RFC2068], a server MAY send a 100 (Continue)
status in response to an HTTP/1.1 PUT or POST request that does status code in response to an HTTP/1.1 PUT or POST request that
not include an Expect request-header field with the "100-continue" does not include an Expect request-header field with the "100-
expectation. This exception, the purpose of which is to minimize continue" expectation. This exception, the purpose of which is to
any client processing delays associated with an undeclared wait minimize any client processing delays associated with an
for 100 (Continue) status, applies only to HTTP/1.1 requests, and undeclared wait for 100 (Continue) status code, applies only to
not to requests with any other HTTP-version value. HTTP/1.1 requests, and not to requests with any other HTTP-version
value.
o An origin server MAY omit a 100 (Continue) response if it has o An origin server MAY omit a 100 (Continue) response if it has
already received some or all of the request body for the already received some or all of the request body for the
corresponding request. corresponding request.
o An origin server that sends a 100 (Continue) response MUST o An origin server that sends a 100 (Continue) response MUST
ultimately send a final status code, once the request body is ultimately send a final status code, once the request body is
received and processed, unless it terminates the transport received and processed, unless it terminates the transport
connection prematurely. connection prematurely.
skipping to change at page 46, line 40 skipping to change at page 47, line 46
Requirements for HTTP/1.1 proxies: Requirements for HTTP/1.1 proxies:
o If a proxy receives a request that includes an Expect request- o If a proxy receives a request that includes an Expect request-
header field with the "100-continue" expectation, and the proxy header field with the "100-continue" expectation, and the proxy
either knows that the next-hop server complies with HTTP/1.1 or either knows that the next-hop server complies with HTTP/1.1 or
higher, or does not know the HTTP version of the next-hop server, higher, or does not know the HTTP version of the next-hop server,
it MUST forward the request, including the Expect header field. it MUST forward the request, including the Expect header field.
o If the proxy knows that the version of the next-hop server is o If the proxy knows that the version of the next-hop server is
HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST
respond with a 417 (Expectation Failed) status. respond with a 417 (Expectation Failed) status code.
o Proxies SHOULD maintain a cache recording the HTTP version numbers o Proxies SHOULD maintain a cache recording the HTTP version numbers
received from recently-referenced next-hop servers. received from recently-referenced next-hop servers.
o A proxy MUST NOT forward a 100 (Continue) response if the request o A proxy MUST NOT forward a 100 (Continue) response if the request
message was received from an HTTP/1.0 (or earlier) client and did message was received from an HTTP/1.0 (or earlier) client and did
not include an Expect request-header field with the "100-continue" not include an Expect request-header field with the "100-continue"
expectation. This requirement overrides the general rule for expectation. This requirement overrides the general rule for
forwarding of 1xx responses (see Section 8.1 of [Part2]). forwarding of 1xx responses (see Section 8.1 of [Part2]).
7.2.4. Client Behavior if Server Prematurely Closes Connection 7.2.4. Client Behavior if Server Prematurely Closes Connection
If an HTTP/1.1 client sends a request which includes a request body, If an HTTP/1.1 client sends a request which includes a request body,
but which does not include an Expect request-header field with the but which does not include an Expect request-header field with the
"100-continue" expectation, and if the client is not directly "100-continue" expectation, and if the client is not directly
connected to an HTTP/1.1 origin server, and if the client sees the connected to an HTTP/1.1 origin server, and if the client sees the
connection close before receiving any status from the server, the connection close before receiving a status line from the server, the
client SHOULD retry the request. If the client does retry this client SHOULD retry the request. If the client does retry this
request, it MAY use the following "binary exponential backoff" request, it MAY use the following "binary exponential backoff"
algorithm to be assured of obtaining a reliable response: algorithm to be assured of obtaining a reliable response:
1. Initiate a new connection to the server 1. Initiate a new connection to the server
2. Transmit the request-headers 2. Transmit the request-headers
3. Initialize a variable R to the estimated round-trip time to the 3. Initialize a variable R to the estimated round-trip time to the
server (e.g., based on the time it took to establish the server (e.g., based on the time it took to establish the
skipping to change at page 47, line 39 skipping to change at page 48, line 45
seconds (whichever comes first) seconds (whichever comes first)
6. If no error response is received, after T seconds transmit the 6. If no error response is received, after T seconds transmit the
body of the request. body of the request.
7. If client sees that the connection is closed prematurely, repeat 7. If client sees that the connection is closed prematurely, repeat
from step 1 until the request is accepted, an error response is from step 1 until the request is accepted, an error response is
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 code 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. Miscellaneous notes that may disappear 8. Miscellaneous notes that might disappear
8.1. Scheme aliases considered harmful 8.1. Scheme aliases considered harmful
[[TBD-aliases-harmful: describe why aliases like webcal are [[TBD-aliases-harmful: describe why aliases like webcal are
harmful.]] harmful.]]
8.2. Use of HTTP for proxy communication 8.2. Use of HTTP for proxy communication
[[TBD-proxy-other: Configured to use HTTP to proxy HTTP or other [[TBD-proxy-other: Configured to use HTTP to proxy HTTP or other
protocols.]] protocols.]]
skipping to change at page 48, line 30 skipping to change at page 49, line 37
8.5. Use of HTTP by media type specification 8.5. Use of HTTP by media type specification
[[TBD-hypertext: Instructions on composing HTTP requests via [[TBD-hypertext: Instructions on composing HTTP requests via
hypertext formats.]] hypertext formats.]]
9. Header Field Definitions 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
the client or the server, depending on who sends and who receives the
entity.
9.1. Connection 9.1. Connection
The "Connection" general-header field allows the sender to specify The "Connection" general-header field allows the sender to specify
options that are desired for that particular connection and MUST NOT options that are desired for that particular connection and MUST NOT
be communicated by proxies over further connections. be communicated by proxies over further connections.
The Connection header'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
message is forwarded and, for each connection-token in this field, message is forwarded and, for each connection-token in this field,
remove any header field(s) from the message with the same name as the remove any header field(s) from the message with the same name as the
connection-token. Connection options are signaled by the presence of connection-token. Connection options are signaled by the presence of
a connection-token in the Connection header field, not by any a connection-token in the Connection header field, not by any
corresponding additional header field(s), since the additional header corresponding additional header field(s), since the additional header
field may not be sent if there are no parameters associated with that field might not be sent if there are no parameters associated with
connection option. that connection option.
Message headers listed in the Connection header MUST NOT include end- Message headers listed in the Connection header MUST NOT include end-
to-end headers, such as Cache-Control. to-end headers, such as Cache-Control.
HTTP/1.1 defines the "close" connection option for the sender to HTTP/1.1 defines the "close" connection option for the sender to
signal that the connection will be closed after completion of the signal that the connection will be closed after completion of the
response. For example, response. For example,
Connection: close Connection: close
skipping to change at page 49, line 35 skipping to change at page 50, line 38
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.
9.2. Content-Length 9.2. Content-Length
The "Content-Length" entity-header field indicates the size of the The "Content-Length" header field indicates the size of the message-
entity-body, in number of OCTETs. In the case of responses to the body, in decimal number of octets, for any message other than a
HEAD method, it indicates the size of the entity-body that would have response to the HEAD method or a response with a status code of 304.
been sent had the request been a GET. In the case of responses to the HEAD method, it indicates the size of
the payload body (not including any potential transfer-coding) that
would have been sent had the request been a GET. In the case of the
304 (Not Modified) response, it indicates the size of the payload
body (not including any potential transfer-coding) that would have
been sent in a 200 (OK) response.
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 Implementations SHOULD use this field to indicate the message-body
the message-body, unless this is prohibited by the rules in length when no transfer-coding is being applied and the payload's
Section 3.4. body length can be determined prior to being transferred.
Section 3.3 describes how recipients determine the length of a
message-body.
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 3.4 describes how to determine the length of a message-body Note that the use of this field in HTTP is significantly different
if a Content-Length is not given. from the corresponding definition in MIME, where it is an optional
field used within the "message/external-body" content-type.
Note that the meaning of this field is significantly different from
the corresponding definition in MIME, where it is an optional field
used within the "message/external-body" content-type. In HTTP, it
SHOULD be sent whenever the message's length can be determined prior
to being transferred, unless this is prohibited by the rules in
Section 3.4.
9.3. Date 9.3. Date
The "Date" general-header field represents the date and time at which The "Date" general-header field represents the date and time at which
the message was originated, having the same semantics as the the message was originated, having the same semantics as the
Origination Date Field (orig-date) defined in Section 3.6.1 of Origination Date Field (orig-date) defined in Section 3.6.1 of
[RFC5322]. The field value is an HTTP-date, as described in [RFC5322]. The field value is an HTTP-date, as described in
Section 6.1; it MUST be sent in rfc1123-date format. Section 6.1; it MUST be sent in rfc1123-date format.
Date = "Date" ":" OWS Date-v Date = "Date" ":" OWS Date-v
skipping to change at page 51, line 6 skipping to change at page 52, line 10
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.
Clients SHOULD only send a Date header field in messages that include Clients SHOULD only send a Date header field in messages that include
an entity-body, as in the case of the PUT and POST requests, and even a payload, as is usually the case for PUT and POST requests, and even
then it is optional. A client without a clock MUST NOT send a Date then it is optional. A client without a clock MUST NOT send a Date
header field in a request. header field in a request.
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 payload 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.
9.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
skipping to change at page 52, line 23 skipping to change at page 53, line 28
field. field.
See Sections 4.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.
9.5. TE 9.5. TE
The "TE" request-header field indicates what extension transfer- The "TE" request-header field indicates what extension transfer-
codings it is willing to accept in the response, and whether or not 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. 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 consists of the keyword "trailers" and/or a comma-separated
separated list of extension transfer-coding names with optional list of extension transfer-coding names with optional accept
accept parameters (as described in Section 6.2). 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 [ "=" word ] te-ext = OWS ";" OWS token [ "=" word ]
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 6.2.1. This keyword is reserved for use with defined in Section 6.2.1. This keyword is reserved for use with
skipping to change at page 53, line 21 skipping to change at page 54, line 25
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 6.4, 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.
9.6. Trailer 9.6. Trailer
skipping to change at page 54, line 27 skipping to change at page 55, line 30
intermediaries), whereas content-codings are not. 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 6.2. 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 a representation, the
codings MUST be listed in the order in which they were applied. transfer-codings MUST be listed in the order in which they were
Additional information about the encoding parameters MAY be provided applied. Additional information about the encoding parameters MAY be
by other entity-header fields not defined by this specification. provided by other 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.
9.8. Upgrade 9.8. Upgrade
The "Upgrade" general-header field allows the client to specify what The "Upgrade" general-header field allows the client to specify what
additional communication protocols it would like to use, if the additional communication protocols it would like to use, if the
server chooses to switch protocols. Additionally, the server MUST server chooses to switch protocols. Additionally, the server MUST
use the Upgrade header field within a 101 (Switching Protocols) use the Upgrade header field within a 101 (Switching Protocols)
skipping to change at page 55, line 41 skipping to change at page 56, line 45
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.5 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 should be associated with one or a set of registered token is associated with contact information and an
specifications, and with contact information. optional set of specifications that details how the connection will
be processed after it has been upgraded.
Registrations should be allowed on a First Come First Served basis as Registrations are allowed on a First Come First Served basis as
described in Section 4.1 of [RFC5226]. These specifications need not described in Section 4.1 of [RFC5226]. The specifications need not
be IETF documents or be subject to IESG review, but should obey the be IETF documents or be subject to IESG review. Registrations are
following rules: subject to the following rules:
1. A token, once registered, stays registered forever. 1. A token, once registered, stays registered forever.
2. The registration MUST name a responsible party for the 2. The registration MUST name a responsible party for the
registration. registration.
3. The registration MUST name a point of contact. 3. The registration MUST name a point of contact.
4. The registration MAY name the documentation required for the 4. The registration MAY name a set of specifications associated with
token. that token. Such specifications need not be publicly available.
5. The responsible party MAY change the registration at any time. 5. The responsible party MAY change the registration at any time.
The IANA will keep a record of all such changes, and make them The IANA will keep a record of all such changes, and make them
available upon request. available upon request.
6. The responsible party for the first registration of a "product" 6. The responsible party for the first registration of a "product"
token MUST approve later registrations of a "version" token token MUST approve later registrations of a "version" token
together with that "product" token before they can be registered. together with that "product" token before they can be registered.
7. If absolutely required, the IESG MAY reassign the responsibility 7. If absolutely required, the IESG MAY reassign the responsibility
for a token. This will normally only be used in the case when a for a token. This will normally only be used in the case when a
responsible party cannot be contacted. 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 9.9. Via
The "Via" general-header field MUST be used by gateways and proxies 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.
skipping to change at page 58, line 12 skipping to change at page 59, line 8
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.
10. IANA Considerations 10. IANA Considerations
10.1. Message Header Registration 10.1. Header Field Registration
The Message Header Registry located at <http://www.iana.org/ The Message Header Field Registry located at <http://www.iana.org/
assignments/message-headers/message-header-index.html> should be assignments/message-headers/message-header-index.html> shall 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 9.1 | | Connection | http | standard | Section 9.1 |
| Content-Length | http | standard | Section 9.2 | | Content-Length | http | standard | Section 9.2 |
| Date | http | standard | Section 9.3 | | Date | http | standard | Section 9.3 |
| Host | http | standard | Section 9.4 | | Host | http | standard | Section 9.4 |
| TE | http | standard | Section 9.5 | | TE | http | standard | Section 9.5 |
skipping to change at page 58, line 38 skipping to change at page 59, line 34
| Upgrade | http | standard | Section 9.8 | | Upgrade | http | standard | Section 9.8 |
| 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> should 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.6.1 and 2.6.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 61, line 14 skipping to change at page 62, line 14
Restrictions on usage: none Restrictions on usage: none
Author/Change controller: IESG Author/Change controller: IESG
10.4. Transfer Coding Registry 10.4. Transfer Coding Registry
The registration procedure for HTTP Transfer Codings is now defined The registration procedure for HTTP Transfer Codings is now defined
by Section 6.2.3 of this document. by Section 6.2.3 of this document.
The HTTP Transfer Codings Registry located at The HTTP Transfer Codings Registry located at
<http://www.iana.org/assignments/http-parameters> should be updated <http://www.iana.org/assignments/http-parameters> shall be updated
with the registrations below: with the registrations below:
+----------+--------------------------------------+-----------------+ +----------+--------------------------------------+-----------------+
| Name | Description | Reference | | Name | Description | Reference |
+----------+--------------------------------------+-----------------+ +----------+--------------------------------------+-----------------+
| chunked | Transfer in a series of chunks | Section 6.2.1 | | chunked | Transfer in a series of chunks | Section 6.2.1 |
| compress | UNIX "compress" program method | Section 6.2.2.1 | | compress | UNIX "compress" program method | Section 6.2.2.1 |
| deflate | "deflate" compression mechanism | Section 6.2.2.2 | | deflate | "deflate" compression mechanism | Section 6.2.2.2 |
| | ([RFC1951]) used inside the "zlib" | | | | ([RFC1951]) used inside the "zlib" | |
| | data format ([RFC1950]) | | | | data format ([RFC1950]) | |
| gzip | Same as GNU zip [RFC1952] | Section 6.2.2.3 | | gzip | Same as GNU zip [RFC1952] | Section 6.2.2.3 |
+----------+--------------------------------------+-----------------+ +----------+--------------------------------------+-----------------+
10.5. Upgrade Token Registration 10.5. Upgrade Token Registration
The registration procedure for HTTP Upgrade Tokens -- previously The registration procedure for HTTP Upgrade Tokens -- previously
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/> should 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.5 of this |
| | Protocol | specification | | | Protocol | specification |
+-------+---------------------------+-------------------------------+ +-------+---------------------------+-------------------------------+
11. Security Considerations 11. Security Considerations
skipping to change at page 63, line 42 skipping to change at page 64, line 42
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 need to 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 needs to be
guarded, and appropriate guidelines for use should be developed and carefully guarded, and appropriate guidelines for use need to be
followed. (Section 11.2). developed and followed. (Section 11.2).
Proxy implementors should consider the privacy and security Proxy implementors need to 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 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, may 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. 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
skipping to change at page 65, line 36 skipping to change at page 66, line 36
13.1. Normative References 13.1. Normative References
[ISO-8859-1] International Organization for Standardization, [ISO-8859-1] International Organization for Standardization,
"Information technology -- 8-bit single-byte coded "Information technology -- 8-bit single-byte coded
graphic character sets -- Part 1: Latin alphabet No. graphic character sets -- Part 1: Latin alphabet No.
1", ISO/IEC 8859-1:1998, 1998. 1", ISO/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., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
Ed., and J. Reschke, Ed., "HTTP/1.1, part 2: Message Ed., and J. Reschke, Ed., "HTTP/1.1, part 2: Message
Semantics", draft-ietf-httpbis-p2-semantics-10 (work in Semantics", draft-ietf-httpbis-p2-semantics-11 (work in
progress), July 2010. progress), August 2010.
[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., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
Ed., and J. Reschke, Ed., "HTTP/1.1, part 3: Message Ed., and J. Reschke, Ed., "HTTP/1.1, part 3: Message
Payload and Content Negotiation", Payload and Content Negotiation",
draft-ietf-httpbis-p3-payload-10 (work in progress), draft-ietf-httpbis-p3-payload-11 (work in progress),
July 2010. August 2010.
[Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
Ed., and J. Reschke, Ed., "HTTP/1.1, part 5: Range
Requests and Partial Responses",
draft-ietf-httpbis-p5-range-10 (work in progress),
July 2010.
[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., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
Ed., Nottingham, M., Ed., and J. Reschke, Ed., Ed., Nottingham, M., Ed., and J. Reschke, Ed.,
"HTTP/1.1, part 6: Caching", "HTTP/1.1, part 6: Caching",
draft-ietf-httpbis-p6-cache-10 (work in progress), draft-ietf-httpbis-p6-cache-11 (work in progress),
July 2010. August 2010.
[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
Format Specification version 3.3", RFC 1950, May 1996. Format Specification version 3.3", RFC 1950, May 1996.
RFC 1950 is an Informational RFC, thus it may be less RFC 1950 is an Informational RFC, thus it might be less
stable than this specification. On the other hand, stable than this specification. On the other hand,
this downward reference was present since the this downward reference was present since the
publication of RFC 2068 in 1997 ([RFC2068]), therefore publication of RFC 2068 in 1997 ([RFC2068]), therefore
it is unlikely to cause problems in practice. See also it is unlikely to cause problems in practice. See also
[BCP97]. [BCP97].
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format
Specification version 1.3", RFC 1951, May 1996. Specification version 1.3", RFC 1951, May 1996.
RFC 1951 is an Informational RFC, thus it may be less RFC 1951 is an Informational RFC, thus it might be less
stable than this specification. On the other hand, stable than this specification. On the other hand,
this downward reference was present since the this downward reference was present since the
publication of RFC 2068 in 1997 ([RFC2068]), therefore publication of RFC 2068 in 1997 ([RFC2068]), therefore
it is unlikely to cause problems in practice. See also it is unlikely to cause problems in practice. See also
[BCP97]. [BCP97].
[RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and
G. Randers-Pehrson, "GZIP file format specification G. Randers-Pehrson, "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 it may be less RFC 1952 is an Informational RFC, thus it might be less
stable than this specification. On the other hand, stable than this specification. On the other hand,
this downward reference was present since the this downward reference was present since the
publication of RFC 2068 in 1997 ([RFC2068]), therefore publication of RFC 2068 in 1997 ([RFC2068]), therefore
it is unlikely to cause problems in practice. See also it is unlikely to cause problems in practice. See also
[BCP97]. [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, [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
skipping to change at page 69, line 26 skipping to change at page 70, line 22
Clients SHOULD be tolerant in parsing the Status-Line and servers Clients SHOULD be tolerant in parsing the Status-Line and servers
SHOULD be tolerant when parsing the Request-Line. In particular, SHOULD be tolerant when parsing the Request-Line. In particular,
they SHOULD accept any amount of WSP characters between fields, even they SHOULD accept any amount of WSP characters between fields, even
though only a single SP is required. though only a single SP is required.
The line terminator for header fields is the sequence CRLF. However, The line terminator for header fields is the sequence CRLF. However,
we recommend that applications, when parsing such headers, recognize we recommend that applications, when parsing such headers, 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 a representation 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
the exception that not labeling the entity is preferred over labeling representation, with the exception that not labeling the
the entity with the labels US-ASCII or ISO-8859-1. See [Part3]. representation is preferred over labeling the representation 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
which appears to be more than 50 years in the future is in fact in which appears to be more than 50 years in the future is in fact in
the past (this helps solve the "year 2000" problem). the past (this helps solve the "year 2000" problem).
o Although all date formats are specified to be case-sensitive, o Although all date formats are specified to be case-sensitive,
recipients SHOULD match day, week and timezone names case- recipients SHOULD match day, week and timezone names case-
skipping to change at page 71, line 52 skipping to change at page 72, line 47
o Servers MUST accept absolute URIs. o Servers MUST accept absolute URIs.
B.2. Compatibility with HTTP/1.0 Persistent Connections B.2. Compatibility with HTTP/1.0 Persistent Connections
Some clients and servers might wish to be compatible with some Some clients and servers might wish to be compatible with some
previous implementations of persistent connections in HTTP/1.0 previous implementations of persistent connections in HTTP/1.0
clients and servers. Persistent connections in HTTP/1.0 are clients and servers. Persistent connections in HTTP/1.0 are
explicitly negotiated as they are not the default behavior. HTTP/1.0 explicitly negotiated as they are not the default behavior. HTTP/1.0
experimental implementations of persistent connections are faulty, experimental implementations of persistent connections are faulty,
and the new facilities in HTTP/1.1 are designed to rectify these and the new facilities in HTTP/1.1 are designed to rectify these
problems. The problem was that some existing HTTP/1.0 clients may be problems. The problem was that some existing HTTP/1.0 clients might
sending Keep-Alive to a proxy server that doesn't understand send Keep-Alive to a proxy server that doesn't understand Connection,
Connection, which would then erroneously forward it to the next which would then erroneously forward it to the next inbound server,
inbound server, which would establish the Keep-Alive connection and which would establish the Keep-Alive connection and result in a hung
result in a hung HTTP/1.0 proxy waiting for the close on the HTTP/1.0 proxy waiting for the close on the response. The result is
response. The result is that HTTP/1.0 clients must be prevented from that HTTP/1.0 clients must be prevented from using Keep-Alive when
using Keep-Alive when talking to proxies. 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 9.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 2616
This specification has been carefully audited to correct and
disambiguate key word usage; RFC 2068 had many problems in respect to
the conventions laid out in [RFC2119].
Transfer-coding and message lengths all interact in ways that
required fixing exactly when chunked encoding is used (to allow for
transfer encoding that may not be self delimiting); it was important
to straighten out exactly how message lengths are computed.
(Sections 6.2, 3.4, 9.2, see also [Part3], [Part5] and [Part6])
The use and interpretation of HTTP version numbers has been clarified
by [RFC2145]. Require proxies to upgrade requests to highest
protocol version they support to deal with problems discovered in
HTTP/1.0 implementations (Section 2.5)
Quality Values of zero should indicate that "I don't want something"
to allow clients to refuse a representation. (Section 6.4)
Transfer-coding had significant problems, particularly with
interactions with chunked encoding. The solution is that transfer-
codings become as full fledged as content-codings. This involves
adding an IANA registry for transfer-codings (separate from content
codings), a new header field (TE) and enabling trailer headers in the
future. Transfer encoding is a major performance benefit, so it was
worth fixing [Nie1997]. TE also solves another, obscure, downward
interoperability problem that could have occurred due to interactions
between authentication trailers, chunked encoding and HTTP/1.0
clients.(Section 6.2, 6.2.1, 7.1.3.2, and 9.5)
Proxies should be able to add Content-Length when appropriate.
(Section 7.1.3.2)
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 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 HTTP-Version is case sensitive. (Section 2.5)
Remove reference to non-existent identity transfer-coding value Remove reference to non-existent identity transfer-coding value
tokens. (Sections 6.2 and 3.4) tokens. (Sections 6.2 and 3.3)
Require that invalid whitespace around field-names be rejected. Require that invalid whitespace around field-names be rejected.
(Section 3.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 4.1.2) query components of RFC3986. (Section 4.1.2)
Clarification that the chunk length does not include the count of the Clarification that the chunk length does not include the count of the
octets in the chunk header and trailer. Furthermore disallowed line octets in the chunk header and trailer. Furthermore disallowed line
folding in chunk extensions. (Section 6.2.1) folding in chunk extensions. (Section 6.2.1)
skipping to change at page 74, line 19 skipping to change at page 74, line 27
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 = start-line *( header-field CRLF ) CRLF [ message-body 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 ]
MIME-Version = <MIME-Version, defined in [Part3], Appendix A.1>
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 )
Reason-Phrase = *( WSP / VCHAR / obs-text ) Reason-Phrase = *( WSP / VCHAR / obs-text )
Request = Request-Line *( ( general-header / request-header / Request = Request-Line *( header-field CRLF ) CRLF [ message-body ]
entity-header ) 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 *( ( general-header / response-header / Response = Status-Line *( header-field CRLF ) CRLF [ message-body ]
entity-header ) 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
TE = "TE:" OWS TE-v TE = "TE:" OWS TE-v
TE-v = [ ( "," / t-codings ) *( OWS "," [ OWS t-codings ] ) ] TE-v = [ ( "," / t-codings ) *( OWS "," [ OWS t-codings ] ) ]
Trailer = "Trailer:" OWS Trailer-v Trailer = "Trailer:" OWS Trailer-v
Trailer-v = *( "," OWS ) field-name *( OWS "," [ OWS field-name ] ) Trailer-v = *( "," OWS ) field-name *( OWS "," [ OWS field-name ] )
Transfer-Encoding = "Transfer-Encoding:" OWS Transfer-Encoding-v Transfer-Encoding = "Transfer-Encoding:" OWS Transfer-Encoding-v
Transfer-Encoding-v = *( "," OWS ) transfer-coding *( OWS "," [ OWS Transfer-Encoding-v = *( "," OWS ) transfer-coding *( OWS "," [ OWS
skipping to change at page 75, line 44 skipping to change at page 75, line 51
/ %x53.61.74 ; Sat / %x53.61.74 ; Sat
/ %x53.75.6E ; Sun / %x53.75.6E ; Sun
day-name-l = %x4D.6F.6E.64.61.79 ; Monday day-name-l = %x4D.6F.6E.64.61.79 ; Monday
/ %x54.75.65.73.64.61.79 ; Tuesday / %x54.75.65.73.64.61.79 ; Tuesday
/ %x57.65.64.6E.65.73.64.61.79 ; Wednesday / %x57.65.64.6E.65.73.64.61.79 ; Wednesday
/ %x54.68.75.72.73.64.61.79 ; Thursday / %x54.68.75.72.73.64.61.79 ; Thursday
/ %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-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 )
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 / MIME-Version
header-field = field-name ":" OWS [ field-value ] OWS 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 ] 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 = *OCTET
<entity-body encoded as per Transfer-Encoding>
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 77, line 28 skipping to change at page 77, line 34
DQUOTE / "/" / "[" / "]" / "?" / "=" / "{" / "}" DQUOTE / "/" / "[" / "]" / "?" / "=" / "{" / "}"
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 [ "=" word ] te-ext = OWS ";" OWS token [ "=" word ]
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 = *( header-field CRLF )
transfer-coding = "chunked" / "compress" / "deflate" / "gzip" / transfer-coding = "chunked" / "compress" / "deflate" / "gzip" /
transfer-extension 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 = word value = word
word = token / quoted-string word = token / quoted-string
skipping to change at page 78, line 14 skipping to change at page 78, line 14
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 ; Request defined but not used
; Response defined but not used ; Response defined but not used
; TE defined but not used ; TE defined but not used
; URI-reference defined but not used ; URI-reference defined but not used
; general-header defined but not used
; http-URI defined but not used ; http-URI defined but not used
; https-URI defined but not used ; https-URI defined but not used
; partial-URI defined but not used ; partial-URI defined but not used
; request-header defined but not used
; response-header defined but not used
; special defined but not used ; special defined but not used
Appendix D. Change Log (to be removed by RFC Editor before publication) Appendix D. Change Log (to be removed by RFC Editor before publication)
D.1. Since RFC2616 D.1. Since RFC2616
Extracted relevant partitions from [RFC2616]. Extracted relevant partitions from [RFC2616].
D.2. Since draft-ietf-httpbis-p1-messaging-00 D.2. Since draft-ietf-httpbis-p1-messaging-00
skipping to change at page 83, line 45 skipping to change at page 83, line 45
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 might 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 D.9. Since draft-ietf-httpbis-p1-messaging-07
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/93>: "Repeating o <http://tools.ietf.org/wg/httpbis/trac/ticket/93>: "Repeating
skipping to change at page 85, line 18 skipping to change at page 85, line 18
D.11. Since draft-ietf-httpbis-p1-messaging-09 D.11. Since draft-ietf-httpbis-p1-messaging-09
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/73>: "Clarification o <http://tools.ietf.org/wg/httpbis/trac/ticket/73>: "Clarification
of the term 'deflate'" of the term 'deflate'"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/83>: "OPTIONS * and o <http://tools.ietf.org/wg/httpbis/trac/ticket/83>: "OPTIONS * and
proxies" proxies"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/122>: "MIME-Version
not listed in P1, general header fields"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/143>: "IANA registry o <http://tools.ietf.org/wg/httpbis/trac/ticket/143>: "IANA registry
for content/transfer encodings" for content/transfer encodings"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/165>: "Case- o <http://tools.ietf.org/wg/httpbis/trac/ticket/165>: "Case-
sensitivity of HTTP-date" sensitivity of HTTP-date"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/200>: "use of term o <http://tools.ietf.org/wg/httpbis/trac/ticket/200>: "use of term
"word" when talking about header structure" "word" when talking about header structure"
Partly resolved issues: Partly resolved issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/196>: "Term for the o <http://tools.ietf.org/wg/httpbis/trac/ticket/196>: "Term for the
requested resource's URI" requested resource's URI"
D.12. Since draft-ietf-httpbis-p1-messaging-10
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/28>: "Connection
Closing"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/90>: "Delimiting
messages with multipart/byteranges"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/95>: "Handling
multiple Content-Length headers"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/109>: "Clarify
entity / representation / variant terminology"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider
removing the 'changes from 2068' sections"
Partly resolved issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/159>: "HTTP(s) URI
scheme definitions"
Index Index
A A
application/http Media Type 60 application/http Media Type 61
B
browser 10
C C
cache 13 cache 13
cacheable 14 cacheable 14
chunked (Coding Format) 34 chunked (Coding Format) 35
client 11 client 10
Coding Format Coding Format
chunked 34 chunked 35
compress 36 compress 38
deflate 37 deflate 38
gzip 37 gzip 38
compress (Coding Format) 36 compress (Coding Format) 38
connection 11 connection 10
Connection header 48 Connection header 49
Content-Length header 49 Content-Length header 50
D D
Date header 50 Date header 51
deflate (Coding Format) 37 deflate (Coding Format) 38
downstream 12 downstream 12
E E
Effective Request URI 28 effective request URI 29
G G
gateway 13 gateway 13
Grammar Grammar
absolute-URI 16 absolute-URI 16
ALPHA 7 ALPHA 7
asctime-date 33 asctime-date 34
attribute 33 attribute 34
authority 16 authority 16
BWS 9 BWS 9
chunk 35 chunk 35
chunk-data 35 chunk-data 35
chunk-ext 35 chunk-ext 35
chunk-ext-name 35 chunk-ext-name 35
chunk-ext-val 35 chunk-ext-val 35
chunk-size 35 chunk-size 35
Chunked-Body 35 Chunked-Body 35
comment 22 comment 22
Connection 48 Connection 49
connection-token 48 connection-token 49
Connection-v 48 Connection-v 49
Content-Length 49 Content-Length 50
Content-Length-v 49 Content-Length-v 50
CR 7 CR 7
CRLF 7 CRLF 7
ctext 22 ctext 22
CTL 7 CTL 7
Date 50 Date 51
Date-v 50 Date-v 51
date1 32 date1 33
date2 33 date2 34
date3 33 date3 34
day 32 day 33
day-name 32 day-name 33
day-name-l 32 day-name-l 33
DIGIT 7 DIGIT 7
DQUOTE 7 DQUOTE 7
extension-code 31 extension-code 32
extension-method 25 extension-method 26
field-content 20 field-content 20
field-name 20 field-name 20
field-value 20 field-value 20
general-header 25 general-header 26
GMT 32 GMT 33
header-field 20 header-field 20
HEXDIG 7 HEXDIG 7
Host 51 Host 52
Host-v 51 Host-v 52
hour 32 hour 33
HTTP-date 31 HTTP-date 32
HTTP-message 19 HTTP-message 19
HTTP-Prot-Name 15 HTTP-Prot-Name 15
http-URI 17 http-URI 16
HTTP-Version 15 HTTP-Version 15
https-URI 18 https-URI 18
last-chunk 35 last-chunk 35
LF 7 LF 7
message-body 22 message-body 22
Method 25 Method 26
minute 32 minute 33
month 32 month 33
obs-date 32 obs-date 33
obs-text 10 obs-text 10
OCTET 7 OCTET 7
OWS 9 OWS 9
path-absolute 16 path-absolute 16
port 16 port 16
product 38 product 39
product-version 38 product-version 39
protocol-name 56 protocol-name 57
protocol-version 56 protocol-version 57
pseudonym 56 pseudonym 57
qdtext 10 qdtext 10
qdtext-nf 35 qdtext-nf 35
query 16 query 16
quoted-cpair 22 quoted-cpair 22
quoted-pair 10 quoted-pair 10
quoted-str-nf 35 quoted-str-nf 35
quoted-string 10 quoted-string 10
qvalue 38 qvalue 39
Reason-Phrase 31 Reason-Phrase 32
received-by 56 received-by 57
received-protocol 56 received-protocol 57
Request 25 Request 26
Request-Line 25 Request-Line 26
request-target 26 request-target 27
Response 30 Response 31
rfc850-date 33 rfc850-date 34
rfc1123-date 32 rfc1123-date 33
RWS 9 RWS 9
second 32 second 33
SP 7 SP 7
special 10 special 9
Status-Code 31 Status-Code 32
Status-Line 30 Status-Line 31
t-codings 52 t-codings 53
tchar 10 tchar 9
TE 52 TE 53
te-ext 52 te-ext 53
te-params 52 te-params 53
TE-v 52 TE-v 53
time-of-day 32 time-of-day 33
token 10 token 9
Trailer 53 Trailer 54
trailer-part 35 trailer-part 35
Trailer-v 53 Trailer-v 54
transfer-coding 33 transfer-coding 34
Transfer-Encoding 54 Transfer-Encoding 55
Transfer-Encoding-v 54 Transfer-Encoding-v 55
transfer-extension 33 transfer-extension 34
transfer-parameter 33 transfer-parameter 34
Upgrade 54 Upgrade 55
Upgrade-v 54 Upgrade-v 55
uri-host 16 uri-host 16
URI-reference 16 URI-reference 16
value 33 value 34
VCHAR 7 VCHAR 7
Via 56 Via 57
Via-v 56 Via-v 57
word 10 word 9
WSP 7 WSP 7
year 32 year 33
gzip (Coding Format) 37 gzip (Coding Format) 38
H H
header field 19 header field 19
header section 19 header section 19
Headers Headers
Connection 48 Connection 49
Content-Length 49 Content-Length 50
Date 50 Date 51
Host 51 Host 52
TE 52 TE 53
Trailer 53 Trailer 54
Transfer-Encoding 54 Transfer-Encoding 55
Upgrade 54 Upgrade 55
Via 56 Via 57
headers 19 headers 19
Host header 51 Host header 52
http URI scheme 17 http URI scheme 16
https URI scheme 18 https URI scheme 18
I I
inbound 12 inbound 12
intermediary 12
M M
Media Type Media Type
application/http 60 application/http 61
message/http 58 message/http 59
message 11 message 11
message/http Media Type 58 message/http Media Type 59
O O
origin server 11 origin server 10
outbound 12 outbound 12
P P
proxy 13 proxy 12
R R
request 11 request 11
resource 16 resource 16
response 11 response 11
reverse proxy 13 reverse proxy 13
S S
server 11 server 10
spider 10
T T
TE header 52 target resource 29
Trailer header 53 TE header 53
Transfer-Encoding header 54 Trailer header 54
Transfer-Encoding header 55
tunnel 13 tunnel 13
U U
Upgrade header 54 Upgrade header 55
upstream 12 upstream 12
URI scheme URI scheme
http 17 http 16
https 18 https 18
user agent 11 user agent 10
V V
Via header 56 Via header 57
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. 195 change blocks. 
629 lines changed or deleted 678 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/