draft-ietf-httpbis-p1-messaging-15.txt   draft-ietf-httpbis-p1-messaging-16.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: January 12, 2012 HP Expires: February 25, 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
July 11, 2011 August 24, 2011
HTTP/1.1, part 1: URIs, Connections, and Message Parsing HTTP/1.1, part 1: URIs, Connections, and Message Parsing
draft-ietf-httpbis-p1-messaging-15 draft-ietf-httpbis-p1-messaging-16
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is an application-level The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypertext information protocol for distributed, collaborative, hypertext information
systems. HTTP has been in use by the World Wide Web global systems. HTTP has been in use by the World Wide Web global
information initiative since 1990. This document is Part 1 of the information initiative since 1990. This document is Part 1 of the
seven-part specification that defines the protocol referred to as seven-part specification that defines the protocol referred to as
"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides "HTTP/1.1" and, taken together, obsoletes RFC 2616 and moves it to
an overview of HTTP and its associated terminology, defines the historic status, along with its predecessor RFC 2068.
"http" and "https" Uniform Resource Identifier (URI) schemes, defines
the generic message syntax and parsing requirements for HTTP message Part 1 provides an overview of HTTP and its associated terminology,
frames, and describes general security concerns for implementations. defines the "http" and "https" Uniform Resource Identifier (URI)
schemes, defines the generic message syntax and parsing requirements
for HTTP message frames, and describes general security concerns for
implementations.
This part also obsoletes RFCs 2145 (on HTTP version numbers) and 2817
(on using CONNECT for TLS upgrades) and moves them to historic
status.
Editorial Note (To be removed by RFC Editor) Editorial Note (To be removed by RFC Editor)
Discussion of this draft should take place on the HTTPBIS working Discussion of this draft should take place on the HTTPBIS working
group mailing list (ietf-http-wg@w3.org), which is archived at group mailing list (ietf-http-wg@w3.org), which is archived at
<http://lists.w3.org/Archives/Public/ietf-http-wg/>. <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
The current issues list is at The current issues list is at
<http://tools.ietf.org/wg/httpbis/trac/report/3> and related <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
documents (including fancy diffs) can be found at documents (including fancy diffs) can be found at
<http://tools.ietf.org/wg/httpbis/>. <http://tools.ietf.org/wg/httpbis/>.
The changes in this draft are summarized in Appendix D.16. The changes in this draft are summarized in Appendix C.17.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 12, 2012. This Internet-Draft will expire on February 25, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 4 skipping to change at page 3, line 10
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7
1.2.1. ABNF Extension: #rule . . . . . . . . . . . . . . . . 7 1.2.1. ABNF Extension: #rule . . . . . . . . . . . . . . . . 7
1.2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . 8 1.2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . 8
2. HTTP-related architecture . . . . . . . . . . . . . . . . . . 10 2. HTTP-related architecture . . . . . . . . . . . . . . . . . . 9
2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 10 2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 9
2.2. Message Orientation and Buffering . . . . . . . . . . . . 12 2.2. Message Orientation and Buffering . . . . . . . . . . . . 11
2.3. Connections and Transport Independence . . . . . . . . . . 12 2.3. Connections and Transport Independence . . . . . . . . . . 11
2.4. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 13 2.4. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 12
2.5. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.5. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.6. Protocol Versioning . . . . . . . . . . . . . . . . . . . 15 2.6. Protocol Versioning . . . . . . . . . . . . . . . . . . . 15
2.7. Uniform Resource Identifiers . . . . . . . . . . . . . . . 18 2.7. Uniform Resource Identifiers . . . . . . . . . . . . . . . 17
2.7.1. http URI scheme . . . . . . . . . . . . . . . . . . . 18 2.7.1. http URI scheme . . . . . . . . . . . . . . . . . . . 18
2.7.2. https URI scheme . . . . . . . . . . . . . . . . . . . 20 2.7.2. https URI scheme . . . . . . . . . . . . . . . . . . . 19
2.7.3. http and https URI Normalization and Comparison . . . 20 2.7.3. http and https URI Normalization and Comparison . . . 20
3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 21 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 20
3.1. Message Parsing Robustness . . . . . . . . . . . . . . . . 22 3.1. Message Parsing and Robustness . . . . . . . . . . . . . . 21
3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 22 3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 22
3.2.1. Field Parsing . . . . . . . . . . . . . . . . . . . . 23
3.2.2. Field Length . . . . . . . . . . . . . . . . . . . . . 24
3.2.3. Common Field ABNF Rules . . . . . . . . . . . . . . . 24
3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 25 3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 25
3.4. General Header Fields . . . . . . . . . . . . . . . . . . 28 3.4. Incomplete Messages . . . . . . . . . . . . . . . . . . . 28
4. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.5. General Header Fields . . . . . . . . . . . . . . . . . . 29
4.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 29 4. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 29 4.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 30
4.1.2. request-target . . . . . . . . . . . . . . . . . . . . 29 4.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2. The Resource Identified by a Request . . . . . . . . . . . 31 4.1.2. request-target . . . . . . . . . . . . . . . . . . . . 30
4.3. Effective Request URI . . . . . . . . . . . . . . . . . . 32 4.2. The Resource Identified by a Request . . . . . . . . . . . 32
5. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.3. Effective Request URI . . . . . . . . . . . . . . . . . . 33
5.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 33 5. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 34 5.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 34
6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 34 5.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 35
6.1. Date/Time Formats: Full Date . . . . . . . . . . . . . . . 34 6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 35
6.2. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 37 6.1. Date/Time Formats: Full Date . . . . . . . . . . . . . . . 35
6.2.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 38 6.2. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 38
6.2.2. Compression Codings . . . . . . . . . . . . . . . . . 40 6.2.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 39
6.2.3. Transfer Coding Registry . . . . . . . . . . . . . . . 41 6.2.2. Compression Codings . . . . . . . . . . . . . . . . . 41
6.3. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 42 6.2.3. Transfer Coding Registry . . . . . . . . . . . . . . . 42
6.4. Quality Values . . . . . . . . . . . . . . . . . . . . . . 42 6.3. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 43
7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 42 6.4. Quality Values . . . . . . . . . . . . . . . . . . . . . . 43
7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 43 7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 43
7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 43 7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 44
7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 43 7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 44
7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 45 7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 44
7.1.4. Practical Considerations . . . . . . . . . . . . . . . 47 7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 46
7.2. Message Transmission Requirements . . . . . . . . . . . . 48 7.1.4. Practical Considerations . . . . . . . . . . . . . . . 48
7.2.1. Persistent Connections and Flow Control . . . . . . . 48 7.2. Message Transmission Requirements . . . . . . . . . . . . 49
7.2.2. Monitoring Connections for Error Status Messages . . . 49 7.2.1. Persistent Connections and Flow Control . . . . . . . 49
7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 49 7.2.2. Monitoring Connections for Error Status Messages . . . 50
7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 50
7.2.4. Client Behavior if Server Prematurely Closes 7.2.4. Client Behavior if Server Prematurely Closes
Connection . . . . . . . . . . . . . . . . . . . . . . 51 Connection . . . . . . . . . . . . . . . . . . . . . . 52
8. Miscellaneous notes that might disappear . . . . . . . . . . . 52 8. Miscellaneous notes that might disappear . . . . . . . . . . . 53
8.1. Scheme aliases considered harmful . . . . . . . . . . . . 52 8.1. Scheme aliases considered harmful . . . . . . . . . . . . 53
8.2. Use of HTTP for proxy communication . . . . . . . . . . . 52 8.2. Use of HTTP for proxy communication . . . . . . . . . . . 53
8.3. Interception of HTTP for access control . . . . . . . . . 52 8.3. Interception of HTTP for access control . . . . . . . . . 53
8.4. Use of HTTP by other protocols . . . . . . . . . . . . . . 52 8.4. Use of HTTP by other protocols . . . . . . . . . . . . . . 53
8.5. Use of HTTP by media type specification . . . . . . . . . 52 8.5. Use of HTTP by media type specification . . . . . . . . . 53
9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 52 9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 53
9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 52 9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 53
9.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 54 9.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 55
9.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 9.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
9.3.1. Clockless Origin Server Operation . . . . . . . . . . 55 9.3.1. Clockless Origin Server Operation . . . . . . . . . . 56
9.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 9.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
9.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 9.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
9.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 58 9.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 59
9.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 58 9.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 59
9.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 59 9.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 60
9.8.1. Upgrade Token Registry . . . . . . . . . . . . . . . . 60 9.8.1. Upgrade Token Registry . . . . . . . . . . . . . . . . 61
9.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 9.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 63
10.1. Header Field Registration . . . . . . . . . . . . . . . . 62 10.1. Header Field Registration . . . . . . . . . . . . . . . . 63
10.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 63 10.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 64
10.3. Internet Media Type Registrations . . . . . . . . . . . . 63 10.3. Internet Media Type Registrations . . . . . . . . . . . . 64
10.3.1. Internet Media Type message/http . . . . . . . . . . . 63 10.3.1. Internet Media Type message/http . . . . . . . . . . . 64
10.3.2. Internet Media Type application/http . . . . . . . . . 64 10.3.2. Internet Media Type application/http . . . . . . . . . 66
10.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 65 10.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 67
10.5. Upgrade Token Registration . . . . . . . . . . . . . . . . 66 10.5. Upgrade Token Registration . . . . . . . . . . . . . . . . 67
11. Security Considerations . . . . . . . . . . . . . . . . . . . 66 11. Security Considerations . . . . . . . . . . . . . . . . . . . 67
11.1. Personal Information . . . . . . . . . . . . . . . . . . . 66 11.1. Personal Information . . . . . . . . . . . . . . . . . . . 68
11.2. Abuse of Server Log Information . . . . . . . . . . . . . 67 11.2. Abuse of Server Log Information . . . . . . . . . . . . . 68
11.3. Attacks Based On File and Path Names . . . . . . . . . . . 67 11.3. Attacks Based On File and Path Names . . . . . . . . . . . 68
11.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 67 11.4. DNS-related Attacks . . . . . . . . . . . . . . . . . . . 68
11.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 68 11.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 69
11.6. Protocol Element Size Overflows . . . . . . . . . . . . . 69 11.6. Protocol Element Size Overflows . . . . . . . . . . . . . 69
11.7. Denial of Service Attacks on Proxies . . . . . . . . . . . 69 11.7. Denial of Service Attacks on Proxies . . . . . . . . . . . 70
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 69 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 70
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 70 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 70
13.1. Normative References . . . . . . . . . . . . . . . . . . . 70 13.1. Normative References . . . . . . . . . . . . . . . . . . . 70
13.2. Informative References . . . . . . . . . . . . . . . . . . 72 13.2. Informative References . . . . . . . . . . . . . . . . . . 72
Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 74 Appendix A. HTTP Version History . . . . . . . . . . . . . . . . 74
Appendix B. HTTP Version History . . . . . . . . . . . . . . . . 75 A.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 75
B.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 76 A.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 75
B.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 76 A.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 75
B.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 76 A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 76
B.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 77 Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 77
Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 78 Appendix C. Change Log (to be removed by RFC Editor before
Appendix D. Change Log (to be removed by RFC Editor before publication) . . . . . . . . . . . . . . . . . . . . 81
publication) . . . . . . . . . . . . . . . . . . . . 82 C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 81
D.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 82 C.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 81
D.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 82 C.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 83
D.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 84 C.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 84
D.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 85 C.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 84
D.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 85 C.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 85
D.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 86 C.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 85
D.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 86 C.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 86
D.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 87 C.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 87
D.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 88 C.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 87
D.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 88 C.11. Since draft-ietf-httpbis-p1-messaging-09 . . . . . . . . . 88
D.11. Since draft-ietf-httpbis-p1-messaging-09 . . . . . . . . . 89 C.12. Since draft-ietf-httpbis-p1-messaging-10 . . . . . . . . . 88
D.12. Since draft-ietf-httpbis-p1-messaging-10 . . . . . . . . . 89 C.13. Since draft-ietf-httpbis-p1-messaging-11 . . . . . . . . . 89
D.13. Since draft-ietf-httpbis-p1-messaging-11 . . . . . . . . . 90 C.14. Since draft-ietf-httpbis-p1-messaging-12 . . . . . . . . . 89
D.14. Since draft-ietf-httpbis-p1-messaging-12 . . . . . . . . . 90 C.15. Since draft-ietf-httpbis-p1-messaging-13 . . . . . . . . . 90
D.15. Since draft-ietf-httpbis-p1-messaging-13 . . . . . . . . . 91 C.16. Since draft-ietf-httpbis-p1-messaging-14 . . . . . . . . . 90
D.16. Since draft-ietf-httpbis-p1-messaging-14 . . . . . . . . . 91 C.17. Since draft-ietf-httpbis-p1-messaging-15 . . . . . . . . . 90
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
1. Introduction 1. Introduction
The Hypertext Transfer Protocol (HTTP) is an application-level The Hypertext Transfer Protocol (HTTP) is an application-level
request/response protocol that uses extensible semantics and MIME- request/response protocol that uses extensible semantics and MIME-
like message payloads for flexible interaction with network-based like message payloads for flexible interaction with network-based
hypertext information systems. HTTP relies upon the Uniform Resource hypertext information systems. HTTP relies upon the Uniform Resource
Identifier (URI) standard [RFC3986] to indicate the target resource Identifier (URI) standard [RFC3986] to indicate the target resource
and relationships between resources. Messages are passed in a format and relationships between resources. Messages are passed in a format
skipping to change at page 8, line 27 skipping to change at page 8, line 27
#element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ] #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ]
1#element => *( "," OWS ) element *( OWS "," [ OWS element ] ) 1#element => *( "," OWS ) element *( OWS "," [ OWS element ] )
Note that empty elements do not contribute to the count of elements Note that empty elements do not contribute to the count of elements
present, though. present, though.
For example, given these ABNF productions: For example, given these ABNF productions:
example-list = 1#example-list-elmt example-list = 1#example-list-elmt
example-list-elmt = token ; see Section 1.2.2 example-list-elmt = token ; see Section 3.2.3
Then these are valid values for example-list (not including the Then these are valid values for example-list (not including the
double quotes, which are present for delimitation only): double quotes, which are present for delimitation only):
"foo,bar" "foo,bar"
" foo ,bar," " foo ,bar,"
" foo , ,bar,charlie " " foo , ,bar,charlie "
"foo ,bar, charlie " "foo ,bar, charlie "
But these values would be invalid, as at least one non-empty element But these values would be invalid, as at least one non-empty element
is required: is required:
"" ""
"," ","
", ," ", ,"
Appendix C shows the collected ABNF, with the list rules expanded as Appendix B shows the collected ABNF, with the list rules expanded as
explained above. explained above.
1.2.2. Basic Rules 1.2.2. Basic Rules
HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all
protocol elements other than the message-body (see Appendix A for
tolerant applications).
This specification uses three rules to denote the use of linear This specification uses three rules to denote the use of linear
whitespace: OWS (optional whitespace), RWS (required whitespace), and whitespace: OWS (optional whitespace), RWS (required whitespace), and
BWS ("bad" whitespace). BWS ("bad" whitespace).
The OWS rule is used where zero or more linear whitespace octets The OWS rule is used where zero or more linear whitespace octets
might appear. OWS SHOULD either not be produced or be produced as a might appear. OWS SHOULD either not be produced or be produced as a
single SP. Multiple OWS octets that occur within field-content single SP. Multiple OWS octets that occur within field-content
SHOULD be replaced with a single SP before interpreting the field SHOULD either be replaced with a single SP or transformed to all SP
value or forwarding the message downstream. octets (each WSP 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 RWS is used when at least one linear whitespace octet is required to
separate field tokens. RWS SHOULD be produced as a single SP. separate field tokens. RWS SHOULD be produced as a single SP.
Multiple RWS octets that occur within field-content SHOULD be Multiple RWS octets octets that occur within field-content SHOULD
replaced with a single SP before interpreting the field value or either be replaced with a single SP or transformed to all SP octets
forwarding the message downstream. (each WSP octet other than SP replaced with SP) before interpreting
the field value or forwarding the message downstream.
BWS is used where the grammar allows optional whitespace for BWS is used where the grammar allows optional whitespace for
historical reasons but senders SHOULD NOT produce it in messages. historical reasons but senders SHOULD NOT produce it in messages.
HTTP/1.1 recipients MUST accept such bad optional whitespace and HTTP/1.1 recipients MUST accept such bad optional whitespace and
remove it before interpreting the field value or forwarding the remove it before interpreting the field value or forwarding the
message downstream. message downstream.
OWS = *( [ obs-fold ] WSP ) OWS = *( [ obs-fold ] WSP )
; "optional" whitespace ; "optional" whitespace
RWS = 1*( [ obs-fold ] WSP ) RWS = 1*( [ obs-fold ] WSP )
; "required" whitespace ; "required" whitespace
BWS = OWS BWS = OWS
; "bad" whitespace ; "bad" whitespace
obs-fold = CRLF obs-fold = CRLF
; see Section 3.2 ; see Section 3.2
Many HTTP/1.1 header field values consist of words (token or quoted-
string) separated by whitespace or special characters. These special
characters MUST be in a quoted string to be used within a parameter
value (as defined in Section 6.2).
word = token / quoted-string
token = 1*tchar
tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*"
/ "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
/ DIGIT / ALPHA
; any VCHAR, except special
special = "(" / ")" / "<" / ">" / "@" / ","
/ ";" / ":" / "\" / DQUOTE / "/" / "["
/ "]" / "?" / "=" / "{" / "}"
A string of text is parsed as a single word if it is quoted using
double-quote marks.
quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
qdtext = OWS / %x21 / %x23-5B / %x5D-7E / obs-text
; OWS / <VCHAR except DQUOTE and "\"> / obs-text
obs-text = %x80-FF
The backslash octet ("\") can be used as a single-octet quoting
mechanism within quoted-string constructs:
quoted-pair = "\" ( WSP / VCHAR / obs-text )
Senders SHOULD NOT escape octets that do not require escaping (i.e.,
other than DQUOTE and the backslash octet).
2. HTTP-related architecture 2. HTTP-related architecture
HTTP was created for the World Wide Web architecture and has evolved HTTP was created for the World Wide Web architecture and has evolved
over time to support the scalability needs of a worldwide hypertext over time to support the scalability needs of a worldwide hypertext
system. Much of that architecture is reflected in the terminology system. Much of that architecture is reflected in the terminology
and syntax productions used to define HTTP. and syntax productions used to define HTTP.
2.1. Client/Server Messaging 2.1. Client/Server Messaging
HTTP is a stateless request/response protocol that operates by HTTP is a stateless request/response protocol that operates by
skipping to change at page 22, line 9 skipping to change at page 21, line 20
Implementations MUST NOT send whitespace between the start-line and Implementations MUST NOT send whitespace between the start-line and
the first header field. The presence of such whitespace in a request the first header field. The presence of such whitespace in a request
might be an attempt to trick a server into ignoring that field or might be an attempt to trick a server into ignoring that field or
processing the line after it as a new request, either of which might processing the line after it as a new request, either of which might
result in a security vulnerability if other implementations within result in a security vulnerability if other implementations within
the request chain interpret the same message differently. Likewise, the request chain interpret the same message differently. Likewise,
the presence of such whitespace in a response might be ignored by the presence of such whitespace in a response might be ignored by
some clients or cause others to cease parsing. some clients or cause others to cease parsing.
3.1. Message Parsing Robustness 3.1. Message Parsing and Robustness
In the interest of robustness, servers SHOULD ignore at least one
empty line received where a Request-Line is expected. In other
words, if the server is reading the protocol stream at the beginning
of a message and receives a CRLF first, it SHOULD ignore the CRLF.
Some old HTTP/1.0 client implementations send an extra CRLF after a
POST request as a lame workaround for some early server applications
that failed to read message-body content that was not terminated by a
line-ending. An HTTP/1.1 client MUST NOT preface or follow a request
with an extra CRLF. If terminating the request message-body with a
line-ending is desired, then the client MUST include the terminating
CRLF octets as part of the message-body length.
When a server listening only for HTTP request messages, or processing
what appears from the start-line to be an HTTP request message,
receives a sequence of octets that does not match the HTTP-message
grammar aside from the robustness exceptions listed above, the server
MUST respond with an HTTP/1.1 400 (Bad Request) response.
The normal procedure for parsing an HTTP message is to read the The normal procedure for parsing an HTTP message is to read the
start-line into a structure, read each header field into a hash table start-line into a structure, read each header field into a hash table
by field name until the empty line, and then use the parsed data to by field name until the empty line, and then use the parsed data to
determine if a message-body is expected. If a message-body has been determine if a message-body is expected. If a message-body has been
indicated, then it is read as a stream until an amount of octets indicated, then it is read as a stream until an amount of octets
equal to the message-body length is read or the connection is closed. equal to the message-body length is read or the connection is closed.
Care must be taken to parse an HTTP message as a sequence of octets Care must be taken to parse an HTTP message as a sequence of octets
in an encoding that is a superset of US-ASCII. Attempting to parse in an encoding that is a superset of US-ASCII. Attempting to parse
HTTP as a stream of Unicode characters in a character encoding like HTTP as a stream of Unicode characters in a character encoding like
UTF-16 might introduce security flaws due to the differing ways that UTF-16 might introduce security flaws due to the differing ways that
such parsers interpret invalid characters. such parsers interpret invalid characters.
HTTP allows the set of defined header fields to be extended without Older HTTP/1.0 client implementations might send an extra CRLF after
changing the protocol version (see Section 10.1). Unrecognized a POST request as a lame workaround for some early server
header fields MUST be forwarded by a proxy unless the proxy is applications that failed to read message-body content that was not
specifically configured to block or otherwise transform such fields. terminated by a line-ending. An HTTP/1.1 client MUST NOT preface or
Unrecognized header fields SHOULD be ignored by other recipients. follow a request with an extra CRLF. If terminating the request
message-body with a line-ending is desired, then the client MUST
include the terminating CRLF octets as part of the message-body
length.
In the interest of robustness, servers SHOULD ignore at least one
empty line received where a Request-Line is expected. In other
words, if the server is reading the protocol stream at the beginning
of a message and receives a CRLF first, it SHOULD ignore the CRLF.
Likewise, although the line terminator for the start-line and header
fields is the sequence CRLF, we recommend that recipients recognize a
single LF as a line terminator and ignore any CR.
When a server listening only for HTTP request messages, or processing
what appears from the start-line to be an HTTP request message,
receives a sequence of octets that does not match the HTTP-message
grammar aside from the robustness exceptions listed above, the server
MUST respond with an HTTP/1.1 400 (Bad Request) response.
3.2. Header Fields 3.2. Header Fields
Each HTTP header field consists of a case-insensitive field name Each HTTP header field consists of a case-insensitive field name
followed by a colon (":"), optional whitespace, and the field value. followed by a colon (":"), optional whitespace, and the field value.
header-field = field-name ":" OWS [ field-value ] OWS header-field = field-name ":" OWS [ field-value ] OWS
field-name = token field-name = token
field-value = *( field-content / OWS ) field-value = *( field-content / OWS )
field-content = *( WSP / VCHAR / obs-text ) field-content = *( WSP / VCHAR / obs-text )
No whitespace is allowed between the header field name and colon. The field-name token labels the corresponding field-value as having
For security reasons, any request message received containing such the semantics defined by that header field. For example, the Date
whitespace MUST be rejected with a response code of 400 (Bad header field is defined in Section 9.3 as containing the origination
Request). A proxy MUST remove any such whitespace from a response timestamp for the message in which it appears.
message before forwarding the message downstream.
A field value MAY be preceded by optional whitespace (OWS); a single HTTP header fields are fully extensible: there is no limit on the
SP is preferred. The field value does not include any leading or introduction of new field names, each presumably defining new
trailing white space: OWS occurring before the first non-whitespace semantics, or on the number of header fields used in a given message.
octet of the field value or after the last non-whitespace octet of Existing fields are defined in each part of this specification and in
the field value is ignored and SHOULD be removed before further many other specifications outside the standards process. New header
processing (as this does not change the meaning of the header field). fields can be introduced without changing the protocol version if
their defined semantics allow them to be safely ignored by recipients
that do not recognize them.
New HTTP header fields SHOULD be registered with IANA according to
the procedures in Section 10.1. Unrecognized header fields MUST be
forwarded by a proxy unless the field-name is listed in the
Connection header field (Section 9.1) or the proxy is specifically
configured to block or otherwise transform such fields. Unrecognized
header fields SHOULD be ignored by other recipients.
The order in which header fields with differing field names are The order in which header fields with differing field names are
received is not significant. However, it is "good practice" to send received is not significant. However, it is "good practice" to send
header fields that contain control data first, such as Host on header fields that contain control data first, such as Host on
requests and Date on responses, so that implementations can decide requests and Date on responses, so that implementations can decide
when not to handle a message as early as possible. A server MUST when not to handle a message as early as possible. A server MUST
wait until the entire header section is received before interpreting wait until the entire header section is received before interpreting
a request message, since later header fields might include a request message, since later header fields might include
conditionals, authentication credentials, or deliberately misleading conditionals, authentication credentials, or deliberately misleading
duplicate header fields that would impact request processing. duplicate header fields that would impact request processing.
skipping to change at page 23, line 50 skipping to change at page 23, line 19
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
No whitespace is allowed between the header field-name and colon. In
the past, differences in the handling of such whitespace have led to
security vulnerabilities in request routing and response handling.
Any received request message that contains whitespace between a
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
response message before forwarding the message downstream.
A field value MAY be preceded by optional whitespace (OWS); a single
SP is preferred. The field value does not include any leading or
trailing white space: OWS occurring before the first non-whitespace
octet of the field value or after the last non-whitespace octet of
the field value is ignored and SHOULD be removed before further
processing (as this does not change the meaning of the header field).
Historically, HTTP header field values could be extended over Historically, HTTP header field values could be extended over
multiple lines by preceding each extra line with at least one space multiple lines by preceding each extra line with at least one space
or horizontal tab octet (line folding). This specification or horizontal tab octet (line folding). This specification
deprecates such line folding except within the message/http media deprecates such line folding except within the message/http media
type (Section 10.3.1). HTTP/1.1 senders MUST NOT produce messages type (Section 10.3.1). HTTP senders MUST NOT produce messages that
that include line folding (i.e., that contain any field-content that include line folding (i.e., that contain any field-content that
matches the obs-fold rule) unless the message is intended for matches the obs-fold rule) unless the message is intended for
packaging within the message/http media type. HTTP/1.1 recipients packaging within the message/http media type. HTTP recipients SHOULD
SHOULD accept line folding and replace any embedded obs-fold accept line folding and replace any embedded obs-fold whitespace with
whitespace with a single SP prior to interpreting the field value or either a single SP or a matching number of SP octets (to avoid buffer
forwarding the message downstream. copying) prior to interpreting the field value or forwarding the
message 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.
Comments can be included in some HTTP header fields by surrounding 3.2.2. Field Length
the comment text with parentheses. Comments are only allowed in
fields containing "comment" as part of their field value definition.
comment = "(" *( ctext / quoted-cpair / comment ) ")"
ctext = OWS / %x21-27 / %x2A-5B / %x5D-7E / obs-text
; OWS / <VCHAR except "(", ")", and "\"> / obs-text
The backslash octet ("\") can be used as a single-octet quoting
mechanism within comment constructs:
quoted-cpair = "\" ( WSP / VCHAR / obs-text )
Senders SHOULD NOT escape octets that do not require escaping (i.e.,
other than the backslash octet "\" and the parentheses "(" and ")").
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
Many HTTP/1.1 header field values consist of words (token or quoted-
string) separated by whitespace or special characters. These special
characters MUST be in a quoted string to be used within a parameter
value (as defined in Section 6.2).
word = token / quoted-string
token = 1*tchar
tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*"
/ "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
/ DIGIT / ALPHA
; any VCHAR, except special
special = "(" / ")" / "<" / ">" / "@" / ","
/ ";" / ":" / "\" / DQUOTE / "/" / "["
/ "]" / "?" / "=" / "{" / "}"
A string of text is parsed as a single word if it is quoted using
double-quote marks.
quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
qdtext = OWS / %x21 / %x23-5B / %x5D-7E / obs-text
obs-text = %x80-FF
The backslash octet ("\") can be used as a single-octet quoting
mechanism within quoted-string constructs:
quoted-pair = "\" ( WSP / VCHAR / obs-text )
Recipients that process the value of the quoted-string MUST handle a
quoted-pair as if it were replaced by the octet following the
backslash.
Senders SHOULD NOT escape octets in quoted-strings that do not
require escaping (i.e., other than DQUOTE and the backslash octet).
Comments can be included in some HTTP header fields by surrounding
the comment text with parentheses. Comments are only allowed in
fields containing "comment" as part of their field value definition.
comment = "(" *( ctext / quoted-cpair / comment ) ")"
ctext = OWS / %x21-27 / %x2A-5B / %x5D-7E / obs-text
The backslash octet ("\") can be used as a single-octet quoting
mechanism within comment constructs:
quoted-cpair = "\" ( WSP / VCHAR / obs-text )
Senders SHOULD NOT escape octets in comments that do not require
escaping (i.e., other than the backslash octet "\" and the
parentheses "(" and ")").
3.3. Message Body 3.3. Message Body
The message-body (if any) of an HTTP message is used to carry the The message-body (if any) of an HTTP message is used to carry the
payload body associated with the request or response. payload body associated with the request or response.
message-body = *OCTET message-body = *OCTET
The message-body differs from the payload body only when a transfer- The message-body differs from the payload body only when a transfer-
coding has been applied, as indicated by the Transfer-Encoding header coding has been applied, as indicated by the Transfer-Encoding header
field (Section 9.7). If more than one Transfer-Encoding header field field (Section 9.7). If more than one Transfer-Encoding header field
skipping to change at page 27, line 18 skipping to change at page 27, line 45
length in octets. If the actual number of octets sent in the length in octets. If the actual number of octets sent in the
message is less than the indicated Content-Length, the recipient message is less than the indicated Content-Length, the recipient
MUST consider the message to be incomplete and treat the MUST consider the message to be incomplete and treat the
connection as no longer usable. If the actual number of octets connection as no longer usable. If the actual number of octets
sent in the message is more than the indicated Content-Length, sent in the message is more than the indicated Content-Length,
the recipient MUST only process the message-body up to the field the recipient MUST only process the message-body up to the field
value's number of octets; the remainder of the message MUST value's number of octets; the remainder of the message MUST
either be discarded or treated as the next message in a pipeline. either be discarded or treated as the next message in a pipeline.
For the sake of robustness, a user-agent MAY attempt to detect For the sake of robustness, a user-agent MAY attempt to detect
and correct such an error in message framing if it is parsing the and correct such an error in message framing if it is parsing the
response to the last request on on a connection and the response to the last request on a connection and the connection
connection has been closed by the server. has been closed by the server.
5. If this is a request message and none of the above are true, then 5. If this is a request message and none of the above are true, then
the message-body length is zero (no message-body is present). the message-body length is zero (no message-body is present).
6. Otherwise, this is a response message without a declared message- 6. Otherwise, this is a response message without a declared message-
body length, so the message-body length is determined by the body length, so the message-body length is determined by the
number of octets received prior to the server closing the number of octets received prior to the server closing the
connection. connection.
Since there is no way to distinguish a successfully completed, close- Since there is no way to distinguish a successfully completed, close-
skipping to change at page 28, line 7 skipping to change at page 28, line 36
requires a content-length in advance of being called and the server requires a content-length in advance of being called and the server
is unable or unwilling to buffer the entire request before is unable or unwilling to buffer the entire request before
processing. processing.
A client that sends a request containing a message-body MUST include A client that sends a request containing a message-body MUST include
a valid Content-Length header field if it does not know the server a valid Content-Length header field if it does not know the server
will handle HTTP/1.1 (or later) requests; such knowledge can be in will handle HTTP/1.1 (or later) requests; such knowledge can be in
the form of specific user configuration or by remembering the version the form of specific user configuration or by remembering the version
of a prior received response. of a prior received response.
3.4. Incomplete Messages
Request messages that are prematurely terminated, possibly due to a Request messages that are prematurely terminated, possibly due to a
cancelled connection or a server-imposed time-out exception, MUST cancelled connection or a server-imposed time-out exception, MUST
result in closure of the connection; sending an HTTP/1.1 error result in closure of the connection; sending an HTTP/1.1 error
response prior to closing the connection is OPTIONAL. Response response prior to closing the connection is OPTIONAL.
messages that are prematurely terminated, usually by closure of the
connection prior to receiving the expected number of octets or by Response messages that are prematurely terminated, usually by closure
failure to decode a transfer-encoded message-body, MUST be recorded of the connection prior to receiving the expected number of octets or
as incomplete. A user agent MUST NOT render an incomplete response by failure to decode a transfer-encoded message-body, MUST be
message-body as if it were complete (i.e., some indication must be recorded as incomplete. A response that terminates in the middle of
given to the user that an error occurred). Cache requirements for the header block (before the empty line is received) cannot be
incomplete responses are defined in Section 2.1.1 of [Part6]. assumed to convey the full semantics of the response and MUST be
treated as an error.
A message-body that uses the chunked transfer encoding is incomplete
if the zero-sized chunk that terminates the encoding has not been
received. A message that uses a valid Content-Length is incomplete
if the size of the message-body received (in octets) is less than the
value given by Content-Length. A response that has neither chunked
transfer encoding nor Content-Length is terminated by closure of the
connection, and thus is considered complete regardless of the number
of message-body octets received, provided that the header block was
received intact.
A user agent MUST NOT render an incomplete response message-body as
if it were complete (i.e., some indication must be given to the user
that an error occurred). Cache requirements for incomplete responses
are defined in Section 2.1 of [Part6].
A server MUST read the entire request message-body or close the A server MUST read the entire request message-body or close the
connection after sending its response, since otherwise the remaining connection after sending its response, since otherwise the remaining
data on a persistent connection would be misinterpreted as the next data on a persistent connection would be misinterpreted as the next
request. Likewise, a client MUST read the entire response message- request. Likewise, a client MUST read the entire response message-
body if it intends to reuse the same connection for a subsequent body if it intends to reuse the same connection for a subsequent
request. Pipelining multiple requests on a connection is described request. Pipelining multiple requests on a connection is described
in Section 7.1.2.2. in Section 7.1.2.2.
3.4. General Header Fields 3.5. General Header Fields
There are a few header fields which have general applicability for There are a few header fields which have general applicability for
both request and response messages, but which do not apply to the both request and response messages, but which do not apply to the
payload being transferred. These header fields apply only to the payload being transferred. These header fields apply only to the
message being transmitted. message being transmitted.
+-------------------+---------------+ +-------------------+---------------+
| Header Field Name | Defined in... | | Header Field Name | Defined in... |
+-------------------+---------------+ +-------------------+---------------+
| Connection | Section 9.1 | | Connection | Section 9.1 |
skipping to change at page 31, line 51 skipping to change at page 32, line 51
request. request.
4.2. The Resource Identified by a Request 4.2. The Resource Identified by a Request
The exact resource identified by an Internet request is determined by The exact resource identified by an Internet request is determined by
examining both the request-target and the Host header field. examining both the request-target and the Host header field.
An origin server that does not allow resources to differ by the An origin server that does not allow resources to differ by the
requested host MAY ignore the Host header field value when requested host MAY ignore the Host header field value when
determining the resource identified by an HTTP/1.1 request. (But see determining the resource identified by an HTTP/1.1 request. (But see
Appendix B.1.1 for other requirements on Host support in HTTP/1.1.) Appendix A.1.1 for other requirements on Host support in HTTP/1.1.)
An origin server that does differentiate resources based on the host An origin server that does differentiate resources based on the host
requested (sometimes referred to as virtual hosts or vanity host requested (sometimes referred to as virtual hosts or vanity host
names) MUST use the following rules for determining the requested names) MUST use the following rules for determining the requested
resource on an HTTP/1.1 request: resource on an HTTP/1.1 request:
1. If request-target is an absolute-URI, the host is part of the 1. If request-target is an absolute-URI, the host is part of the
request-target. Any Host header field value in the request MUST request-target. Any Host header field value in the request MUST
be ignored. be ignored.
2. If the request-target is not an absolute-URI, and the request 2. If the request-target is not an absolute-URI, and the request
skipping to change at page 33, line 27 skipping to change at page 34, line 27
GET /pub/WWW/TheProject.html HTTP/1.1 GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.example.org:8080 Host: www.example.org:8080
(received over an insecure TCP connection) is "http", plus "://", (received over an insecure TCP connection) is "http", plus "://",
plus the authority component "www.example.org:8080", plus the plus the authority component "www.example.org:8080", plus the
request-target "/pub/WWW/TheProject.html", thus request-target "/pub/WWW/TheProject.html", thus
"http://www.example.org:8080/pub/WWW/TheProject.html". "http://www.example.org:8080/pub/WWW/TheProject.html".
Example 2: the effective request URI for the message Example 2: the effective request URI for the message
GET * HTTP/1.1 OPTIONS * HTTP/1.1
Host: www.example.org Host: www.example.org
(received over an SSL/TLS secured TCP connection) is "https", plus (received over an SSL/TLS secured TCP connection) is "https", plus
"://", plus the authority component "www.example.org", thus "://", plus the authority component "www.example.org", thus
"https://www.example.org". "https://www.example.org".
Effective request URIs are compared using the rules described in Effective request URIs are compared using the rules described in
Section 2.7.3, except that empty path components MUST NOT be treated Section 2.7.3, except that empty path components MUST NOT be treated
as equivalent to an absolute path of "/". as equivalent to an absolute path of "/".
skipping to change at page 35, line 11 skipping to change at page 36, line 11
The other formats are described here only for compatibility with The other formats are described here only for compatibility with
obsolete implementations. obsolete implementations.
Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format
Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
HTTP/1.1 clients and servers that parse a date value MUST accept all HTTP/1.1 clients and servers that parse a date value MUST accept all
three formats (for compatibility with HTTP/1.0), though they MUST three formats (for compatibility with HTTP/1.0), though they MUST
only generate the RFC 1123 format for representing HTTP-date values only generate the RFC 1123 format for representing HTTP-date values
in header fields. See Appendix A for further information. in header fields.
All HTTP date/time stamps MUST be represented in Greenwich Mean Time All HTTP date/time stamps MUST be represented in Greenwich Mean Time
(GMT), without exception. For the purposes of HTTP, GMT is exactly (GMT), without exception. For the purposes of HTTP, GMT is exactly
equal to UTC (Coordinated Universal Time). This is indicated in the equal to UTC (Coordinated Universal Time). This is indicated in the
first two formats by the inclusion of "GMT" as the three-letter first two formats by the inclusion of "GMT" as the three-letter
abbreviation for time zone, and MUST be assumed when reading the abbreviation for time zone, and MUST be assumed when reading the
asctime format. HTTP-date is case sensitive and MUST NOT include asctime format. HTTP-date is case sensitive and MUST NOT include
additional whitespace beyond that specifically included as SP in the additional whitespace beyond that specifically included as SP in the
grammar. grammar.
skipping to change at page 44, line 34 skipping to change at page 45, line 34
In case the client does not want to maintain a connection for more In case the client does not want to maintain a connection for more
than that request, it SHOULD send a Connection header field including than that request, it SHOULD send a Connection header field including
the connection-token close. the connection-token close.
If either the client or the server sends the close token in the If either the client or the server sends the close token in the
Connection header field, that request becomes the last one for the Connection header field, that request becomes the last one for the
connection. connection.
Clients and servers SHOULD NOT assume that a persistent connection is Clients and servers SHOULD NOT assume that a persistent connection is
maintained for HTTP versions less than 1.1 unless it is explicitly maintained for HTTP versions less than 1.1 unless it is explicitly
signaled. See Appendix B.1.2 for more information on backward signaled. See Appendix A.1.2 for more information on backward
compatibility with HTTP/1.0 clients. compatibility with HTTP/1.0 clients.
In order to remain persistent, all messages on the connection MUST In order to remain persistent, all messages on the connection MUST
have a self-defined message length (i.e., one not defined by closure have a self-defined message length (i.e., one not defined by closure
of the connection), as described in Section 3.3. of the connection), as described in Section 3.3.
7.1.2.2. Pipelining 7.1.2.2. Pipelining
A client that supports persistent connections MAY "pipeline" its A client that supports persistent connections MAY "pipeline" its
requests (i.e., send multiple requests without waiting for each requests (i.e., send multiple requests without waiting for each
skipping to change at page 51, line 5 skipping to change at page 52, line 5
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.
o If the proxy knows that the version of the next-hop server is o If the proxy knows that the version of the next-hop server is
HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST
respond with a 417 (Expectation Failed) status code. respond with a 417 (Expectation Failed) status code.
o Proxies SHOULD maintain a cache recording the HTTP version numbers o Proxies SHOULD maintain a record of the HTTP version numbers
received from recently-referenced next-hop servers. received from recently-referenced next-hop servers.
o A proxy MUST NOT forward a 100 (Continue) response if the request o A proxy MUST NOT forward a 100 (Continue) response if the request
message was received from an HTTP/1.0 (or earlier) client and did message was received from an HTTP/1.0 (or earlier) client and did
not include an Expect header field with the "100-continue" not include an Expect header field with the "100-continue"
expectation. This requirement overrides the general rule for expectation. This requirement overrides the general rule for
forwarding of 1xx responses (see Section 8.1 of [Part2]). forwarding of 1xx responses (see Section 8.1 of [Part2]).
7.2.4. Client Behavior if Server Prematurely Closes Connection 7.2.4. Client Behavior if Server Prematurely Closes Connection
skipping to change at page 57, line 7 skipping to change at page 58, line 7
Host header field value for redirecting requests to internal servers, Host header field value for redirecting requests to internal servers,
or for use as a cache key in a shared cache, without first verifying or for use as a cache key in a shared cache, without first verifying
that the intercepted connection is targeting a valid IP address for that the intercepted connection is targeting a valid IP address for
that host. that host.
A server MUST respond with a 400 (Bad Request) status code to any A server MUST respond with a 400 (Bad Request) status code to any
HTTP/1.1 request message that lacks a Host header field and to any HTTP/1.1 request message that lacks a Host header field and to any
request message that contains more than one Host header field or a request message that contains more than one Host header field or a
Host header field with an invalid field-value. Host header field with an invalid field-value.
See Sections 4.2 and B.1.1 for other requirements relating to Host. See Sections 4.2 and A.1.1 for other requirements relating to Host.
9.5. TE 9.5. TE
The "TE" header field indicates what extension transfer-codings it is The "TE" header field indicates what extension transfer-codings it is
willing to accept in the response, and whether or not it is willing willing to accept in the response, and whether or not it is willing
to accept trailer fields in a chunked transfer-coding. to accept trailer fields in a chunked transfer-coding.
Its value consists of the keyword "trailers" and/or a comma-separated Its value consists of the keyword "trailers" and/or a comma-separated
list of extension transfer-coding names with optional accept list of extension transfer-coding names with optional accept
parameters (as described in Section 6.2). parameters (as described in Section 6.2).
skipping to change at page 63, line 19 skipping to change at page 64, line 19
| Content-Length | http | standard | Section 9.2 | | Content-Length | http | standard | Section 9.2 |
| Date | http | standard | Section 9.3 | | Date | http | standard | Section 9.3 |
| Host | http | standard | Section 9.4 | | Host | http | standard | Section 9.4 |
| TE | http | standard | Section 9.5 | | TE | http | standard | Section 9.5 |
| Trailer | http | standard | Section 9.6 | | Trailer | http | standard | Section 9.6 |
| Transfer-Encoding | http | standard | Section 9.7 | | Transfer-Encoding | http | standard | Section 9.7 |
| Upgrade | http | standard | Section 9.8 | | Upgrade | http | standard | Section 9.8 |
| Via | http | standard | Section 9.9 | | Via | http | standard | Section 9.9 |
+-------------------+----------+----------+-------------+ +-------------------+----------+----------+-------------+
Furthermore, the header field name "Close" shall be registered as
"reserved", as its use as HTTP header field would be in conflict with
the use of the "close" connection option for the "Connection" header
field (Section 9.1).
+-------------------+----------+----------+--------------+
| Header Field Name | Protocol | Status | Reference |
+-------------------+----------+----------+--------------+
| Close | http | reserved | Section 10.1 |
+-------------------+----------+----------+--------------+
The change controller is: "IETF (iesg@ietf.org) - Internet The change controller is: "IETF (iesg@ietf.org) - Internet
Engineering Task Force". Engineering Task Force".
10.2. URI Scheme Registration 10.2. URI Scheme Registration
The entries for the "http" and "https" URI Schemes in the registry The entries for the "http" and "https" URI Schemes in the registry
located at <http://www.iana.org/assignments/uri-schemes.html> shall located at <http://www.iana.org/assignments/uri-schemes.html> shall
be updated to point to Sections 2.7.1 and 2.7.2 of this document (see be updated to point to Sections 2.7.1 and 2.7.2 of this document (see
[RFC4395]). [RFC4395]).
skipping to change at page 67, line 34 skipping to change at page 68, line 47
directory level above the current one. On such a system, an HTTP directory level above the current one. On such a system, an HTTP
server MUST disallow any such construct in the request-target if it server MUST disallow any such construct in the request-target if it
would otherwise allow access to a resource outside those intended to would otherwise allow access to a resource outside those intended to
be accessible via the HTTP server. Similarly, files intended for be accessible via the HTTP server. Similarly, files intended for
reference only internally to the server (such as access control reference only internally to the server (such as access control
files, configuration files, and script code) MUST be protected from files, configuration files, and script code) MUST be protected from
inappropriate retrieval, since they might contain sensitive inappropriate retrieval, since they might contain sensitive
information. Experience has shown that minor bugs in such HTTP information. Experience has shown that minor bugs in such HTTP
server implementations have turned into security risks. server implementations have turned into security risks.
11.4. DNS Spoofing 11.4. DNS-related Attacks
Clients using HTTP rely heavily on the Domain Name Service, and are
thus generally prone to security attacks based on the deliberate mis-
association of IP addresses and DNS names. Clients need to be
cautious in assuming the continuing validity of an IP number/DNS name
association.
In particular, HTTP clients SHOULD rely on their name resolver for
confirmation of an IP number/DNS name association, rather than
caching the result of previous host name lookups. Many platforms
already can cache host name lookups locally when appropriate, and
they SHOULD be configured to do so. It is proper for these lookups
to be cached, however, only when the TTL (Time To Live) information
reported by the name server makes it likely that the cached
information will remain useful.
If HTTP clients cache the results of host name lookups in order to
achieve a performance improvement, they MUST observe the TTL
information reported by DNS.
If HTTP clients do not observe this rule, they could be spoofed when
a previously-accessed server's IP address changes. As network
renumbering is expected to become increasingly common [RFC1900], the
possibility of this form of attack will grow. Observing this
requirement thus reduces this potential security vulnerability.
This requirement also improves the load-balancing behavior of clients HTTP clients rely heavily on the Domain Name Service (DNS), and are
for replicated servers using the same DNS name and reduces the thus generally prone to security attacks based on the deliberate
likelihood of a user's experiencing failure in accessing sites which misassociation of IP addresses and DNS names not protected by DNSSec.
use that strategy. Clients need to be cautious in assuming the validity of an IP number/
DNS name association unless the response is protected by DNSSec
([RFC4033]).
11.5. Proxies and Caching 11.5. Proxies and Caching
By their very nature, HTTP proxies are men-in-the-middle, and By their very nature, HTTP proxies are men-in-the-middle, and
represent an opportunity for man-in-the-middle attacks. Compromise represent an opportunity for man-in-the-middle attacks. Compromise
of the systems on which the proxies run can result in serious of the systems on which the proxies run can result in serious
security and privacy problems. Proxies have access to security- security and privacy problems. Proxies have access to security-
related information, personal information about individual users and related information, personal information about individual users and
organizations, and proprietary information belonging to users and organizations, and proprietary information belonging to users and
content providers. A compromised proxy, or a proxy implemented or content providers. A compromised proxy, or a proxy implemented or
skipping to change at page 69, line 36 skipping to change at page 70, line 22
limited by implementations carefully, so as to not impede limited by implementations carefully, so as to not impede
interoperability. interoperability.
11.7. Denial of Service Attacks on Proxies 11.7. Denial of Service Attacks on Proxies
They exist. They are hard to defend against. Research continues. They exist. They are hard to defend against. Research continues.
Beware. Beware.
12. Acknowledgments 12. Acknowledgments
HTTP has evolved considerably over the years. It has benefited from This document revision builds on the work that went into RFC 2616 and
a large and active developer community -- the many people who have its predecessors. See Section 16 of [RFC2616] for detailed
participated on the www-talk mailing list -- and it is that community acknowledgements.
which has been most responsible for the success of HTTP and of the
World-Wide Web in general. Marc Andreessen, Robert Cailliau, Daniel
W. Connolly, Bob Denny, John Franks, Jean-Francois Groff, Phillip M.
Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Lou Montulli,
Dave Raggett, Tony Sanders, and Marc VanHeyningen deserve special
recognition for their efforts in defining early aspects of the
protocol.
This document has benefited greatly from the comments of all those
participating in the HTTP-WG. In addition to those already
mentioned, the following individuals have contributed to this
specification:
Gary Adams, Harald Tveit Alvestrand, Keith Ball, Brian Behlendorf,
Paul Burchard, Maurizio Codogno, Josh Cohen, Mike Cowlishaw, Roman
Czyborra, Michael A. Dolan, Daniel DuBois, David J. Fiander, Alan
Freier, Marc Hedlund, Greg Herlihy, Koen Holtman, Alex Hopmann, Bob
Jernigan, Shel Kaphan, Rohit Khare, John Klensin, Martijn Koster,
Alexei Kosut, David M. Kristol, Daniel LaLiberte, Ben Laurie, Paul J.
Leach, Albert Lunde, John C. Mallery, Jean-Philippe Martin-Flatin,
Mitra, David Morris, Gavin Nicol, Ross Patterson, Bill Perry, Jeffrey
Perry, Scott Powers, Owen Rees, Luigi Rizzo, David Robinson, Marc
Salomon, Rich Salz, Allan M. Schiffman, Jim Seidman, Chuck Shotton,
Eric W. Sink, Simon E. Spero, Richard N. Taylor, Robert S. Thau, Bill
(BearHeart) Weinman, Francois Yergeau, Mary Ellen Zurko.
Thanks to the "cave men" of Palo Alto. You know who you are.
Jim Gettys (the editor of [RFC2616]) wishes particularly to thank Roy
Fielding, the editor of [RFC2068], along with John Klensin, Jeff
Mogul, Paul Leach, Dave Kristol, Koen Holtman, John Franks, Josh
Cohen, Alex Hopmann, Scott Lawrence, and Larry Masinter for their
help. And thanks go particularly to Jeff Mogul and Scott Lawrence
for performing the "MUST/MAY/SHOULD" audit.
The Apache Group, Anselm Baird-Smith, author of Jigsaw, and Henrik
Frystyk implemented RFC 2068 early, and we wish to thank them for the
discovery of many of the problems that this document attempts to
rectify.
This specification makes heavy use of the augmented BNF and generic [[todoacks: Insert HTTPbis-specific acknowledgements here.]]
constructs defined by David H. Crocker for [RFC5234]. Similarly, it
reuses many of the definitions provided by Nathaniel Borenstein and
Ned Freed for MIME [RFC2045]. We hope that their inclusion in this
specification will help reduce past confusion over the relationship
between HTTP and Internet mail message formats.
13. References 13. References
13.1. Normative References 13.1. Normative References
[ISO-8859-1] International Organization for 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-15 (work in Semantics", draft-ietf-httpbis-p2-semantics-16 (work in
progress), July 2011. progress), August 2011.
[Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
Ed., and J. Reschke, Ed., "HTTP/1.1, part 3: Message Ed., and J. Reschke, Ed., "HTTP/1.1, part 3: Message
Payload and Content Negotiation", Payload and Content Negotiation",
draft-ietf-httpbis-p3-payload-15 (work in progress), draft-ietf-httpbis-p3-payload-16 (work in progress),
July 2011. August 2011.
[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
Ed., Nottingham, M., Ed., and J. Reschke, Ed., Ed., Nottingham, M., Ed., and J. Reschke, Ed.,
"HTTP/1.1, part 6: Caching", "HTTP/1.1, part 6: Caching",
draft-ietf-httpbis-p6-cache-15 (work in progress), draft-ietf-httpbis-p6-cache-16 (work in progress),
July 2011. August 2011.
[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
Format Specification version 3.3", RFC 1950, May 1996. Format Specification version 3.3", RFC 1950, May 1996.
RFC 1950 is an Informational RFC, thus it might be less RFC 1950 is an Informational RFC, thus it might be less
stable than this specification. On the other hand, stable than this specification. On the other hand,
this downward reference was present since the this downward reference was present since the
publication of RFC 2068 in 1997 ([RFC2068]), therefore publication of RFC 2068 in 1997 ([RFC2068]), therefore
it is unlikely to cause problems in practice. See also it is unlikely to cause problems in practice. See also
[BCP97]. [BCP97].
skipping to change at page 72, line 45 skipping to change at page 72, line 34
[Pad1995] Padmanabhan, V. and J. Mogul, "Improving HTTP Latency", [Pad1995] Padmanabhan, V. and J. Mogul, "Improving HTTP Latency",
Computer Networks and ISDN Systems v. 28, pp. 25-35, Computer Networks and ISDN Systems v. 28, pp. 25-35,
December 1995, December 1995,
<http://portal.acm.org/citation.cfm?id=219094>. <http://portal.acm.org/citation.cfm?id=219094>.
[RFC1123] Braden, R., "Requirements for Internet Hosts - [RFC1123] Braden, R., "Requirements for Internet Hosts -
Application and Support", STD 3, RFC 1123, Application and Support", STD 3, RFC 1123,
October 1989. October 1989.
[RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work",
RFC 1900, February 1996.
[RFC1919] Chatel, M., "Classical versus Transparent IP Proxies", [RFC1919] Chatel, M., "Classical versus Transparent IP Proxies",
RFC 1919, March 1996. RFC 1919, March 1996.
[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen,
"Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945,
May 1996. May 1996.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet Mail Extensions (MIME) Part One: Format of Internet
Message Bodies", RFC 2045, November 1996. Message Bodies", RFC 2045, November 1996.
skipping to change at page 73, line 42 skipping to change at page 73, line 29
Mechanism", RFC 2965, October 2000. Mechanism", RFC 2965, October 2000.
[RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web [RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web
Replication and Caching Taxonomy", RFC 3040, Replication and Caching Taxonomy", RFC 3040,
January 2001. January 2001.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, Procedures for Message Header Fields", BCP 90,
RFC 3864, September 2004. RFC 3864, September 2004.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications
and Registration Procedures", BCP 13, RFC 4288, and Registration Procedures", BCP 13, RFC 4288,
December 2005. December 2005.
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines
and Registration Procedures for New URI Schemes", and Registration Procedures for New URI Schemes",
BCP 115, RFC 4395, February 2006. BCP 115, RFC 4395, February 2006.
[RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based
Kerberos and NTLM HTTP Authentication in Microsoft Kerberos and NTLM HTTP Authentication in Microsoft
skipping to change at page 74, line 25 skipping to change at page 74, line 15
[Spe] Spero, S., "Analysis of HTTP Performance Problems", [Spe] Spero, S., "Analysis of HTTP Performance Problems",
<http://sunsite.unc.edu/mdma-release/http-prob.html>. <http://sunsite.unc.edu/mdma-release/http-prob.html>.
[Tou1998] Touch, J., Heidemann, J., and K. Obraczka, "Analysis of [Tou1998] Touch, J., Heidemann, J., and K. Obraczka, "Analysis of
HTTP Performance", ISI Research Report ISI/RR-98-463, HTTP Performance", ISI Research Report ISI/RR-98-463,
Aug 1998, <http://www.isi.edu/touch/pubs/http-perf96/>. Aug 1998, <http://www.isi.edu/touch/pubs/http-perf96/>.
(original report dated Aug. 1996) (original report dated Aug. 1996)
Appendix A. Tolerant Applications Appendix A. HTTP Version History
Although this document specifies the requirements for the generation
of HTTP/1.1 messages, not all applications will be correct in their
implementation. We therefore recommend that operational applications
be tolerant of deviations whenever those deviations can be
interpreted unambiguously.
The line terminator for header fields is the sequence CRLF. However,
we recommend that applications, when parsing such headers fields,
recognize a single LF as a line terminator and ignore the leading CR.
The character encoding of a representation SHOULD be labeled as the
lowest common denominator of the character codes used within that
representation, with the exception that not labeling the
representation is preferred over labeling the representation with the
labels US-ASCII or ISO-8859-1. See [Part3].
Additional rules for requirements on parsing and encoding of dates
and other potential problems with date encodings include:
o HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date
which appears to be more than 50 years in the future is in fact in
the past (this helps solve the "year 2000" problem).
o Although all date formats are specified to be case-sensitive,
recipients SHOULD match day, week and timezone names case-
insensitively.
o An HTTP/1.1 implementation MAY internally represent a parsed
Expires date as earlier than the proper value, but MUST NOT
internally represent a parsed Expires date as later than the
proper value.
o All expiration-related calculations MUST be done in GMT. The
local time zone MUST NOT influence the calculation or comparison
of an age or expiration time.
o If an HTTP header field incorrectly carries a date value with a
time zone other than GMT, it MUST be converted into GMT using the
most conservative possible conversion.
Appendix B. HTTP Version History
HTTP has been in use by the World-Wide Web global information HTTP has been in use by the World-Wide Web global information
initiative since 1990. The first version of HTTP, later referred to initiative since 1990. The first version of HTTP, later referred to
as HTTP/0.9, was a simple protocol for hypertext data transfer across as HTTP/0.9, was a simple protocol for hypertext data transfer across
the Internet with only a single request method (GET) and no metadata. the Internet with only a single request method (GET) and no metadata.
HTTP/1.0, as defined by [RFC1945], added a range of request methods HTTP/1.0, as defined by [RFC1945], added a range of request methods
and MIME-like messaging that could include metadata about the data and MIME-like messaging that could include metadata about the data
transferred and modifiers on the request/response semantics. transferred and modifiers on the request/response semantics.
However, HTTP/1.0 did not sufficiently take into consideration the However, HTTP/1.0 did not sufficiently take into consideration the
effects of hierarchical proxies, caching, the need for persistent effects of hierarchical proxies, caching, the need for persistent
skipping to change at page 76, line 12 skipping to change at page 75, line 8
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.
B.1. Changes from HTTP/1.0 A.1. Changes from HTTP/1.0
This section summarizes major differences between versions HTTP/1.0 This section summarizes major differences between versions HTTP/1.0
and HTTP/1.1. and HTTP/1.1.
B.1.1. Multi-homed Web Servers A.1.1. Multi-homed Web Servers
The requirements that clients and servers support the Host header The requirements that clients and servers support the Host header
field (Section 9.4), report an error if it is missing from an field (Section 9.4), report an error if it is missing from an
HTTP/1.1 request, and accept absolute URIs (Section 4.1.2) are among HTTP/1.1 request, and accept absolute URIs (Section 4.1.2) are among
the most important changes defined by HTTP/1.1. the most important changes defined by HTTP/1.1.
Older HTTP/1.0 clients assumed a one-to-one relationship of IP Older HTTP/1.0 clients assumed a one-to-one relationship of IP
addresses and servers; there was no other established mechanism for addresses and servers; there was no other established mechanism for
distinguishing the intended server of a request than the IP address distinguishing the intended server of a request than the IP address
to which that request was directed. The Host header field was to which that request was directed. The Host header field was
introduced during the development of HTTP/1.1 and, though it was introduced during the development of HTTP/1.1 and, though it was
quickly implemented by most HTTP/1.0 browsers, additional quickly implemented by most HTTP/1.0 browsers, additional
requirements were placed on all HTTP/1.1 requests in order to ensure requirements were placed on all HTTP/1.1 requests in order to ensure
complete adoption. At the time of this writing, most HTTP-based complete adoption. At the time of this writing, most HTTP-based
services are dependent upon the Host header field for targeting services are dependent upon the Host header field for targeting
requests. requests.
B.1.2. Keep-Alive Connections A.1.2. Keep-Alive Connections
For most implementations of HTTP/1.0, each connection is established For most implementations of HTTP/1.0, each connection is established
by the client prior to the request and closed by the server after by the client prior to the request and closed by the server after
sending the response. However, some implementations implement the sending the response. However, some implementations implement the
Keep-Alive version of persistent connections described in Section Keep-Alive version of persistent connections described in Section
19.7.1 of [RFC2068]. 19.7.1 of [RFC2068].
Some clients and servers might wish to be compatible with some Some clients and servers might wish to be compatible with some
previous implementations of persistent connections in HTTP/1.0 previous implementations of persistent connections in HTTP/1.0
clients and servers. Persistent connections in HTTP/1.0 are clients and servers. Persistent connections in HTTP/1.0 are
skipping to change at page 77, line 17 skipping to change at page 76, line 13
talking to proxies. talking to proxies.
However, talking to proxies is the most important use of persistent However, talking to proxies is the most important use of persistent
connections, so that prohibition is clearly unacceptable. Therefore, connections, so that prohibition is clearly unacceptable. Therefore,
we need some other mechanism for indicating a persistent connection we need some other mechanism for indicating a persistent connection
is desired, which is safe to use even when talking to an old proxy is desired, which is safe to use even when talking to an old proxy
that ignores Connection. Persistent connections are the default for that ignores Connection. Persistent connections are the default for
HTTP/1.1 messages; we introduce a new keyword (Connection: close) for HTTP/1.1 messages; we introduce a new keyword (Connection: close) for
declaring non-persistence. See Section 9.1. declaring non-persistence. See Section 9.1.
B.2. Changes from RFC 2616 A.2. Changes from RFC 2616
Empty list elements in list productions have been deprecated. Empty list elements in list productions have been deprecated.
(Section 1.2.1) (Section 1.2.1)
Rules about implicit linear whitespace between certain grammar Rules about implicit linear whitespace between certain grammar
productions have been removed; now it's only allowed when productions have been removed; now it's only allowed when
specifically pointed out in the ABNF. The NUL octet is no longer specifically pointed out in the ABNF. (Section 1.2.2)
allowed in comment and quoted-string text. The quoted-pair rule no
longer allows escaping control characters other than HTAB. Non-ASCII
content in header fields and reason phrase has been obsoleted and
made opaque (the TEXT rule was removed) (Section 1.2.2)
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 quoted-pair rule no longer allows escaping control characters
other than HTAB. Non-ASCII content in header fields and reason
phrase has been obsoleted and made opaque (the TEXT rule was
removed). (Section 3.2.3)
Require recipients to handle bogus Content-Length header fields as Require recipients to handle bogus Content-Length header fields as
errors. (Section 3.3) errors. (Section 3.3)
Remove reference to non-existent identity transfer-coding value Remove reference to non-existent identity transfer-coding value
tokens. (Sections 3.3 and 6.2) tokens. (Sections 3.3 and 6.2)
Update use of abs_path production from RFC 1808 to the path-absolute Update use of abs_path production from RFC 1808 to the path-absolute
+ query components of RFC 3986. State that the asterisk form is + query components of RFC 3986. State that the asterisk form is
allowed for the OPTIONS request method only. (Section 4.1.2) allowed for the OPTIONS request method only. (Section 4.1.2)
skipping to change at page 78, line 15 skipping to change at page 77, line 12
Change ABNF productions for header fields to only define the field Change ABNF productions for header fields to only define the field
value. (Section 9) value. (Section 9)
Clarify exactly when close connection options must be sent. Clarify exactly when close connection options must be sent.
(Section 9.1) (Section 9.1)
Define the semantics of the "Upgrade" header field in responses other Define the semantics of the "Upgrade" header field in responses other
than 101 (this was incorporated from [RFC2817]). (Section 9.8) than 101 (this was incorporated from [RFC2817]). (Section 9.8)
Appendix C. Collected ABNF Appendix B. Collected ABNF
BWS = OWS BWS = OWS
Chunked-Body = *chunk last-chunk trailer-part CRLF Chunked-Body = *chunk last-chunk trailer-part CRLF
Connection = *( "," OWS ) connection-token *( OWS "," [ OWS Connection = *( "," OWS ) connection-token *( OWS "," [ OWS
connection-token ] ) connection-token ] )
Content-Length = 1*DIGIT Content-Length = 1*DIGIT
Date = HTTP-date Date = HTTP-date
skipping to change at page 82, line 25 skipping to change at page 81, line 25
; Trailer defined but not used ; Trailer defined but not used
; Transfer-Encoding defined but not used ; Transfer-Encoding defined but not used
; URI-reference defined but not used ; URI-reference defined but not used
; Upgrade defined but not used ; Upgrade defined but not used
; Via defined but not used ; Via defined but not used
; http-URI defined but not used ; http-URI defined but not used
; https-URI defined but not used ; https-URI defined but not used
; partial-URI defined but not used ; partial-URI defined but not used
; special defined but not used ; special defined but not used
Appendix D. Change Log (to be removed by RFC Editor before publication) Appendix C. Change Log (to be removed by RFC Editor before publication)
D.1. Since RFC 2616 C.1. Since RFC 2616
Extracted relevant partitions from [RFC2616]. Extracted relevant partitions from [RFC2616].
D.2. Since draft-ietf-httpbis-p1-messaging-00 C.2. Since draft-ietf-httpbis-p1-messaging-00
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/1>: "HTTP Version o <http://tools.ietf.org/wg/httpbis/trac/ticket/1>: "HTTP Version
should be case sensitive" should be case sensitive"
(<http://purl.org/NET/http-errata#verscase>) (<http://purl.org/NET/http-errata#verscase>)
o <http://tools.ietf.org/wg/httpbis/trac/ticket/2>: "'unsafe' o <http://tools.ietf.org/wg/httpbis/trac/ticket/2>: "'unsafe'
characters" (<http://purl.org/NET/http-errata#unsafe-uri>) characters" (<http://purl.org/NET/http-errata#unsafe-uri>)
skipping to change at page 84, line 6 skipping to change at page 83, line 6
to-date references" to-date references"
Other changes: Other changes:
o Update media type registrations to use RFC4288 template. o Update media type registrations to use RFC4288 template.
o Use names of RFC4234 core rules DQUOTE and WSP, fix broken ABNF o Use names of RFC4234 core rules DQUOTE and WSP, fix broken ABNF
for chunk-data (work in progress on for chunk-data (work in progress on
<http://tools.ietf.org/wg/httpbis/trac/ticket/36>) <http://tools.ietf.org/wg/httpbis/trac/ticket/36>)
D.3. Since draft-ietf-httpbis-p1-messaging-01 C.3. Since draft-ietf-httpbis-p1-messaging-01
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/19>: "Bodies on GET o <http://tools.ietf.org/wg/httpbis/trac/ticket/19>: "Bodies on GET
(and other) requests" (and other) requests"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/55>: "Updating to o <http://tools.ietf.org/wg/httpbis/trac/ticket/55>: "Updating to
RFC4288" RFC4288"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/57>: "Status Code o <http://tools.ietf.org/wg/httpbis/trac/ticket/57>: "Status Code
skipping to change at page 85, line 5 skipping to change at page 84, line 5
o Move "Product Tokens" section (back) into Part 1, as "token" is o Move "Product Tokens" section (back) into Part 1, as "token" is
used in the definition of the Upgrade header field. used in the definition of the Upgrade header field.
o Add explicit references to BNF syntax and rules imported from o Add explicit references to BNF syntax and rules imported from
other parts of the specification. other parts of the specification.
o Rewrite prose rule "token" in terms of "tchar", rewrite prose rule o Rewrite prose rule "token" in terms of "tchar", rewrite prose rule
"TEXT". "TEXT".
D.4. Since draft-ietf-httpbis-p1-messaging-02 C.4. Since draft-ietf-httpbis-p1-messaging-02
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/51>: "HTTP-date vs. o <http://tools.ietf.org/wg/httpbis/trac/ticket/51>: "HTTP-date vs.
rfc1123-date" rfc1123-date"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/64>: "WS in quoted- o <http://tools.ietf.org/wg/httpbis/trac/ticket/64>: "WS in quoted-
pair" pair"
Ongoing work on IANA Message Header Field Registration Ongoing work on IANA Message Header Field Registration
skipping to change at page 85, line 27 skipping to change at page 84, line 27
o Reference RFC 3984, and update header field registrations for o Reference RFC 3984, and update header field registrations for
headers defined in this document. headers defined in this document.
Ongoing work on ABNF conversion Ongoing work on ABNF conversion
(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
o Replace string literals when the string really is case-sensitive o Replace string literals when the string really is case-sensitive
(HTTP-Version). (HTTP-Version).
D.5. Since draft-ietf-httpbis-p1-messaging-03 C.5. Since draft-ietf-httpbis-p1-messaging-03
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/28>: "Connection o <http://tools.ietf.org/wg/httpbis/trac/ticket/28>: "Connection
closing" closing"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/97>: "Move o <http://tools.ietf.org/wg/httpbis/trac/ticket/97>: "Move
registrations and registry information to IANA Considerations" registrations and registry information to IANA Considerations"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/120>: "need new URL o <http://tools.ietf.org/wg/httpbis/trac/ticket/120>: "need new URL
skipping to change at page 86, line 11 skipping to change at page 85, line 11
Ongoing work on ABNF conversion Ongoing work on ABNF conversion
(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
o Replace string literals when the string really is case-sensitive o Replace string literals when the string really is case-sensitive
(HTTP-Date). (HTTP-Date).
o Replace HEX by HEXDIG for future consistence with RFC 5234's core o Replace HEX by HEXDIG for future consistence with RFC 5234's core
rules. rules.
D.6. Since draft-ietf-httpbis-p1-messaging-04 C.6. Since draft-ietf-httpbis-p1-messaging-04
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/34>: "Out-of-date o <http://tools.ietf.org/wg/httpbis/trac/ticket/34>: "Out-of-date
reference for URIs" reference for URIs"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/132>: "RFC 2822 is o <http://tools.ietf.org/wg/httpbis/trac/ticket/132>: "RFC 2822 is
updated by RFC 5322" updated by RFC 5322"
Ongoing work on ABNF conversion Ongoing work on ABNF conversion
skipping to change at page 86, line 36 skipping to change at page 85, line 36
o Get rid of RFC822 dependency; use RFC5234 plus extensions instead. o Get rid of RFC822 dependency; use RFC5234 plus extensions instead.
o Only reference RFC 5234's core rules. o Only reference RFC 5234's core rules.
o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
whitespace ("OWS") and required whitespace ("RWS"). whitespace ("OWS") and required whitespace ("RWS").
o Rewrite ABNFs to spell out whitespace rules, factor out header o Rewrite ABNFs to spell out whitespace rules, factor out header
field value format definitions. field value format definitions.
D.7. Since draft-ietf-httpbis-p1-messaging-05 C.7. Since draft-ietf-httpbis-p1-messaging-05
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/30>: "Header LWS" o <http://tools.ietf.org/wg/httpbis/trac/ticket/30>: "Header LWS"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/52>: "Sort 1.3 o <http://tools.ietf.org/wg/httpbis/trac/ticket/52>: "Sort 1.3
Terminology" Terminology"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/63>: "RFC2047 o <http://tools.ietf.org/wg/httpbis/trac/ticket/63>: "RFC2047
encoded words" encoded words"
skipping to change at page 87, line 33 skipping to change at page 86, line 33
o Add appendix containing collected and expanded ABNF. o Add appendix containing collected and expanded ABNF.
Other changes: Other changes:
o Rewrite introduction; add mostly new Architecture Section. o Rewrite introduction; add mostly new Architecture Section.
o Move definition of quality values from Part 3 into Part 1; make TE o Move definition of quality values from Part 3 into Part 1; make TE
request header field grammar independent of accept-params (defined request header field grammar independent of accept-params (defined
in Part 3). in Part 3).
D.8. Since draft-ietf-httpbis-p1-messaging-06 C.8. Since draft-ietf-httpbis-p1-messaging-06
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/161>: "base for o <http://tools.ietf.org/wg/httpbis/trac/ticket/161>: "base for
numeric protocol elements" numeric protocol elements"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/162>: "comment ABNF" o <http://tools.ietf.org/wg/httpbis/trac/ticket/162>: "comment ABNF"
Partly resolved issues: Partly resolved issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/88>: "205 Bodies" o <http://tools.ietf.org/wg/httpbis/trac/ticket/88>: "205 Bodies"
(took out language that implied that there might be methods for (took out language that implied that there might be methods for
which a request body MUST NOT be included) which a request body MUST NOT be included)
o <http://tools.ietf.org/wg/httpbis/trac/ticket/163>: "editorial o <http://tools.ietf.org/wg/httpbis/trac/ticket/163>: "editorial
improvements around HTTP-date" improvements around HTTP-date"
D.9. Since draft-ietf-httpbis-p1-messaging-07 C.9. Since draft-ietf-httpbis-p1-messaging-07
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/93>: "Repeating o <http://tools.ietf.org/wg/httpbis/trac/ticket/93>: "Repeating
single-value headers" single-value headers"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/131>: "increase o <http://tools.ietf.org/wg/httpbis/trac/ticket/131>: "increase
connection limit" connection limit"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/157>: "IP addresses o <http://tools.ietf.org/wg/httpbis/trac/ticket/157>: "IP addresses
skipping to change at page 88, line 42 skipping to change at page 87, line 42
o <http://tools.ietf.org/wg/httpbis/trac/ticket/194>: "disallow o <http://tools.ietf.org/wg/httpbis/trac/ticket/194>: "disallow
control characters in quoted-pair" control characters in quoted-pair"
Partly resolved issues: Partly resolved issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/148>: "update IANA o <http://tools.ietf.org/wg/httpbis/trac/ticket/148>: "update IANA
requirements wrt Transfer-Coding values" (add the IANA requirements wrt Transfer-Coding values" (add the IANA
Considerations subsection) Considerations subsection)
D.10. Since draft-ietf-httpbis-p1-messaging-08 C.10. Since draft-ietf-httpbis-p1-messaging-08
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/201>: "header o <http://tools.ietf.org/wg/httpbis/trac/ticket/201>: "header
parsing, treatment of leading and trailing OWS" parsing, treatment of leading and trailing OWS"
Partly resolved issues: Partly resolved issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/60>: "Placement of o <http://tools.ietf.org/wg/httpbis/trac/ticket/60>: "Placement of
13.5.1 and 13.5.2" 13.5.1 and 13.5.2"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/200>: "use of term o <http://tools.ietf.org/wg/httpbis/trac/ticket/200>: "use of term
"word" when talking about header structure" "word" when talking about header structure"
D.11. Since draft-ietf-httpbis-p1-messaging-09 C.11. Since draft-ietf-httpbis-p1-messaging-09
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/73>: "Clarification o <http://tools.ietf.org/wg/httpbis/trac/ticket/73>: "Clarification
of the term 'deflate'" of the term 'deflate'"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/83>: "OPTIONS * and o <http://tools.ietf.org/wg/httpbis/trac/ticket/83>: "OPTIONS * and
proxies" proxies"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/122>: "MIME-Version o <http://tools.ietf.org/wg/httpbis/trac/ticket/122>: "MIME-Version
skipping to change at page 89, line 35 skipping to change at page 88, line 35
sensitivity of HTTP-date" sensitivity of HTTP-date"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/200>: "use of term o <http://tools.ietf.org/wg/httpbis/trac/ticket/200>: "use of term
"word" when talking about header structure" "word" when talking about header structure"
Partly resolved issues: Partly resolved issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/196>: "Term for the o <http://tools.ietf.org/wg/httpbis/trac/ticket/196>: "Term for the
requested resource's URI" requested resource's URI"
D.12. Since draft-ietf-httpbis-p1-messaging-10 C.12. Since draft-ietf-httpbis-p1-messaging-10
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/28>: "Connection o <http://tools.ietf.org/wg/httpbis/trac/ticket/28>: "Connection
Closing" Closing"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/90>: "Delimiting o <http://tools.ietf.org/wg/httpbis/trac/ticket/90>: "Delimiting
messages with multipart/byteranges" messages with multipart/byteranges"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/95>: "Handling o <http://tools.ietf.org/wg/httpbis/trac/ticket/95>: "Handling
skipping to change at page 90, line 10 skipping to change at page 89, line 10
entity / representation / variant terminology" entity / representation / variant terminology"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider o <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider
removing the 'changes from 2068' sections" removing the 'changes from 2068' sections"
Partly resolved issues: Partly resolved issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/159>: "HTTP(s) URI o <http://tools.ietf.org/wg/httpbis/trac/ticket/159>: "HTTP(s) URI
scheme definitions" scheme definitions"
D.13. Since draft-ietf-httpbis-p1-messaging-11 C.13. Since draft-ietf-httpbis-p1-messaging-11
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/193>: "Trailer o <http://tools.ietf.org/wg/httpbis/trac/ticket/193>: "Trailer
requirements" requirements"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/204>: "Text about o <http://tools.ietf.org/wg/httpbis/trac/ticket/204>: "Text about
clock requirement for caches belongs in p6" clock requirement for caches belongs in p6"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/221>: "effective o <http://tools.ietf.org/wg/httpbis/trac/ticket/221>: "effective
request URI: handling of missing host in HTTP/1.0" request URI: handling of missing host in HTTP/1.0"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/248>: "confusing o <http://tools.ietf.org/wg/httpbis/trac/ticket/248>: "confusing
Date requirements for clients" Date requirements for clients"
Partly resolved issues: Partly resolved issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/95>: "Handling o <http://tools.ietf.org/wg/httpbis/trac/ticket/95>: "Handling
multiple Content-Length headers" multiple Content-Length headers"
D.14. Since draft-ietf-httpbis-p1-messaging-12 C.14. Since draft-ietf-httpbis-p1-messaging-12
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/75>: "RFC2145 o <http://tools.ietf.org/wg/httpbis/trac/ticket/75>: "RFC2145
Normative" Normative"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/159>: "HTTP(s) URI o <http://tools.ietf.org/wg/httpbis/trac/ticket/159>: "HTTP(s) URI
scheme definitions" (tune the requirements on userinfo) scheme definitions" (tune the requirements on userinfo)
o <http://tools.ietf.org/wg/httpbis/trac/ticket/210>: "define o <http://tools.ietf.org/wg/httpbis/trac/ticket/210>: "define
skipping to change at page 91, line 11 skipping to change at page 90, line 11
o <http://tools.ietf.org/wg/httpbis/trac/ticket/240>: "Migrate o <http://tools.ietf.org/wg/httpbis/trac/ticket/240>: "Migrate
Upgrade details from RFC2817" Upgrade details from RFC2817"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle
ABNFs for header fields" ABNFs for header fields"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/279>: "update RFC o <http://tools.ietf.org/wg/httpbis/trac/ticket/279>: "update RFC
2109 reference" 2109 reference"
D.15. Since draft-ietf-httpbis-p1-messaging-13 C.15. Since draft-ietf-httpbis-p1-messaging-13
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/53>: "Allow is not o <http://tools.ietf.org/wg/httpbis/trac/ticket/53>: "Allow is not
in 13.5.2" in 13.5.2"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/95>: "Handling
multiple Content-Length headers"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle
ABNFs for header fields" ABNFs for header fields"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/286>: "Content- o <http://tools.ietf.org/wg/httpbis/trac/ticket/286>: "Content-
Length ABNF broken" Length ABNF broken"
D.16. Since draft-ietf-httpbis-p1-messaging-14 C.16. Since draft-ietf-httpbis-p1-messaging-14
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/273>: "HTTP-Version o <http://tools.ietf.org/wg/httpbis/trac/ticket/273>: "HTTP-Version
should be redefined as fixed length pair of DIGIT . DIGIT" should be redefined as fixed length pair of DIGIT . DIGIT"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/282>: "Recommend o <http://tools.ietf.org/wg/httpbis/trac/ticket/282>: "Recommend
minimum sizes for protocol elements" minimum sizes for protocol elements"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/283>: "Set o <http://tools.ietf.org/wg/httpbis/trac/ticket/283>: "Set
expectations around buffering" expectations around buffering"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/288>: "Considering o <http://tools.ietf.org/wg/httpbis/trac/ticket/288>: "Considering
messages in isolation" messages in isolation"
C.17. Since draft-ietf-httpbis-p1-messaging-15
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/100>: "DNS Spoofing
/ DNS Binding advice"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/254>: "move RFCs
2145, 2616, 2817 to Historic status"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/270>: "\-escaping in
quoted strings"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/305>: "'Close'
should be reserved in the HTTP header field registry"
Index Index
A A
absolute-URI form (of request-target) 29 absolute-URI form (of request-target) 30
accelerator 14 accelerator 13
application/http Media Type 64 application/http Media Type 66
asterisk form (of request-target) 29 asterisk form (of request-target) 30
authority form (of request-target) 30 authority form (of request-target) 31
B B
browser 10 browser 9
C C
cache 15 cache 14
cacheable 15 cacheable 14
captive portal 14 captive portal 14
chunked (Coding Format) 38 chunked (Coding Format) 39
client 10 client 9
Coding Format Coding Format
chunked 38 chunked 39
compress 41 compress 42
deflate 41 deflate 42
gzip 41 gzip 42
compress (Coding Format) 41 compress (Coding Format) 42
connection 10 connection 9
Connection header field 52 Connection header field 53
Content-Length header field 54 Content-Length header field 55
D D
Date header field 54 Date header field 55
deflate (Coding Format) 41 deflate (Coding Format) 42
downstream 13 downstream 12
E E
effective request URI 32 effective request URI 33
G G
gateway 14 gateway 13
Grammar Grammar
absolute-URI 18 absolute-URI 17
ALPHA 7 ALPHA 7
asctime-date 37 asctime-date 38
attribute 37 attribute 38
authority 18 authority 17
BWS 9 BWS 9
chunk 38 chunk 39
chunk-data 38 chunk-data 39
chunk-ext 38 chunk-ext 39
chunk-ext-name 38 chunk-ext-name 39
chunk-ext-val 38 chunk-ext-val 39
chunk-size 38 chunk-size 39
Chunked-Body 38 Chunked-Body 39
comment 24 comment 25
Connection 53 Connection 54
connection-token 53 connection-token 54
Content-Length 54 Content-Length 55
CR 7 CR 7
CRLF 7 CRLF 7
ctext 24 ctext 25
CTL 7 CTL 7
Date 54 Date 55
date1 36 date1 37
date2 37 date2 38
date3 37 date3 38
day 36 day 37
day-name 36 day-name 37
day-name-l 36 day-name-l 37
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
GMT 36 GMT 37
header-field 23 header-field 22
HEXDIG 7 HEXDIG 7
Host 56 Host 57
hour 36 hour 37
HTTP-date 35 HTTP-date 36
HTTP-message 21 HTTP-message 21
HTTP-Prot-Name 16 HTTP-Prot-Name 15
http-URI 18 http-URI 18
HTTP-Version 16 HTTP-Version 15
https-URI 20 https-URI 19
last-chunk 38 last-chunk 39
LF 7 LF 7
message-body 25 message-body 25
Method 29 Method 30
minute 36 minute 37
month 36 month 37
obs-date 36 obs-date 37
obs-text 10 obs-text 24
OCTET 7 OCTET 7
OWS 9 OWS 9
path-absolute 18 path-absolute 17
port 18 port 17
product 42 product 43
product-version 42 product-version 43
protocol-name 61 protocol-name 62
protocol-version 61 protocol-version 62
pseudonym 61 pseudonym 62
qdtext 10 qdtext 24
qdtext-nf 38 qdtext-nf 39
query 18 query 17
quoted-cpair 24 quoted-cpair 25
quoted-pair 10 quoted-pair 25
quoted-str-nf 38 quoted-str-nf 39
quoted-string 10 quoted-string 24
qvalue 42 qvalue 43
Reason-Phrase 34 Reason-Phrase 35
received-by 61 received-by 62
received-protocol 61 received-protocol 62
Request 29 Request 29
Request-Line 29 Request-Line 30
request-target 29 request-target 30
Response 33 Response 34
rfc850-date 37 rfc850-date 38
rfc1123-date 36 rfc1123-date 37
RWS 9 RWS 9
second 36 second 37
SP 7 SP 7
special 9 special 24
Status-Code 34 Status-Code 35
Status-Line 34 Status-Line 35
t-codings 57 t-codings 58
tchar 9 tchar 24
TE 57 TE 58
te-ext 57 te-ext 58
te-params 57 te-params 58
time-of-day 36 time-of-day 37
token 9 token 24
Trailer 58 Trailer 59
trailer-part 38 trailer-part 39
transfer-coding 37 transfer-coding 38
Transfer-Encoding 59 Transfer-Encoding 60
transfer-extension 37 transfer-extension 38
transfer-parameter 37 transfer-parameter 38
Upgrade 59 Upgrade 60
uri-host 18 uri-host 17
URI-reference 18 URI-reference 17
value 37 value 38
VCHAR 7 VCHAR 7
Via 61 Via 62
word 9 word 24
WSP 7 WSP 7
year 36 year 37
gzip (Coding Format) 41 gzip (Coding Format) 42
H H
header field 21 header field 20
Header Fields Header Fields
Connection 52 Connection 53
Content-Length 54 Content-Length 55
Date 54 Date 55
Host 56 Host 57
TE 57 TE 58
Trailer 58 Trailer 59
Transfer-Encoding 58 Transfer-Encoding 59
Upgrade 59 Upgrade 60
Via 61 Via 62
header section 21 header section 20
headers 21 headers 20
Host header field 56 Host header field 57
http URI scheme 18 http URI scheme 18
https URI scheme 20 https URI scheme 19
I I
inbound 13 inbound 12
interception proxy 14 interception proxy 14
intermediary 13 intermediary 12
M M
Media Type Media Type
application/http 64 application/http 66
message/http 63 message/http 64
message 11 message 10
message/http Media Type 63 message/http Media Type 64
N N
non-transforming proxy 13 non-transforming proxy 13
O O
origin form (of request-target) 30 origin form (of request-target) 31
origin server 10 origin server 9
outbound 13 outbound 12
P P
proxy 13 proxy 12
R R
recipient 10 recipient 9
request 11 request 10
resource 18 resource 17
response 11 response 10
reverse proxy 14 reverse proxy 13
S S
sender 10 sender 9
server 10 server 9
spider 10 spider 9
T T
target resource 32 target resource 33
TE header field 57 TE header field 58
Trailer header field 58 Trailer header field 59
Transfer-Encoding header field 58 Transfer-Encoding header field 59
transforming proxy 13 transforming proxy 13
transparent proxy 14 transparent proxy 14
tunnel 14 tunnel 13
U U
Upgrade header field 59 Upgrade header field 60
upstream 13 upstream 12
URI scheme URI scheme
http 18 http 18
https 20 https 19
user agent 10 user agent 9
V V
Via header field 61 Via header field 62
Authors' Addresses Authors' Addresses
Roy T. Fielding (editor) Roy T. Fielding (editor)
Adobe Systems Incorporated Adobe Systems Incorporated
345 Park Ave 345 Park Ave
San Jose, CA 95110 San Jose, CA 95110
USA USA
EMail: fielding@gbiv.com EMail: fielding@gbiv.com
 End of changes. 118 change blocks. 
537 lines changed or deleted 521 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/