draft-ietf-httpbis-p1-messaging-18.txt   draft-ietf-httpbis-p1-messaging-latest.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: July 7, 2012 HP Expires: August 6, 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
January 4, 2012 February 3, 2012
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-18 draft-ietf-httpbis-p1-messaging-latest
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.19. The changes in this draft are summarized in Appendix C.20.
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 July 7, 2012. This Internet-Draft will expire on August 6, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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. Conformance and Error Handling . . . . . . . . . . . . . . 7 1.1. Requirement Notation . . . . . . . . . . . . . . . . . . . 7
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7
1.2.1. ABNF Extension: #rule . . . . . . . . . . . . . . . . 8 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . 9 2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 7
2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2. Connections and Transport Independence . . . . . . . . . . 9
2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 10 2.3. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 9
2.2. Message Orientation and Buffering . . . . . . . . . . . . 11 2.4. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3. Connections and Transport Independence . . . . . . . . . . 12 2.5. Conformance and Error Handling . . . . . . . . . . . . . . 12
2.4. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 12 2.6. Protocol Versioning . . . . . . . . . . . . . . . . . . . 13
2.5. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.7. Uniform Resource Identifiers . . . . . . . . . . . . . . . 15
2.6. Protocol Versioning . . . . . . . . . . . . . . . . . . . 15 2.7.1. http URI scheme . . . . . . . . . . . . . . . . . . . 16
2.7. Uniform Resource Identifiers . . . . . . . . . . . . . . . 17 2.7.2. https URI scheme . . . . . . . . . . . . . . . . . . . 17
2.7.1. http URI scheme . . . . . . . . . . . . . . . . . . . 18 2.7.3. http and https URI Normalization and Comparison . . . 18
2.7.2. https URI scheme . . . . . . . . . . . . . . . . . . . 19 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 19
2.7.3. http and https URI Normalization and Comparison . . . 20 3.1. Start Line . . . . . . . . . . . . . . . . . . . . . . . . 19
3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 21 3.1.1. Request-Line . . . . . . . . . . . . . . . . . . . . . 20
3.1. Start Line . . . . . . . . . . . . . . . . . . . . . . . . 21 3.1.2. Response Status-Line . . . . . . . . . . . . . . . . . 21
3.1.1. Request-Line . . . . . . . . . . . . . . . . . . . . . 22 3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 21
3.1.2. Response Status-Line . . . . . . . . . . . . . . . . . 23 3.2.1. Whitespace . . . . . . . . . . . . . . . . . . . . . . 23
3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 23 3.2.2. Field Parsing . . . . . . . . . . . . . . . . . . . . 23
3.2.1. Field Parsing . . . . . . . . . . . . . . . . . . . . 25 3.2.3. Field Length . . . . . . . . . . . . . . . . . . . . . 24
3.2.2. Field Length . . . . . . . . . . . . . . . . . . . . . 25 3.2.4. Field value components . . . . . . . . . . . . . . . . 25
3.2.3. Common Field ABNF Rules . . . . . . . . . . . . . . . 26 3.2.5. ABNF list extension: #rule . . . . . . . . . . . . . . 26
3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 27 3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 27
3.4. Handling Incomplete Messages . . . . . . . . . . . . . . . 30 3.4. Handling Incomplete Messages . . . . . . . . . . . . . . . 30
3.5. Message Parsing Robustness . . . . . . . . . . . . . . . . 31 3.5. Message Parsing Robustness . . . . . . . . . . . . . . . . 31
4. Message Routing . . . . . . . . . . . . . . . . . . . . . . . 31 4. Message Routing . . . . . . . . . . . . . . . . . . . . . . . 31
4.1. Types of Request Target . . . . . . . . . . . . . . . . . 31 4.1. Types of Request Target . . . . . . . . . . . . . . . . . 31
4.2. The Resource Identified by a Request . . . . . . . . . . . 33 4.2. The Resource Identified by a Request . . . . . . . . . . . 33
4.3. Effective Request URI . . . . . . . . . . . . . . . . . . 34 4.3. Effective Request URI . . . . . . . . . . . . . . . . . . 34
5. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 35 5. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 35
5.1. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 35 5.1. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 35
5.1.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 36 5.1.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 36
5.1.2. Compression Codings . . . . . . . . . . . . . . . . . 38 5.1.2. Compression Codings . . . . . . . . . . . . . . . . . 38
5.1.3. Transfer Coding Registry . . . . . . . . . . . . . . . 39 5.1.3. Transfer Coding Registry . . . . . . . . . . . . . . . 39
5.2. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 39 5.2. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 40
5.3. Quality Values . . . . . . . . . . . . . . . . . . . . . . 40 5.3. Quality Values . . . . . . . . . . . . . . . . . . . . . . 40
6. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 40 6. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.1. Persistent Connections . . . . . . . . . . . . . . . . . . 40 6.1. Persistent Connections . . . . . . . . . . . . . . . . . . 41
6.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 40 6.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 41
6.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 41 6.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 41
6.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 42 6.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 43
6.1.4. Practical Considerations . . . . . . . . . . . . . . . 45 6.1.4. Practical Considerations . . . . . . . . . . . . . . . 45
6.1.5. Retrying Requests . . . . . . . . . . . . . . . . . . 46 6.1.5. Retrying Requests . . . . . . . . . . . . . . . . . . 46
6.2. Message Transmission Requirements . . . . . . . . . . . . 46 6.2. Message Transmission Requirements . . . . . . . . . . . . 46
6.2.1. Persistent Connections and Flow Control . . . . . . . 46 6.2.1. Persistent Connections and Flow Control . . . . . . . 46
6.2.2. Monitoring Connections for Error Status Messages . . . 46 6.2.2. Monitoring Connections for Error Status Messages . . . 47
6.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 46 6.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 47
7. Miscellaneous notes that might disappear . . . . . . . . . . . 48 7. Miscellaneous notes that might disappear . . . . . . . . . . . 49
7.1. Scheme aliases considered harmful . . . . . . . . . . . . 48 7.1. Scheme aliases considered harmful . . . . . . . . . . . . 49
7.2. Use of HTTP for proxy communication . . . . . . . . . . . 49 7.2. Use of HTTP for proxy communication . . . . . . . . . . . 49
7.3. Interception of HTTP for access control . . . . . . . . . 49 7.3. Interception of HTTP for access control . . . . . . . . . 49
7.4. Use of HTTP by other protocols . . . . . . . . . . . . . . 49 7.4. Use of HTTP by other protocols . . . . . . . . . . . . . . 49
7.5. Use of HTTP by media type specification . . . . . . . . . 49 7.5. Use of HTTP by media type specification . . . . . . . . . 49
8. Header Field Definitions . . . . . . . . . . . . . . . . . . . 49 8. Header Field Definitions . . . . . . . . . . . . . . . . . . . 49
8.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 49 8.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 50
8.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 51 8.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 51
8.3. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 8.3. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
8.4. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 8.4. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
8.5. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 54 8.5. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 54
8.6. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 54 8.6. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 55
8.7. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 55 8.7. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 55
8.7.1. Upgrade Token Registry . . . . . . . . . . . . . . . . 56 8.7.1. Upgrade Token Registry . . . . . . . . . . . . . . . . 56
8.8. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 8.8. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59
9.1. Header Field Registration . . . . . . . . . . . . . . . . 58 9.1. Header Field Registration . . . . . . . . . . . . . . . . 59
9.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 59 9.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 59
9.3. Internet Media Type Registrations . . . . . . . . . . . . 59 9.3. Internet Media Type Registrations . . . . . . . . . . . . 60
9.3.1. Internet Media Type message/http . . . . . . . . . . . 59 9.3.1. Internet Media Type message/http . . . . . . . . . . . 60
9.3.2. Internet Media Type application/http . . . . . . . . . 61 9.3.2. Internet Media Type application/http . . . . . . . . . 61
9.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 62 9.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 62
9.5. Upgrade Token Registration . . . . . . . . . . . . . . . . 62 9.5. Upgrade Token Registration . . . . . . . . . . . . . . . . 62
10. Security Considerations . . . . . . . . . . . . . . . . . . . 62 10. Security Considerations . . . . . . . . . . . . . . . . . . . 63
10.1. Personal Information . . . . . . . . . . . . . . . . . . . 63 10.1. Personal Information . . . . . . . . . . . . . . . . . . . 63
10.2. Abuse of Server Log Information . . . . . . . . . . . . . 63 10.2. Abuse of Server Log Information . . . . . . . . . . . . . 63
10.3. Attacks Based On File and Path Names . . . . . . . . . . . 63 10.3. Attacks Based On File and Path Names . . . . . . . . . . . 63
10.4. DNS-related Attacks . . . . . . . . . . . . . . . . . . . 63 10.4. DNS-related Attacks . . . . . . . . . . . . . . . . . . . 64
10.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 64 10.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 64
10.6. Protocol Element Size Overflows . . . . . . . . . . . . . 64 10.6. Protocol Element Size Overflows . . . . . . . . . . . . . 65
10.7. Denial of Service Attacks on Proxies . . . . . . . . . . . 65 10.7. Denial of Service Attacks on Proxies . . . . . . . . . . . 65
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 65 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 65
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 66 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 67
12.1. Normative References . . . . . . . . . . . . . . . . . . . 66 12.1. Normative References . . . . . . . . . . . . . . . . . . . 67
12.2. Informative References . . . . . . . . . . . . . . . . . . 67 12.2. Informative References . . . . . . . . . . . . . . . . . . 68
Appendix A. HTTP Version History . . . . . . . . . . . . . . . . 69 Appendix A. HTTP Version History . . . . . . . . . . . . . . . . 70
A.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 70 A.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 71
A.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 70 A.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 71
A.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 71 A.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 71
A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 71 A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 72
Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 72 Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 73
Appendix C. Change Log (to be removed by RFC Editor before Appendix C. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 75 publication) . . . . . . . . . . . . . . . . . . . . 76
C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 75 C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 76
C.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 75 C.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 76
C.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 77 C.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 78
C.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 78 C.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 79
C.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 78 C.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 79
C.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 79 C.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 80
C.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 79 C.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 80
C.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 80 C.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 81
C.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 81 C.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 82
C.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 82 C.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 82
C.11. Since draft-ietf-httpbis-p1-messaging-09 . . . . . . . . . 82 C.11. Since draft-ietf-httpbis-p1-messaging-09 . . . . . . . . . 83
C.12. Since draft-ietf-httpbis-p1-messaging-10 . . . . . . . . . 82 C.12. Since draft-ietf-httpbis-p1-messaging-10 . . . . . . . . . 83
C.13. Since draft-ietf-httpbis-p1-messaging-11 . . . . . . . . . 83 C.13. Since draft-ietf-httpbis-p1-messaging-11 . . . . . . . . . 84
C.14. Since draft-ietf-httpbis-p1-messaging-12 . . . . . . . . . 83 C.14. Since draft-ietf-httpbis-p1-messaging-12 . . . . . . . . . 84
C.15. Since draft-ietf-httpbis-p1-messaging-13 . . . . . . . . . 84 C.15. Since draft-ietf-httpbis-p1-messaging-13 . . . . . . . . . 85
C.16. Since draft-ietf-httpbis-p1-messaging-14 . . . . . . . . . 84 C.16. Since draft-ietf-httpbis-p1-messaging-14 . . . . . . . . . 85
C.17. Since draft-ietf-httpbis-p1-messaging-15 . . . . . . . . . 85 C.17. Since draft-ietf-httpbis-p1-messaging-15 . . . . . . . . . 85
C.18. Since draft-ietf-httpbis-p1-messaging-16 . . . . . . . . . 85 C.18. Since draft-ietf-httpbis-p1-messaging-16 . . . . . . . . . 86
C.19. Since draft-ietf-httpbis-p1-messaging-17 . . . . . . . . . 85 C.19. Since draft-ietf-httpbis-p1-messaging-17 . . . . . . . . . 86
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 C.20. Since draft-ietf-httpbis-p1-messaging-18 . . . . . . . . . 87
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
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. Conformance and Error Handling 1.1. Requirement Notation
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].
This document defines conformance criteria for several roles in HTTP
communication, including Senders, Recipients, Clients, Servers, User-
Agents, Origin Servers, Intermediaries, Proxies and Gateways. See
Section 2 for definitions of these terms.
An implementation is considered conformant if it complies with all of
the requirements associated with its role(s). Note that SHOULD-level
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] with the list rule extension defined in
Section 3.2.5. Appendix B shows the collected ABNF with the list
rule expanded.
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), HTAB (horizontal tab), LF (line HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line
feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any
visible [USASCII] character). visible [USASCII] character).
As a syntactic convention, ABNF rule names prefixed with "obs-" As a convention, ABNF rule names prefixed with "obs-" denote
denote "obsolete" grammar rules that appear for historical reasons. "obsolete" grammar rules that appear for historical reasons.
1.2.1. ABNF Extension: #rule
The #rule extension to the ABNF rules of [RFC5234] is used to improve
readability.
A construct "#" is defined, similar to "*", for defining comma-
delimited lists of elements. The full form is "<n>#<m>element"
indicating at least <n> and at most <m> elements, each separated by a
single comma (",") and optional whitespace (OWS, Section 1.2.2).
Thus,
1#element => element *( OWS "," OWS element )
and:
#element => [ 1#element ]
and for n >= 1 and m > 1:
<n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element )
For compatibility with legacy list rules, recipients SHOULD accept
empty list elements. In other words, consumers would follow the list
productions:
#element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ]
1#element => *( "," OWS ) element *( OWS "," [ OWS element ] )
Note that empty elements do not contribute to the count of elements
present, though.
For example, given these ABNF productions:
example-list = 1#example-list-elmt
example-list-elmt = token ; see Section 3.2.3
Then these are valid values for example-list (not including the
double quotes, which are present for delimitation only):
"foo,bar"
"foo ,bar,"
"foo , ,bar,charlie "
But these values would be invalid, as at least one non-empty element
is required:
""
","
", ,"
Appendix B shows the collected ABNF, with the list rules expanded as
explained above.
1.2.2. Basic Rules
This specification uses three rules to denote the use of linear
whitespace: OWS (optional whitespace), RWS (required whitespace), and
BWS ("bad" whitespace).
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
single SP. Multiple OWS octets that occur within field-content
SHOULD either be replaced with a single SP or transformed to all SP
octets (each octet other than SP replaced with SP) before
interpreting the field value or forwarding the message downstream.
RWS is used when at least one linear whitespace octet is required to
separate field tokens. RWS SHOULD be produced as a single SP.
Multiple RWS octets that occur within field-content SHOULD either be
replaced with a single SP or transformed to all SP octets before
interpreting the field value or forwarding the message downstream.
BWS is used where the grammar allows optional whitespace for
historical reasons but senders SHOULD NOT produce it in messages.
HTTP/1.1 recipients MUST accept such bad optional whitespace and
remove it before interpreting the field value or forwarding the
message downstream.
OWS = *( SP / HTAB / obs-fold )
; "optional" whitespace
RWS = 1*( SP / HTAB / obs-fold )
; "required" whitespace
BWS = OWS
; "bad" whitespace
obs-fold = CRLF ( SP / HTAB )
; obsolete line folding
; see Section 3.2.1
2. 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
skipping to change at page 11, line 42 skipping to change at page 9, line 26
Server: Apache Server: Apache
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00" ETag: "34aa387-d-1568eb00"
Accept-Ranges: bytes Accept-Ranges: bytes
Content-Length: 14 Content-Length: 14
Vary: Accept-Encoding Vary: Accept-Encoding
Content-Type: text/plain Content-Type: text/plain
Hello World! Hello World!
2.2. Message Orientation and Buffering 2.2. Connections and Transport Independence
Fundamentally, HTTP is a message-based protocol. Although message
bodies can be chunked (Section 5.1.1) and implementations often make
parts of a message available progressively, this is not required, and
some widely-used implementations only make a message available when
it is complete. Furthermore, while most proxies will progressively
stream messages, some amount of buffering will take place, and some
proxies might buffer messages to perform transformations, check
content or provide other services.
Therefore, extensions to and uses of HTTP cannot rely on the
availability of a partial message, or assume that messages will not
be buffered. There are strategies that can be used to test for
buffering in a given connection, but it should be understood that
behaviors can differ across connections, and between requests and
responses.
Recipients MUST consider every message in a connection in isolation;
because HTTP is a stateless protocol, it cannot be assumed that two
requests on the same connection are from the same client or share any
other common attributes. In particular, intermediaries might mix
requests from different clients into a single server connection.
Note that some existing HTTP extensions (e.g., [RFC4559]) violate
this requirement, thereby potentially causing interoperability and
security problems.
2.3. Connections and Transport Independence
HTTP messaging is independent of the underlying transport or session- HTTP messaging is independent of the underlying transport or session-
layer connection protocol(s). HTTP only presumes a reliable layer connection protocol(s). HTTP only presumes a reliable
transport with in-order delivery of requests and the corresponding transport with in-order delivery of requests and the corresponding
in-order delivery of responses. The mapping of HTTP request and in-order delivery of responses. The mapping of HTTP request and
response structures onto the data units of the underlying transport response structures onto the data units of the underlying transport
protocol is outside the scope of this specification. protocol is outside the scope of this specification.
The specific connection protocols to be used for an interaction are The specific connection protocols to be used for an interaction are
determined by client configuration and the target resource's URI. determined by client configuration and the target resource's URI.
For example, the "http" URI scheme (Section 2.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 6.1. exchanges, as defined in Section 6.1.
2.4. Intermediaries 2.3. Intermediaries
HTTP enables the use of intermediaries to satisfy requests through a HTTP enables the use of intermediaries to satisfy requests through a
chain of connections. There are three common forms of HTTP chain of connections. There are three common forms of HTTP
intermediary: proxy, gateway, and tunnel. In some cases, a single intermediary: proxy, gateway, and tunnel. In some cases, a single
intermediary might act as an origin server, proxy, gateway, or intermediary might act as an origin server, proxy, gateway, or
tunnel, switching behavior based on the nature of each request. tunnel, switching behavior based on the nature of each request.
> > > > > > > >
UA =========== A =========== B =========== C =========== O UA =========== A =========== B =========== C =========== O
< < < < < < < <
skipping to change at page 14, line 16 skipping to change at page 11, line 21
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 conform to HTTP user agent requirements
requirements on the gateway's inbound connection and MUST implement on the gateway's inbound connection and MUST implement the Connection
the Connection (Section 8.1) and Via (Section 8.8) header fields for (Section 8.1) and Via (Section 8.8) header fields for both
both connections. 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 14, line 45 skipping to change at page 11, line 50
proxy" [RFC3040], "transparent proxy" [RFC1919], or "captive portal", proxy" [RFC3040], "transparent proxy" [RFC1919], or "captive portal",
differs from an HTTP proxy because it has not been selected by the differs from an HTTP proxy because it has not been selected by the
client. Instead, the network intermediary redirects outgoing TCP client. Instead, the network intermediary redirects outgoing TCP
port 80 packets (and occasionally other common port traffic) to an port 80 packets (and occasionally other common port traffic) to an
internal HTTP server. Interception proxies are commonly found on internal HTTP server. Interception proxies are commonly found on
public network access points, as a means of enforcing account public network access points, as a means of enforcing account
subscription prior to allowing use of non-local Internet services, subscription prior to allowing use of non-local Internet services,
and within corporate firewalls to enforce network usage policies. and within corporate firewalls to enforce network usage policies.
They are indistinguishable from a man-in-the-middle attack. They are indistinguishable from a man-in-the-middle attack.
2.5. Caches HTTP is defined as a stateless protocol, meaning that each request
message can be understood in isolation. Many implementations depend
on HTTP's stateless design in order to reuse proxied connections or
dynamically load balance requests across multiple servers. Hence,
servers MUST NOT assume that two requests on the same connection are
from the same user agent unless the connection is secured and
specific to that agent. Some non-standard HTTP extensions (e.g.,
[RFC4559]) have been known to violate this requirement, resulting in
security and interoperability problems.
2.4. Caches
A "cache" is a local store of previous response messages and the A "cache" is a local store of previous response messages and the
subsystem that controls its message storage, retrieval, and deletion. subsystem that controls its message storage, retrieval, and deletion.
A cache stores cacheable responses in order to reduce the response A cache stores cacheable responses in order to reduce the response
time and network bandwidth consumption on future, equivalent time and network bandwidth consumption on future, equivalent
requests. Any client or server MAY employ a cache, though a cache requests. Any client or server MAY employ a cache, though a cache
cannot be used by a server while it is acting as a tunnel. cannot be used by a server while it is acting as a tunnel.
The effect of a cache is that the request/response chain is shortened The effect of a cache is that the request/response chain is shortened
if one of the participants along the chain has a cached response if one of the participants along the chain has a cached response
skipping to change at page 15, line 31 skipping to change at page 12, line 46
cache behavior and cacheable responses are defined in Section 2 of cache behavior and cacheable responses are defined in Section 2 of
[Part6]. [Part6].
There are a wide variety of architectures and configurations of There are a wide variety of architectures and configurations of
caches and proxies deployed across the World Wide Web and inside caches and proxies deployed across the World Wide Web and inside
large organizations. These systems include national hierarchies of large organizations. These systems include national hierarchies of
proxy caches to save transoceanic bandwidth, systems that broadcast proxy caches to save transoceanic bandwidth, systems that broadcast
or multicast cache entries, organizations that distribute subsets of or multicast cache entries, organizations that distribute subsets of
cached data via optical media, and so on. cached data via optical media, and so on.
2.5. Conformance and Error Handling
This specification targets conformance criteria according to the role
of a participant in HTTP communication. Hence, HTTP requirements are
placed on senders, recipients, clients, servers, user agents,
intermediaries, origin servers, proxies, gateways, or caches,
depending on what behavior is being constrained by the requirement.
An implementation is considered conformant if it complies with all of
the requirements associated with the roles it partakes in HTTP.
Senders MUST NOT generate protocol elements that do not match the
grammar defined by the ABNF rules for those protocol elements.
Unless otherwise noted, recipients MAY attempt to recover a usable
protocol element from an invalid construct. HTTP does not define
specific error handling mechanisms except when they have a direct
impact on security, since different applications of the protocol
require different error handling strategies. For example, a Web
browser might wish to transparently recover from a response where the
Location header field doesn't parse according to the ABNF, whereas a
systems control client might consider any form of error recovery to
be dangerous.
2.6. Protocol Versioning 2.6. Protocol Versioning
HTTP uses a "<major>.<minor>" numbering scheme to indicate versions HTTP uses a "<major>.<minor>" numbering scheme to indicate versions
of the protocol. This specification defines version "1.1". The of the protocol. This specification defines version "1.1". The
protocol version as a whole indicates the sender's compliance with protocol version as a whole indicates the sender's conformance with
the set of requirements laid out in that version's corresponding the set of requirements laid out in that version's corresponding
specification of HTTP. specification of HTTP.
The version of an HTTP message is indicated by an HTTP-Version field The version of an HTTP message is indicated by an HTTP-Version field
in the first line of the message. HTTP-Version is case-sensitive. in the first line of the message. HTTP-Version is case-sensitive.
HTTP-Version = HTTP-Prot-Name "/" DIGIT "." DIGIT HTTP-Version = HTTP-Prot-Name "/" DIGIT "." DIGIT
HTTP-Prot-Name = %x48.54.54.50 ; "HTTP", case-sensitive HTTP-Prot-Name = %x48.54.54.50 ; "HTTP", case-sensitive
The HTTP version number consists of two decimal digits separated by a The HTTP version number consists of two decimal digits separated by a
"." (period or decimal point). The first digit ("major version") "." (period or decimal point). The first digit ("major version")
indicates the HTTP messaging syntax, whereas the second digit ("minor indicates the HTTP messaging syntax, whereas the second digit ("minor
version") indicates the highest minor version to which the sender is version") indicates the highest minor version to which the sender is
at least conditionally compliant and able to understand for future conformant and able to understand for future communication. The
communication. The minor version advertises the sender's minor version advertises the sender's communication capabilities even
communication capabilities even when the sender is only using a when the sender is only using a backwards-compatible subset of the
backwards-compatible subset of the protocol, thereby letting the protocol, thereby letting the recipient know that more advanced
recipient know that more advanced features can be used in response features can be used in response (by servers) or in future requests
(by servers) or in future requests (by clients). (by clients).
When an HTTP/1.1 message is sent to an HTTP/1.0 recipient [RFC1945] When an HTTP/1.1 message is sent to an HTTP/1.0 recipient [RFC1945]
or a recipient whose version is unknown, the HTTP/1.1 message is or a recipient whose version is unknown, the HTTP/1.1 message is
constructed such that it can be interpreted as a valid HTTP/1.0 constructed such that it can be interpreted as a valid HTTP/1.0
message if all of the newer features are ignored. This specification message if all of the newer features are ignored. This specification
places recipient-version requirements on some new features so that a places recipient-version requirements on some new features so that a
compliant sender will only use compatible features until it has conformant sender will only use compatible features until it has
determined, through configuration or the receipt of a message, that determined, through configuration or the receipt of a message, that
the recipient supports HTTP/1.1. the recipient supports HTTP/1.1.
The interpretation of an HTTP header field does not change between The interpretation of an HTTP header field does not change between
minor versions of the same major version, though the default behavior minor versions of the same major version, though the default behavior
of a recipient in the absence of such a field can change. Unless of a recipient in the absence of such a field can change. Unless
specified otherwise, header fields defined in HTTP/1.1 are defined specified otherwise, header fields defined in HTTP/1.1 are defined
for all versions of HTTP/1.x. In particular, the Host and Connection for all versions of HTTP/1.x. In particular, the Host and Connection
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 conformance 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 8.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 deployed 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 tunnels) 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 in that message matches a version to which that intermediary
conditionally compliant to, for both the receiving and sending of is conformant for both the receiving and sending of messages.
messages. Forwarding an HTTP message without rewriting the HTTP- Forwarding an HTTP message without rewriting the HTTP-Version might
Version might result in communication errors when downstream result in communication errors when downstream recipients use the
recipients use the message sender's version to determine what message sender's version to determine what features are safe to use
features are safe to use for later communication with that sender. for later communication with that sender.
An HTTP client SHOULD send a request version equal to the highest An HTTP client SHOULD send a request version equal to the highest
version for which the client is at least conditionally compliant and version to which the client is conformant and whose major version is
whose major version is no higher than the highest version supported no higher than the highest version supported by the server, if this
by the server, if this is known. An HTTP client MUST NOT send a is known. An HTTP client MUST NOT send a version to which it is not
version for which it is not at least conditionally compliant. conformant.
An HTTP client MAY send a lower request version if it is known that An HTTP client MAY send a lower request version if it is known that
the server incorrectly implements the HTTP specification, but only the server incorrectly implements the HTTP specification, but only
after the client has attempted at least one normal request and after the client has attempted at least one normal request and
determined from the response status or header fields (e.g., Server) determined from the response status or header fields (e.g., Server)
that the server improperly handles higher request versions. that the server improperly handles higher request versions.
An HTTP server SHOULD send a response version equal to the highest An HTTP server SHOULD send a response version equal to the highest
version for which the server is at least conditionally compliant and version to which the server is conformant and whose major version is
whose major version is less than or equal to the one received in the less than or equal to the one received in the request. An HTTP
request. An HTTP server MUST NOT send a version for which it is not server MUST NOT send a version to which it is not conformant. A
at least conditionally compliant. A server MAY send a 505 (HTTP server MAY send a 505 (HTTP Version Not Supported) response if it
Version Not Supported) response if it cannot send a response using cannot send a response using the major version used in the client's
the major version used in the client's request. request.
An HTTP server MAY send an HTTP/1.0 response to an HTTP/1.0 request An HTTP server MAY send an HTTP/1.0 response to an HTTP/1.0 request
if it is known or suspected that the client incorrectly implements if it is known or suspected that the client incorrectly implements
the HTTP specification and is incapable of correctly processing later the HTTP specification and is incapable of correctly processing later
version responses, such as when a client fails to parse the version version responses, such as when a client fails to parse the version
number correctly or when an intermediary is known to blindly forward number correctly or when an intermediary is known to blindly forward
the HTTP-Version even when it doesn't comply with the given minor the HTTP-Version even when it doesn't conform to the given minor
version of the protocol. Such protocol downgrades SHOULD NOT be version of the protocol. Such protocol downgrades SHOULD NOT be
performed unless triggered by specific client attributes, such as performed unless triggered by specific client attributes, such as
when one or more of the request header fields (e.g., User-Agent) when one or more of the request header fields (e.g., User-Agent)
uniquely match the values sent by a client known to be in error. uniquely match the values sent by a client known to be in error.
The intention of HTTP's versioning design is that the major number The intention of HTTP's versioning design is that the major number
will only be incremented if an incompatible message syntax is will only be incremented if an incompatible message syntax is
introduced, and that the minor number will only be incremented when introduced, and that the minor number will only be incremented when
changes made to the protocol have the effect of adding to the message changes made to the protocol have the effect of adding to the message
semantics or implying additional capabilities of the sender. semantics or implying additional capabilities of the sender.
skipping to change at page 21, line 40 skipping to change at page 19, line 40
encoding that is a superset of US-ASCII [USASCII]. Parsing an HTTP encoding that is a superset of US-ASCII [USASCII]. Parsing an HTTP
message as a stream of Unicode characters, without regard for the message as a stream of Unicode characters, without regard for the
specific encoding, creates security vulnerabilities due to the specific encoding, creates security vulnerabilities due to the
varying ways that string processing libraries handle invalid varying ways that string processing libraries handle invalid
multibyte character sequences that contain the octet LF (%x0A). multibyte character sequences that contain the octet LF (%x0A).
String-based parsers can only be safely used within protocol elements String-based parsers can only be safely used within protocol elements
after the element has been extracted from the message, such as within after the element has been extracted from the message, such as within
a header field-value after message parsing has delineated the a header field-value after message parsing has delineated the
individual fields. individual fields.
An HTTP message can be parsed as a stream for incremental processing
or forwarding downstream. However, recipients cannot rely on
incremental delivery of partial messages, since some implementations
will buffer or delay message forwarding for the sake of network
efficiency, security checks, or payload transformations.
3.1. Start Line 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
skipping to change at page 22, line 50 skipping to change at page 21, line 7
request-target = "*" request-target = "*"
/ absolute-URI / absolute-URI
/ ( path-absolute [ "?" query ] ) / ( path-absolute [ "?" query ] )
/ authority / authority
HTTP does not place a pre-defined limit on the length of a request- HTTP does not place a pre-defined limit on the length of a request-
target. A server MUST be prepared to receive URIs of unbounded target. A server MUST be prepared to receive URIs of unbounded
length and respond with the 414 (URI Too Long) status code if the length and respond with the 414 (URI Too Long) status code if the
received request-target would be longer than the server wishes to received request-target would be longer than the server wishes to
handle (see Section 7.4.15 of [Part2]). handle (see Section 7.4.12 of [Part2]).
Various ad-hoc limitations on request-target length are found in Various ad-hoc limitations on request-target length are found in
practice. It is RECOMMENDED that all HTTP senders and recipients practice. It is RECOMMENDED that all HTTP senders and recipients
support request-target lengths of 8000 or more octets. support request-target lengths of 8000 or more octets.
Note: Fragments ([RFC3986], Section 3.5) are not part of the Note: Fragments ([RFC3986], Section 3.5) are not part of the
request-target and thus will not be transmitted in an HTTP request-target and thus will not be transmitted in an HTTP
request. request.
3.1.2. Response Status-Line 3.1.2. Response Status-Line
skipping to change at page 25, line 5 skipping to change at page 23, line 11
the same field name are received is therefore significant to the the same field name are received is therefore significant to the
interpretation of the combined field value; a proxy MUST NOT change interpretation of the combined field value; a proxy MUST NOT change
the order of these field values when forwarding a message. the order of these field values when forwarding a message.
Note: The "Set-Cookie" header field as implemented in practice can Note: The "Set-Cookie" header field as implemented in practice can
occur multiple times, but does not use the list syntax, and thus occur multiple times, but does not use the list syntax, and thus
cannot be combined into a single line ([RFC6265]). (See Appendix cannot be combined into a single line ([RFC6265]). (See Appendix
A.2.3 of [Kri2001] for details.) Also note that the Set-Cookie2 A.2.3 of [Kri2001] for details.) Also note that the Set-Cookie2
header field specified in [RFC2965] does not share this problem. header field specified in [RFC2965] does not share this problem.
3.2.1. Field Parsing 3.2.1. Whitespace
This specification uses three rules to denote the use of linear
whitespace: OWS (optional whitespace), RWS (required whitespace), and
BWS ("bad" whitespace).
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
single SP. Multiple OWS octets that occur within field-content
SHOULD either be replaced with a single SP or transformed to all SP
octets (each octet other than SP replaced with SP) before
interpreting the field value or forwarding the message downstream.
RWS is used when at least one linear whitespace octet is required to
separate field tokens. RWS SHOULD be produced as a single SP.
Multiple RWS octets that occur within field-content SHOULD either be
replaced with a single SP or transformed to all SP octets before
interpreting the field value or forwarding the message downstream.
BWS is used where the grammar allows optional whitespace for
historical reasons but senders SHOULD NOT produce it in messages.
HTTP/1.1 recipients MUST accept such bad optional whitespace and
remove it before interpreting the field value or forwarding the
message downstream.
OWS = *( SP / HTAB / obs-fold )
; "optional" whitespace
RWS = 1*( SP / HTAB / obs-fold )
; "required" whitespace
BWS = OWS
; "bad" whitespace
obs-fold = CRLF ( SP / HTAB )
; obsolete line folding
; see Section 3.2.2
3.2.2. Field Parsing
No whitespace is allowed between the header field-name and colon. In No whitespace is allowed between the header field-name and colon. In
the past, differences in the handling of such whitespace have led to the past, differences in the handling of such whitespace have led to
security vulnerabilities in request routing and response handling. security vulnerabilities in request routing and response handling.
Any received request message that contains whitespace between a Any received request message that contains whitespace between a
header field-name and colon MUST be rejected with a response code of header field-name and colon MUST be rejected with a response code of
400 (Bad Request). A proxy MUST remove any such whitespace from a 400 (Bad Request). A proxy MUST remove any such whitespace from a
response message before forwarding the message downstream. response message before forwarding the message downstream.
A field value MAY be preceded by optional whitespace (OWS); a single A field value MAY be preceded by optional whitespace (OWS); a single
skipping to change at page 25, line 43 skipping to change at page 24, line 36
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.3. Field Length
HTTP does not place a pre-defined limit on the length of header HTTP does not place a pre-defined limit on the length of header
fields, either in isolation or as a set. A server MUST be prepared fields, either in isolation or as a set. A server MUST be prepared
to receive request header fields of unbounded length and respond with to receive request header fields of unbounded length and respond with
a 4xx status code if the received header field(s) would be longer a 4xx status code if the received header field(s) would be longer
than the server wishes to handle. than the server wishes to handle.
A client that receives response headers that are longer than it A client that receives response headers that are longer than it
wishes to handle can only treat it as a server error. wishes to handle can only treat it as a server error.
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.4. Field value components
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 5.1). value (as defined in Section 5.1).
word = token / quoted-string word = token / quoted-string
token = 1*tchar token = 1*tchar
skipping to change at page 27, line 15 skipping to change at page 26, line 11
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 = "\" ( HTAB / SP / 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.2.5. ABNF list extension: #rule
A #rule extension to the ABNF rules of [RFC5234] is used to improve
readability in the definitions of some header field values.
A construct "#" is defined, similar to "*", for defining comma-
delimited lists of elements. The full form is "<n>#<m>element"
indicating at least <n> and at most <m> elements, each separated by a
single comma (",") and optional whitespace (OWS).
Thus,
1#element => element *( OWS "," OWS element )
and:
#element => [ 1#element ]
and for n >= 1 and m > 1:
<n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element )
For compatibility with legacy list rules, recipients SHOULD accept
empty list elements. In other words, consumers would follow the list
productions:
#element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ]
1#element => *( "," OWS ) element *( OWS "," [ OWS element ] )
Note that empty elements do not contribute to the count of elements
present, though.
For example, given these ABNF productions:
example-list = 1#example-list-elmt
example-list-elmt = token ; see Section 3.2.4
Then these are valid values for example-list (not including the
double quotes, which are present for delimitation only):
"foo,bar"
"foo ,bar,"
"foo , ,bar,charlie "
But these values would be invalid, as at least one non-empty element
is required:
""
","
", ,"
Appendix B shows the collected ABNF, with the list rules expanded as
explained above.
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 8.6). If more than one Transfer-Encoding header field field (Section 8.6). If more than one Transfer-Encoding header field
skipping to change at page 31, line 43 skipping to change at page 31, line 43
4. Message Routing 4. Message Routing
In most cases, the user agent is provided a URI reference from which In most cases, the user agent is provided a URI reference from which
it determines an absolute URI for identifying the target resource. it determines an absolute URI for identifying the target resource.
When a request to the resource is initiated, all or part of that URI When a request to the resource is initiated, all or part of that URI
is used to construct the HTTP request-target. is used to construct the HTTP request-target.
4.1. Types of Request Target 4.1. Types of Request Target
The four options for request-target are dependent on the nature of The proper format choice of the four options available to request-
the request. target depends on the method being requested and if the request is
being made to a proxy.
The asterisk "*" form of request-target, which MUST NOT be used with The most common form of request-target is that used when making a
any request method other than OPTIONS, means that the request applies request to an origin server ("origin form") to access a resource
to the server as a whole (the listening process) rather than to a identified by an "http" (Section 2.7.1) or "https" (Section 2.7.2)
specific named resource at that server. For example, URI. In this case, the absolute path and query components of the URI
MUST be transmitted as the request-target and the authority component
(excluding any userinfo) MUST be transmitted in a Host header field.
For example, a client wishing to retrieve a representation of the
resource identified as
OPTIONS * HTTP/1.1 http://www.example.org/where?q=now
The "absolute-URI" form is REQUIRED when the request is being made to directly from the origin server would open (or reuse) a TCP
a proxy. The proxy is requested to either forward the request or connection to port 80 of the host "www.example.org" and send the
service it from a valid cache, and then return the response. Note lines:
that the proxy MAY forward the request on to another proxy or
directly to the server specified by the absolute-URI. In order to GET /where?q=now HTTP/1.1
avoid request loops, a proxy that forwards requests to other proxies Host: www.example.org
MUST be able to recognize and exclude all of its own server names,
including any aliases, local variations, and the numeric IP address. followed by the remainder of the request. Note that the origin form
An example Request-Line would be: of request-target always starts with an absolute path. If the target
resource's URI path is empty, then an absolute path of "/" MUST be
provided in the request-target.
If the request-target is percent-encoded ([RFC3986], Section 2.1),
the origin server MUST decode the request-target in order to properly
interpret the request. Servers SHOULD respond to invalid request-
targets with an appropriate status code.
The "absolute-URI" form of request-target is REQUIRED when the
request is being made to a proxy. The proxy is requested to either
forward the request or service it from a valid cache, and then return
the response. Note that the proxy MAY forward the request on to
another proxy or directly to the server specified by the absolute-
URI. In order to avoid request loops, a proxy that forwards requests
to other proxies MUST be able to recognize and exclude all of its own
server names, including any aliases, local variations, or literal IP
addresses. An example Request-Line would be:
GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1 GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
To allow for transition to absolute-URIs in all requests in future To allow for transition to absolute-URIs in all requests in future
versions of HTTP, all HTTP/1.1 servers MUST accept the absolute-URI versions of HTTP, all HTTP/1.1 servers MUST accept the absolute-URI
form in requests, even though HTTP/1.1 clients will only generate form in requests, even though HTTP/1.1 clients will only generate
them in requests to proxies. them in requests to proxies.
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" of request-target, which MUST NOT be used with
(Section 6.9 of [Part2]). any request method other than CONNECT, is used to establish a tunnel
through one or more proxies (Section 6.9 of [Part2]). For example,
The most common form of request-target is that used when making a CONNECT www.example.com:80 HTTP/1.1
request to an origin server ("origin form"). In this case, the
absolute path and query components of the URI MUST be transmitted as
the request-target, and the authority component MUST be transmitted
in a Host header field. For example, a client wishing to retrieve a
representation of the resource, as identified above, directly from
the origin server would open (or reuse) a TCP connection to port 80
of the host "www.example.org" and send the lines:
GET /pub/WWW/TheProject.html HTTP/1.1 The asterisk ("*") form of request-target, which MUST NOT be used
Host: www.example.org with any request method other than OPTIONS, means that the request
applies to the server as a whole (the listening process) rather than
to a specific named resource at that server. For example,
followed by the remainder of the Request. Note that the origin form OPTIONS * HTTP/1.1
of request-target always starts with an absolute path; if the target
resource's URI path is empty, then an absolute path of "/" MUST be
provided in the request-target.
If a proxy receives an OPTIONS request with an absolute-URI form of If a proxy receives an OPTIONS request with an absolute-URI form of
request-target in which the URI has an empty path and no query request-target in which the URI has an empty path and no query
component, then the last proxy on the request chain MUST use a component, then the last proxy on the request chain MUST use a
request-target of "*" when it forwards the request to the indicated request-target of "*" when it forwards the request to the indicated
origin server. origin server.
For example, the request For example, the request
OPTIONS http://www.example.org:8001 HTTP/1.1 OPTIONS http://www.example.org:8001 HTTP/1.1
would be forwarded by the final proxy as would be forwarded by the final proxy as
OPTIONS * HTTP/1.1 OPTIONS * HTTP/1.1
Host: www.example.org:8001 Host: www.example.org:8001
after connecting to port 8001 of host "www.example.org". after connecting to port 8001 of host "www.example.org".
The request-target is transmitted in the format specified in
Section 2.7.1. If the request-target is percent-encoded ([RFC3986],
Section 2.1), the origin server MUST decode the request-target in
order to properly interpret the request. Servers SHOULD respond to
invalid request-targets with an appropriate status code.
A non-transforming proxy MUST NOT rewrite the "path-absolute" and A non-transforming proxy MUST NOT rewrite the "path-absolute" and
"query" parts of the received request-target when forwarding it to "query" parts of the received request-target when forwarding it to
the next inbound server, except as noted above to replace a null the next inbound server, except as noted above to replace a null
path-absolute with "/" or "*". path-absolute with "/" or "*".
Note: The "no rewrite" rule prevents the proxy from changing the
meaning of the request when the origin server is improperly using
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
rewrite the request-target.
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.)
skipping to change at page 37, line 32 skipping to change at page 37, line 34
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
message is being received by an HTTP/1.1 (or later) proxy and message is being received by an HTTP/1.1 (or later) proxy and
forwarded to an HTTP/1.0 recipient. It avoids a situation where forwarded to an HTTP/1.0 recipient. It avoids a situation where
compliance with the protocol would have necessitated a possibly conformance with the protocol would have necessitated a possibly
infinite buffer on the proxy. infinite buffer on the proxy.
A process for decoding the "chunked" transfer-coding can be A process for decoding the "chunked" transfer-coding can be
represented in pseudo-code as: represented in pseudo-code as:
length := 0 length := 0
read chunk-size, chunk-ext (if any) and CRLF read chunk-size, chunk-ext (if any) and CRLF
while (chunk-size > 0) { while (chunk-size > 0) {
read chunk-data and CRLF read chunk-data and CRLF
append chunk-data to decoded-body append chunk-data to decoded-body
skipping to change at page 48, line 18 skipping to change at page 48, line 37
connection prematurely. connection prematurely.
o If an origin server receives a request that does not include an o If an origin server receives a request that does not include an
Expect header field with the "100-continue" expectation, the Expect header field with the "100-continue" expectation, the
request includes a request body, and the server responds with a request includes a request body, and the server responds with a
final status code before reading the entire request body from the final status code before reading the entire request body from the
transport connection, then the server SHOULD NOT close the transport connection, then the server SHOULD NOT close the
transport connection until it has read the entire request, or transport connection until it has read the entire request, or
until the client closes the connection. Otherwise, the client until the client closes the connection. Otherwise, the client
might not reliably receive the response message. However, this might not reliably receive the response message. However, this
requirement is not be construed as preventing a server from requirement ought not be construed as preventing a server from
defending itself against denial-of-service attacks, or from badly defending itself against denial-of-service attacks, or from badly
broken client implementations. broken client implementations.
Requirements for HTTP/1.1 proxies: Requirements for HTTP/1.1 proxies:
o If a proxy receives a request that includes an Expect header field o If a proxy receives a request that includes an Expect header field
with the "100-continue" expectation, and the proxy either knows with the "100-continue" expectation, and the proxy either knows
that the next-hop server complies with HTTP/1.1 or higher, or does that the next-hop server complies with HTTP/1.1 or higher, or does
not know the HTTP version of the next-hop server, it MUST forward not know the HTTP version of the next-hop server, it MUST forward
the request, including the Expect header field. the request, including the Expect header field.
skipping to change at page 50, line 34 skipping to change at page 51, line 9
The connection options do not have to correspond to a header field The connection options do not have to correspond to a header field
present in the message, since a connection-specific header field present in the message, since a connection-specific header field
might not be needed if there are no parameters associated with that might not be needed if there are no parameters associated with that
connection option. Recipients that trigger certain connection connection option. Recipients that trigger certain connection
behavior based on the presence of connection options MUST do so based behavior based on the presence of connection options MUST do so based
on the presence of the connection-token rather than only the presence on the presence of the connection-token rather than only the presence
of the optional header field. In other words, if the connection of the optional header field. In other words, if the connection
option is received as a header field but not indicated within the option is received as a header field but not indicated within the
Connection field-value, then the recipient MUST ignore the Connection field-value, then the recipient MUST ignore the
connection-specific header field because it has likely been forwarded connection-specific header field because it has likely been forwarded
by an intermediary that is only partially compliant. by an intermediary that is only partially conformant.
When defining new connection options, specifications ought to When defining new connection options, specifications ought to
carefully consider existing deployed header fields and ensure that carefully consider existing deployed header fields and ensure that
the new connection-token does not share the same name as an unrelated the new connection-token does not share the same name as an unrelated
header field that might already be deployed. Defining a new header field that might already be deployed. Defining a new
connection-token essentially reserves that potential field-name for connection-token essentially reserves that potential field-name for
carrying additional information related to the connection option, carrying additional information related to the connection option,
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.
skipping to change at page 53, line 7 skipping to change at page 53, line 27
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.
8.4. TE 8.4. TE
The "TE" header field indicates what extension transfer-codings it is The "TE" header field indicates what extension transfer-codings the
willing to accept in the response, and whether or not it is willing client is willing to accept in the response, and whether or not it is
to accept trailer fields in a chunked transfer-coding. willing 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 5.1). 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 ]
skipping to change at page 54, line 15 skipping to change at page 54, line 35
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 5.3, 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 acceptable transfer-coding is "chunked". A message with no transfer-
always acceptable. coding is always acceptable.
8.5. 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
skipping to change at page 55, line 31 skipping to change at page 55, line 51
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,
Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
The Upgrade header field is intended to provide a simple mechanism The Upgrade header field is intended to provide a simple mechanism
for transition from HTTP/1.1 to some other, incompatible protocol. for transitioning from HTTP/1.1 to some other, incompatible protocol.
It does so by allowing the client to advertise its desire to use It does so by allowing the client to advertise its desire to use
another protocol, such as a later version of HTTP with a higher major another protocol, such as a later version of HTTP with a higher major
version number, even though the current request has been made using version number, even though the current request has been made using
HTTP/1.1. This eases the difficult transition between incompatible HTTP/1.1. This eases the difficult transition between incompatible
protocols by allowing the client to initiate a request in the more protocols by allowing the client to initiate a request in the more
commonly supported protocol while indicating to the server that it commonly supported protocol while indicating to the server that it
would like to use a "better" protocol if available (where "better" is would like to use a "better" protocol if available (where "better" is
determined by the server, possibly according to the nature of the determined by the server, possibly according to the nature of the
request method or target resource). request method or target resource).
skipping to change at page 64, line 32 skipping to change at page 64, line 47
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 10.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 more
than the people who run them; HTTP itself cannot solve this problem. trustworthy 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.
10.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 3.1.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 7.4.15 of that have request-targets that are too long (Section 7.4.12 of
[Part2]) or request entities that are too large (Section 7.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.
10.7. Denial of Service Attacks on Proxies 10.7. Denial of Service Attacks on Proxies
skipping to change at page 66, line 9 skipping to change at page 66, line 26
James Lacey, James M. Snell, Jamie Lokier, Jan Algermissen, Jeff James Lacey, James M. Snell, Jamie Lokier, Jan Algermissen, Jeff
Hodges (for coming up with the term 'effective Request-URI'), Jeff Hodges (for coming up with the term 'effective Request-URI'), Jeff
Walden, Jim Luther, Joe D. Williams, Joe Gregorio, Joe Orton, John C. Walden, Jim Luther, Joe D. Williams, Joe Gregorio, Joe Orton, John C.
Klensin, John C. Mallery, John Cowan, John Kemp, John Panzer, John Klensin, John C. Mallery, John Cowan, John Kemp, John Panzer, John
Schneider, John Stracke, Jonas Sicking, Jonathan Moore, Jonathan Schneider, John Stracke, Jonas Sicking, Jonathan Moore, Jonathan
Rees, Jordi Ros, Joris Dobbelsteen, Josh Cohen, Julien Pierre, Rees, Jordi Ros, Joris Dobbelsteen, Josh Cohen, Julien Pierre,
Jungshik Shin, Justin Chapweske, Justin Erenkrantz, Justin James, Jungshik Shin, Justin Chapweske, Justin Erenkrantz, Justin James,
Kalvinder Singh, Karl Dubost, Keith Hoffman, Keith Moore, Koen Kalvinder Singh, Karl Dubost, Keith Hoffman, Keith Moore, Koen
Holtman, Konstantin Voronkov, Kris Zyp, Lisa Dusseault, Maciej Holtman, Konstantin Voronkov, Kris Zyp, Lisa Dusseault, Maciej
Stachowiak, Marc Schneider, Marc Slemko, Mark Baker, Mark Nottingham Stachowiak, Marc Schneider, Marc Slemko, Mark Baker, Mark Nottingham
(Working Group chair), Mark Pauley, Martin J. Duerst, Martin Thomson, (Working Group chair), Mark Pauley, Markus Lanthaler, Martin J.
Matt Lynch, Matthew Cox, Max Clark, Michael Burrows, Michael Duerst, Martin Thomson, Matt Lynch, Matthew Cox, Max Clark, Michael
Hausenblas, Mike Amundsen, Mike Kelly, Mike Schinkel, Miles Sabin, Burrows, Michael Hausenblas, Mike Amundsen, Mike Kelly, Mike
Mykyta Yevstifeyev, Nathan Rixham, Nicholas Shanks, Nico Williams, Schinkel, Miles Sabin, Mykyta Yevstifeyev, Nathan Rixham, Nicholas
Nicolas Alvarez, Noah Slater, Pablo Castro, Pat Hayes, Patrick R. Shanks, Nico Williams, Nicolas Alvarez, Noah Slater, Pablo Castro,
McManus, Paul E. Jones, Paul Hoffman, Paul Marquess, Peter Saint- Pat Hayes, Patrick R. McManus, Paul E. Jones, Paul Hoffman, Paul
Andre, Peter Watkins, Phil Archer, Phillip Hallam-Baker, Poul-Henning Marquess, Peter Saint-Andre, Peter Watkins, Phil Archer, Phillip
Kamp, Preethi Natarajan, Reto Bachmann-Gmuer, Richard Cyganiak, Hallam-Baker, Poul-Henning Kamp, Preethi Natarajan, Ray Polk, Reto
Robert Brewer, Robert Collins, Robert O'Callahan, Robert Olofsson, Bachmann-Gmuer, Richard Cyganiak, Robert Brewer, Robert Collins,
Robert Sayre, Robert Siemer, Robert de Wilde, Roberto Javier Godoy, Robert O'Callahan, Robert Olofsson, Robert Sayre, Robert Siemer,
Ronny Widjaja, S. Mike Dierken, Salvatore Loreto, Sam Johnston, Sam Robert de Wilde, Roberto Javier Godoy, Ronny Widjaja, S. Mike
Ruby, Scott Lawrence (for maintaining the original issues list), Sean Dierken, Salvatore Loreto, Sam Johnston, Sam Ruby, Scott Lawrence
B. Palmer, Shane McCarron, Stefan Eissing, Stefan Tilkov, Stefanos (for maintaining the original issues list), Sean B. Palmer, Shane
Harhalakis, Stephane Bortzmeyer, Stuart Williams, Subbu Allamaraju, McCarron, Stefan Eissing, Stefan Tilkov, Stefanos Harhalakis,
Sylvain Hellegouarch, Tapan Divekar, Thomas Broyer, Thomas Nordin, Stephane Bortzmeyer, Stuart Williams, Subbu Allamaraju, Sylvain
Thomas Roessler, Tim Morgan, Tim Olsen, Travis Snoozy, Tyler Close, Hellegouarch, Tapan Divekar, Thomas Broyer, Thomas Nordin, Thomas
Vincent Murphy, Wenbo Zhu, Werner Baumann, Wilbur Streett, Wilfredo Roessler, Tim Morgan, Tim Olsen, Travis Snoozy, Tyler Close, Vincent
Sanchez Vega, William A. Rowe Jr., William Chan, Willy Tarreau, Murphy, Wenbo Zhu, Werner Baumann, Wilbur Streett, Wilfredo Sanchez
Xiaoshu Wang, Yaron Goland, Yngve Nysaeter Pettersen, Yogesh Bang, Vega, William A. Rowe Jr., William Chan, Willy Tarreau, Xiaoshu Wang,
Yutaka Oiwa, and Zed A. Shaw. Yaron Goland, Yngve Nysaeter Pettersen, Yogesh Bang, Yutaka Oiwa, Zed
A. Shaw, and Zhong Yu.
12. References 12. References
12.1. Normative 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
skipping to change at page 66, line 42 skipping to change at page 67, line 14
12.1. Normative 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-18 (work in Semantics", draft-ietf-httpbis-p2-semantics-latest
progress), January 2012. (work in progress), February 2012.
[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-18 (work in progress), draft-ietf-httpbis-p3-payload-latest (work in
January 2012. progress), February 2012.
[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-18 (work in progress), draft-ietf-httpbis-p6-cache-latest (work in progress),
January 2012. February 2012.
[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.
[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.
[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.
skipping to change at page 70, line 11 skipping to change at page 70, line 32
connections, or name-based virtual hosts. The proliferation of connections, or name-based virtual hosts. The proliferation of
incompletely-implemented applications calling themselves "HTTP/1.0" incompletely-implemented applications calling themselves "HTTP/1.0"
further necessitated a protocol version change in order for two further necessitated a protocol version change in order for two
communicating applications to determine each other's true communicating applications to determine each other's true
capabilities. capabilities.
HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent
requirements that enable reliable implementations, adding only those requirements that enable reliable implementations, adding only those
new features that will either be safely ignored by an HTTP/1.0 new features that will either be safely ignored by an HTTP/1.0
recipient or only sent when communicating with a party advertising recipient or only sent when communicating with a party advertising
compliance with HTTP/1.1. conformance with HTTP/1.1.
It is beyond the scope of a protocol specification to mandate It is beyond the scope of a protocol specification to mandate
compliance with previous versions. HTTP/1.1 was deliberately conformance with previous versions. HTTP/1.1 was deliberately
designed, however, to make supporting previous versions easy. We designed, however, to make supporting previous versions easy. We
would expect a general-purpose HTTP/1.1 server to understand any would expect a general-purpose HTTP/1.1 server to understand any
valid request in the format of HTTP/1.0 and respond appropriately valid request in the format of HTTP/1.0 and respond appropriately
with an HTTP/1.1 message that only uses features understood (or with an HTTP/1.1 message that only uses features understood (or
safely ignored) by HTTP/1.0 clients. Likewise, would expect an safely ignored) by HTTP/1.0 clients. Likewise, we would expect an
HTTP/1.1 client to understand any valid HTTP/1.0 response. HTTP/1.1 client to understand any valid HTTP/1.0 response.
Since HTTP/0.9 did not support header fields in a request, there is Since HTTP/0.9 did not support header fields in a request, there is
no mechanism for it to support name-based virtual hosts (selection of no mechanism for it to support name-based virtual hosts (selection of
resource by inspection of the Host header field). Any server that resource by inspection of the Host header field). Any server that
implements name-based virtual hosts ought to disable support for implements name-based virtual hosts ought to disable support for
HTTP/0.9. Most requests that appear to be HTTP/0.9 are, in fact, HTTP/0.9. Most requests that appear to be HTTP/0.9 are, in fact,
badly constructed HTTP/1.x requests wherein a buggy client failed to badly constructed HTTP/1.x requests wherein a buggy client failed to
properly encode linear whitespace found in a URI reference and placed properly encode linear whitespace found in a URI reference and placed
in the request-target. in the request-target.
skipping to change at page 71, line 41 skipping to change at page 72, line 15
Clients are also encouraged to consider the use of Connection: keep- Clients are also encouraged to consider the use of Connection: keep-
alive in requests carefully; while they can enable persistent alive in requests carefully; while they can enable persistent
connections with HTTP/1.0 servers, clients using them need will need connections with HTTP/1.0 servers, clients using them need will need
to monitor the connection for "hung" requests (which indicate that to monitor the connection for "hung" requests (which indicate that
the client ought stop sending the header), and this mechanism ought the client ought stop sending the header), and this mechanism ought
not be used by clients at all when a proxy is being used. not be used by clients at all when a proxy is being used.
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 3.2.5)
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 whitespace is only allowed where
specifically pointed out in the ABNF. (Section 1.2.2) specifically defined in the ABNF. (Section 3.2.1)
Clarify that the string "HTTP" in the HTTP-Version ABFN production is Clarify that the string "HTTP" in the HTTP-Version ABFN production is
case sensitive. Restrict the version numbers to be single digits due case sensitive. Restrict the version numbers to be single digits due
to the fact that implementations are known to handle multi-digit to the fact that implementations are known to handle multi-digit
version numbers incorrectly. (Section 2.6) version numbers incorrectly. (Section 2.6)
Require that invalid whitespace around field-names be rejected. Require that invalid whitespace around field-names be rejected.
(Section 3.2) (Section 3.2)
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.4)
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 5.1) 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 3.1.1.2) allowed for the OPTIONS request method only. (Section 3.1.1.2)
skipping to change at page 86, line 14 skipping to change at page 87, line 5
o <http://tools.ietf.org/wg/httpbis/trac/ticket/323>: "intended o <http://tools.ietf.org/wg/httpbis/trac/ticket/323>: "intended
maturity level vs normative references" maturity level vs normative references"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/324>: "Intermediary o <http://tools.ietf.org/wg/httpbis/trac/ticket/324>: "Intermediary
rewriting of queries" rewriting of queries"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/158>: "Proxy- o <http://tools.ietf.org/wg/httpbis/trac/ticket/158>: "Proxy-
Connection and Keep-Alive" Connection and Keep-Alive"
C.20. Since draft-ietf-httpbis-p1-messaging-18
None yet.
Index Index
A A
absolute-URI form (of request-target) 32 absolute-URI form (of request-target) 32
accelerator 13 accelerator 11
application/http Media Type 61 application/http Media Type 61
asterisk form (of request-target) 31 asterisk form (of request-target) 33
authority form (of request-target) 32 authority form (of request-target) 32
B B
browser 10 browser 7
C C
cache 14 cache 12
cacheable 15 cacheable 12
captive portal 14 captive portal 11
chunked (Coding Format) 36 chunked (Coding Format) 36
client 10 client 7
Coding Format Coding Format
chunked 36 chunked 36
compress 38 compress 39
deflate 38 deflate 39
gzip 39 gzip 39
compress (Coding Format) 38 compress (Coding Format) 39
connection 10 connection 7
Connection header field 49 Connection header field 50
Content-Length header field 51 Content-Length header field 51
D D
deflate (Coding Format) 38 deflate (Coding Format) 39
downstream 13 downstream 10
E E
effective request URI 34 effective request URI 34
G G
gateway 13 gateway 11
Grammar Grammar
absolute-URI 18 absolute-URI 16
ALPHA 7 ALPHA 7
attribute 35 attribute 35
authority 18 authority 16
BWS 9 BWS 23
chunk 36 chunk 36
chunk-data 36 chunk-data 36
chunk-ext 36 chunk-ext 36
chunk-ext-name 36 chunk-ext-name 36
chunk-ext-val 36 chunk-ext-val 36
chunk-size 36 chunk-size 36
Chunked-Body 36 Chunked-Body 36
comment 26 comment 25
Connection 50 Connection 50
connection-token 50 connection-token 50
Content-Length 51 Content-Length 51
CR 7 CR 7
CRLF 7 CRLF 7
ctext 26 ctext 25
CTL 7 CTL 7
date2 35 date2 35
date3 35 date3 35
DIGIT 7 DIGIT 7
DQUOTE 7 DQUOTE 7
field-content 23 field-content 22
field-name 23 field-name 22
field-value 23 field-value 22
header-field 23 header-field 22
HEXDIG 7 HEXDIG 7
Host 52 Host 52
HTAB 7 HTAB 7
HTTP-message 21 HTTP-message 19
HTTP-Prot-Name 15 HTTP-Prot-Name 13
http-URI 18 http-URI 16
HTTP-Version 15 HTTP-Version 13
https-URI 20 https-URI 18
last-chunk 36 last-chunk 36
LF 7 LF 7
message-body 27 message-body 27
Method 22 Method 20
obs-text 26 obs-text 25
OCTET 7 OCTET 7
OWS 9 OWS 23
path-absolute 18 path-absolute 16
port 18 port 16
product 39 product 40
product-version 39 product-version 40
protocol-name 57 protocol-name 57
protocol-version 57 protocol-version 57
pseudonym 57 pseudonym 57
qdtext 26 qdtext 25
qdtext-nf 36 qdtext-nf 36
query 18 query 16
quoted-cpair 27 quoted-cpair 26
quoted-pair 26 quoted-pair 25
quoted-str-nf 36 quoted-str-nf 36
quoted-string 26 quoted-string 25
qvalue 40 qvalue 40
Reason-Phrase 23 Reason-Phrase 21
received-by 57 received-by 57
received-protocol 57 received-protocol 57
Request-Line 22 Request-Line 20
request-target 22 request-target 20
RWS 9 RWS 23
SP 7 SP 7
special 26 special 25
start-line 21 start-line 20
Status-Code 23 Status-Code 21
Status-Line 23 Status-Line 21
t-codings 53 t-codings 53
tchar 26 tchar 25
TE 53 TE 53
te-ext 53 te-ext 53
te-params 53 te-params 53
token 26 token 25
Trailer 54 Trailer 54
trailer-part 36 trailer-part 36
transfer-coding 35 transfer-coding 35
Transfer-Encoding 54 Transfer-Encoding 55
transfer-extension 35 transfer-extension 35
transfer-parameter 35 transfer-parameter 35
Upgrade 55 Upgrade 55
uri-host 18 uri-host 16
URI-reference 18 URI-reference 16
value 35 value 35
VCHAR 7 VCHAR 7
Via 57 Via 57
word 26 word 25
gzip (Coding Format) 39 gzip (Coding Format) 39
H H
header field 21 header field 19
Header Fields Header Fields
Connection 49 Connection 50
Content-Length 51 Content-Length 51
Host 51 Host 52
TE 53 TE 53
Trailer 54 Trailer 54
Transfer-Encoding 54 Transfer-Encoding 55
Upgrade 55 Upgrade 55
Via 57 Via 57
header section 21 header section 19
headers 21 headers 19
Host header field 51 Host header field 52
http URI scheme 18 http URI scheme 16
https URI scheme 19 https URI scheme 17
I I
inbound 13 inbound 10
interception proxy 14 interception proxy 11
intermediary 12 intermediary 9
M M
Media Type Media Type
application/http 61 application/http 61
message/http 59 message/http 60
message 10 message 8
message/http Media Type 59 message/http Media Type 60
N N
non-transforming proxy 13 non-transforming proxy 10
O O
origin form (of request-target) 32 origin form (of request-target) 31
origin server 10 origin server 7
outbound 13 outbound 10
P P
proxy 13 proxy 10
R R
recipient 10 recipient 7
request 10 request 8
resource 17 resource 15
response 10 response 8
reverse proxy 13 reverse proxy 11
S S
sender 10 sender 7
server 10 server 7
spider 10 spider 7
T T
target resource 34 target resource 34
TE header field 53 TE header field 53
Trailer header field 54 Trailer header field 54
Transfer-Encoding header field 54 Transfer-Encoding header field 55
transforming proxy 13 transforming proxy 10
transparent proxy 14 transparent proxy 11
tunnel 14 tunnel 11
U U
Upgrade header field 55 Upgrade header field 55
upstream 13 upstream 10
URI scheme URI scheme
http 18 http 16
https 19 https 17
user agent 10 user agent 7
V V
Via header field 57 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
 End of changes. 122 change blocks. 
438 lines changed or deleted 439 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/