draft-ietf-httpbis-p1-messaging-16.txt   draft-ietf-httpbis-p1-messaging-17.txt 
HTTPbis Working Group R. Fielding, Ed. HTTPbis Working Group R. Fielding, Ed.
Internet-Draft Adobe Internet-Draft Adobe
Obsoletes: 2145,2616 (if approved) J. Gettys Obsoletes: 2145,2616 (if approved) J. Gettys
Updates: 2817 (if approved) Alcatel-Lucent Updates: 2817 (if approved) Alcatel-Lucent
Intended status: Standards Track J. Mogul Intended status: Standards Track J. Mogul
Expires: February 25, 2012 HP Expires: May 3, 2012 HP
H. Frystyk H. Frystyk
Microsoft Microsoft
L. Masinter L. Masinter
Adobe Adobe
P. Leach P. Leach
Microsoft Microsoft
T. Berners-Lee T. Berners-Lee
W3C/MIT W3C/MIT
Y. Lafon, Ed. Y. Lafon, Ed.
W3C W3C
J. Reschke, Ed. J. Reschke, Ed.
greenbytes greenbytes
August 24, 2011 October 31, 2011
HTTP/1.1, part 1: URIs, Connections, and Message Parsing HTTP/1.1, part 1: URIs, Connections, and Message Parsing
draft-ietf-httpbis-p1-messaging-16 draft-ietf-httpbis-p1-messaging-17
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 and moves it to "HTTP/1.1" and, taken together, obsoletes RFC 2616 and moves it to
historic status, along with its predecessor RFC 2068. historic status, along with its predecessor RFC 2068.
skipping to change at page 2, line 11 skipping to change at page 2, line 11
Discussion of this draft should take place on the HTTPBIS working Discussion of this draft should take place on the HTTPBIS working
group mailing list (ietf-http-wg@w3.org), which is archived at group mailing list (ietf-http-wg@w3.org), which is archived at
<http://lists.w3.org/Archives/Public/ietf-http-wg/>. <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
The current issues list is at The current issues list is at
<http://tools.ietf.org/wg/httpbis/trac/report/3> and related <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
documents (including fancy diffs) can be found at documents (including fancy diffs) can be found at
<http://tools.ietf.org/wg/httpbis/>. <http://tools.ietf.org/wg/httpbis/>.
The changes in this draft are summarized in Appendix C.17. The changes in this draft are summarized in Appendix C.18.
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 February 25, 2012. This Internet-Draft will expire on May 3, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 12 skipping to change at page 3, line 12
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7 1.1. Conformance and Error Handling . . . . . . . . . . . . . . 7
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7
1.2.1. ABNF Extension: #rule . . . . . . . . . . . . . . . . 7 1.2.1. ABNF Extension: #rule . . . . . . . . . . . . . . . . 8
1.2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . 8 1.2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . 9
2. HTTP-related architecture . . . . . . . . . . . . . . . . . . 9 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 9 2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 10
2.2. Message Orientation and Buffering . . . . . . . . . . . . 11 2.2. Message Orientation and Buffering . . . . . . . . . . . . 11
2.3. Connections and Transport Independence . . . . . . . . . . 11 2.3. Connections and Transport Independence . . . . . . . . . . 12
2.4. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 12 2.4. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 12
2.5. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.5. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.6. Protocol Versioning . . . . . . . . . . . . . . . . . . . 15 2.6. Protocol Versioning . . . . . . . . . . . . . . . . . . . 15
2.7. Uniform Resource Identifiers . . . . . . . . . . . . . . . 17 2.7. Uniform Resource Identifiers . . . . . . . . . . . . . . . 17
2.7.1. http URI scheme . . . . . . . . . . . . . . . . . . . 18 2.7.1. http URI scheme . . . . . . . . . . . . . . . . . . . 18
2.7.2. https URI scheme . . . . . . . . . . . . . . . . . . . 19 2.7.2. https URI scheme . . . . . . . . . . . . . . . . . . . 19
2.7.3. http and https URI Normalization and Comparison . . . 20 2.7.3. http and https URI Normalization and Comparison . . . 20
3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 20 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 20
3.1. Message Parsing and Robustness . . . . . . . . . . . . . . 21 3.1. Start Line . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 22 3.1.1. Request-Line . . . . . . . . . . . . . . . . . . . . . 22
3.2.1. Field Parsing . . . . . . . . . . . . . . . . . . . . 23 3.1.2. Response Status-Line . . . . . . . . . . . . . . . . . 23
3.2.2. Field Length . . . . . . . . . . . . . . . . . . . . . 24 3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 23
3.2.3. Common Field ABNF Rules . . . . . . . . . . . . . . . 24 3.2.1. Field Parsing . . . . . . . . . . . . . . . . . . . . 24
3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 25 3.2.2. Field Length . . . . . . . . . . . . . . . . . . . . . 25
3.4. Incomplete Messages . . . . . . . . . . . . . . . . . . . 28 3.2.3. Common Field ABNF Rules . . . . . . . . . . . . . . . 25
3.5. General Header Fields . . . . . . . . . . . . . . . . . . 29 3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 27
4. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.4. Handling Incomplete Messages . . . . . . . . . . . . . . . 30
4.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 30 3.5. Message Parsing Robustness . . . . . . . . . . . . . . . . 30
4.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 30 4. Message Routing . . . . . . . . . . . . . . . . . . . . . . . 31
4.1.2. request-target . . . . . . . . . . . . . . . . . . . . 30 4.1. Types of Request Target . . . . . . . . . . . . . . . . . 31
4.2. The Resource Identified by a Request . . . . . . . . . . . 32 4.2. The Resource Identified by a Request . . . . . . . . . . . 33
4.3. Effective Request URI . . . . . . . . . . . . . . . . . . 33 4.3. Effective Request URI . . . . . . . . . . . . . . . . . . 34
5. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 5. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 35
5.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 34 5.1. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 35
5.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 35 5.1.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 36
6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 35 5.1.2. Compression Codings . . . . . . . . . . . . . . . . . 38
6.1. Date/Time Formats: Full Date . . . . . . . . . . . . . . . 35 5.1.3. Transfer Coding Registry . . . . . . . . . . . . . . . 39
6.2. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 38 5.2. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 39
6.2.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 39 5.3. Quality Values . . . . . . . . . . . . . . . . . . . . . . 40
6.2.2. Compression Codings . . . . . . . . . . . . . . . . . 41 6. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.2.3. Transfer Coding Registry . . . . . . . . . . . . . . . 42 6.1. Persistent Connections . . . . . . . . . . . . . . . . . . 40
6.3. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 43 6.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 40
6.4. Quality Values . . . . . . . . . . . . . . . . . . . . . . 43 6.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 41
7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 43 6.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 42
7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 44 6.1.4. Practical Considerations . . . . . . . . . . . . . . . 45
7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 44 6.1.5. Retrying Requests . . . . . . . . . . . . . . . . . . 46
7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 44 6.2. Message Transmission Requirements . . . . . . . . . . . . 46
7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 46 6.2.1. Persistent Connections and Flow Control . . . . . . . 46
7.1.4. Practical Considerations . . . . . . . . . . . . . . . 48 6.2.2. Monitoring Connections for Error Status Messages . . . 46
7.2. Message Transmission Requirements . . . . . . . . . . . . 49 6.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 46
7.2.1. Persistent Connections and Flow Control . . . . . . . 49 7. Miscellaneous notes that might disappear . . . . . . . . . . . 48
7.2.2. Monitoring Connections for Error Status Messages . . . 50 7.1. Scheme aliases considered harmful . . . . . . . . . . . . 48
7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 50 7.2. Use of HTTP for proxy communication . . . . . . . . . . . 49
7.2.4. Client Behavior if Server Prematurely Closes 7.3. Interception of HTTP for access control . . . . . . . . . 49
Connection . . . . . . . . . . . . . . . . . . . . . . 52 7.4. Use of HTTP by other protocols . . . . . . . . . . . . . . 49
8. Miscellaneous notes that might disappear . . . . . . . . . . . 53 7.5. Use of HTTP by media type specification . . . . . . . . . 49
8.1. Scheme aliases considered harmful . . . . . . . . . . . . 53 8. Header Field Definitions . . . . . . . . . . . . . . . . . . . 49
8.2. Use of HTTP for proxy communication . . . . . . . . . . . 53 8.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 49
8.3. Interception of HTTP for access control . . . . . . . . . 53 8.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 51
8.4. Use of HTTP by other protocols . . . . . . . . . . . . . . 53 8.3. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
8.5. Use of HTTP by media type specification . . . . . . . . . 53 8.4. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 53 8.5. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 54
9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 53 8.6. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 54
9.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 55 8.7. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 55
9.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 8.7.1. Upgrade Token Registry . . . . . . . . . . . . . . . . 56
9.3.1. Clockless Origin Server Operation . . . . . . . . . . 56 8.8. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
9.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58
9.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 9.1. Header Field Registration . . . . . . . . . . . . . . . . 58
9.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 59 9.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 59
9.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 59 9.3. Internet Media Type Registrations . . . . . . . . . . . . 59
9.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 60 9.3.1. Internet Media Type message/http . . . . . . . . . . . 59
9.8.1. Upgrade Token Registry . . . . . . . . . . . . . . . . 61 9.3.2. Internet Media Type application/http . . . . . . . . . 61
9.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 9.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 62
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 63 9.5. Upgrade Token Registration . . . . . . . . . . . . . . . . 62
10.1. Header Field Registration . . . . . . . . . . . . . . . . 63 10. Security Considerations . . . . . . . . . . . . . . . . . . . 62
10.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 64 10.1. Personal Information . . . . . . . . . . . . . . . . . . . 63
10.3. Internet Media Type Registrations . . . . . . . . . . . . 64 10.2. Abuse of Server Log Information . . . . . . . . . . . . . 63
10.3.1. Internet Media Type message/http . . . . . . . . . . . 64 10.3. Attacks Based On File and Path Names . . . . . . . . . . . 63
10.3.2. Internet Media Type application/http . . . . . . . . . 66 10.4. DNS-related Attacks . . . . . . . . . . . . . . . . . . . 63
10.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 67 10.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 64
10.5. Upgrade Token Registration . . . . . . . . . . . . . . . . 67 10.6. Protocol Element Size Overflows . . . . . . . . . . . . . 64
11. Security Considerations . . . . . . . . . . . . . . . . . . . 67 10.7. Denial of Service Attacks on Proxies . . . . . . . . . . . 65
11.1. Personal Information . . . . . . . . . . . . . . . . . . . 68 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 65
11.2. Abuse of Server Log Information . . . . . . . . . . . . . 68 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 66
11.3. Attacks Based On File and Path Names . . . . . . . . . . . 68 12.1. Normative References . . . . . . . . . . . . . . . . . . . 66
11.4. DNS-related Attacks . . . . . . . . . . . . . . . . . . . 68 12.2. Informative References . . . . . . . . . . . . . . . . . . 68
11.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 69 Appendix A. HTTP Version History . . . . . . . . . . . . . . . . 70
11.6. Protocol Element Size Overflows . . . . . . . . . . . . . 69 A.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 71
11.7. Denial of Service Attacks on Proxies . . . . . . . . . . . 70 A.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 71
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 70 A.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 71
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 70
13.1. Normative References . . . . . . . . . . . . . . . . . . . 70 A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 72
13.2. Informative References . . . . . . . . . . . . . . . . . . 72 Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 73
Appendix A. HTTP Version History . . . . . . . . . . . . . . . . 74
A.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 75
A.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 75
A.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 75
A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 76
Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 77
Appendix C. Change Log (to be removed by RFC Editor before Appendix C. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 81 publication) . . . . . . . . . . . . . . . . . . . . 76
C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 81 C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 76
C.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 81 C.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 76
C.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 83 C.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 78
C.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 84 C.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 79
C.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 84 C.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 79
C.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 85 C.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 80
C.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 85 C.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 80
C.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 86 C.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 81
C.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 87 C.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 82
C.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 87 C.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 82
C.11. Since draft-ietf-httpbis-p1-messaging-09 . . . . . . . . . 88 C.11. Since draft-ietf-httpbis-p1-messaging-09 . . . . . . . . . 83
C.12. Since draft-ietf-httpbis-p1-messaging-10 . . . . . . . . . 88 C.12. Since draft-ietf-httpbis-p1-messaging-10 . . . . . . . . . 83
C.13. Since draft-ietf-httpbis-p1-messaging-11 . . . . . . . . . 89 C.13. Since draft-ietf-httpbis-p1-messaging-11 . . . . . . . . . 84
C.14. Since draft-ietf-httpbis-p1-messaging-12 . . . . . . . . . 89 C.14. Since draft-ietf-httpbis-p1-messaging-12 . . . . . . . . . 84
C.15. Since draft-ietf-httpbis-p1-messaging-13 . . . . . . . . . 90 C.15. Since draft-ietf-httpbis-p1-messaging-13 . . . . . . . . . 85
C.16. Since draft-ietf-httpbis-p1-messaging-14 . . . . . . . . . 90 C.16. Since draft-ietf-httpbis-p1-messaging-14 . . . . . . . . . 85
C.17. Since draft-ietf-httpbis-p1-messaging-15 . . . . . . . . . 90 C.17. Since draft-ietf-httpbis-p1-messaging-15 . . . . . . . . . 85
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 C.18. Since draft-ietf-httpbis-p1-messaging-16 . . . . . . . . . 86
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 the target resource Identifier (URI) standard [RFC3986] to indicate the target resource
and relationships between resources. Messages are passed in a format and relationships between resources. Messages are passed in a format
similar to that used by Internet mail [RFC5322] and the Multipurpose similar to that used by Internet mail [RFC5322] and the Multipurpose
skipping to change at page 7, line 6 skipping to change at page 7, line 6
defining the protocol referred to as "HTTP/1.1", obsoleting [RFC2616] defining the protocol referred to as "HTTP/1.1", obsoleting [RFC2616]
and [RFC2145]. Part 1 describes the architectural elements that are and [RFC2145]. Part 1 describes the architectural elements that are
used or referred to in HTTP, defines the "http" and "https" URI used or referred to in HTTP, defines the "http" and "https" URI
schemes, describes overall network operation and connection schemes, describes overall network operation and connection
management, and defines HTTP message framing and forwarding management, and defines HTTP message framing and forwarding
requirements. Our goal is to define all of the mechanisms necessary requirements. Our goal is to define all of the mechanisms necessary
for HTTP message handling that are independent of message semantics, for HTTP message handling that are independent of message semantics,
thereby defining the complete set of requirements for message parsers thereby defining the complete set of requirements for message parsers
and message-forwarding intermediaries. and message-forwarding intermediaries.
1.1. Requirements 1.1. Conformance and Error Handling
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
An implementation is not compliant if it fails to satisfy one or more This document defines conformance criteria for several roles in HTTP
of the "MUST" or "REQUIRED" level requirements for the protocols it communication, including Senders, Recipients, Clients, Servers, User-
implements. An implementation that satisfies all the "MUST" or Agents, Origin Servers, Intermediaries, Proxies and Gateways. See
"REQUIRED" level and all the "SHOULD" level requirements for its Section 2 for definitions of these terms.
protocols is said to be "unconditionally compliant"; one that
satisfies all the "MUST" level requirements but not all the "SHOULD" An implementation is considered conformant if it complies with all of
level requirements for its protocols is said to be "conditionally the requirements associated with its role(s). Note that SHOULD-level
compliant". requirements are relevant here, unless one of the documented
exceptions is applicable.
This document also uses ABNF to define valid protocol elements
(Section 1.2). In addition to the prose requirements placed upon
them, Senders MUST NOT generate protocol elements that are invalid.
Unless noted otherwise, Recipients MAY take steps to recover a usable
protocol element from an invalid construct. However, HTTP does not
define specific error handling mechanisms, except in cases where it
has direct impact on security. This is because different uses of the
protocol require different error handling strategies; for example, a
Web browser may wish to transparently recover from a response where
the Location header field doesn't parse according to the ABNF,
whereby in a systems control protocol using HTTP, this type of error
recovery could lead to dangerous consequences.
1.2. Syntax Notation 1.2. Syntax Notation
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), HTAB (horizontal tab), LF (line
sequence of data), SP (space), VCHAR (any visible [USASCII] feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any
character), and WSP (whitespace). visible [USASCII] character).
As a syntactic 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-
skipping to change at page 8, line 33 skipping to change at page 8, line 47
For example, given these ABNF productions: For example, given these ABNF productions:
example-list = 1#example-list-elmt example-list = 1#example-list-elmt
example-list-elmt = token ; see Section 3.2.3 example-list-elmt = token ; see Section 3.2.3
Then these are valid values for example-list (not including the Then these are valid values for example-list (not including the
double quotes, which are present for delimitation only): double quotes, which are present for delimitation only):
"foo,bar" "foo,bar"
" foo ,bar," "foo ,bar,"
" foo , ,bar,charlie " "foo , ,bar,charlie "
"foo ,bar, charlie "
But these values would be invalid, as at least one non-empty element But these values would be invalid, as at least one non-empty element
is required: is required:
"" ""
"," ","
", ," ", ,"
Appendix B shows the collected ABNF, with the list rules expanded as Appendix B shows the collected ABNF, with the list rules expanded as
explained above. explained above.
skipping to change at page 9, line 9 skipping to change at page 9, line 22
1.2.2. Basic Rules 1.2.2. Basic Rules
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 octets The OWS rule is used where zero or more linear whitespace octets
might 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. Multiple OWS octets that occur within field-content single SP. Multiple OWS octets that occur within field-content
SHOULD either be replaced with a single SP or transformed to all SP SHOULD either be replaced with a single SP or transformed to all SP
octets (each WSP octet other than SP replaced with SP) before octets (each octet other than SP replaced with SP) before
interpreting the field value or forwarding the message downstream. interpreting the field value or forwarding the message downstream.
RWS is used when at least one linear whitespace octet is required to RWS is used when at least one linear whitespace octet is required to
separate field tokens. RWS SHOULD be produced as a single SP. separate field tokens. RWS SHOULD be produced as a single SP.
Multiple RWS octets octets that occur within field-content SHOULD Multiple RWS octets that occur within field-content SHOULD either be
either be replaced with a single SP or transformed to all SP octets replaced with a single SP or transformed to all SP octets before
(each WSP octet other than SP replaced with SP) before interpreting interpreting the field value or forwarding the message downstream.
the field value or forwarding the message downstream.
BWS is used where the grammar allows optional whitespace for BWS is used where the grammar allows optional whitespace for
historical reasons but senders SHOULD NOT produce it in messages. historical reasons but senders SHOULD NOT produce it in messages.
HTTP/1.1 recipients MUST accept such bad optional whitespace and HTTP/1.1 recipients MUST accept such bad optional whitespace and
remove it before interpreting the field value or forwarding the remove it before interpreting the field value or forwarding the
message downstream. message downstream.
OWS = *( [ obs-fold ] WSP ) OWS = *( SP / HTAB / obs-fold )
; "optional" whitespace ; "optional" whitespace
RWS = 1*( [ obs-fold ] WSP ) RWS = 1*( SP / HTAB / obs-fold )
; "required" whitespace ; "required" whitespace
BWS = OWS BWS = OWS
; "bad" whitespace ; "bad" whitespace
obs-fold = CRLF obs-fold = CRLF ( SP / HTAB )
; see Section 3.2 ; obsolete line folding
; see Section 3.2.1
2. HTTP-related architecture 2. 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 Messaging 2.1. Client/Server Messaging
HTTP is a stateless request/response protocol that operates by HTTP is a stateless request/response protocol that operates by
exchanging messages across a reliable transport or session-layer exchanging messages (Section 3) across a reliable transport or
"connection". An HTTP "client" is a program that establishes a session-layer "connection". An HTTP "client" is a program that
connection to a server for the purpose of sending one or more HTTP establishes a connection to a server for the purpose of sending one
requests. An HTTP "server" is a program that accepts connections in or more HTTP requests. An HTTP "server" is a program that accepts
order to service HTTP requests by sending HTTP responses. connections in order to service HTTP requests by sending HTTP
responses.
Note that the terms client and server refer only to the roles that Note that the terms client and server refer only to the roles that
these programs perform for a particular connection. The same program these programs perform for a particular connection. The same program
might act as a client on some connections and a server on others. We might act as a client on some connections and a server on others. We
use the term "user agent" to refer to the program that initiates a use the term "user agent" to refer to the program that initiates a
request, such as a WWW browser, editor, or spider (web-traversing request, such as a WWW browser, editor, or spider (web-traversing
robot), and the term "origin server" to refer to the program that can robot), and the term "origin server" to refer to the program that can
originate authoritative responses to a request. For general originate authoritative responses to a request. For general
requirements, we use the term "sender" to refer to whichever requirements, we use the term "sender" to refer to whichever
component sent a given message and the term "recipient" to refer to component sent a given message and the term "recipient" to refer to
skipping to change at page 10, line 24 skipping to change at page 10, line 38
representation of some resource identified by a URI. In the simplest representation of some resource identified by a URI. In the simplest
case, this might be accomplished via a single bidirectional case, this might be accomplished via a single bidirectional
connection (===) between the user agent (UA) and the origin server connection (===) between the user agent (UA) and the origin server
(O). (O).
request > request >
UA ======================================= O UA ======================================= O
< response < 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, beginning with a request-line that includes a method, URI,
version, followed by MIME-like header fields containing request and protocol version (Section 3.1.1), followed by MIME-like header
modifiers, client information, and payload metadata, an empty line to fields containing request modifiers, client information, and payload
indicate the end of the header section, and finally the payload body metadata (Section 3.2), an empty line to indicate the end of the
(if any). header section, and finally a message body containing the payload
body (if any, Section 3.3).
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, beginning with a status line that includes the protocol
protocol version, a success or error code, and textual reason phrase, version, a success or error code, and textual reason phrase
followed by MIME-like header fields containing server information, (Section 3.1.2), followed by MIME-like header fields containing
resource metadata, and payload metadata, an empty line to indicate server information, resource metadata, and payload metadata
the end of the header section, and finally the payload body (if any). (Section 3.2), an empty line to indicate the end of the header
section, and finally a message body containing the payload body (if
any, Section 3.3).
The following example illustrates a typical message exchange for a The following example illustrates a typical message exchange for a
GET request on the URI "http://www.example.com/hello.txt": GET request on the URI "http://www.example.com/hello.txt":
client request: client request:
GET /hello.txt HTTP/1.1 GET /hello.txt HTTP/1.1
User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
Host: www.example.com Host: www.example.com
Accept: */* Accept: */*
skipping to change at page 11, line 22 skipping to change at page 11, line 33
Accept-Ranges: bytes Accept-Ranges: bytes
Content-Length: 14 Content-Length: 14
Vary: Accept-Encoding Vary: Accept-Encoding
Content-Type: text/plain Content-Type: text/plain
Hello World! Hello World!
2.2. Message Orientation and Buffering 2.2. Message Orientation and Buffering
Fundamentally, HTTP is a message-based protocol. Although message Fundamentally, HTTP is a message-based protocol. Although message
bodies can be chunked (Section 6.2.1) and implementations often make bodies can be chunked (Section 5.1.1) and implementations often make
parts of a message available progressively, this is not required, and parts of a message available progressively, this is not required, and
some widely-used implementations only make a message available when some widely-used implementations only make a message available when
it is complete. Furthermore, while most proxies will progressively it is complete. Furthermore, while most proxies will progressively
stream messages, some amount of buffering will take place, and some stream messages, some amount of buffering will take place, and some
proxies might buffer messages to perform transformations, check proxies might buffer messages to perform transformations, check
content or provide other services. content or provide other services.
Therefore, extensions to and uses of HTTP cannot rely on the Therefore, extensions to and uses of HTTP cannot rely on the
availability of a partial message, or assume that messages will not availability of a partial message, or assume that messages will not
be buffered. There are strategies that can be used to test for be buffered. There are strategies that can be used to test for
skipping to change at page 12, line 14 skipping to change at page 12, line 27
protocol is outside the scope of this specification. protocol is outside the scope of this specification.
The specific connection protocols to be used for an interaction are The specific connection protocols to be used for an interaction are
determined by client configuration and the target resource's URI. determined by client configuration and the target resource's URI.
For example, the "http" URI scheme (Section 2.7.1) indicates a For example, the "http" URI scheme (Section 2.7.1) indicates a
default connection of TCP over IP, with a default TCP port of 80, but default connection of TCP over IP, with a default TCP port of 80, but
the client might be configured to use a proxy via some other the client might be configured to use a proxy via some other
connection port or protocol instead of using the defaults. connection port or protocol instead of using the defaults.
A connection might be used for multiple HTTP request/response A connection might be used for multiple HTTP request/response
exchanges, as defined in Section 7.1. exchanges, as defined in Section 6.1.
2.4. Intermediaries 2.4. Intermediaries
HTTP enables the use of intermediaries to satisfy requests through a HTTP enables the use of intermediaries to satisfy requests through a
chain of connections. There are three common forms of HTTP chain of connections. There are three common forms of HTTP
intermediary: proxy, gateway, and tunnel. In some cases, a single intermediary: proxy, gateway, and tunnel. In some cases, a single
intermediary might act as an origin server, proxy, gateway, or intermediary might act as an origin server, proxy, gateway, or
tunnel, switching behavior based on the nature of each request. tunnel, switching behavior based on the nature of each request.
> > > > > > > >
skipping to change at page 13, line 23 skipping to change at page 13, line 36
that would be significant to the original sender or potentially that would be significant to the original sender or potentially
significant to downstream recipients). For example, a transforming significant to downstream recipients). For example, a transforming
proxy might be acting as a shared annotation server (modifying proxy might be acting as a shared annotation server (modifying
responses to include references to a local annotation database), a responses to include references to a local annotation database), a
malware filter, a format transcoder, or an intranet-to-Internet malware filter, a format transcoder, or an intranet-to-Internet
privacy filter. Such transformations are presumed to be desired by privacy filter. Such transformations are presumed to be desired by
the client (or client organization) that selected the proxy and are the client (or client organization) that selected the proxy and are
beyond the scope of this specification. However, when a proxy is not beyond the scope of this specification. However, when a proxy is not
intended to transform a given message, we use the term "non- intended to transform a given message, we use the term "non-
transforming proxy" to target requirements that preserve HTTP message transforming proxy" to target requirements that preserve HTTP message
semantics. See Section 8.2.4 of [Part2] and Section 3.6 of [Part6] semantics. See Section 7.2.4 of [Part2] and Section 3.6 of [Part6]
for status and warning codes related to transformations. for status and warning codes related to transformations.
A "gateway" (a.k.a., "reverse proxy") is a receiving agent that acts A "gateway" (a.k.a., "reverse proxy") is a receiving agent that acts
as a layer above some other server(s) and translates the received as a layer above some other server(s) and translates the received
requests to the underlying server's protocol. Gateways are often requests to the underlying server's protocol. Gateways are often
used to encapsulate legacy or untrusted information services, to used to encapsulate legacy or untrusted information services, to
improve server performance through "accelerator" caching, and to improve server performance through "accelerator" caching, and to
enable partitioning or load-balancing of HTTP services across enable partitioning or load-balancing of HTTP services across
multiple machines. multiple machines.
skipping to change at page 13, line 40 skipping to change at page 14, line 4
improve server performance through "accelerator" caching, and to improve server performance through "accelerator" caching, and to
enable partitioning or load-balancing of HTTP services across enable partitioning or load-balancing of HTTP services across
multiple machines. multiple machines.
A gateway behaves as an origin server on its outbound connection and A gateway behaves as an origin server on its outbound connection and
as a user agent on its inbound connection. All HTTP requirements as a user agent on its inbound connection. All HTTP requirements
applicable to an origin server also apply to the outbound applicable to an origin server also apply to the outbound
communication of a gateway. A gateway communicates with inbound communication of a gateway. A gateway communicates with inbound
servers using any protocol that it desires, including private servers using any protocol that it desires, including private
extensions to HTTP that are outside the scope of this specification. extensions to HTTP that are outside the scope of this specification.
However, an HTTP-to-HTTP gateway that wishes to interoperate with However, an HTTP-to-HTTP gateway that wishes to interoperate with
third-party HTTP servers MUST comply with HTTP user agent third-party HTTP servers MUST comply with HTTP user agent
requirements on the gateway's inbound connection and MUST implement requirements on the gateway's inbound connection and MUST implement
the Connection (Section 9.1) and Via (Section 9.9) header fields for the Connection (Section 8.1) and Via (Section 8.8) header fields for
both connections. both connections.
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 might 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.
skipping to change at page 16, line 9 skipping to change at page 16, line 20
header fields ought to be implemented by all HTTP/1.x implementations header fields ought to be implemented by all HTTP/1.x implementations
whether or not they advertise compliance with HTTP/1.1. whether or not they advertise compliance with HTTP/1.1.
New header fields can be defined such that, when they are understood New header fields can be defined such that, when they are understood
by a recipient, they might override or enhance the interpretation of by a recipient, they might override or enhance the interpretation of
previously defined header fields. When an implementation receives an previously defined header fields. When an implementation receives an
unrecognized header field, the recipient MUST ignore that header unrecognized header field, the recipient MUST ignore that header
field for local processing regardless of the message's HTTP version. field for local processing regardless of the message's HTTP version.
An unrecognized header field received by a proxy MUST be forwarded An unrecognized header field received by a proxy MUST be forwarded
downstream unless the header field's field-name is listed in the downstream unless the header field's field-name is listed in the
message's Connection header-field (see Section 9.1). These message's Connection header-field (see Section 8.1). These
requirements allow HTTP's functionality to be enhanced without requirements allow HTTP's functionality to be enhanced without
requiring prior update of all compliant intermediaries. requiring prior update of all compliant intermediaries.
Intermediaries that process HTTP messages (i.e., all intermediaries Intermediaries that process HTTP messages (i.e., all intermediaries
other than those acting as a tunnel) MUST send their own HTTP-Version other than those acting as a tunnel) MUST send their own HTTP-Version
in forwarded messages. In other words, they MUST NOT blindly forward in forwarded messages. In other words, they MUST NOT blindly forward
the first line of an HTTP message without ensuring that the protocol the first line of an HTTP message without ensuring that the protocol
version matches what the intermediary understands, and is at least version matches what the intermediary understands, and is at least
conditionally compliant to, for both the receiving and sending of conditionally compliant to, for both the receiving and sending of
messages. Forwarding an HTTP message without rewriting the HTTP- messages. Forwarding an HTTP message without rewriting the HTTP-
skipping to change at page 18, line 44 skipping to change at page 19, line 6
be running an HTTP server or listening to the indicated port. The be running an HTTP server or listening to the indicated port. The
"http" URI scheme makes use of the delegated nature of Internet names "http" URI scheme makes use of the delegated nature of Internet names
and addresses to establish a naming authority (whatever entity has and addresses to establish a naming authority (whatever entity has
the ability to place an HTTP server at that Internet name or address) the ability to place an HTTP server at that Internet name or address)
and allows that authority to determine which names are valid and how and allows that authority to determine which names are valid and how
they 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
server containing the URI's identifying data as described in (Section 3) containing the URI's identifying data (Section 4) to the
Section 4. If the server responds to that request with a non-interim server. 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 4 of [Part2], then
is considered an authoritative answer to the client's request. that response 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 might 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 authoritative access to "http" identified resources -- it is only the authoritative
interface used for mapping the namespace that is specific to TCP. interface used for mapping the namespace that is specific to TCP.
skipping to change at page 20, line 43 skipping to change at page 21, line 6
http://EXAMPLE.com:/%7esmith/home.html http://EXAMPLE.com:/%7esmith/home.html
3. Message Format 3. Message Format
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 octets in a format similar to the Internet Message Format of octets 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.
HTTP-message = start-line
*( header-field CRLF )
CRLF
[ message-body ]
The normal procedure for parsing an HTTP message is to read the
start-line into a structure, read each header field into a hash table
by field name until the empty line, and then use the parsed data to
determine if a message-body is expected. If a message-body has been
indicated, then it is read as a stream until an amount of octets
equal to the message-body length is read or the connection is closed.
Recipients MUST parse an HTTP message as a sequence of octets in an
encoding that is a superset of US-ASCII [USASCII]. Parsing an HTTP
message as a stream of Unicode characters, without regard for the
specific encoding, creates security vulnerabilities due to the
varying ways that string processing libraries handle invalid
multibyte character sequences that contain the octet LF (%x0A).
String-based parsers can only be safely used within protocol elements
after the element has been extracted from the message, such as within
a header field-value after message parsing has delineated the
individual fields.
3.1. Start Line
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.3). 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
*( header-field CRLF )
CRLF
[ message-body ]
start-line = Request-Line / Status-Line start-line = Request-Line / Status-Line
Implementations MUST NOT send whitespace between the start-line and Implementations MUST NOT send whitespace between the start-line and
the first header field. The presence of such whitespace in a request the first header field. The presence of such whitespace in a request
might be an attempt to trick a server into ignoring that field or might be an attempt to trick a server into ignoring that field or
processing the line after it as a new request, either of which might processing the line after it as a new request, either of which might
result in a security vulnerability if other implementations within result in a security vulnerability if other implementations within
the request chain interpret the same message differently. Likewise, the request chain interpret the same message differently. Likewise,
the presence of such whitespace in a response might be ignored by the presence of such whitespace in a response might be ignored by
some clients or cause others to cease parsing. some clients or cause others to cease parsing.
3.1. Message Parsing and Robustness 3.1.1. Request-Line
The normal procedure for parsing an HTTP message is to read the The Request-Line begins with a method token, followed by a single
start-line into a structure, read each header field into a hash table space (SP), the request-target, another single space (SP), the
by field name until the empty line, and then use the parsed data to protocol version, and ending with CRLF.
determine if a message-body is expected. If a message-body has been
indicated, then it is read as a stream until an amount of octets
equal to the message-body length is read or the connection is closed.
Care must be taken to parse an HTTP message as a sequence of octets Request-Line = Method SP request-target SP HTTP-Version CRLF
in an encoding that is a superset of US-ASCII. Attempting to parse
HTTP as a stream of Unicode characters in a character encoding like
UTF-16 might introduce security flaws due to the differing ways that
such parsers interpret invalid characters.
Older HTTP/1.0 client implementations might send an extra CRLF after 3.1.1.1. Method
a POST request as a lame workaround for some early server
applications that failed to read message-body content that was not
terminated by a line-ending. An HTTP/1.1 client MUST NOT preface or
follow a request with an extra CRLF. If terminating the request
message-body with a line-ending is desired, then the client MUST
include the terminating CRLF octets as part of the message-body
length.
In the interest of robustness, servers SHOULD ignore at least one The Method token indicates the request method to be performed on the
empty line received where a Request-Line is expected. In other target resource. The request method is case-sensitive.
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.
Likewise, although the line terminator for the start-line and header
fields is the sequence CRLF, we recommend that recipients recognize a
single LF as a line terminator and ignore any CR.
When a server listening only for HTTP request messages, or processing Method = token
what appears from the start-line to be an HTTP request message,
receives a sequence of octets that does not match the HTTP-message See Section 2 of [Part2] for further information, such as the list of
grammar aside from the robustness exceptions listed above, the server methods defined by this specification, the IANA registry, and
MUST respond with an HTTP/1.1 400 (Bad Request) response. considerations for new methods.
3.1.1.2. request-target
The request-target identifies the target resource upon which to apply
the request. The four options for request-target are described in
Section 4.1.
request-target = "*"
/ absolute-URI
/ ( path-absolute [ "?" query ] )
/ authority
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
length and respond with the 414 (URI Too Long) status code if the
received request-target would be longer than the server wishes to
handle (see Section 7.4.15 of [Part2]).
Various ad-hoc limitations on request-target length are found in
practice. It is RECOMMENDED that all HTTP senders and recipients
support request-target lengths of 8000 or more octets.
Note: Fragments ([RFC3986], Section 3.5) are not part of the
request-target and thus will not be transmitted in an HTTP
request.
3.1.2. Response Status-Line
The first line of a Response message is the Status-Line, consisting
of the protocol version, a space (SP), the status code, another
space, a possibly-empty textual phrase describing the status code,
and ending with CRLF.
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
3.1.2.1. Status Code
The Status-Code element is a 3-digit integer result code of the
attempt to understand and satisfy the request. See Section 4 of
[Part2] for further information, such as the list of status codes
defined by this specification, the IANA registry, and considerations
for new status codes.
Status-Code = 3DIGIT
3.1.2.2. Reason Phrase
The Reason Phrase exists for the sole purpose of providing a textual
description associated with the numeric status code, out of deference
to earlier Internet application protocols that were more frequently
used with interactive text clients. A client SHOULD ignore the
content of the Reason Phrase.
Reason-Phrase = *( HTAB / SP / VCHAR / obs-text )
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 BWS
field-name = token field-name = token
field-value = *( field-content / OWS ) field-value = *( field-content / obs-fold )
field-content = *( WSP / VCHAR / obs-text ) field-content = *( HTAB / SP / VCHAR / obs-text )
The field-name token labels the corresponding field-value as having The field-name token labels the corresponding field-value as having
the semantics defined by that header field. For example, the Date the semantics defined by that header field. For example, the Date
header field is defined in Section 9.3 as containing the origination header field is defined in Section 9.2 of [Part2] as containing the
timestamp for the message in which it appears. origination timestamp for the message in which it appears.
HTTP header fields are fully extensible: there is no limit on the HTTP header fields are fully extensible: there is no limit on the
introduction of new field names, each presumably defining new introduction of new field names, each presumably defining new
semantics, or on the number of header fields used in a given message. semantics, or on the number of header fields used in a given message.
Existing fields are defined in each part of this specification and in Existing fields are defined in each part of this specification and in
many other specifications outside the standards process. New header many other specifications outside the standards process. New header
fields can be introduced without changing the protocol version if fields can be introduced without changing the protocol version if
their defined semantics allow them to be safely ignored by recipients their defined semantics allow them to be safely ignored by recipients
that do not recognize them. that do not recognize them.
New HTTP header fields SHOULD be registered with IANA according to New HTTP header fields SHOULD be registered with IANA according to
the procedures in Section 10.1. Unrecognized header fields MUST be the procedures in Section 3.1 of [Part2]. Unrecognized header fields
forwarded by a proxy unless the field-name is listed in the MUST be forwarded by a proxy unless the field-name is listed in the
Connection header field (Section 9.1) or the proxy is specifically Connection header field (Section 8.1) or the proxy is specifically
configured to block or otherwise transform such fields. Unrecognized configured to block or otherwise transform such fields. Unrecognized
header fields SHOULD be ignored by other recipients. header fields SHOULD be ignored by other recipients.
The order in which header fields with differing field names are The order in which header fields with differing field names are
received is not significant. However, it is "good practice" to send received is not significant. However, it is "good practice" to send
header fields that contain control data first, such as Host on header fields that contain control data first, such as Host on
requests and Date on responses, so that implementations can decide requests and Date on responses, so that implementations can decide
when not to handle a message as early as possible. A server MUST when not to handle a message as early as possible. A server MUST
wait until the entire header section is received before interpreting wait until the entire header section is received before interpreting
a request message, since later header fields might include a request message, since later header fields might include
skipping to change at page 23, line 38 skipping to change at page 25, line 14
A field value MAY be preceded by optional whitespace (OWS); a single A field value MAY be preceded by optional whitespace (OWS); a single
SP is preferred. The field value does not include any leading or SP is preferred. The field value does not include any leading or
trailing white space: OWS occurring before the first non-whitespace trailing white space: OWS occurring before the first non-whitespace
octet of the field value or after the last non-whitespace octet of octet of the field value or after the last non-whitespace octet of
the field value is ignored and SHOULD be removed before further the field value is ignored and SHOULD be removed before further
processing (as this does not change the meaning of the header field). processing (as this does not change the meaning of the header field).
Historically, HTTP header field values could be extended over Historically, HTTP header field values could be extended over
multiple lines by preceding each extra line with at least one space multiple lines by preceding each extra line with at least one space
or horizontal tab octet (line folding). This specification or horizontal tab (obs-fold). This specification deprecates such
deprecates such line folding except within the message/http media line folding except within the message/http media type
type (Section 10.3.1). HTTP senders MUST NOT produce messages that (Section 9.3.1). HTTP senders MUST NOT produce messages that include
include line folding (i.e., that contain any field-content that line folding (i.e., that contain any field-content that matches the
matches the obs-fold rule) unless the message is intended for obs-fold rule) unless the message is intended for packaging within
packaging within the message/http media type. HTTP recipients SHOULD the message/http media type. HTTP recipients SHOULD accept line
accept line folding and replace any embedded obs-fold whitespace with folding and replace any embedded obs-fold whitespace with either a
either a single SP or a matching number of SP octets (to avoid buffer single SP or a matching number of SP octets (to avoid buffer copying)
copying) prior to interpreting the field value or forwarding the prior to interpreting the field value or forwarding the message
message downstream. downstream.
Historically, HTTP has allowed field content with text in the ISO- Historically, HTTP has allowed field content with text in the ISO-
8859-1 [ISO-8859-1] character encoding and supported other character 8859-1 [ISO-8859-1] character encoding and supported other character
sets only through use of [RFC2047] encoding. In practice, most HTTP sets only through use of [RFC2047] encoding. In practice, most HTTP
header field values use only a subset of the US-ASCII character header field values use only a subset of the US-ASCII character
encoding [USASCII]. Newly defined header fields SHOULD limit their encoding [USASCII]. Newly defined header fields SHOULD limit their
field values to US-ASCII octets. Recipients SHOULD treat other (obs- field values to US-ASCII octets. Recipients SHOULD treat other (obs-
text) octets in field content as opaque data. text) octets in field content as opaque data.
3.2.2. Field Length 3.2.2. Field Length
skipping to change at page 24, line 29 skipping to change at page 26, line 4
Various ad-hoc limitations on header length are found in practice. Various ad-hoc limitations on header length are found in practice.
It is RECOMMENDED that all HTTP senders and recipients support It is RECOMMENDED that all HTTP senders and recipients support
messages whose combined header fields have 4000 or more octets. messages whose combined header fields have 4000 or more octets.
3.2.3. Common Field ABNF Rules 3.2.3. Common Field ABNF Rules
Many HTTP/1.1 header field values consist of words (token or quoted- Many HTTP/1.1 header field values consist of words (token or quoted-
string) separated by whitespace or special characters. These special string) separated by whitespace or special characters. These special
characters MUST be in a quoted string to be used within a parameter characters MUST be in a quoted string to be used within a parameter
value (as defined in Section 6.2). value (as defined in Section 5.1).
word = token / quoted-string word = token / quoted-string
token = 1*tchar token = 1*tchar
tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*"
/ "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
/ DIGIT / ALPHA / DIGIT / ALPHA
; any VCHAR, except special ; any VCHAR, except special
skipping to change at page 25, line 6 skipping to change at page 26, line 29
A string of text is parsed as a single word if it is quoted using A string of text is parsed as a single word if it is quoted using
double-quote marks. double-quote marks.
quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
qdtext = OWS / %x21 / %x23-5B / %x5D-7E / obs-text qdtext = OWS / %x21 / %x23-5B / %x5D-7E / obs-text
obs-text = %x80-FF obs-text = %x80-FF
The backslash octet ("\") can be used as a single-octet quoting The backslash octet ("\") can be used as a single-octet quoting
mechanism within quoted-string constructs: mechanism within quoted-string constructs:
quoted-pair = "\" ( WSP / VCHAR / obs-text ) quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
Recipients that process the value of the quoted-string MUST handle a Recipients that process the value of the quoted-string MUST handle a
quoted-pair as if it were replaced by the octet following the quoted-pair as if it were replaced by the octet following the
backslash. backslash.
Senders SHOULD NOT escape octets in quoted-strings that do not Senders SHOULD NOT escape octets in quoted-strings that do not
require escaping (i.e., other than DQUOTE and the backslash octet). require escaping (i.e., other than DQUOTE and the backslash octet).
Comments can be included in some HTTP header fields by surrounding Comments can be included in some HTTP header fields by surrounding
the comment text with parentheses. Comments are only allowed in the comment text with parentheses. Comments are only allowed in
fields containing "comment" as part of their field value definition. fields containing "comment" as part of their field value definition.
comment = "(" *( ctext / quoted-cpair / comment ) ")" comment = "(" *( ctext / quoted-cpair / comment ) ")"
ctext = OWS / %x21-27 / %x2A-5B / %x5D-7E / obs-text ctext = OWS / %x21-27 / %x2A-5B / %x5D-7E / obs-text
The backslash octet ("\") can be used as a single-octet quoting The backslash octet ("\") can be used as a single-octet quoting
mechanism within comment constructs: mechanism within comment constructs:
quoted-cpair = "\" ( WSP / VCHAR / obs-text ) quoted-cpair = "\" ( HTAB / SP / VCHAR / obs-text )
Senders SHOULD NOT escape octets in comments that do not require Senders SHOULD NOT escape octets in comments that do not require
escaping (i.e., other than the backslash octet "\" and the escaping (i.e., other than the backslash octet "\" and the
parentheses "(" and ")"). parentheses "(" 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
payload body associated with the request or response. payload body associated with the request or response.
message-body = *OCTET message-body = *OCTET
The message-body differs from the payload body only when a transfer- The message-body differs from the payload body only when a transfer-
coding has been applied, as indicated by the Transfer-Encoding header coding has been applied, as indicated by the Transfer-Encoding header
field (Section 9.7). If more than one Transfer-Encoding header field field (Section 8.6). If more than one Transfer-Encoding header field
is present in a message, the multiple field-values MUST be combined is present in a message, the multiple field-values MUST be combined
into one field-value, according to the algorithm defined in into one field-value, according to the algorithm defined in
Section 3.2, before determining the message-body length. Section 3.2, before determining the message-body length.
When one or more transfer-codings are applied to a payload in order When one or more transfer-codings are applied to a payload in order
to form the message-body, the Transfer-Encoding header field MUST to form the message-body, the Transfer-Encoding header field MUST
contain the list of transfer-codings applied. Transfer-Encoding is a contain the list of transfer-codings applied. Transfer-Encoding is a
property of the message, not of the payload, and thus MAY be added or property of the message, not of the payload, and thus MAY be added or
removed by any implementation along the request/response chain under removed by any implementation along the request/response chain under
the constraints found in Section 6.2. the constraints found in Section 5.1.
If a message is received that has multiple Content-Length header If a message is received that has multiple Content-Length header
fields (Section 9.2) with field-values consisting of the same decimal fields (Section 8.2) with field-values consisting of the same decimal
value, or a single Content-Length header field with a field value value, or a single Content-Length header field with a field value
containing a list of identical decimal values (e.g., "Content-Length: containing a list of identical decimal values (e.g., "Content-Length:
42, 42"), indicating that duplicate Content-Length header fields have 42, 42"), indicating that duplicate Content-Length header fields have
been generated or combined by an upstream message processor, then the been generated or combined by an upstream message processor, then the
recipient MUST either reject the message as invalid or replace the recipient MUST either reject the message as invalid or replace the
duplicated field-values with a single valid Content-Length field duplicated field-values with a single valid Content-Length field
containing that decimal value prior to determining the message-body containing that decimal value prior to determining the message-body
length. length.
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, even if the request method does not the request's header fields, even if the request method does not
define any use for a message-body. This allows the request message define any use for a message-body. This allows the request message
framing algorithm to be independent of method semantics. framing algorithm to be independent of method semantics.
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). Responses to the HEAD request method status code (Section 3.1.2.1). Responses to the HEAD request method
never include a message-body because the associated response header never include a message-body because the associated response header
fields (e.g., Transfer-Encoding, Content-Length, etc.) only indicate fields (e.g., Transfer-Encoding, Content-Length, etc.) only indicate
what their values would have been if the request method had been GET. what their values would have been if the request method had been GET.
All 1xx (Informational), 204 (No Content), and 304 (Not Modified) All 1xx (Informational), 204 (No Content), and 304 (Not Modified)
responses MUST NOT include a message-body. All other responses do responses MUST NOT include a message-body. All other responses do
include a message-body, although the body MAY be of zero length. include a message-body, although the body MAY be of zero length.
The length of the message-body is determined by one of the following The length of the message-body is determined by one of the following
(in order of precedence): (in order of precedence):
1. Any response to a HEAD request and any response with a status 1. Any response to a HEAD request and any response with a status
code of 100-199, 204, or 304 is always terminated by the first code of 100-199, 204, or 304 is always terminated by the first
empty line after the header fields, regardless of the header empty line after the header fields, regardless of the header
fields present in the message, and thus cannot contain a message- fields present in the message, and thus cannot contain a message-
body. body.
2. If a Transfer-Encoding header field is present and the "chunked" 2. If a Transfer-Encoding header field is present and the "chunked"
transfer-coding (Section 6.2) is the final encoding, the message- transfer-coding (Section 5.1) is the final encoding, the message-
body length is determined by reading and decoding the chunked body length is determined by reading and decoding the chunked
data until the transfer-coding indicates the data is complete. data until the transfer-coding indicates the data is complete.
If a Transfer-Encoding header field is present in a response and If a Transfer-Encoding header field is present in a response and
the "chunked" transfer-coding is not the final encoding, the the "chunked" transfer-coding is not the final encoding, the
message-body length is determined by reading the connection until message-body length is determined by reading the connection until
it is closed by the server. If a Transfer-Encoding header field it is closed by the server. If a Transfer-Encoding header field
is present in a request and the "chunked" transfer-coding is not is present in a request and the "chunked" transfer-coding is not
the final encoding, the message-body length cannot be determined the final encoding, the message-body length cannot be determined
reliably; the server MUST respond with the 400 (Bad Request) reliably; the server MUST respond with the 400 (Bad Request)
skipping to change at page 28, line 36 skipping to change at page 30, line 9
requires a content-length in advance of being called and the server requires a content-length in advance of being called and the server
is unable or unwilling to buffer the entire request before is unable or unwilling to buffer the entire request before
processing. processing.
A client that sends a request containing a message-body MUST include 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 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 will handle HTTP/1.1 (or later) requests; such knowledge can be in
the form of specific user configuration or by remembering the version the form of specific user configuration or by remembering the version
of a prior received response. of a prior received response.
3.4. Incomplete Messages 3.4. Handling Incomplete Messages
Request messages that are prematurely terminated, possibly due to a Request messages that are prematurely terminated, possibly due to a
cancelled connection or a server-imposed time-out exception, MUST cancelled connection or a server-imposed time-out exception, MUST
result in closure of the connection; sending an HTTP/1.1 error result in closure of the connection; sending an HTTP/1.1 error
response prior to closing the connection is OPTIONAL. response prior to closing the connection is OPTIONAL.
Response messages that are prematurely terminated, usually by closure Response messages that are prematurely terminated, usually by closure
of the connection prior to receiving the expected number of octets or of the connection prior to receiving the expected number of octets or
by failure to decode a transfer-encoded message-body, MUST be by failure to decode a transfer-encoded message-body, MUST be
recorded as incomplete. A response that terminates in the middle of recorded as incomplete. A response that terminates in the middle of
skipping to change at page 29, line 23 skipping to change at page 30, line 45
if it were complete (i.e., some indication must be given to the user if it were complete (i.e., some indication must be given to the user
that an error occurred). Cache requirements for incomplete responses that an error occurred). Cache requirements for incomplete responses
are defined in Section 2.1 of [Part6]. are defined in Section 2.1 of [Part6].
A server MUST read the entire request message-body or close the A server MUST read the entire request message-body or close the
connection after sending its response, since otherwise the remaining connection after sending its response, since otherwise the remaining
data on a persistent connection would be misinterpreted as the next data on a persistent connection would be misinterpreted as the next
request. Likewise, a client MUST read the entire response message- request. Likewise, a client MUST read the entire response message-
body if it intends to reuse the same connection for a subsequent body if it intends to reuse the same connection for a subsequent
request. Pipelining multiple requests on a connection is described request. Pipelining multiple requests on a connection is described
in Section 7.1.2.2. in Section 6.1.2.2.
3.5. General Header Fields
There are a few header fields which have general applicability for
both request and response messages, but which do not apply to the
payload being transferred. These header fields apply only to the
message being transmitted.
+-------------------+---------------+
| Header Field Name | Defined in... |
+-------------------+---------------+
| Connection | Section 9.1 |
| Date | Section 9.3 |
| Trailer | Section 9.6 |
| Transfer-Encoding | Section 9.7 |
| Upgrade | Section 9.8 |
| Via | Section 9.9 |
+-------------------+---------------+
4. Request
A request message from a client to a server begins with a Request-
Line, followed by zero or more header fields, an empty line
signifying the end of the header block, and an optional message body.
Request = Request-Line ; Section 4.1
*( header-field CRLF ) ; Section 3.2
CRLF
[ message-body ] ; Section 3.3
4.1. Request-Line
The Request-Line begins with a method token, followed by a single
space (SP), the request-target, another single space (SP), the
protocol version, and ending with CRLF.
Request-Line = Method SP request-target SP HTTP-Version CRLF 3.5. Message Parsing Robustness
4.1.1. Method Older HTTP/1.0 client implementations might send an extra CRLF after
a POST request as a lame workaround for some early server
applications that failed to read message-body content that was not
terminated by a line-ending. An HTTP/1.1 client MUST NOT preface or
follow a request with an extra CRLF. If terminating the request
message-body with a line-ending is desired, then the client MUST
include the terminating CRLF octets as part of the message-body
length.
The Method token indicates the request method to be performed on the In the interest of robustness, servers SHOULD ignore at least one
target resource. The request method is case-sensitive. empty line received where a Request-Line is expected. In other
words, if the server is reading the protocol stream at the beginning
of a message and receives a CRLF first, it SHOULD ignore the CRLF.
Likewise, although the line terminator for the start-line and header
fields is the sequence CRLF, we recommend that recipients recognize a
single LF as a line terminator and ignore any CR.
Method = token When a server listening only for HTTP request messages, or processing
what appears from the start-line to be an HTTP request message,
receives a sequence of octets that does not match the HTTP-message
grammar aside from the robustness exceptions listed above, the server
MUST respond with an HTTP/1.1 400 (Bad Request) response.
4.1.2. request-target 4. Message Routing
The request-target identifies the target resource upon which to apply In most cases, the user agent is provided a URI reference from which
the request. In most cases, the user agent is provided a URI it determines an absolute URI for identifying the target resource.
reference from which it determines an absolute URI for identifying When a request to the resource is initiated, all or part of that URI
the target resource. When a request to the resource is initiated, is used to construct the HTTP request-target.
all or part of that URI is used to construct the HTTP request-target.
request-target = "*" 4.1. Types of Request Target
/ absolute-URI
/ ( path-absolute [ "?" query ] )
/ authority
The four options for request-target are dependent on the nature of The four options for request-target are dependent on the nature of
the request. the request.
The asterisk "*" form of request-target, which MUST NOT be used with The asterisk "*" form of request-target, which MUST NOT be used with
any request method other than OPTIONS, means that the request applies any request method other than OPTIONS, means that the request applies
to the server as a whole (the listening process) rather than to a to the server as a whole (the listening process) rather than to a
specific named resource at that server. For example, specific named resource at that server. For example,
OPTIONS * HTTP/1.1 OPTIONS * HTTP/1.1
skipping to change at page 31, line 20 skipping to change at page 32, line 18
versions of HTTP, all HTTP/1.1 servers MUST accept the absolute-URI versions of HTTP, all HTTP/1.1 servers MUST accept the absolute-URI
form in requests, even though HTTP/1.1 clients will only generate form in requests, even though HTTP/1.1 clients will only generate
them in requests to proxies. them in requests to proxies.
If a proxy receives a host name that is not a fully qualified domain If a proxy receives a host name that is not a fully qualified domain
name, it MAY add its domain to the host name it received. If a proxy name, it MAY add its domain to the host name it received. If a proxy
receives a fully qualified domain name, the proxy MUST NOT change the receives a fully qualified domain name, the proxy MUST NOT change the
host name. host name.
The "authority form" is only used by the CONNECT request method The "authority form" is only used by the CONNECT request method
(Section 7.9 of [Part2]). (Section 6.9 of [Part2]).
The most common form of request-target is that used when making a The most common form of request-target is that used when making a
request to an origin server ("origin form"). In this case, the request to an origin server ("origin form"). In this case, the
absolute path and query components of the URI MUST be transmitted as absolute path and query components of the URI MUST be transmitted as
the request-target, and the authority component MUST be transmitted the request-target, and the authority component MUST be transmitted
in a Host header field. For example, a client wishing to retrieve a in a Host header field. For example, a client wishing to retrieve a
representation of the resource, as identified above, directly from representation of the resource, as identified above, directly from
the origin server would open (or reuse) a TCP connection to port 80 the origin server would open (or reuse) a TCP connection to port 80
of the host "www.example.org" and send the lines: of the host "www.example.org" and send the lines:
skipping to change at page 32, line 29 skipping to change at page 33, line 29
the received request-target when forwarding it to the next inbound the received request-target when forwarding it to the next inbound
server, except as noted above to replace a null path-absolute with server, except as noted above to replace a null path-absolute with
"/" or "*". "/" or "*".
Note: The "no rewrite" rule prevents the proxy from changing the Note: The "no rewrite" rule prevents the proxy from changing the
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
need to 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-
target. A server MUST be prepared to receive URIs of unbounded
length and respond with the 414 (URI Too Long) status code if the
received request-target would be longer than the server wishes to
handle (see Section 8.4.15 of [Part2]).
Various ad-hoc limitations on request-target length are found in
practice. It is RECOMMENDED that all HTTP senders and recipients
support request-target lengths of 8000 or more octets.
Note: Fragments ([RFC3986], Section 3.5) are not part of the
request-target and thus will not be transmitted in an HTTP
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.
An origin server that does not allow resources to differ by the An origin server that does not allow resources to differ by the
requested host MAY ignore the Host header field value when requested host MAY ignore the Host header field value when
determining the resource identified by an HTTP/1.1 request. (But see determining the resource identified by an HTTP/1.1 request. (But see
Appendix A.1.1 for other requirements on Host support in HTTP/1.1.) Appendix A.1.1 for other requirements on Host support in HTTP/1.1.)
An origin server that does differentiate resources based on the host An origin server that does differentiate resources based on the host
requested (sometimes referred to as virtual hosts or vanity host requested (sometimes referred to as virtual hosts or vanity host
names) MUST use the following rules for determining the requested names) MUST use the following rules for determining the requested
resource on an HTTP/1.1 request: resource on an HTTP/1.1 request:
1. If request-target is an absolute-URI, the host is part of the 1. If request-target is an absolute-URI, the host is part of the
request-target. Any Host header field value in the request MUST request-target. Any Host header field value in the request MUST
be ignored. be ignored.
2. If the request-target is not an absolute-URI, and the request 2. If the request-target is not an absolute-URI, and the request
skipping to change at page 33, line 49 skipping to change at page 34, line 37
form, and the Host header field is present, then the effective form, and the Host header field is present, then the effective
request URI is constructed by concatenating request 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 a SSL/ insecure TCP connection, or "https" when received over a SSL/
TLS-secured TCP connection, TLS-secured TCP connection,
o the octet sequence "://", o the octet sequence "://",
o the authority component, as specified in the Host header field o the authority component, as specified in the Host header field
(Section 9.4), and (Section 8.3), 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 "*".
If the request-target uses the path-absolute form or the asterisk If the request-target uses the path-absolute form or the asterisk
form, and the Host header field is not present, then the effective form, and the Host header field is not present, then the effective
request URI is undefined. request URI is undefined.
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.
skipping to change at page 34, line 38 skipping to change at page 35, line 28
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.7.3, except that empty path components MUST NOT be treated Section 2.7.3, except that empty path components MUST NOT be treated
as equivalent to an absolute path of "/". as equivalent to an absolute path of "/".
5. Response 5. Protocol Parameters
After receiving and interpreting a request message, a server responds
with an HTTP response message.
Response = Status-Line ; Section 5.1
*( header-field CRLF ) ; Section 3.2
CRLF
[ message-body ] ; Section 3.3
5.1. Status-Line
The first line of a Response message is the Status-Line, consisting
of the protocol version, a space (SP), the status code, another
space, a possibly-empty textual phrase describing the status code,
and ending with CRLF.
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
5.1.1. Status Code and Reason Phrase
The Status-Code element is a 3-digit integer result code of the
attempt to understand and satisfy the request. These codes are fully
defined in Section 8 of [Part2]. The Reason Phrase exists for the
sole purpose of providing a textual description associated with the
numeric status code, out of deference to earlier Internet application
protocols that were more frequently used with interactive text
clients. A client SHOULD ignore the content of the Reason Phrase.
The first digit of the Status-Code defines the class of response.
The last two digits do not have any categorization role. There are 5
values for the first digit:
o 1xx: Informational - Request received, continuing process
o 2xx: Success - The action was successfully received, understood,
and accepted
o 3xx: Redirection - Further action must be taken in order to
complete the request
o 4xx: Client Error - The request contains bad syntax or cannot be
fulfilled
o 5xx: Server Error - The server failed to fulfill an apparently
valid request
Status-Code = 3DIGIT
Reason-Phrase = *( WSP / VCHAR / obs-text )
6. Protocol Parameters
6.1. Date/Time Formats: Full Date
HTTP applications have historically allowed three different formats
for date/time stamps. However, the preferred format is a fixed-
length subset of that defined by [RFC1123]:
Sun, 06 Nov 1994 08:49:37 GMT ; RFC 1123
The other formats are described here only for compatibility with
obsolete implementations.
Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format
Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
HTTP/1.1 clients and servers that parse a date value MUST accept all
three formats (for compatibility with HTTP/1.0), though they MUST
only generate the RFC 1123 format for representing HTTP-date values
in header fields.
All HTTP date/time stamps MUST be represented in Greenwich Mean Time
(GMT), without exception. For the purposes of HTTP, GMT is exactly
equal to UTC (Coordinated Universal Time). This is indicated in the
first two formats by the inclusion of "GMT" as the three-letter
abbreviation for time zone, and MUST be assumed when reading the
asctime format. HTTP-date is case sensitive and MUST NOT include
additional whitespace beyond that specifically included as SP in the
grammar.
HTTP-date = rfc1123-date / obs-date
Preferred format:
rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT
; fixed length subset of the format defined in
; Section 5.2.14 of [RFC1123]
day-name = %x4D.6F.6E ; "Mon", case-sensitive
/ %x54.75.65 ; "Tue", case-sensitive
/ %x57.65.64 ; "Wed", case-sensitive
/ %x54.68.75 ; "Thu", case-sensitive
/ %x46.72.69 ; "Fri", case-sensitive
/ %x53.61.74 ; "Sat", case-sensitive
/ %x53.75.6E ; "Sun", case-sensitive
date1 = day SP month SP year
; e.g., 02 Jun 1982
day = 2DIGIT
month = %x4A.61.6E ; "Jan", case-sensitive
/ %x46.65.62 ; "Feb", case-sensitive
/ %x4D.61.72 ; "Mar", case-sensitive
/ %x41.70.72 ; "Apr", case-sensitive
/ %x4D.61.79 ; "May", case-sensitive
/ %x4A.75.6E ; "Jun", case-sensitive
/ %x4A.75.6C ; "Jul", case-sensitive
/ %x41.75.67 ; "Aug", case-sensitive
/ %x53.65.70 ; "Sep", case-sensitive
/ %x4F.63.74 ; "Oct", case-sensitive
/ %x4E.6F.76 ; "Nov", case-sensitive
/ %x44.65.63 ; "Dec", case-sensitive
year = 4DIGIT
GMT = %x47.4D.54 ; "GMT", case-sensitive
time-of-day = hour ":" minute ":" second
; 00:00:00 - 23:59:59
hour = 2DIGIT
minute = 2DIGIT
second = 2DIGIT
The semantics of day-name, day, month, year, and time-of-day are the
same as those defined for the RFC 5322 constructs with the
corresponding name ([RFC5322], Section 3.3).
Obsolete formats:
obs-date = rfc850-date / asctime-date
rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT
date2 = day "-" month "-" 2DIGIT
; day-month-year (e.g., 02-Jun-82)
day-name-l = %x4D.6F.6E.64.61.79 ; "Monday", case-sensitive
/ %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive
/ %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive
/ %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive
/ %x46.72.69.64.61.79 ; "Friday", case-sensitive
/ %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive
/ %x53.75.6E.64.61.79 ; "Sunday", case-sensitive
asctime-date = day-name SP date3 SP time-of-day SP year
date3 = month SP ( 2DIGIT / ( SP 1DIGIT ))
; month day (e.g., Jun 2)
Note: Recipients of date values are encouraged to be robust in
accepting date values that might have been sent by non-HTTP
applications, as is sometimes the case when retrieving or posting
messages via proxies/gateways to SMTP or NNTP.
Note: HTTP requirements for the date/time stamp format apply only
to their usage within the protocol stream. Clients and servers
are not required to use these formats for user presentation,
request logging, etc.
6.2. Transfer Codings 5.1. 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 might need to be applied to transformation that has been, can be, or might need to be applied to
a payload body in order to ensure "safe transport" through the a payload body in order to ensure "safe transport" through the
network. This differs from a content coding in that the transfer- network. This differs from a content coding in that the transfer-
coding is a property of the message rather than a property of the coding is a property of the message rather than a property of the
representation that is being transferred. representation that is being transferred.
transfer-coding = "chunked" ; Section 6.2.1 transfer-coding = "chunked" ; Section 5.1.1
/ "compress" ; Section 6.2.2.1 / "compress" ; Section 5.1.2.1
/ "deflate" ; Section 6.2.2.2 / "deflate" ; Section 5.1.2.2
/ "gzip" ; Section 6.2.2.3 / "gzip" ; Section 5.1.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 8.4) and in
the Transfer-Encoding header field (Section 9.7). the Transfer-Encoding header field (Section 8.6).
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 message message-bodies is the difficulty in determining the exact message
body length (Section 3.3), or the desire to encrypt data over a body length (Section 3.3), or the desire to encrypt data over a
shared transport. shared transport.
A server that receives a request message with a transfer-coding it A server that receives a request message with a transfer-coding it
does not understand SHOULD respond with 501 (Not Implemented) and does not understand SHOULD respond with 501 (Not Implemented) and
then close the connection. A server MUST NOT send transfer-codings then close the connection. A server MUST NOT send transfer-codings
to an HTTP/1.0 client. to an HTTP/1.0 client.
6.2.1. Chunked Transfer Coding 5.1.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 header fields. This followed by an OPTIONAL trailer containing header fields. This
allows dynamically produced content to be transferred along with the allows dynamically produced content to be transferred along with 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 [ 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") [ chunk-ext ] CRLF
chunk-ext = *( ";" *WSP chunk-ext-name chunk-ext = *( ";" chunk-ext-name
[ "=" chunk-ext-val ] *WSP ) [ "=" chunk-ext-val ] )
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 = *( header-field 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 = HTAB / SP / %x21 / %x23-5B / %x5D-7E / obs-text
; WSP / <VCHAR except DQUOTE and "\"> / obs-text
The chunk-size field is a string of hex digits indicating the size of The chunk-size field is a string of hex digits indicating the size of
the chunk-data in octets. The chunked encoding is ended by any chunk the chunk-data in octets. The chunked encoding is ended by any chunk
whose size is zero, followed by the trailer, which is terminated by whose size is zero, followed by the trailer, which is terminated by
an empty line. an empty line.
The trailer allows the sender to include additional HTTP header The trailer allows the sender to include additional HTTP header
fields at the end of the message. The Trailer header field can be fields at the end of the message. The Trailer header field can be
used to indicate which header fields are included in a trailer (see used to indicate which header fields are included in a trailer (see
Section 9.6). Section 8.5).
A server using chunked transfer-coding in a response MUST NOT use the A server using chunked transfer-coding in a response MUST NOT use the
trailer for any header fields unless at least one of the following is trailer for any header fields unless at least one of the following is
true: true:
1. the request included a TE header field that indicates "trailers" 1. the request included a TE header field that indicates "trailers"
is acceptable in the transfer-coding of the response, as is acceptable in the transfer-coding of the response, as
described in Section 9.5; or, described in Section 8.4; or,
2. the trailer fields consist entirely of optional metadata, and the 2. the trailer fields consist entirely of optional metadata, and the
recipient could use the message (in a manner acceptable to the recipient could use the message (in a manner acceptable to the
server where the field originated) without receiving it. In server where the field originated) without receiving it. In
other words, the server that generated the header (often but not other words, the server that generated the header (often but not
always the origin server) is willing to accept the possibility always the origin server) is willing to accept the possibility
that the trailer fields might be silently discarded along the that the trailer fields might be silently discarded along the
path to the client. path to the client.
This requirement prevents an interoperability failure when the This requirement prevents an interoperability failure when the
skipping to change at page 41, line 37 skipping to change at page 38, line 22
messages on a persistent connection. Whenever a transfer-coding is messages on a persistent connection. Whenever a transfer-coding is
applied to a payload body in a request, the final transfer-coding applied to a payload body in a request, the final transfer-coding
applied MUST be "chunked". If a transfer-coding is applied to a applied MUST be "chunked". If a transfer-coding is applied to a
response payload body, then either the final transfer-coding applied response payload body, then either the final transfer-coding applied
MUST be "chunked" or the message MUST be terminated by closing the MUST be "chunked" or the message MUST be terminated by closing the
connection. When the "chunked" transfer-coding is used, it MUST be connection. When the "chunked" transfer-coding is used, it MUST be
the last transfer-coding applied to form the message-body. The the last transfer-coding applied to form the message-body. The
"chunked" transfer-coding MUST NOT be applied more than once in a "chunked" transfer-coding MUST NOT be applied more than once in a
message-body. message-body.
6.2.2. Compression Codings 5.1.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.
Note: For compatibility with previous implementations of HTTP, Note: For compatibility with previous implementations of HTTP,
applications SHOULD consider "x-gzip" and "x-compress" to be applications SHOULD consider "x-gzip" and "x-compress" to be
equivalent to "gzip" and "compress" respectively. equivalent to "gzip" and "compress" respectively.
6.2.2.1. Compress Coding 5.1.2.1. Compress Coding
The "compress" format is produced by the common UNIX file compression The "compress" format is produced by the common UNIX file compression
program "compress". This format is an adaptive Lempel-Ziv-Welch program "compress". This format is an adaptive Lempel-Ziv-Welch
coding (LZW). coding (LZW).
6.2.2.2. Deflate Coding 5.1.2.2. Deflate Coding
The "deflate" format is defined as the "deflate" compression The "deflate" format is defined as the "deflate" compression
mechanism (described in [RFC1951]) used inside the "zlib" data format mechanism (described in [RFC1951]) used inside the "zlib" data format
([RFC1950]). ([RFC1950]).
Note: Some incorrect implementations send the "deflate" compressed Note: Some incorrect implementations send the "deflate" compressed
data without the zlib wrapper. data without the zlib wrapper.
6.2.2.3. Gzip Coding 5.1.2.3. Gzip Coding
The "gzip" format is produced by the file compression program "gzip" The "gzip" format is produced by the file compression program "gzip"
(GNU zip), as described in [RFC1952]. This format is a Lempel-Ziv (GNU zip), as described in [RFC1952]. This format is a Lempel-Ziv
coding (LZ77) with a 32 bit CRC. coding (LZ77) with a 32 bit CRC.
6.2.3. Transfer Coding Registry 5.1.3. Transfer Coding Registry
The HTTP Transfer Coding Registry defines the name space for the The HTTP Transfer Coding Registry defines the name space for the
transfer coding names. transfer coding names.
Registrations MUST include the following fields: Registrations MUST include the following fields:
o Name o Name
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 5.1.2).
Values to be added to this name space require a specification (see Values to be added to this name space require a specification (see
"Specification Required" in Section 4.1 of [RFC5226]), and MUST "Specification Required" in Section 4.1 of [RFC5226]), and MUST
conform to the purpose of transfer coding defined in this section. conform to the purpose of 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 5.2. 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
convention, the products are listed in order of their significance convention, the products are listed in order of their significance
for identifying the application. for identifying the application.
product = token ["/" product-version] product = token ["/" product-version]
product-version = token product-version = token
skipping to change at page 43, line 29 skipping to change at page 40, line 12
User-Agent: CERN-LineMode/2.15 libwww/2.17b3 User-Agent: CERN-LineMode/2.15 libwww/2.17b3
Server: Apache/0.8.4 Server: Apache/0.8.4
Product tokens SHOULD be short and to the point. They MUST NOT be Product tokens SHOULD be short and to the point. They MUST NOT be
used for advertising or other non-essential information. Although used for advertising or other non-essential information. Although
any token octet MAY appear in a product-version, this token SHOULD any token octet MAY appear in a product-version, this token SHOULD
only be used for a version identifier (i.e., successive versions of only be used for a version identifier (i.e., successive versions of
the same product SHOULD only differ in the product-version portion of the same product SHOULD only differ in the product-version portion of
the product value). the product value).
6.4. Quality Values 5.3. Quality Values
Both transfer codings (TE request header field, Section 9.5) and Both transfer codings (TE request header field, Section 8.4) and
content negotiation (Section 5 of [Part3]) use short "floating point" content negotiation (Section 5 of [Part3]) use short "floating point"
numbers to indicate the relative importance ("weight") of various numbers to indicate the relative importance ("weight") of various
negotiable parameters. A weight is normalized to a real number in negotiable parameters. A weight is normalized to a real number in
the range 0 through 1, where 0 is the minimum and 1 the maximum the range 0 through 1, where 0 is the minimum and 1 the maximum
value. If a parameter has a quality value of 0, then content with value. If a parameter has a quality value of 0, then content with
this parameter is "not acceptable" for the client. HTTP/1.1 this parameter is "not acceptable" for the client. HTTP/1.1
applications MUST NOT generate more than three digits after the applications MUST NOT generate more than three digits after the
decimal point. User configuration of these values SHOULD also be decimal point. User configuration of these values SHOULD also be
limited in this fashion. limited in this fashion.
qvalue = ( "0" [ "." 0*3DIGIT ] ) qvalue = ( "0" [ "." 0*3DIGIT ] )
/ ( "1" [ "." 0*3("0") ] ) / ( "1" [ "." 0*3("0") ] )
Note: "Quality values" is a misnomer, since these values merely Note: "Quality values" is a misnomer, since these values merely
represent relative degradation in desired quality. represent relative degradation in desired quality.
7. Connections 6. Connections
7.1. Persistent Connections
7.1.1. Purpose 6.1. Persistent Connections
6.1.1. Purpose
Prior to persistent connections, a separate TCP connection was Prior to persistent connections, a separate TCP connection was
established for each request, increasing the load on HTTP servers and established for each request, increasing the load on HTTP servers and
causing congestion on the Internet. The use of inline images and causing congestion on the Internet. The use of inline images and
other associated data often requires a client to make multiple other associated data often requires a client to make multiple
requests of the same server in a short amount of time. Analysis of requests of the same server in a short amount of time. Analysis of
these performance problems and results from a prototype these performance problems and results from a prototype
implementation are available [Pad1995] [Spe]. Implementation implementation are available [Pad1995] [Spe]. Implementation
experience and measurements of actual HTTP/1.1 implementations show experience and measurements of actual HTTP/1.1 implementations show
good results [Nie1997]. Alternatives have also been explored, for good results [Nie1997]. Alternatives have also been explored, for
skipping to change at page 44, line 46 skipping to change at page 41, line 26
spent in TCP's connection opening handshake. spent in TCP's connection opening handshake.
o HTTP can evolve more gracefully, since errors can be reported o HTTP can evolve more gracefully, since errors can be reported
without the penalty of closing the TCP connection. Clients using without the penalty of closing the TCP connection. Clients using
future versions of HTTP might optimistically try a new feature, future versions of HTTP might optimistically try a new feature,
but if communicating with an older server, retry with old but if communicating with an older server, retry with old
semantics after an error is reported. semantics after an error is reported.
HTTP implementations SHOULD implement persistent connections. HTTP implementations SHOULD implement persistent connections.
7.1.2. Overall Operation 6.1.2. Overall Operation
A significant difference between HTTP/1.1 and earlier versions of A significant difference between HTTP/1.1 and earlier versions of
HTTP is that persistent connections are the default behavior of any HTTP is that persistent connections are the default behavior of any
HTTP connection. That is, unless otherwise indicated, the client HTTP connection. That is, unless otherwise indicated, the client
SHOULD assume that the server will maintain a persistent connection, SHOULD assume that the server will maintain a persistent connection,
even after error responses from the server. even after error responses from the server.
Persistent connections provide a mechanism by which a client and a Persistent connections provide a mechanism by which a client and a
server can signal the close of a TCP connection. This signaling server can signal the close of a TCP connection. This signaling
takes place using the Connection header field (Section 9.1). Once a takes place using the Connection header field (Section 8.1). Once a
close has been signaled, the client MUST NOT send any more requests close has been signaled, the client MUST NOT send any more requests
on that connection. on that connection.
7.1.2.1. Negotiation 6.1.2.1. Negotiation
An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to
maintain a persistent connection unless a Connection header field maintain a persistent connection unless a Connection header field
including the connection-token "close" was sent in the request. If including the connection-token "close" was sent in the request. If
the server chooses to close the connection immediately after sending the server chooses to close the connection immediately after sending
the response, it SHOULD send a Connection header field including the the response, it SHOULD send a Connection header field including the
connection-token "close". connection-token "close".
An HTTP/1.1 client MAY expect a connection to remain open, but would An HTTP/1.1 client MAY expect a connection to remain open, but would
decide to keep it open based on whether the response from a server decide to keep it open based on whether the response from a server
skipping to change at page 45, line 41 skipping to change at page 42, line 22
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 A.1.2 for more information on backward signaled. See Appendix A.1.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.3. of the connection), as described in Section 3.3.
7.1.2.2. Pipelining 6.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
connection if the first pipelined attempt fails. If a client does connection if the first pipelined attempt fails. If a client does
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 request Clients SHOULD NOT pipeline requests using non-idempotent request
methods or non-idempotent sequences of request methods (see Section methods or non-idempotent sequences of request methods (see Section
7.1.2 of [Part2]). Otherwise, a premature termination of the 6.1.2 of [Part2]). Otherwise, a premature termination of the
transport connection could lead to indeterminate results. A client transport connection could lead to indeterminate results. A client
wishing to send a non-idempotent request SHOULD wait to send that wishing to send a non-idempotent request SHOULD wait to send that
request until it has received the response status line for the request until it has received the response status line for the
previous request. previous request.
7.1.3. Proxy Servers 6.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 8.1.
The proxy server MUST signal persistent connections separately with The proxy server MUST signal persistent connections separately with
its clients and the origin servers (or other proxy servers) that it its clients and the origin servers (or other proxy servers) that it
connects to. Each persistent connection applies to only one connects to. Each persistent connection applies to only one
transport link. transport link.
A proxy server MUST NOT establish a HTTP/1.1 persistent connection A proxy server MUST NOT establish a HTTP/1.1 persistent connection
with an HTTP/1.0 client (but see Section 19.7.1 of [RFC2068] for with an HTTP/1.0 client (but see Section 19.7.1 of [RFC2068] for
information and discussion of the problems with the Keep-Alive header information and discussion of the problems with the Keep-Alive header
field implemented by many HTTP/1.0 clients). field implemented by many HTTP/1.0 clients).
7.1.3.1. End-to-end and Hop-by-hop Header Fields 6.1.3.1. End-to-end and Hop-by-hop Header Fields
For the purpose of defining the behavior of caches and non-caching For the purpose of defining the behavior of caches and non-caching
proxies, we divide HTTP header fields into two categories: proxies, we divide HTTP header fields into two categories:
o End-to-end header fields, which are transmitted to the ultimate o End-to-end header fields, which are transmitted to the ultimate
recipient of a request or response. End-to-end header fields in recipient of a request or response. End-to-end header fields in
responses MUST be stored as part of a cache entry and MUST be responses MUST be stored as part of a cache entry and MUST be
transmitted in any response formed from a cache entry. transmitted in any response formed from a cache entry.
o Hop-by-hop header fields, which are meaningful only for a single o Hop-by-hop header fields, which are meaningful only for a single
skipping to change at page 47, line 20 skipping to change at page 43, line 48
o Trailer o Trailer
o Transfer-Encoding o Transfer-Encoding
o Upgrade o Upgrade
All other header fields defined by HTTP/1.1 are end-to-end header All other header fields defined by HTTP/1.1 are end-to-end header
fields. fields.
Other hop-by-hop header fields MUST be listed in a Connection header Other hop-by-hop header fields MUST be listed in a Connection header
field (Section 9.1). field (Section 8.1).
7.1.3.2. Non-modifiable Header Fields 6.1.3.2. Non-modifiable Header Fields
Some features of HTTP/1.1, such as Digest Authentication, depend on Some features of HTTP/1.1, such as Digest Authentication, depend on
the value of certain end-to-end header fields. A non-transforming the value of certain end-to-end header fields. A non-transforming
proxy SHOULD NOT modify an end-to-end header field unless the proxy SHOULD NOT modify an end-to-end header field unless the
definition of that header field requires or specifically allows that. definition of that header field requires or specifically allows that.
A non-transforming proxy MUST NOT modify any of the following fields A non-transforming proxy MUST NOT modify any of the following fields
in a request or response, and it MUST NOT add any of these fields if in a request or response, and it MUST NOT add any of these fields if
not already present: not already present:
skipping to change at page 48, line 29 skipping to change at page 45, line 13
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 header fields Warning: Unnecessary modification of end-to-end header fields
might cause authentication failures if stronger authentication might 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.
A non-transforming proxy MUST preserve the message payload ([Part3]), A non-transforming proxy MUST preserve the message payload ([Part3]),
though it MAY change the message-body through application or removal though it MAY change the message-body through application or removal
of a transfer-coding (Section 6.2). of a transfer-coding (Section 5.1).
7.1.4. Practical Considerations 6.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.
When a client or server wishes to time-out it SHOULD issue a graceful When a client or server wishes to time-out it SHOULD issue a graceful
close on the transport connection. Clients and servers SHOULD both close on the transport connection. Clients and servers SHOULD both
skipping to change at page 49, line 6 skipping to change at page 45, line 38
the other side's close promptly it could cause unnecessary resource the other side's close promptly it could cause unnecessary resource
drain on the network. drain on the network.
A client, server, or proxy MAY close the transport connection at any A client, server, or proxy MAY close the transport connection at any
time. For example, a client might have started to send a new request time. For example, a client might have started to send a new request
at the same time that the server has decided to close the "idle" at the same time that the server has decided to close the "idle"
connection. From the server's point of view, the connection is being connection. From the server's point of view, the connection is being
closed while it was idle, but from the client's point of view, a closed while it was idle, but from the client's point of view, a
request is in progress. request is in progress.
This means that clients, servers, and proxies MUST be able to recover
from asynchronous close events. Client software SHOULD reopen the
transport connection and retransmit the aborted sequence of requests
without user interaction so long as the request sequence is
idempotent (see Section 7.1.2 of [Part2]). Non-idempotent request
methods or sequences MUST NOT be automatically retried, although user
agents MAY offer a human operator the choice of retrying the
request(s). Confirmation by user-agent software with semantic
understanding of the application MAY substitute for user
confirmation. The automatic retry SHOULD NOT be repeated if the
second sequence of requests fails.
Servers SHOULD always respond to at least one request per connection,
if at all possible. Servers SHOULD NOT close a connection in the
middle of transmitting a response, unless a network or client failure
is suspected.
Clients (including proxies) SHOULD limit the number of simultaneous Clients (including proxies) SHOULD limit the number of simultaneous
connections that they maintain to a given server (including proxies). connections that they maintain to a given server (including proxies).
Previous revisions of HTTP gave a specific number of connections as a Previous revisions of HTTP gave a specific number of connections as a
ceiling, but this was found to be impractical for many applications. ceiling, but this was found to be impractical for many applications.
As a result, this specification does not mandate a particular maximum As a result, this specification does not mandate a particular maximum
number of connections, but instead encourages clients to be number of connections, but instead encourages clients to be
conservative when opening multiple connections. conservative when opening multiple connections.
In particular, while using multiple connections avoids the "head-of- In particular, while using multiple connections avoids the "head-of-
line blocking" problem (whereby a request that takes significant line blocking" problem (whereby a request that takes significant
server-side processing and/or has a large payload can block server-side processing and/or has a large payload can block
subsequent requests on the same connection), each connection used subsequent requests on the same connection), each connection used
consumes server resources (sometimes significantly), and furthermore consumes server resources (sometimes significantly), and furthermore
using multiple connections can cause undesirable side effects in using multiple connections can cause undesirable side effects in
congested networks. congested networks.
Note that servers might reject traffic that they deem abusive, Note that servers might reject traffic that they deem abusive,
including an excessive number of connections from a client. including an excessive number of connections from a client.
7.2. Message Transmission Requirements 6.1.5. Retrying Requests
7.2.1. Persistent Connections and Flow Control Senders can close the transport connection at any time. Therefore,
clients, servers, and proxies MUST be able to recover from
asynchronous close events. Client software MAY reopen the transport
connection and retransmit the aborted sequence of requests without
user interaction so long as the request sequence is idempotent (see
Section 6.1.2 of [Part2]). Non-idempotent request methods or
sequences MUST NOT be automatically retried, although user agents MAY
offer a human operator the choice of retrying the request(s).
Confirmation by user-agent software with semantic understanding of
the application MAY substitute for user confirmation. The automatic
retry SHOULD NOT be repeated if the second sequence of requests
fails.
6.2. Message Transmission Requirements
6.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 6.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 code while it is the network connection for an error status code while it is
transmitting the request. If the client sees an error status code, transmitting the request. If the client sees an error status code,
it SHOULD immediately cease transmitting the body. If the body is it SHOULD immediately cease transmitting the body. If the body is
being sent using a "chunked" encoding (Section 6.2), a zero length being sent using a "chunked" encoding (Section 5.1), a zero length
chunk and empty trailer MAY be used to prematurely mark the end of chunk and empty trailer MAY be used to prematurely mark the end of
the message. If the body was preceded by a Content-Length header the message. If the body was preceded by a Content-Length header
field, the client MUST close the connection. field, the client MUST close the connection.
7.2.3. Use of the 100 (Continue) Status 6.2.3. Use of the 100 (Continue) Status
The purpose of the 100 (Continue) status code (see Section 8.1.1 of The purpose of the 100 (Continue) status code (see Section 7.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 header fields) before the client the request (based on the request header fields) before the client
sends the request body. In some cases, it might either be sends the request body. In some cases, it might either be
inappropriate or highly inefficient for the client to send the body inappropriate or highly inefficient for the client to send the body
if the server will reject the message without looking at the body. if the server will 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 header field (Section 9.2 the request body, it MUST send an Expect header field (Section 9.3
of [Part2]) with the "100-continue" expectation. of [Part2]) with the "100-continue" expectation.
o A client MUST NOT send an Expect header field (Section 9.2 of o A client MUST NOT send an Expect header field (Section 9.3 of
[Part2]) with the "100-continue" expectation if it does not intend [Part2]) with the "100-continue" expectation if it does not intend
to send a request body. 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 might send "Expect: 100- ambiguous situations in which a client might send "Expect: 100-
continue" without receiving either a 417 (Expectation Failed) or a continue" without receiving either a 417 (Expectation Failed) or a
100 (Continue) status code. 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 code, the client SHOULD NOT has never seen a 100 (Continue) status code, the client SHOULD NOT
wait for an indefinite period before sending the request body. wait for an indefinite period before sending the request body.
skipping to change at page 52, line 12 skipping to change at page 48, line 41
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 code. respond with a 417 (Expectation Failed) status code.
o Proxies SHOULD maintain a record of the HTTP version numbers o Proxies SHOULD maintain a record of 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 header field with the "100-continue" not include an Expect 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 7.1 of [Part2]).
7.2.4. Client Behavior if Server Prematurely Closes Connection
If an HTTP/1.1 client sends a request which includes a request body,
but which does not include an Expect header field with the "100-
continue" expectation, and if the client is not directly connected to
an HTTP/1.1 origin server, and if the client sees the connection
close before receiving a status line from the server, the client
SHOULD retry the request. If the client does retry this request, it
MAY use the following "binary exponential backoff" algorithm to be
assured of obtaining a reliable response:
1. Initiate a new connection to the server
2. Transmit the request-line, header fields, and the CRLF that
indicates the end of header fields.
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
connection), or to a constant value of 5 seconds if the round-
trip time is not available.
4. Compute T = R * (2**N), where N is the number of previous retries
of this request.
5. Wait either for an error response from the server, or for T
seconds (whichever comes first)
6. If no error response is received, after T seconds transmit the
body of the request.
7. If client sees that the connection is closed prematurely, repeat
from step 1 until the request is accepted, an error response is
received, or the user becomes impatient and terminates the retry
process.
If at any point an error status code is received, the client
o SHOULD NOT continue and
o SHOULD close the connection if it has not completed sending the
request message.
8. Miscellaneous notes that might disappear 7. Miscellaneous notes that might disappear
8.1. Scheme aliases considered harmful 7.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 7.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.]]
8.3. Interception of HTTP for access control 7.3. Interception of HTTP for access control
[[TBD-intercept: Interception of HTTP traffic for initiating access [[TBD-intercept: Interception of HTTP traffic for initiating access
control.]] control.]]
8.4. Use of HTTP by other protocols 7.4. Use of HTTP by other protocols
[[TBD-profiles: Profiles of HTTP defined by other protocol. [[TBD-profiles: Profiles of HTTP defined by other protocol.
Extensions of HTTP like WebDAV.]] Extensions of HTTP like WebDAV.]]
8.5. Use of HTTP by media type specification 7.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 8. Header Field Definitions
This section defines the syntax and semantics of HTTP header fields This section defines the syntax and semantics of HTTP header fields
related to message framing and transport protocols. related to message origination, framing, and routing.
9.1. Connection +-------------------+---------------+
| Header Field Name | Defined in... |
+-------------------+---------------+
| Connection | Section 8.1 |
| Content-Length | Section 8.2 |
| Host | Section 8.3 |
| TE | Section 8.4 |
| Trailer | Section 8.5 |
| Transfer-Encoding | Section 8.6 |
| Upgrade | Section 8.7 |
| Via | Section 8.8 |
+-------------------+---------------+
8.1. Connection
The "Connection" header field allows the sender to specify options The "Connection" header field allows the sender to specify options
that are desired only for that particular connection. Such that are desired only for that particular connection. Such
connection options MUST be removed or replaced before the message can connection options MUST be removed or replaced before the message can
be forwarded downstream by a proxy or gateway. This mechanism also be forwarded downstream by a proxy or gateway. This mechanism also
allows the sender to indicate which HTTP header fields used in the allows the sender to indicate which HTTP header fields used in the
message are only intended for the immediate recipient ("hop-by-hop"), message are only intended for the immediate recipient ("hop-by-hop"),
as opposed to all recipients on the chain ("end-to-end"), enabling as opposed to all recipients on the chain ("end-to-end"), enabling
the message to be self-descriptive and allowing future connection- the message to be self-descriptive and allowing future connection-
specific extensions to be deployed in HTTP without fear that they specific extensions to be deployed in HTTP without fear that they
skipping to change at page 54, line 50 skipping to change at page 51, line 4
since it would be unwise for senders to use that field-name for since it would be unwise for senders to use that field-name for
anything else. anything else.
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
in either the request or the response header fields indicates that in either the request or the response header fields indicates that
the connection SHOULD NOT be considered "persistent" (Section 7.1) the connection SHOULD NOT be considered "persistent" (Section 6.1)
after the current request/response is complete. after the current request/response is complete.
An HTTP/1.1 client that does not support persistent connections MUST An HTTP/1.1 client that does not support persistent connections MUST
include the "close" connection option in every request message. include the "close" connection option in every request message.
An HTTP/1.1 server that does not support persistent connections MUST An HTTP/1.1 server that does not support persistent connections MUST
include the "close" connection option in every response message that include the "close" connection option in every response message that
does not have a 1xx (Informational) status code. does not have a 1xx (Informational) status code.
9.2. Content-Length 8.2. Content-Length
The "Content-Length" header field indicates the size of the message- The "Content-Length" header field indicates the size of the message-
body, in decimal number of octets, for any message other than a body, in decimal number of octets, for any message other than a
response to a HEAD request or a response with a status code of 304. response to a HEAD request or a response with a status code of 304.
In the case of a response to a HEAD request, Content-Length indicates In the case of a response to a HEAD request, Content-Length indicates
the size of the payload body (not including any potential transfer- 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 coding) that would have been sent had the request been a GET. In the
case of a 304 (Not Modified) response to a GET request, Content- case of a 304 (Not Modified) response to a GET request, Content-
Length indicates the size of the payload body (not including any Length indicates the size of the payload body (not including any
potential transfer-coding) that would have been sent in a 200 (OK) potential transfer-coding) that would have been sent in a 200 (OK)
skipping to change at page 55, line 43 skipping to change at page 51, line 45
body length can be determined prior to being transferred. body length can be determined prior to being transferred.
Section 3.3 describes how recipients determine the length of a Section 3.3 describes how recipients determine the length of a
message-body. 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.
Note that the use of this field in HTTP is significantly different Note that the use of this field in HTTP is significantly different
from the corresponding definition in MIME, where it is an optional from the corresponding definition in MIME, where it is an optional
field used within the "message/external-body" content-type. field used within the "message/external-body" content-type.
9.3. Date 8.3. Host
The "Date" header field represents the date and time at which the
message was originated, having the same semantics as the Origination
Date Field (orig-date) defined in Section 3.6.1 of [RFC5322]. The
field value is an HTTP-date, as described in Section 6.1; it MUST be
sent in rfc1123-date format.
Date = HTTP-date
An example is
Date: Tue, 15 Nov 1994 08:12:31 GMT
Origin servers MUST include a Date header field in all responses,
except in these cases:
1. If the response status code is 100 (Continue) or 101 (Switching
Protocols), the response MAY include a Date header field, at the
server's option.
2. If the response status code conveys a server error, e.g., 500
(Internal Server Error) or 503 (Service Unavailable), and it is
inconvenient or impossible to generate a valid Date.
3. If the server does not have a clock that can provide a reasonable
approximation of the current time, its responses MUST NOT include
a Date header field. In this case, the rules in Section 9.3.1
MUST be followed.
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
recipient.
Clients can use the Date header field as well; in order to keep
request messages small, they are advised not to include it when it
doesn't convey any useful information (as it is usually the case for
requests that do not contain a payload).
The HTTP-date sent in a Date header field SHOULD NOT represent a date
and time subsequent to the generation of the message. It SHOULD
represent the best available approximation of the date and time of
message generation, unless the implementation has no means of
generating a reasonably accurate date and time. In theory, the date
ought to represent the moment just before the payload is generated.
In practice, the date can be generated at any time during the message
origination without affecting its semantic value.
9.3.1. Clockless Origin Server Operation
Some origin server implementations might not have a clock available.
An origin server without a clock MUST NOT assign Expires or Last-
Modified values to a response, unless these values were associated
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
configuration time, to be in the past (this allows "pre-expiration"
of responses without storing separate Expires values for each
resource).
9.4. Host
The "Host" header field in a request provides the host and port The "Host" header field in a request provides the host and port
information from the target resource's URI, enabling the origin information from the target resource's URI, enabling the origin
server to distinguish between resources while servicing requests for server to distinguish between resources while servicing requests for
multiple host names on a single IP address. Since the Host field- multiple host names on a single IP address. Since the Host field-
value is critical information for handling a request, it SHOULD be value is critical information for handling a request, it SHOULD be
sent as the first header field following the Request-Line. sent as the first header field following the Request-Line.
Host = uri-host [ ":" port ] ; Section 2.7.1 Host = uri-host [ ":" port ] ; Section 2.7.1
skipping to change at page 58, line 9 skipping to change at page 53, line 5
that the intercepted connection is targeting a valid IP address for that the intercepted connection is targeting a valid IP address for
that host. that host.
A server MUST respond with a 400 (Bad Request) status code to any A server MUST respond with a 400 (Bad Request) status code to any
HTTP/1.1 request message that lacks a Host header field and to any HTTP/1.1 request message that lacks a Host header field and to any
request message that contains more than one Host header field or a request message that contains more than one Host header field or a
Host header field with an invalid field-value. Host header field with an invalid field-value.
See Sections 4.2 and A.1.1 for other requirements relating to Host. See Sections 4.2 and A.1.1 for other requirements relating to Host.
9.5. TE 8.4. TE
The "TE" header field indicates what extension transfer-codings it is The "TE" header field indicates what extension transfer-codings it is
willing to accept in the response, and whether or not it is willing willing to accept in the response, and whether or not it is willing
to accept trailer fields in a chunked transfer-coding. to accept trailer fields in a chunked transfer-coding.
Its value consists of the keyword "trailers" and/or a comma-separated Its value consists of the keyword "trailers" and/or a comma-separated
list of extension transfer-coding names with optional accept list of extension transfer-coding names with optional accept
parameters (as described in Section 6.2). parameters (as described in Section 5.1).
TE = #t-codings TE = #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 5.1.1. This keyword is reserved for use with
transfer-coding values even though it does not itself represent a transfer-coding values even though it does not itself represent a
transfer-coding. transfer-coding.
Examples of its use are: Examples of its use are:
TE: deflate TE: deflate
TE: TE:
TE: trailers, deflate;q=0.5 TE: trailers, deflate;q=0.5
The TE header field only applies to the immediate connection. The TE header field only applies to the immediate connection.
Therefore, the keyword MUST be supplied within a Connection header Therefore, the keyword MUST be supplied within a Connection header
field (Section 9.1) whenever TE is present in an HTTP/1.1 message. field (Section 8.1) whenever TE is present in an HTTP/1.1 message.
A server tests whether a transfer-coding is acceptable, according to A server tests whether a transfer-coding is acceptable, according to
a TE field, using these rules: a TE field, using these rules:
1. The "chunked" transfer-coding is always acceptable. If the 1. The "chunked" transfer-coding is always acceptable. If the
keyword "trailers" is listed, the client indicates that it is keyword "trailers" is listed, the client indicates that it is
willing to accept trailer fields in the chunked response on willing to accept trailer fields in the chunked response on
behalf of itself and any downstream clients. The implication is behalf of itself and any downstream clients. The implication is
that, if given, the client is stating that either all downstream that, if given, the client is stating that either all downstream
clients are willing to accept trailer fields in the forwarded clients are willing to accept trailer fields in the forwarded
response, or that it will attempt to buffer the response on response, or that it will attempt to buffer the response on
behalf of downstream recipients. behalf of downstream recipients.
Note: HTTP/1.1 does not define any means to limit the size of a Note: HTTP/1.1 does not define any means to limit the size of a
chunked response such that a client can be assured of buffering chunked response such that a client can be assured of buffering
the entire response. the entire response.
2. If the transfer-coding being tested is one of the transfer- 2. If the transfer-coding being tested is one of the transfer-
codings listed in the TE field, then it is acceptable unless it codings listed in the TE field, then it is acceptable unless it
is accompanied by a qvalue of 0. (As defined in Section 6.4, a is accompanied by a qvalue of 0. (As defined in Section 5.3, 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 8.5. Trailer
The "Trailer" header field indicates that the given set of header The "Trailer" header field indicates that the given set of header
fields is present in the trailer of a message encoded with chunked fields is present in the trailer of a message encoded with chunked
transfer-coding. transfer-coding.
Trailer = 1#field-name Trailer = 1#field-name
An HTTP/1.1 message SHOULD include a Trailer header field in a An HTTP/1.1 message SHOULD include a Trailer header field in a
message using chunked transfer-coding with a non-empty trailer. message using chunked transfer-coding with a non-empty trailer.
Doing so allows the recipient to know which header fields to expect Doing so allows the recipient to know which header fields to expect
in the trailer. in the trailer.
If no Trailer header field is present, the trailer SHOULD NOT include If no Trailer header field is present, the trailer SHOULD NOT include
any header fields. See Section 6.2.1 for restrictions on the use of any header fields. See Section 5.1.1 for restrictions on the use of
trailer fields in a "chunked" transfer-coding. trailer fields in a "chunked" transfer-coding.
Message header fields listed in the Trailer header field MUST NOT Message header fields listed in the Trailer header field MUST NOT
include the following header fields: include the following header fields:
o Transfer-Encoding o Transfer-Encoding
o Content-Length o Content-Length
o Trailer o Trailer
9.7. Transfer-Encoding 8.6. Transfer-Encoding
The "Transfer-Encoding" header field indicates what transfer-codings The "Transfer-Encoding" header field indicates what transfer-codings
(if any) have been applied to the message body. It differs from (if any) have been applied to the message body. It differs from
Content-Encoding (Section 2.2 of [Part3]) in that transfer-codings Content-Encoding (Section 2.2 of [Part3]) in that transfer-codings
are a property of the message (and therefore are removed by are a property of the message (and therefore are removed by
intermediaries), whereas content-codings are not. intermediaries), whereas content-codings are not.
Transfer-Encoding = 1#transfer-coding Transfer-Encoding = 1#transfer-coding
Transfer-codings are defined in Section 6.2. An example is: Transfer-codings are defined in Section 5.1. An example is:
Transfer-Encoding: chunked Transfer-Encoding: chunked
If multiple encodings have been applied to a representation, the If multiple encodings have been applied to a representation, the
transfer-codings MUST be listed in the order in which they were transfer-codings MUST be listed in the order in which they were
applied. Additional information about the encoding parameters MAY be applied. Additional information about the encoding parameters MAY be
provided by other 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 field. Encoding header field.
9.8. Upgrade 8.7. Upgrade
The "Upgrade" header field allows the client to specify what The "Upgrade" 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. Servers can use it to indicate server chooses to switch protocols. Servers can use it to indicate
what protocols they are willing to switch to. what protocols they are willing to switch to.
Upgrade = 1#product Upgrade = 1#product
For example, For example,
skipping to change at page 61, line 9 skipping to change at page 56, line 4
protocols upon the existing transport-layer connection. Upgrade protocols upon the existing transport-layer connection. Upgrade
cannot be used to insist on a protocol change; its acceptance and use cannot be used to insist on a protocol change; its acceptance and use
by the server is optional. The capabilities and nature of the by the server is optional. The capabilities and nature of the
application-layer communication after the protocol change is entirely application-layer communication after the protocol change is entirely
dependent upon the new protocol chosen, although the first action dependent upon the new protocol chosen, although the first action
after changing the protocol MUST be a response to the initial HTTP after changing the protocol MUST be a response to the initial HTTP
request containing the Upgrade header field. request containing the Upgrade header field.
The Upgrade header field only applies to the immediate connection. The Upgrade header field only applies to the immediate connection.
Therefore, the upgrade keyword MUST be supplied within a Connection Therefore, the upgrade keyword MUST be supplied within a Connection
header field (Section 9.1) whenever Upgrade is present in an HTTP/1.1 header field (Section 8.1) whenever Upgrade is present in an HTTP/1.1
message. message.
The Upgrade header field cannot be used to indicate a switch to a The Upgrade header field cannot be used to indicate a switch to a
protocol on a different connection. For that purpose, it is more protocol on a different connection. For that purpose, it is more
appropriate to use a 3xx redirection response (Section 8.3 of appropriate to use a 3xx redirection response (Section 7.3 of
[Part2]). [Part2]).
Servers MUST include the "Upgrade" header field in 101 (Switching Servers MUST include the "Upgrade" header field in 101 (Switching
Protocols) responses to indicate which protocol(s) are being switched Protocols) responses to indicate which protocol(s) are being switched
to, and MUST include it in 426 (Upgrade Required) responses to to, and MUST include it in 426 (Upgrade Required) responses to
indicate acceptable protocols to upgrade to. Servers MAY include it indicate acceptable protocols to upgrade to. Servers MAY include it
in any other response to indicate that they are willing to upgrade to in any other response to indicate that they are willing to upgrade to
one of the specified protocols. one of the specified protocols.
This specification only defines the protocol name "HTTP" for use by This specification only defines the protocol name "HTTP" for use by
the family of Hypertext Transfer Protocols, as defined by the HTTP the family of Hypertext Transfer Protocols, as defined by the HTTP
version rules of Section 2.6 and future updates to this version rules of Section 2.6 and future updates to this
specification. Additional tokens can be registered with IANA using specification. Additional tokens can be registered with IANA using
the registration procedure defined below. the registration procedure defined below.
9.8.1. Upgrade Token Registry 8.7.1. Upgrade Token Registry
The HTTP Upgrade Token Registry defines the name space for product The HTTP Upgrade Token Registry defines the name space for product
tokens used to identify protocols in the Upgrade header field. Each tokens used to identify protocols in the Upgrade header field. Each
registered token is associated with contact information and an registered token is associated with contact information and an
optional set of specifications that details how the connection will optional set of specifications that details how the connection will
be processed after it has been upgraded. be processed after it has been upgraded.
Registrations are 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]. The specifications need not described in Section 4.1 of [RFC5226]. The specifications need not
be IETF documents or be subject to IESG review. Registrations are be IETF documents or be subject to IESG review. Registrations are
skipping to change at page 62, line 17 skipping to change at page 57, line 13
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.
9.9. Via 8.8. Via
The "Via" header field MUST be sent by a proxy or gateway to indicate The "Via" header field MUST be sent by a proxy or gateway to indicate
the intermediate protocols and recipients between the user agent and the intermediate protocols and recipients between the user agent and
the server on requests, and between the origin server and the client the server on requests, and between the origin server and the client
on responses. It is analogous to the "Received" field used by email on responses. It is analogous to the "Received" field used by email
systems (Section 3.6.7 of [RFC5322]) and is intended to be used for systems (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 63, line 42 skipping to change at page 58, line 38
could be collapsed to could be collapsed to
Via: 1.0 ricky, 1.1 mertz, 1.0 lucy Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
Senders SHOULD NOT combine multiple entries unless they are all under Senders SHOULD NOT combine multiple entries unless they are all under
the same organizational control and the hosts have already been the same organizational control and the hosts have already been
replaced by pseudonyms. Senders MUST NOT combine entries which have replaced by pseudonyms. Senders MUST NOT combine entries which have
different received-protocol values. different received-protocol values.
10. IANA Considerations 9. IANA Considerations
10.1. Header Field Registration 9.1. Header Field Registration
The Message Header Field 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> shall 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 8.1 |
| Content-Length | http | standard | Section 9.2 | | Content-Length | http | standard | Section 8.2 |
| Date | http | standard | Section 9.3 | | Host | http | standard | Section 8.3 |
| Host | http | standard | Section 9.4 | | TE | http | standard | Section 8.4 |
| TE | http | standard | Section 9.5 | | Trailer | http | standard | Section 8.5 |
| Trailer | http | standard | Section 9.6 | | Transfer-Encoding | http | standard | Section 8.6 |
| Transfer-Encoding | http | standard | Section 9.7 | | Upgrade | http | standard | Section 8.7 |
| Upgrade | http | standard | Section 9.8 | | Via | http | standard | Section 8.8 |
| Via | http | standard | Section 9.9 |
+-------------------+----------+----------+-------------+ +-------------------+----------+----------+-------------+
Furthermore, the header field name "Close" shall be registered as Furthermore, the header field name "Close" shall be registered as
"reserved", as its use as HTTP header field would be in conflict with "reserved", as its use as HTTP header field would be in conflict with
the use of the "close" connection option for the "Connection" header the use of the "close" connection option for the "Connection" header
field (Section 9.1). field (Section 8.1).
+-------------------+----------+----------+--------------+ +-------------------+----------+----------+-------------+
| Header Field Name | Protocol | Status | Reference | | Header Field Name | Protocol | Status | Reference |
+-------------------+----------+----------+--------------+ +-------------------+----------+----------+-------------+
| Close | http | reserved | Section 10.1 | | Close | http | reserved | Section 9.1 |
+-------------------+----------+----------+--------------+ +-------------------+----------+----------+-------------+
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 9.2. URI Scheme Registration
The entries for the "http" and "https" URI Schemes in the registry The entries for the "http" and "https" URI Schemes in the registry
located at <http://www.iana.org/assignments/uri-schemes.html> shall located at <http://www.iana.org/assignments/uri-schemes.html> shall
be updated to point to Sections 2.7.1 and 2.7.2 of this document (see be updated to point to Sections 2.7.1 and 2.7.2 of this document (see
[RFC4395]). [RFC4395]).
10.3. Internet Media Type Registrations 9.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 9.3.1. Internet Media Type message/http
The message/http type can be used to enclose a single HTTP request or The message/http type can be used to enclose a single HTTP request or
response message, provided that it obeys the MIME restrictions for response message, provided that it obeys the MIME restrictions for
all "message" types regarding line length and encodings. all "message" types regarding line length and encodings.
Type name: message Type name: message
Subtype name: http Subtype name: http
Required parameters: none Required parameters: none
skipping to change at page 65, line 28 skipping to change at page 60, line 28
present, the type can be determined from the first line of the present, the type can be determined from the first line of the
body. body.
Encoding considerations: only "7bit", "8bit", or "binary" are Encoding considerations: only "7bit", "8bit", or "binary" are
permitted permitted
Security considerations: none Security considerations: none
Interoperability considerations: none Interoperability considerations: none
Published specification: This specification (see Section 10.3.1). Published specification: This specification (see Section 9.3.1).
Applications that use this media type: Applications that use this media type:
Additional information: Additional information:
Magic number(s): none Magic number(s): none
File extension(s): none File extension(s): none
Macintosh file type code(s): none Macintosh file type code(s): none
Person and email address to contact for further information: See Person and email address to contact for further information: See
Authors Section. Authors Section.
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: none Restrictions on usage: none
Author/Change controller: IESG Author/Change controller: IESG
10.3.2. Internet Media Type application/http 9.3.2. Internet Media Type application/http
The application/http type can be used to enclose a pipeline of one or The application/http type can be used to enclose a pipeline of one or
more HTTP request or response messages (not intermixed). more HTTP request or response messages (not intermixed).
Type name: application Type name: application
Subtype name: http Subtype name: http
Required parameters: none Required parameters: none
skipping to change at page 66, line 34 skipping to change at page 61, line 34
body. body.
Encoding considerations: HTTP messages enclosed by this type are in Encoding considerations: HTTP messages enclosed by this type are in
"binary" format; use of an appropriate Content-Transfer-Encoding "binary" format; use of an appropriate Content-Transfer-Encoding
is required when transmitted via E-mail. is required when transmitted via E-mail.
Security considerations: none Security considerations: none
Interoperability considerations: none Interoperability considerations: none
Published specification: This specification (see Section 10.3.2). Published specification: This specification (see Section 9.3.2).
Applications that use this media type: Applications that use this media type:
Additional information: Additional information:
Magic number(s): none Magic number(s): none
File extension(s): none File extension(s): none
Macintosh file type code(s): none Macintosh file type code(s): none
Person and email address to contact for further information: See Person and email address to contact for further information: See
Authors Section. Authors Section.
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: none Restrictions on usage: none
Author/Change controller: IESG Author/Change controller: IESG
10.4. Transfer Coding Registry 9.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 5.1.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> shall 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 5.1.1 |
| compress | UNIX "compress" program method | Section 6.2.2.1 | | compress | UNIX "compress" program method | Section 5.1.2.1 |
| deflate | "deflate" compression mechanism | Section 6.2.2.2 | | deflate | "deflate" compression mechanism | Section 5.1.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 5.1.2.3 |
+----------+--------------------------------------+-----------------+ +----------+--------------------------------------+-----------------+
10.5. Upgrade Token Registration 9.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 8.7.1 of this document.
The HTTP Status Code Registry located at The HTTP Status Code Registry located at
<http://www.iana.org/assignments/http-upgrade-tokens/> shall be <http://www.iana.org/assignments/http-upgrade-tokens/> shall be
updated with the registration below: updated with the registration below:
+-------+---------------------------+-------------------------------+ +-------+---------------------------+-------------------------------+
| Value | Description | Reference | | Value | Description | Reference |
+-------+---------------------------+-------------------------------+ +-------+---------------------------+-------------------------------+
| HTTP | Hypertext Transfer | Section 2.6 of this | | HTTP | Hypertext Transfer | Section 2.6 of this |
| | Protocol | specification | | | Protocol | specification |
+-------+---------------------------+-------------------------------+ +-------+---------------------------+-------------------------------+
11. Security Considerations 10. Security Considerations
This section is meant to inform application developers, information This section is meant to inform application developers, information
providers, and users of the security limitations in HTTP/1.1 as providers, and users of the security limitations in HTTP/1.1 as
described by this document. The discussion does not include described by this document. The discussion does not include
definitive solutions to the problems revealed, though it does make definitive solutions to the problems revealed, though it does make
some suggestions for reducing security risks. some suggestions for reducing security risks.
11.1. Personal Information 10.1. Personal Information
HTTP clients are often privy to large amounts of personal information HTTP clients are often privy to large amounts of personal information
(e.g., the user's name, location, mail address, passwords, encryption (e.g., the user's name, location, mail address, passwords, encryption
keys, etc.), and SHOULD be very careful to prevent unintentional keys, etc.), and SHOULD be very careful to prevent unintentional
leakage of this information. We very strongly recommend that a leakage of this information. We very strongly recommend that a
convenient interface be provided for the user to control convenient interface be provided for the user to control
dissemination of such information, and that designers and dissemination of such information, and that designers and
implementors be particularly careful in this area. History shows implementors be particularly careful in this area. History shows
that errors in this area often create serious security and/or privacy that errors in this area often create serious security and/or privacy
problems and generate highly adverse publicity for the implementor's problems and generate highly adverse publicity for the implementor's
company. company.
11.2. Abuse of Server Log Information 10.2. Abuse of Server Log Information
A server is in the position to save personal data about a user's A server is in the position to save personal data about a user's
requests which might identify their reading patterns or subjects of requests which might identify their reading patterns or subjects of
interest. This information is clearly confidential in nature and its interest. This information is clearly confidential in nature and its
handling can be constrained by law in certain countries. People handling can be constrained by law in certain countries. People
using HTTP to provide data are responsible for ensuring that such using HTTP to provide data are responsible for ensuring that such
material is not distributed without the permission of any individuals material is not distributed without the permission of any individuals
that are identifiable by the published results. that are identifiable by the published results.
11.3. Attacks Based On File and Path Names 10.3. Attacks Based On File and Path Names
Implementations of HTTP origin servers SHOULD be careful to restrict Implementations of HTTP origin servers SHOULD be careful to restrict
the documents returned by HTTP requests to be only those that were the documents returned by HTTP requests to be only those that were
intended by the server administrators. If an HTTP server translates intended by the server administrators. If an HTTP server translates
HTTP URIs directly into file system calls, the server MUST take HTTP URIs directly into file system calls, the server MUST take
special care not to serve files that were not intended to be special care not to serve files that were not intended to be
delivered to HTTP clients. For example, UNIX, Microsoft Windows, and delivered to HTTP clients. For example, UNIX, Microsoft Windows, and
other operating systems use ".." as a path component to indicate a other operating systems use ".." as a path component to indicate a
directory level above the current one. On such a system, an HTTP directory level above the current one. On such a system, an HTTP
server MUST disallow any such construct in the request-target if it server MUST disallow any such construct in the request-target if it
would otherwise allow access to a resource outside those intended to would otherwise allow access to a resource outside those intended to
be accessible via the HTTP server. Similarly, files intended for be accessible via the HTTP server. Similarly, files intended for
reference only internally to the server (such as access control reference only internally to the server (such as access control
files, configuration files, and script code) MUST be protected from files, configuration files, and script code) MUST be protected from
inappropriate retrieval, since they might contain sensitive inappropriate retrieval, since they might contain sensitive
information. Experience has shown that minor bugs in such HTTP information. Experience has shown that minor bugs in such HTTP
server implementations have turned into security risks. server implementations have turned into security risks.
11.4. DNS-related Attacks 10.4. DNS-related Attacks
HTTP clients rely heavily on the Domain Name Service (DNS), and are HTTP clients rely heavily on the Domain Name Service (DNS), and are
thus generally prone to security attacks based on the deliberate thus generally prone to security attacks based on the deliberate
misassociation of IP addresses and DNS names not protected by DNSSec. misassociation of IP addresses and DNS names not protected by DNSSec.
Clients need to be cautious in assuming the validity of an IP number/ Clients need to be cautious in assuming the validity of an IP number/
DNS name association unless the response is protected by DNSSec DNS name association unless the response is protected by DNSSec
([RFC4033]). ([RFC4033]).
11.5. Proxies and Caching 10.5. Proxies and Caching
By their very nature, HTTP proxies are men-in-the-middle, and By their very nature, HTTP proxies are men-in-the-middle, and
represent an opportunity for man-in-the-middle attacks. Compromise represent an opportunity for man-in-the-middle attacks. Compromise
of the systems on which the proxies run can result in serious of the systems on which the proxies run can result in serious
security and privacy problems. Proxies have access to security- security and privacy problems. Proxies have access to security-
related information, personal information about individual users and related information, personal information about individual users and
organizations, and proprietary information belonging to users and organizations, and proprietary information belonging to users and
content providers. A compromised proxy, or a proxy implemented or content providers. A compromised proxy, or a proxy implemented or
configured without regard to security and privacy considerations, configured without regard to security and privacy considerations,
might be used in the commission of a wide range of potential attacks. might be used in the commission of a wide range of potential attacks.
Proxy operators need to 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 needs to be information about organizations. Log information needs to be
carefully guarded, and appropriate guidelines for use need to be carefully guarded, and appropriate guidelines for use need to be
developed and followed. (Section 11.2). developed and followed. (Section 10.2).
Proxy implementors need to 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, might suffice to The judicious use of cryptography, when appropriate, might suffice to
protect against a broad range of security and privacy attacks. Such protect against a broad range of security and privacy attacks. Such
cryptography is beyond the scope of the HTTP/1.1 specification. cryptography is beyond the scope of the HTTP/1.1 specification.
11.6. Protocol Element Size Overflows 10.6. Protocol Element Size Overflows
Because HTTP uses mostly textual, character-delimited fields, Because HTTP uses mostly textual, character-delimited fields,
attackers can overflow buffers in implementations, and/or perform a attackers can overflow buffers in implementations, and/or perform a
Denial of Service against implementations that accept fields with Denial of Service against implementations that accept fields with
unlimited lengths. unlimited lengths.
To promote interoperability, this specification makes specific To promote interoperability, this specification makes specific
recommendations for size limits on request-targets (Section 4.1.2) recommendations for size limits on request-targets (Section 3.1.1.2)
and blocks of header fields (Section 3.2). These are minimum and blocks of header fields (Section 3.2). These are minimum
recommendations, chosen to be supportable even by implementations recommendations, chosen to be supportable even by implementations
with limited resources; it is expected that most implementations will with limited resources; it is expected that most implementations will
choose substantially higher limits. choose substantially higher limits.
This specification also provides a way for servers to reject messages This specification also provides a way for servers to reject messages
that have request-targets that are too long (Section 8.4.15 of that have request-targets that are too long (Section 7.4.15 of
[Part2]) or request entities that are too large (Section 8.4 of [Part2]) or request entities that are too large (Section 7.4 of
[Part2]). [Part2]).
Other fields (including but not limited to request methods, response Other fields (including but not limited to request methods, response
status phrases, header field-names, and body chunks) SHOULD be status phrases, header field-names, and body chunks) SHOULD be
limited by implementations carefully, so as to not impede limited by implementations carefully, so as to not impede
interoperability. interoperability.
11.7. Denial of Service Attacks on Proxies 10.7. Denial of Service Attacks on Proxies
They exist. They are hard to defend against. Research continues. They exist. They are hard to defend against. Research continues.
Beware. Beware.
12. Acknowledgments 11. Acknowledgments
This document revision builds on the work that went into RFC 2616 and This document revision builds on the work that went into RFC 2616 and
its predecessors. See Section 16 of [RFC2616] for detailed its predecessors. See Section 16 of [RFC2616] for detailed
acknowledgements. acknowledgements.
[[todoacks: Insert HTTPbis-specific acknowledgements here.]] Since 1999, many contributors have helped by reporting bugs, asking
smart questions, drafting and reviewing text, and discussing open
issues:
13. References Adam Barth, Adam Roach, Addison Phillips, Adrian Chadd, Adrien de
Croy, Alan Ford, Alan Ruttenberg, Albert Lunde, Alex Rousskov, Alexey
Melnikov, Alisha Smith, Amichai Rothman, Amit Klein, Amos Jeffries,
Andreas Maier, Andreas Petersson, Anne van Kesteren, Anthony Bryan,
Asbjorn Ulsberg, Balachander Krishnamurthy, Barry Leiba, Ben Laurie,
Benjamin Niven-Jenkins, Bil Corry, Bill Burke, Bjoern Hoehrmann, Bob
Scheifler, Boris Zbarsky, Brett Slatkin, Brian Kell, Brian McBarron,
Brian Pane, Brian Smith, Bryce Nesbitt, Carl Kugler, Charles Fry,
Chris Newman, Cyrus Daboo, Dale Robert Anderson, Dan Winship, Daniel
Stenberg, Dave Cridland, Dave Crocker, Dave Kristol, David Booth,
David Singer, David W. Morris, Diwakar Shetty, Drummond Reed, Duane
Wessels, Edward Lee, Eliot Lear, Eran Hammer-Lahav, Eric D. Williams,
Eric J. Bowman, Eric Lawrence, Erik Aronesty, Florian Weimer, Frank
Ellermann, Fred Bohle, Geoffrey Sneddon, Gervase Markham, Greg
Wilkins, Harald Tveit Alvestrand, Harry Halpin, Helge Hess, Henrik
Nordstrom, Henry S. Thompson, Henry Story, Howard Melman, Hugo Haas,
Ian Hickson, Ingo Struck, J. Ross Nicoll, James H. Manger, James
Lacey, James M. Snell, Jamie Lokier, Jan Algermissen, Jeff Hodges
(for coming up with the term 'effective Request-URI'), Jeff Walden,
Jim Luther, Joe D. Williams, Joe Gregorio, Joe Orton, John C.
Klensin, John C. Mallery, John Cowan, John Kemp, John Panzer, John
Schneider, John Stracke, Jonas Sicking, Jonathan Moore, Jonathan
Rees, Jordi Ros, Joris Dobbelsteen, Josh Cohen, Julien Pierre,
Jungshik Shin, Justin Chapweske, Justin Erenkrantz, Justin James,
Kalvinder Singh, Karl Dubost, Keith Hoffman, Keith Moore, Koen
Holtman, Konstantin Voronkov, Kris Zyp, Lisa Dusseault, Maciej
Stachowiak, Marc Schneider, Marc Slemko, Mark Baker, Mark Nottingham
(Working Group chair), Mark Pauley, Martin J. Duerst, Martin Thomson,
Matt Lynch, Matthew Cox, Max Clark, Michael Burrows, Michael
Hausenblas, Mike Amundsen, Mike Kelly, Mike Schinkel, Miles Sabin,
Mykyta Yevstifeyev, Nathan Rixham, Nicholas Shanks, Nico Williams,
Nicolas Alvarez, Noah Slater, Pablo Castro, Pat Hayes, Patrick R.
McManus, Paul E. Jones, Paul Hoffman, Paul Marquess, Peter Saint-
Andre, Peter Watkins, Phil Archer, Phillip Hallam-Baker, Poul-Henning
Kamp, Preethi Natarajan, Reto Bachmann-Gmuer, Richard Cyganiak,
Robert Brewer, Robert Collins, Robert O'Callahan, Robert Olofsson,
Robert Sayre, Robert Siemer, Robert de Wilde, Roberto Javier Godoy,
Ronny Widjaja, S. Mike Dierken, Salvatore Loreto, Sam Johnston, Sam
Ruby, Scott Lawrence (for maintaining the original issues list), Sean
B. Palmer, Shane McCarron, Stefan Eissing, Stefan Tilkov, Stefanos
Harhalakis, Stephane Bortzmeyer, Stuart Williams, Subbu Allamaraju,
Sylvain Hellegouarch, Tapan Divekar, Thomas Broyer, Thomas Nordin,
Thomas Roessler, Tim Morgan, Tim Olsen, Travis Snoozy, Tyler Close,
Vincent Murphy, Wenbo Zhu, Werner Baumann, Wilbur Streett, Wilfredo
Sanchez Vega, William A. Rowe Jr., William Chan, Willy Tarreau,
Xiaoshu Wang, Yaron Goland, Yngve Nysaeter Pettersen, Yogesh Bang,
Yutaka Oiwa, and Zed A. Shaw.
13.1. Normative References 12. References
12.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-16 (work in Semantics", draft-ietf-httpbis-p2-semantics-17 (work in
progress), August 2011. progress), October 2011.
[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-16 (work in progress), draft-ietf-httpbis-p3-payload-17 (work in progress),
August 2011. October 2011.
[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-16 (work in progress), draft-ietf-httpbis-p6-cache-17 (work in progress),
August 2011. October 2011.
[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 might 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, therefore it is
it is unlikely to cause problems in practice. See also 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 might 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, therefore it is
it is unlikely to cause problems in practice. See also 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 might 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, therefore it is
it is unlikely to cause problems in practice. See also 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,
"Uniform Resource Identifier (URI): Generic Syntax", "Uniform Resource Identifier (URI): Generic Syntax",
STD 66, RFC 3986, January 2005. STD 66, RFC 3986, January 2005.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, RFC 5234, Syntax Specifications: ABNF", STD 68, RFC 5234,
January 2008. January 2008.
[USASCII] American National Standards Institute, "Coded Character [USASCII] American National Standards Institute, "Coded Character
Set -- 7-bit American Standard Code for Information Set -- 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986. Interchange", ANSI X3.4, 1986.
13.2. Informative References 12.2. Informative References
[BCP97] Klensin, J. and S. Hartman, "Handling Normative [BCP97] Klensin, J. and S. Hartman, "Handling Normative
References to Standards-Track Documents", BCP 97, References to Standards-Track Documents", BCP 97,
RFC 4897, June 2007. RFC 4897, June 2007.
[Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and [Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and
Politics", ACM Transactions on Internet Technology Vol. Politics", ACM Transactions on Internet Technology Vol.
1, #2, November 2001, 1, #2, November 2001,
<http://arxiv.org/abs/cs.SE/0105018>. <http://arxiv.org/abs/cs.SE/0105018>.
skipping to change at page 72, line 30 skipping to change at page 68, line 33
SIGCOMM '97 conference on Applications, technologies, SIGCOMM '97 conference on Applications, technologies,
architectures, and protocols for computer communication architectures, and protocols for computer communication
SIGCOMM '97, September 1997, SIGCOMM '97, September 1997,
<http://doi.acm.org/10.1145/263105.263157>. <http://doi.acm.org/10.1145/263105.263157>.
[Pad1995] Padmanabhan, V. and J. Mogul, "Improving HTTP Latency", [Pad1995] Padmanabhan, V. and J. Mogul, "Improving HTTP Latency",
Computer Networks and ISDN Systems v. 28, pp. 25-35, Computer Networks and ISDN Systems v. 28, pp. 25-35,
December 1995, December 1995,
<http://portal.acm.org/citation.cfm?id=219094>. <http://portal.acm.org/citation.cfm?id=219094>.
[RFC1123] Braden, R., "Requirements for Internet Hosts -
Application and Support", STD 3, RFC 1123,
October 1989.
[RFC1919] Chatel, M., "Classical versus Transparent IP Proxies", [RFC1919] Chatel, M., "Classical versus Transparent IP Proxies",
RFC 1919, March 1996. RFC 1919, March 1996.
[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen,
"Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945,
May 1996. May 1996.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet Mail Extensions (MIME) Part One: Format of Internet
Message Bodies", RFC 2045, November 1996. Message Bodies", RFC 2045, November 1996.
skipping to change at page 75, line 16 skipping to change at page 71, line 14
in the request-target. in the request-target.
A.1. Changes from HTTP/1.0 A.1. Changes from HTTP/1.0
This section summarizes major differences between versions HTTP/1.0 This section summarizes major differences between versions HTTP/1.0
and HTTP/1.1. and HTTP/1.1.
A.1.1. Multi-homed Web Servers A.1.1. Multi-homed Web Servers
The requirements that clients and servers support the Host header The requirements that clients and servers support the Host header
field (Section 9.4), report an error if it is missing from an field (Section 8.3), report an error if it is missing from an
HTTP/1.1 request, and accept absolute URIs (Section 4.1.2) are among HTTP/1.1 request, and accept absolute URIs (Section 3.1.1.2) are
the most important changes defined by HTTP/1.1. among the most important changes defined by HTTP/1.1.
Older HTTP/1.0 clients assumed a one-to-one relationship of IP Older HTTP/1.0 clients assumed a one-to-one relationship of IP
addresses and servers; there was no other established mechanism for addresses and servers; there was no other established mechanism for
distinguishing the intended server of a request than the IP address distinguishing the intended server of a request than the IP address
to which that request was directed. The Host header field was to which that request was directed. The Host header field was
introduced during the development of HTTP/1.1 and, though it was introduced during the development of HTTP/1.1 and, though it was
quickly implemented by most HTTP/1.0 browsers, additional quickly implemented by most HTTP/1.0 browsers, additional
requirements were placed on all HTTP/1.1 requests in order to ensure requirements were placed on all HTTP/1.1 requests in order to ensure
complete adoption. At the time of this writing, most HTTP-based complete adoption. At the time of this writing, most HTTP-based
services are dependent upon the Host header field for targeting services are dependent upon the Host header field for targeting
skipping to change at page 76, line 11 skipping to change at page 72, line 9
HTTP/1.0 proxy waiting for the close on the response. The result is HTTP/1.0 proxy waiting for the close on the response. The result is
that HTTP/1.0 clients must be prevented from using Keep-Alive when that HTTP/1.0 clients must be prevented from 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 8.1.
A.2. Changes from RFC 2616 A.2. 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. (Section 1.2.2) specifically pointed out in the ABNF. (Section 1.2.2)
skipping to change at page 76, line 40 skipping to change at page 72, line 38
The NUL octet is no longer allowed in comment and quoted-string text. The NUL octet is no longer allowed in comment and quoted-string text.
The quoted-pair rule no longer allows escaping control characters The quoted-pair rule no longer allows escaping control characters
other than HTAB. Non-ASCII content in header fields and reason other than HTAB. Non-ASCII content in header fields and reason
phrase has been obsoleted and made opaque (the TEXT rule was phrase has been obsoleted and made opaque (the TEXT rule was
removed). (Section 3.2.3) removed). (Section 3.2.3)
Require recipients to handle bogus Content-Length header fields as Require recipients to handle bogus Content-Length header fields as
errors. (Section 3.3) errors. (Section 3.3)
Remove reference to non-existent identity transfer-coding value Remove reference to non-existent identity transfer-coding value
tokens. (Sections 3.3 and 6.2) tokens. (Sections 3.3 and 5.1)
Update use of abs_path production from RFC 1808 to the path-absolute Update use of abs_path production from RFC 1808 to the path-absolute
+ query components of RFC 3986. State that the asterisk form is + query components of RFC 3986. State that the asterisk form is
allowed for the OPTIONS request method only. (Section 4.1.2) allowed for the OPTIONS request method only. (Section 3.1.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 5.1.1)
Remove hard limit of two connections per server. (Section 7.1.4) Remove hard limit of two connections per server. Remove requirement
to retry a sequence of requests as long it was idempotent. Remove
requirements about when servers are allowed to close connections
prematurely. (Section 6.1.4)
Remove requirement to retry requests under certain cirumstances when
the server prematurely closes the connection. (Section 6.2)
Change ABNF productions for header fields to only define the field Change ABNF productions for header fields to only define the field
value. (Section 9) value. (Section 8)
Clarify exactly when close connection options must be sent. Clarify exactly when close connection options must be sent.
(Section 9.1) (Section 8.1)
Define the semantics of the "Upgrade" header field in responses other Define the semantics of the "Upgrade" header field in responses other
than 101 (this was incorporated from [RFC2817]). (Section 9.8) than 101 (this was incorporated from [RFC2817]). (Section 8.7)
Appendix B. Collected ABNF Appendix B. Collected ABNF
BWS = OWS BWS = OWS
Chunked-Body = *chunk last-chunk trailer-part CRLF Chunked-Body = *chunk last-chunk trailer-part CRLF
Connection = *( "," OWS ) connection-token *( OWS "," [ OWS Connection = *( "," OWS ) connection-token *( OWS "," [ OWS
connection-token ] ) connection-token ] )
Content-Length = 1*DIGIT Content-Length = 1*DIGIT
Date = HTTP-date
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 "/" DIGIT "." DIGIT HTTP-Version = HTTP-Prot-Name "/" DIGIT "." DIGIT
HTTP-date = rfc1123-date / obs-date
HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body
] ]
Host = uri-host [ ":" port ] Host = uri-host [ ":" port ]
Method = token Method = token
OWS = *( [ obs-fold ] WSP ) OWS = *( SP / HTAB / obs-fold )
RWS = 1*( [ obs-fold ] WSP ) RWS = 1*( SP / HTAB / obs-fold )
Reason-Phrase = *( WSP / VCHAR / obs-text ) Reason-Phrase = *( HTAB / SP / VCHAR / obs-text )
Request = Request-Line *( header-field CRLF ) CRLF [ message-body ]
Request-Line = Method SP request-target SP HTTP-Version CRLF Request-Line = Method SP request-target SP HTTP-Version CRLF
Response = Status-Line *( header-field CRLF ) CRLF [ message-body ]
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 = [ ( "," / t-codings ) *( OWS "," [ OWS t-codings ] ) ] TE = [ ( "," / t-codings ) *( OWS "," [ OWS t-codings ] ) ]
Trailer = *( "," OWS ) field-name *( OWS "," [ OWS field-name ] ) Trailer = *( "," OWS ) field-name *( OWS "," [ OWS field-name ] )
Transfer-Encoding = *( "," OWS ) transfer-coding *( OWS "," [ OWS Transfer-Encoding = *( "," OWS ) transfer-coding *( OWS "," [ OWS
transfer-coding ] ) transfer-coding ] )
URI-reference = <URI-reference, defined in [RFC3986], Section 4.1> URI-reference = <URI-reference, defined in [RFC3986], Section 4.1>
Upgrade = *( "," OWS ) product *( OWS "," [ OWS product ] ) Upgrade = *( "," OWS ) product *( OWS "," [ OWS product ] )
Via = *( "," OWS ) received-protocol RWS received-by [ RWS comment ] Via = *( "," OWS ) received-protocol RWS received-by [ RWS comment ]
*( OWS "," [ OWS received-protocol RWS received-by [ RWS comment ] ] *( OWS "," [ OWS received-protocol RWS received-by [ RWS comment ] ]
) )
absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3> absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3>
asctime-date = day-name SP date3 SP time-of-day SP year
attribute = token attribute = token
authority = <authority, defined in [RFC3986], Section 3.2> authority = <authority, defined in [RFC3986], Section 3.2>
chunk = chunk-size *WSP [ chunk-ext ] CRLF chunk-data CRLF chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF
chunk-data = 1*OCTET chunk-data = 1*OCTET
chunk-ext = *( ";" *WSP chunk-ext-name [ "=" chunk-ext-val ] *WSP ) chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
chunk-ext-name = token chunk-ext-name = token
chunk-ext-val = token / quoted-str-nf chunk-ext-val = token / quoted-str-nf
chunk-size = 1*HEXDIG chunk-size = 1*HEXDIG
comment = "(" *( ctext / quoted-cpair / comment ) ")" comment = "(" *( ctext / quoted-cpair / comment ) ")"
connection-token = token connection-token = token
ctext = OWS / %x21-27 ; '!'-''' ctext = OWS / %x21-27 ; '!'-'''
/ %x2A-5B ; '*'-'[' / %x2A-5B ; '*'-'['
/ %x5D-7E ; ']'-'~' / %x5D-7E ; ']'-'~'
/ obs-text / obs-text
date1 = day SP month SP year field-content = *( HTAB / SP / VCHAR / obs-text )
date2 = day "-" month "-" 2DIGIT
date3 = month SP ( 2DIGIT / ( SP DIGIT ) )
day = 2DIGIT
day-name = %x4D.6F.6E ; Mon
/ %x54.75.65 ; Tue
/ %x57.65.64 ; Wed
/ %x54.68.75 ; Thu
/ %x46.72.69 ; Fri
/ %x53.61.74 ; Sat
/ %x53.75.6E ; Sun
day-name-l = %x4D.6F.6E.64.61.79 ; Monday
/ %x54.75.65.73.64.61.79 ; Tuesday
/ %x57.65.64.6E.65.73.64.61.79 ; Wednesday
/ %x54.68.75.72.73.64.61.79 ; Thursday
/ %x46.72.69.64.61.79 ; Friday
/ %x53.61.74.75.72.64.61.79 ; Saturday
/ %x53.75.6E.64.61.79 ; Sunday
field-content = *( WSP / VCHAR / obs-text )
field-name = token field-name = token
field-value = *( field-content / OWS ) field-value = *( field-content / obs-fold )
header-field = field-name ":" OWS [ field-value ] OWS header-field = field-name ":" OWS field-value BWS
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" [ chunk-ext ] CRLF
message-body = *OCTET message-body = *OCTET
minute = 2DIGIT
month = %x4A.61.6E ; Jan
/ %x46.65.62 ; Feb
/ %x4D.61.72 ; Mar
/ %x41.70.72 ; Apr
/ %x4D.61.79 ; May
/ %x4A.75.6E ; Jun
/ %x4A.75.6C ; Jul
/ %x41.75.67 ; Aug
/ %x53.65.70 ; Sep
/ %x4F.63.74 ; Oct
/ %x4E.6F.76 ; Nov
/ %x44.65.63 ; Dec
obs-date = rfc850-date / asctime-date obs-fold = CRLF ( SP / HTAB )
obs-fold = CRLF
obs-text = %x80-FF obs-text = %x80-FF
partial-URI = relative-part [ "?" query ] partial-URI = relative-part [ "?" query ]
path-abempty = <path-abempty, defined in [RFC3986], Section 3.3> path-abempty = <path-abempty, defined in [RFC3986], Section 3.3>
path-absolute = <path-absolute, defined in [RFC3986], Section 3.3> path-absolute = <path-absolute, defined in [RFC3986], Section 3.3>
port = <port, defined in [RFC3986], Section 3.2.3> port = <port, defined in [RFC3986], Section 3.2.3>
product = token [ "/" product-version ] product = token [ "/" product-version ]
product-version = token product-version = token
protocol-name = token protocol-name = token
protocol-version = token protocol-version = token
skipping to change at page 79, line 36 skipping to change at page 75, line 4
partial-URI = relative-part [ "?" query ] partial-URI = relative-part [ "?" query ]
path-abempty = <path-abempty, defined in [RFC3986], Section 3.3> path-abempty = <path-abempty, defined in [RFC3986], Section 3.3>
path-absolute = <path-absolute, defined in [RFC3986], Section 3.3> path-absolute = <path-absolute, defined in [RFC3986], Section 3.3>
port = <port, defined in [RFC3986], Section 3.2.3> port = <port, defined in [RFC3986], Section 3.2.3>
product = token [ "/" product-version ] product = token [ "/" product-version ]
product-version = token product-version = token
protocol-name = token protocol-name = token
protocol-version = token protocol-version = token
pseudonym = token pseudonym = token
qdtext = OWS / "!" / %x23-5B ; '#'-'[' qdtext = OWS / "!" / %x23-5B ; '#'-'['
/ %x5D-7E ; ']'-'~' / %x5D-7E ; ']'-'~'
/ obs-text / obs-text
qdtext-nf = WSP / "!" / %x23-5B ; '#'-'[' qdtext-nf = HTAB / SP / "!" / %x23-5B ; '#'-'['
/ %x5D-7E ; ']'-'~' / %x5D-7E ; ']'-'~'
/ obs-text / obs-text
query = <query, defined in [RFC3986], Section 3.4> query = <query, defined in [RFC3986], Section 3.4>
quoted-cpair = "\" ( WSP / VCHAR / obs-text ) quoted-cpair = "\" ( HTAB / SP / VCHAR / obs-text )
quoted-pair = "\" ( WSP / VCHAR / obs-text ) quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
quoted-str-nf = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE quoted-str-nf = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE
quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] ) qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
received-by = ( uri-host [ ":" port ] ) / pseudonym received-by = ( uri-host [ ":" port ] ) / pseudonym
received-protocol = [ protocol-name "/" ] protocol-version received-protocol = [ protocol-name "/" ] protocol-version
relative-part = <relative-part, defined in [RFC3986], Section 4.2> relative-part = <relative-part, defined in [RFC3986], Section 4.2>
request-target = "*" / absolute-URI / ( path-absolute [ "?" query ] ) request-target = "*" / absolute-URI / ( path-absolute [ "?" query ] )
/ authority / authority
rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT
rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT
second = 2DIGIT
special = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" / special = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" /
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
token = 1*tchar token = 1*tchar
trailer-part = *( header-field 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
year = 4DIGIT
ABNF diagnostics: ABNF diagnostics:
; Chunked-Body defined but not used ; Chunked-Body defined but not used
; Connection defined but not used ; Connection defined but not used
; Content-Length defined but not used ; Content-Length defined but not used
; Date defined but not used
; HTTP-message defined but not used ; HTTP-message defined but not used
; Host defined but not used ; Host defined but not used
; Request defined but not used
; Response defined but not used
; TE defined but not used ; TE defined but not used
; Trailer defined but not used ; Trailer defined but not used
; Transfer-Encoding defined but not used ; Transfer-Encoding defined but not used
; URI-reference defined but not used ; URI-reference defined but not used
; Upgrade defined but not used ; Upgrade defined but not used
; Via defined but not used ; Via 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
; special defined but not used ; special defined but not used
skipping to change at page 82, line 51 skipping to change at page 77, line 48
o <http://tools.ietf.org/wg/httpbis/trac/ticket/66>: "ISO-8859-1 o <http://tools.ietf.org/wg/httpbis/trac/ticket/66>: "ISO-8859-1
Reference" Reference"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/86>: "Normative up- o <http://tools.ietf.org/wg/httpbis/trac/ticket/86>: "Normative up-
to-date references" to-date references"
Other changes: Other changes:
o Update media type registrations to use RFC4288 template. o Update media type registrations to use RFC4288 template.
o Use names of RFC4234 core rules DQUOTE and WSP, fix broken ABNF o Use names of RFC4234 core rules DQUOTE and HTAB, fix broken ABNF
for chunk-data (work in progress on for chunk-data (work in progress on
<http://tools.ietf.org/wg/httpbis/trac/ticket/36>) <http://tools.ietf.org/wg/httpbis/trac/ticket/36>)
C.3. Since draft-ietf-httpbis-p1-messaging-01 C.3. Since draft-ietf-httpbis-p1-messaging-01
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/19>: "Bodies on GET o <http://tools.ietf.org/wg/httpbis/trac/ticket/19>: "Bodies on GET
(and other) requests" (and other) requests"
skipping to change at page 91, line 11 skipping to change at page 86, line 11
o <http://tools.ietf.org/wg/httpbis/trac/ticket/254>: "move RFCs o <http://tools.ietf.org/wg/httpbis/trac/ticket/254>: "move RFCs
2145, 2616, 2817 to Historic status" 2145, 2616, 2817 to Historic status"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/270>: "\-escaping in o <http://tools.ietf.org/wg/httpbis/trac/ticket/270>: "\-escaping in
quoted strings" quoted strings"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/305>: "'Close' o <http://tools.ietf.org/wg/httpbis/trac/ticket/305>: "'Close'
should be reserved in the HTTP header field registry" should be reserved in the HTTP header field registry"
C.18. Since draft-ietf-httpbis-p1-messaging-16
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/186>: "Document
HTTP's error-handling philosophy"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/215>: "Explain
header registration"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/219>: "Revise
Acknowledgements Sections"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/297>: "Retrying
Requests"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/318>: "Closing the
connection on server error"
Index Index
A A
absolute-URI form (of request-target) 30 absolute-URI form (of request-target) 31
accelerator 13 accelerator 13
application/http Media Type 66 application/http Media Type 61
asterisk form (of request-target) 30 asterisk form (of request-target) 31
authority form (of request-target) 31 authority form (of request-target) 32
B B
browser 9 browser 10
C C
cache 14 cache 14
cacheable 14 cacheable 15
captive portal 14 captive portal 14
chunked (Coding Format) 39 chunked (Coding Format) 36
client 9 client 10
Coding Format Coding Format
chunked 39 chunked 36
compress 42 compress 38
deflate 42 deflate 38
gzip 42 gzip 39
compress (Coding Format) 42
connection 9 compress (Coding Format) 38
Connection header field 53 connection 10
Content-Length header field 55 Connection header field 49
Content-Length header field 51
D D
Date header field 55 deflate (Coding Format) 38
deflate (Coding Format) 42 downstream 13
downstream 12
E E
effective request URI 33 effective request URI 34
G G
gateway 13 gateway 13
Grammar Grammar
absolute-URI 17 absolute-URI 17
ALPHA 7 ALPHA 7
asctime-date 38 attribute 35
attribute 38
authority 17 authority 17
BWS 9 BWS 9
chunk 39 chunk 36
chunk-data 39 chunk-data 36
chunk-ext 39 chunk-ext 36
chunk-ext-name 39 chunk-ext-name 36
chunk-ext-val 39 chunk-ext-val 36
chunk-size 39 chunk-size 36
Chunked-Body 39 Chunked-Body 36
comment 25 comment 26
Connection 54 Connection 50
connection-token 54 connection-token 50
Content-Length 55 Content-Length 51
CR 7 CR 7
CRLF 7 CRLF 7
ctext 25 ctext 26
CTL 7 CTL 7
Date 55 date2 35
date1 37 date3 35
date2 38
date3 38
day 37
day-name 37
day-name-l 37
DIGIT 7 DIGIT 7
DQUOTE 7 DQUOTE 7
field-content 22 field-content 23
field-name 22 field-name 23
field-value 22 field-value 23
GMT 37 header-field 23
header-field 22
HEXDIG 7 HEXDIG 7
Host 57 Host 52
hour 37 HTAB 7
HTTP-date 36
HTTP-message 21 HTTP-message 21
HTTP-Prot-Name 15 HTTP-Prot-Name 15
http-URI 18 http-URI 18
HTTP-Version 15 HTTP-Version 15
https-URI 19 https-URI 19
last-chunk 39 last-chunk 36
LF 7 LF 7
message-body 25 message-body 27
Method 30 Method 22
minute 37 obs-text 26
month 37
obs-date 37
obs-text 24
OCTET 7 OCTET 7
OWS 9 OWS 9
path-absolute 17 path-absolute 17
port 17 port 17
product 43 product 39
product-version 43 product-version 39
protocol-name 62 protocol-name 57
protocol-version 62 protocol-version 57
pseudonym 62 pseudonym 57
qdtext 24 qdtext 26
qdtext-nf 39 qdtext-nf 36
query 17 query 17
quoted-cpair 25 quoted-cpair 26
quoted-pair 25 quoted-pair 26
quoted-str-nf 39 quoted-str-nf 36
quoted-string 24 quoted-string 26
qvalue 43 qvalue 40
Reason-Phrase 35 Reason-Phrase 23
received-by 62 received-by 57
received-protocol 62 received-protocol 57
Request 29 Request-Line 22
Request-Line 30 request-target 22
request-target 30
Response 34
rfc850-date 38
rfc1123-date 37
RWS 9 RWS 9
second 37
SP 7 SP 7
special 24 special 26
Status-Code 35 start-line 21
Status-Line 35 Status-Code 23
t-codings 58 Status-Line 23
tchar 24 t-codings 53
TE 58 tchar 26
te-ext 58 TE 53
te-params 58 te-ext 53
time-of-day 37 te-params 53
token 24 token 26
Trailer 59 Trailer 54
trailer-part 39 trailer-part 36
transfer-coding 38 transfer-coding 35
Transfer-Encoding 60 Transfer-Encoding 54
transfer-extension 38 transfer-extension 35
transfer-parameter 38 transfer-parameter 35
Upgrade 60 Upgrade 55
uri-host 17 uri-host 17
URI-reference 17 URI-reference 17
value 38 value 35
VCHAR 7 VCHAR 7
Via 62 Via 57
word 24 word 26
WSP 7 gzip (Coding Format) 39
year 37
gzip (Coding Format) 42
H H
header field 20 header field 20
Header Fields Header Fields
Connection 53 Connection 49
Content-Length 55 Content-Length 51
Date 55 Host 51
Host 57 TE 53
TE 58 Trailer 54
Trailer 59 Transfer-Encoding 54
Transfer-Encoding 59 Upgrade 55
Upgrade 60 Via 57
Via 62
header section 20 header section 20
headers 20 headers 20
Host header field 57 Host header field 51
http URI scheme 18 http URI scheme 18
https URI scheme 19 https URI scheme 19
I I
inbound 12 inbound 13
interception proxy 14 interception proxy 14
intermediary 12 intermediary 12
M M
Media Type Media Type
application/http 66 application/http 61
message/http 64 message/http 59
message 10 message 10
message/http Media Type 64 message/http Media Type 59
N N
non-transforming proxy 13 non-transforming proxy 13
O O
origin form (of request-target) 31 origin form (of request-target) 32
origin server 9 origin server 10
outbound 12 outbound 13
P P
proxy 12 proxy 13
R R
recipient 9 recipient 10
request 10 request 10
resource 17 resource 17
response 10 response 10
reverse proxy 13 reverse proxy 13
S S
sender 9 sender 10
server 9 server 10
spider 9 spider 10
T T
target resource 33 target resource 34
TE header field 58 TE header field 53
Trailer header field 59 Trailer header field 54
Transfer-Encoding header field 59 Transfer-Encoding header field 54
transforming proxy 13 transforming proxy 13
transparent proxy 14 transparent proxy 14
tunnel 13 tunnel 14
U U
Upgrade header field 60 Upgrade header field 55
upstream 12 upstream 13
URI scheme URI scheme
http 18 http 18
https 19 https 19
user agent 9 user agent 10
V V
Via header field 62 Via header field 57
Authors' Addresses Authors' Addresses
Roy T. Fielding (editor) Roy T. Fielding (editor)
Adobe Systems Incorporated Adobe Systems Incorporated
345 Park Ave 345 Park Ave
San Jose, CA 95110 San Jose, CA 95110
USA USA
EMail: fielding@gbiv.com EMail: fielding@gbiv.com
 End of changes. 244 change blocks. 
912 lines changed or deleted 701 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/