< draft-ietf-httpbis-p1-messaging-08.txt   draft-ietf-httpbis-p1-messaging-09.txt >
HTTPbis Working Group R. Fielding, Ed. HTTPbis Working Group R. Fielding, Ed.
Internet-Draft Day Software Internet-Draft Day Software
Obsoletes: 2616 (if approved) J. Gettys Obsoletes: 2616 (if approved) J. Gettys
Updates: 2817 (if approved) One Laptop per Child Updates: 2817 (if approved) One Laptop per Child
Intended status: Standards Track J. Mogul Intended status: Standards Track J. Mogul
Expires: April 29, 2010 HP Expires: September 9, 2010 HP
H. Frystyk H. Frystyk
Microsoft Microsoft
L. Masinter L. Masinter
Adobe Systems Adobe Systems
P. Leach P. Leach
Microsoft Microsoft
T. Berners-Lee T. Berners-Lee
W3C/MIT W3C/MIT
Y. Lafon, Ed. Y. Lafon, Ed.
W3C W3C
J. Reschke, Ed. J. Reschke, Ed.
greenbytes greenbytes
October 26, 2009 March 8, 2010
HTTP/1.1, part 1: URIs, Connections, and Message Parsing HTTP/1.1, part 1: URIs, Connections, and Message Parsing
draft-ietf-httpbis-p1-messaging-08 draft-ietf-httpbis-p1-messaging-09
Status of this Memo Abstract
The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypertext information
systems. HTTP has been in use by the World Wide Web global
information initiative since 1990. This document is Part 1 of the
seven-part specification that defines the protocol referred to as
"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides
an overview of HTTP and its associated terminology, 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.
Editorial Note (To be removed by RFC Editor)
Discussion of this draft should take place on the HTTPBIS working
group mailing list (ietf-http-wg@w3.org). The current issues list is
at <http://tools.ietf.org/wg/httpbis/trac/report/11> and related
documents (including fancy diffs) can be found at
<http://tools.ietf.org/wg/httpbis/>.
The changes in this draft are summarized in Appendix D.10.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79.
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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."
skipping to change at page 2, line 4 skipping to change at page 2, line 16
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 29, 2010. This Internet-Draft will expire on September 9, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
The Hypertext Transfer Protocol (HTTP) is an application-level described in the BSD License.
protocol for distributed, collaborative, hypertext information
systems. HTTP has been in use by the World Wide Web global
information initiative since 1990. This document is Part 1 of the
seven-part specification that defines the protocol referred to as
"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides
an overview of HTTP and its associated terminology, 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.
Editorial Note (To be removed by RFC Editor)
Discussion of this draft should take place on the HTTPBIS working
group mailing list (ietf-http-wg@w3.org). The current issues list is
at <http://tools.ietf.org/wg/httpbis/trac/report/11> and related
documents (including fancy diffs) can be found at
<http://tools.ietf.org/wg/httpbis/>.
The changes in this draft are summarized in Appendix D.9. This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
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
1.2.3. ABNF Rules defined in other Parts of the 1.2.3. ABNF Rules defined in other Parts of the
Specification . . . . . . . . . . . . . . . . . . . . 9 Specification . . . . . . . . . . . . . . . . . . . . 10
2. HTTP architecture . . . . . . . . . . . . . . . . . . . . . . 10 2. HTTP architecture . . . . . . . . . . . . . . . . . . . . . . 10
2.1. Client/Server Operation . . . . . . . . . . . . . . . . . 10 2.1. Client/Server Operation . . . . . . . . . . . . . . . . . 10
2.2. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 11 2.2. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 12
2.3. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.3. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4. Transport Independence . . . . . . . . . . . . . . . . . . 13 2.4. Transport Independence . . . . . . . . . . . . . . . . . . 14
2.5. HTTP Version . . . . . . . . . . . . . . . . . . . . . . . 14 2.5. HTTP Version . . . . . . . . . . . . . . . . . . . . . . . 14
2.6. Uniform Resource Identifiers . . . . . . . . . . . . . . . 15 2.6. Uniform Resource Identifiers . . . . . . . . . . . . . . . 16
2.6.1. http URI scheme . . . . . . . . . . . . . . . . . . . 16 2.6.1. http URI scheme . . . . . . . . . . . . . . . . . . . 16
2.6.2. https URI scheme . . . . . . . . . . . . . . . . . . . 17 2.6.2. https URI scheme . . . . . . . . . . . . . . . . . . . 17
2.6.3. http and https URI Normalization and Comparison . . . 17 2.6.3. http and https URI Normalization and Comparison . . . 18
3. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . . 18 3. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1. Message Parsing Robustness . . . . . . . . . . . . . . . . 19 3.1. Message Parsing Robustness . . . . . . . . . . . . . . . . 19
3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 19 3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 20
3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 21 3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 22
3.4. Message Length . . . . . . . . . . . . . . . . . . . . . . 22 3.4. Message Length . . . . . . . . . . . . . . . . . . . . . . 23
3.5. General Header Fields . . . . . . . . . . . . . . . . . . 23 3.5. General Header Fields . . . . . . . . . . . . . . . . . . 24
4. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 24 4.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 25
4.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 24 4.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 25
4.1.2. request-target . . . . . . . . . . . . . . . . . . . . 24 4.1.2. request-target . . . . . . . . . . . . . . . . . . . . 25
4.2. The Resource Identified by a Request . . . . . . . . . . . 26 4.2. The Resource Identified by a Request . . . . . . . . . . . 27
5. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 5. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 27 5.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 28
5.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 28 5.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 28
6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 28 6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 29
6.1. Date/Time Formats: Full Date . . . . . . . . . . . . . . . 28 6.1. Date/Time Formats: Full Date . . . . . . . . . . . . . . . 29
6.2. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 31 6.2. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 31
6.2.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 32 6.2.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 32
6.2.2. Compression Codings . . . . . . . . . . . . . . . . . 34 6.2.2. Compression Codings . . . . . . . . . . . . . . . . . 34
6.2.3. Transfer Coding Registry . . . . . . . . . . . . . . . 35 6.2.3. Transfer Coding Registry . . . . . . . . . . . . . . . 35
6.3. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 35 6.3. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 35
6.4. Quality Values . . . . . . . . . . . . . . . . . . . . . . 36 6.4. Quality Values . . . . . . . . . . . . . . . . . . . . . . 36
7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 36 7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 36
7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 36 7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 36
7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 36 7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 36
7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 37 7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 37
7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 38 7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 38
7.1.4. Practical Considerations . . . . . . . . . . . . . . . 39 7.1.4. Practical Considerations . . . . . . . . . . . . . . . 41
7.2. Message Transmission Requirements . . . . . . . . . . . . 40 7.2. Message Transmission Requirements . . . . . . . . . . . . 42
7.2.1. Persistent Connections and Flow Control . . . . . . . 40 7.2.1. Persistent Connections and Flow Control . . . . . . . 42
7.2.2. Monitoring Connections for Error Status Messages . . . 40 7.2.2. Monitoring Connections for Error Status Messages . . . 42
7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 40 7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 42
7.2.4. Client Behavior if Server Prematurely Closes 7.2.4. Client Behavior if Server Prematurely Closes
Connection . . . . . . . . . . . . . . . . . . . . . . 42 Connection . . . . . . . . . . . . . . . . . . . . . . 44
8. Miscellaneous notes that may disappear . . . . . . . . . . . . 43 8. Miscellaneous notes that may disappear . . . . . . . . . . . . 45
8.1. Scheme aliases considered harmful . . . . . . . . . . . . 43 8.1. Scheme aliases considered harmful . . . . . . . . . . . . 45
8.2. Use of HTTP for proxy communication . . . . . . . . . . . 43 8.2. Use of HTTP for proxy communication . . . . . . . . . . . 45
8.3. Interception of HTTP for access control . . . . . . . . . 43 8.3. Interception of HTTP for access control . . . . . . . . . 46
8.4. Use of HTTP by other protocols . . . . . . . . . . . . . . 44 8.4. Use of HTTP by other protocols . . . . . . . . . . . . . . 46
8.5. Use of HTTP by media type specification . . . . . . . . . 44 8.5. Use of HTTP by media type specification . . . . . . . . . 46
9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 44 9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 46
9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 44 9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 46
9.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 45 9.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 47
9.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 9.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
9.3.1. Clockless Origin Server Operation . . . . . . . . . . 47 9.3.1. Clockless Origin Server Operation . . . . . . . . . . 49
9.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 9.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
9.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 9.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
9.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 49 9.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 51
9.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 49 9.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 52
9.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 50 9.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 52
9.8.1. Upgrade Token Registry . . . . . . . . . . . . . . . . 51 9.8.1. Upgrade Token Registry . . . . . . . . . . . . . . . . 53
9.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 9.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56
10.1. Message Header Registration . . . . . . . . . . . . . . . 53 10.1. Message Header Registration . . . . . . . . . . . . . . . 56
10.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 54 10.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 56
10.3. Internet Media Type Registrations . . . . . . . . . . . . 54 10.3. Internet Media Type Registrations . . . . . . . . . . . . 56
10.3.1. Internet Media Type message/http . . . . . . . . . . . 54 10.3.1. Internet Media Type message/http . . . . . . . . . . . 56
10.3.2. Internet Media Type application/http . . . . . . . . . 55 10.3.2. Internet Media Type application/http . . . . . . . . . 58
10.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 56 10.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 59
10.5. Upgrade Token Registration . . . . . . . . . . . . . . . . 57 10.5. Upgrade Token Registration . . . . . . . . . . . . . . . . 59
11. Security Considerations . . . . . . . . . . . . . . . . . . . 57 11. Security Considerations . . . . . . . . . . . . . . . . . . . 59
11.1. Personal Information . . . . . . . . . . . . . . . . . . . 57 11.1. Personal Information . . . . . . . . . . . . . . . . . . . 60
11.2. Abuse of Server Log Information . . . . . . . . . . . . . 58 11.2. Abuse of Server Log Information . . . . . . . . . . . . . 60
11.3. Attacks Based On File and Path Names . . . . . . . . . . . 58 11.3. Attacks Based On File and Path Names . . . . . . . . . . . 60
11.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 58 11.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 60
11.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 59 11.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 61
11.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 60 11.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 62
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 60 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 62
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 61 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 63
13.1. Normative References . . . . . . . . . . . . . . . . . . . 61 13.1. Normative References . . . . . . . . . . . . . . . . . . . 63
13.2. Informative References . . . . . . . . . . . . . . . . . . 62 13.2. Informative References . . . . . . . . . . . . . . . . . . 65
Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 64 Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 67
Appendix B. Compatibility with Previous Versions . . . . . . . . 65 Appendix B. Compatibility with Previous Versions . . . . . . . . 67
B.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 66 B.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 68
B.1.1. Changes to Simplify Multi-homed Web Servers and B.1.1. Changes to Simplify Multi-homed Web Servers and
Conserve IP Addresses . . . . . . . . . . . . . . . . 66 Conserve IP Addresses . . . . . . . . . . . . . . . . 68
B.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 67 B.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 69
B.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 67 B.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 70
B.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 68 B.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 70
Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 69 Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 71
Appendix D. Change Log (to be removed by RFC Editor before Appendix D. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 73 publication) . . . . . . . . . . . . . . . . . . . . 76
D.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 73 D.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 76
D.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 73 D.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 76
D.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 75 D.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 77
D.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 76 D.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 78
D.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 76 D.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 79
D.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 77 D.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 79
D.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 77 D.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 80
D.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 78 D.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 81
D.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 79 D.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 81
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 D.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 82
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 84 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 86
1. Introduction 1. Introduction
The Hypertext Transfer Protocol (HTTP) is an application-level The Hypertext Transfer Protocol (HTTP) is an application-level
request/response protocol that uses extensible semantics and MIME- request/response protocol that uses extensible semantics and MIME-
like message payloads for flexible interaction with network-based like message payloads for flexible interaction with network-based
hypertext information systems. HTTP relies upon the Uniform Resource hypertext information systems. HTTP relies upon the Uniform Resource
Identifier (URI) standard [RFC3986] to indicate request targets and Identifier (URI) standard [RFC3986] to indicate request targets and
relationships between resources. Messages are passed in a format relationships between resources. Messages are passed in a format
similar to that used by Internet mail [RFC5322] and the Multipurpose similar to that used by Internet mail [RFC5322] and the Multipurpose
skipping to change at page 7, line 33 skipping to change at page 7, line 33
This specification uses the Augmented Backus-Naur Form (ABNF) This specification uses the Augmented Backus-Naur Form (ABNF)
notation of [RFC5234]. notation of [RFC5234].
The following core rules are included by reference, as defined in The following core rules are included by reference, as defined in
[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
(CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit
sequence of data), SP (space), VCHAR (any visible [USASCII] sequence of data), SP (space), VCHAR (any visible [USASCII]
character), and WSP (whitespace). character), and WSP (whitespace).
As a syntactical convention, ABNF rule names prefixed with "obs-"
denote "obsolete" grammar rules that appear for historical reasons.
1.2.1. ABNF Extension: #rule 1.2.1. ABNF Extension: #rule
One extension to the ABNF rules of [RFC5234] is used to improve The #rule extension to the ABNF rules of [RFC5234] is used to improve
readability. readability.
A construct "#" is defined, similar to "*", for defining lists of A construct "#" is defined, similar to "*", for defining comma-
elements. The full form is "<n>#<m>element" indicating at least <n> delimited lists of elements. The full form is "<n>#<m>element"
and at most <m> elements, each separated by a single comma (",") and indicating at least <n> and at most <m> elements, each separated by a
optional whitespace (OWS). single comma (",") and optional whitespace (OWS, Section 1.2.2).
Thus, Thus,
1#element => element *( OWS "," OWS element ) 1#element => element *( OWS "," OWS element )
and: and:
#element => [ 1#element ] #element => [ 1#element ]
and for n >= 1 and m > 1: and for n >= 1 and m > 1:
skipping to change at page 8, line 17 skipping to change at page 8, line 21
<n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element ) <n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element )
For compatibility with legacy list rules, recipients SHOULD accept For compatibility with legacy list rules, recipients SHOULD accept
empty list elements. In other words, consumers would follow the list empty list elements. In other words, consumers would follow the list
productions: productions:
#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
present, though.
For example, given these ABNF productions:
example-list = 1#example-list-elmt
example-list-elmt = token ; see Section 1.2.2
Then these are valid values for example-list (not including the
double quotes, which are present for delimitation only):
"foo,bar"
" foo ,bar,"
" foo , ,bar,charlie "
"foo ,bar, charlie "
But these values would be invalid, as at least one non-empty element
is required:
""
","
", ,"
Appendix C shows the collected ABNF, with the list rules expanded as Appendix C shows the collected ABNF, with the list rules expanded as
explained above. explained above.
1.2.2. Basic Rules 1.2.2. Basic Rules
HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all
protocol elements except the entity-body (see Appendix A for tolerant protocol elements except the entity-body (see Appendix A for tolerant
applications). The end-of-line marker within an entity-body is applications). The end-of-line marker within an entity-body is
defined by its associated media type, as described in Section 2.3 of defined by its associated media type, as described in Section 2.3 of
[Part3]. [Part3].
This specification uses three rules to denote the use of linear This specification uses three rules to denote the use of linear
whitespace: OWS (optional whitespace), RWS (required whitespace), and whitespace: OWS (optional whitespace), RWS (required whitespace), and
BWS ("bad" whitespace). BWS ("bad" whitespace).
The OWS rule is used where zero or more linear whitespace characters The OWS rule is used where zero or more linear whitespace characters
may appear. OWS SHOULD either not be produced or be produced as a may appear. OWS SHOULD either not be produced or be produced as a
single SP character. Multiple OWS characters that occur within single SP character. Multiple OWS characters that occur within
field-content SHOULD be replaced with a single SP before interpreting field-content SHOULD be replaced with a single SP before interpreting
skipping to change at page 9, line 14 skipping to change at page 9, line 38
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 separated by Many HTTP/1.1 header field values consist of words (token or quoted-
whitespace or special characters. These special characters MUST be string) separated by whitespace or special characters. These special
in a quoted string to be used within a parameter value (as defined in characters MUST be in a quoted string to be used within a parameter
Section 6.2). value (as defined in Section 6.2).
token = 1*tchar
tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*"
/ "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
/ DIGIT / ALPHA / DIGIT / ALPHA
; any VCHAR, except special
token = 1*tchar special = "(" / ")" / "<" / ">" / "@" / ","
/ ";" / ":" / "\" / DQUOTE / "/" / "["
/ "]" / "?" / "=" / "{" / "}"
A string of text is parsed as a single word if it is quoted using A string of text is parsed as a single word if it is quoted using
double-quote marks. double-quote marks.
quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
qdtext = OWS / %x21 / %x23-5B / %x5D-7E / obs-text qdtext = OWS / %x21 / %x23-5B / %x5D-7E / obs-text
; OWS / <VCHAR except DQUOTE and "\"> / obs-text ; OWS / <VCHAR except DQUOTE and "\"> / obs-text
obs-text = %x80-FF obs-text = %x80-FF
The backslash character ("\") can be used as a single-character The backslash character ("\") can be used as a single-character
skipping to change at page 18, line 11 skipping to change at page 18, line 45
than those in the "reserved" set are equivalent to their percent- than those in the "reserved" set are equivalent to their percent-
encoded octets (see [RFC3986], Section 2.1): the normal form is to encoded octets (see [RFC3986], Section 2.1): the normal form is to
not encode them. not encode them.
For example, the following three URIs are equivalent: For example, the following three URIs are equivalent:
http://example.com:80/~smith/home.html http://example.com:80/~smith/home.html
http://EXAMPLE.com/%7Esmith/home.html http://EXAMPLE.com/%7Esmith/home.html
http://EXAMPLE.com:/%7esmith/home.html http://EXAMPLE.com:/%7esmith/home.html
[[anchor1: [[This paragraph does not belong here. --Roy]]]] If path- [[TODO-not-here: This paragraph does not belong here. --roy]] If
abempty is the empty string (i.e., there is no slash "/" path path-abempty is the empty string (i.e., there is no slash "/" path
separator following the authority), then the "http" URI MUST be given separator following the authority), then the "http" URI MUST be given
as "/" when used as a request-target (Section 4.1.2). If a proxy as "/" when used as a request-target (Section 4.1.2). If a proxy
receives a host name which is not a fully qualified domain name, it receives a host name which is not a fully qualified domain name, it
MAY add its domain to the host name it received. If a proxy receives MAY add its domain to the host name it received. If a proxy receives
a fully qualified domain name, the proxy MUST NOT change the host a fully qualified domain name, the proxy MUST NOT change the host
name. name.
3. HTTP Message 3. HTTP Message
All HTTP/1.1 messages consist of a start-line followed by a sequence All HTTP/1.1 messages consist of a start-line followed by a sequence
skipping to change at page 20, line 4 skipping to change at page 20, line 40
No whitespace is allowed between the header field name and colon. No whitespace is allowed between the header field name and colon.
For security reasons, any request message received containing such For security reasons, any request message received containing such
whitespace MUST be rejected with a response code of 400 (Bad whitespace MUST be rejected with a response code of 400 (Bad
Request). A proxy MUST remove any such whitespace from a response Request). A proxy MUST remove any such whitespace from a response
message before forwarding the message downstream. message before forwarding the message downstream.
A field value MAY be preceded by optional whitespace (OWS); a single A field value MAY be preceded by optional whitespace (OWS); a single
SP is preferred. The field value does not include any leading or SP is preferred. The field value does not include any leading or
trailing white space: OWS occurring before the first non-whitespace trailing white space: OWS occurring before the first non-whitespace
character of the field value or after the last non-whitespace character of the field value or after the last non-whitespace
character of the field value is ignored and SHOULD be removed without character of the field value is ignored and SHOULD be removed before
changing the meaning of the header field. further processing (as this does not change the meaning of the header
field).
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 20, line 28 skipping to change at page 21, line 17
message unless the entire field value for that header field is message unless the entire field value for that header field is
defined as a comma-separated list [i.e., #(values)]. Multiple header defined as a comma-separated list [i.e., #(values)]. Multiple header
fields with the same field name can be combined into one "field-name: fields with the same field name can be combined into one "field-name:
field-value" pair, without changing the semantics of the message, by field-value" pair, without changing the semantics of the message, by
appending each subsequent field value to the combined field value in appending each subsequent field value to the combined field value in
order, separated by a comma. The order in which header fields with order, separated by a comma. The order in which header fields with
the same field name are received is therefore significant to the the same field name are received is therefore significant to the
interpretation of the combined field value; a proxy MUST NOT change interpretation of the combined field value; a proxy MUST NOT change
the order of these field values when forwarding a message. the order of these field values when forwarding a message.
Note: the "Set-Cookie" header as implemented in practice (as Note: The "Set-Cookie" header as implemented in practice (as
opposed to how it is specified in [RFC2109]) can occur multiple opposed to how it is specified in [RFC2109]) can occur multiple
times, but does not use the list syntax, and thus cannot be times, but does not use the list syntax, and thus cannot be
combined into a single line. (See Appendix A.2.3 of [Kri2001] for combined into a single line. (See Appendix A.2.3 of [Kri2001] for
details.) Also note that the Set-Cookie2 header specified in details.) Also note that the Set-Cookie2 header specified in
[RFC2965] does not share this problem. [RFC2965] does not share this problem.
Historically, HTTP header field values could be extended over Historically, HTTP header field values could be extended over
multiple lines by preceding each extra line with at least one space multiple lines by preceding each extra line with at least one space
or horizontal tab character (line folding). This specification or horizontal tab character (line folding). This specification
deprecates such line folding except within the message/http media deprecates such line folding except within the message/http media
skipping to change at page 22, line 12 skipping to change at page 22, line 50
either ignore the message-body or respond with an appropriate error either ignore the message-body or respond with an appropriate error
message (e.g., 413). A proxy or gateway, when presented the same message (e.g., 413). A proxy or gateway, when presented the same
request, SHOULD either forward the request inbound with the message- request, SHOULD either forward the request inbound with the message-
body or ignore the message-body when determining a response. body or ignore the message-body when determining a response.
For response messages, whether or not a message-body is included with For response messages, whether or not a message-body is included with
a message is dependent on both the request method and the response a message is dependent on both the request method and the response
status code (Section 5.1.1). All responses to the HEAD request status code (Section 5.1.1). All responses to the HEAD request
method MUST NOT include a message-body, even though the presence of method MUST NOT include a message-body, even though the presence of
entity-header fields might lead one to believe they do. All 1xx entity-header fields might lead one to believe they do. All 1xx
(informational), 204 (No Content), and 304 (Not Modified) responses (Informational), 204 (No Content), and 304 (Not Modified) responses
MUST NOT include a message-body. All other responses do include a MUST NOT include a message-body. All other responses do include a
message-body, although it MAY be of zero length. message-body, although it MAY be of zero length.
3.4. Message Length 3.4. Message Length
The transfer-length of a message is the length of the message-body as The transfer-length of a message is the length of the message-body as
it appears in the message; that is, after any transfer-codings have it appears in the message; that is, after any transfer-codings have
been applied. When a message-body is included with a message, the been applied. When a message-body is included with a message, the
transfer-length of that body is determined by one of the following transfer-length of that body is determined by one of the following
(in order of precedence): (in order of precedence):
skipping to change at page 22, line 50 skipping to change at page 23, line 39
sent if these two lengths are different (i.e., if a Transfer- sent if these two lengths are different (i.e., if a Transfer-
Encoding header field is present). If a message is received with Encoding header field is present). If a message is received with
both a Transfer-Encoding header field and a Content-Length header both a Transfer-Encoding header field and a Content-Length header
field, the latter MUST be ignored. field, the latter MUST be ignored.
4. If the message uses the media type "multipart/byteranges", and 4. If the message uses the media type "multipart/byteranges", and
the transfer-length is not otherwise specified, then this self- the transfer-length is not otherwise specified, then this self-
delimiting media type defines the transfer-length. This media delimiting media type defines the transfer-length. This media
type MUST NOT be used unless the sender knows that the recipient type MUST NOT be used unless the sender knows that the recipient
can parse it; the presence in a request of a Range header with can parse it; the presence in a request of a Range header with
multiple byte-range specifiers from a 1.1 client implies that the multiple byte-range specifiers from a HTTP/1.1 client implies
client can parse multipart/byteranges responses. that the client can parse multipart/byteranges responses.
A range header might be forwarded by a 1.0 proxy that does not A range header might be forwarded by a HTTP/1.0 proxy that
understand multipart/byteranges; in this case the server MUST does not understand multipart/byteranges; in this case the
delimit the message using methods defined in items 1, 3 or 5 server MUST delimit the message using methods defined in items
of this section. 1, 3 or 5 of this section.
5. By the server closing the connection. (Closing the connection 5. By the server closing the connection. (Closing the connection
cannot be used to indicate the end of a request body, since that cannot be used to indicate the end of a request body, since that
would leave no possibility for the server to send back a would leave no possibility for the server to send back a
response.) response.)
For compatibility with HTTP/1.0 applications, HTTP/1.1 requests For compatibility with HTTP/1.0 applications, HTTP/1.1 requests
containing a message-body MUST include a valid Content-Length header containing a message-body MUST include a valid Content-Length header
field unless the server is known to be HTTP/1.1 compliant. If a field unless the server is known to be HTTP/1.1 compliant. If a
request contains a message-body and a Content-Length is not given, request contains a message-body and a Content-Length is not given,
skipping to change at page 36, line 20 skipping to change at page 36, line 20
version portion of the product value). version portion of the product value).
6.4. Quality Values 6.4. Quality Values
Both transfer codings (TE request header, Section 9.5) and content Both transfer codings (TE request header, Section 9.5) and content
negotiation (Section 4 of [Part3]) use short "floating point" numbers negotiation (Section 4 of [Part3]) use short "floating point" numbers
to indicate the relative importance ("weight") of various negotiable to indicate the relative importance ("weight") of various negotiable
parameters. A weight is normalized to a real number in the range 0 parameters. A weight is normalized to a real number in the range 0
through 1, where 0 is the minimum and 1 the maximum value. If a through 1, where 0 is the minimum and 1 the maximum value. If a
parameter has a quality value of 0, then content with this parameter parameter has a quality value of 0, then content with this parameter
is `not acceptable' for the client. HTTP/1.1 applications MUST NOT is "not acceptable" for the client. HTTP/1.1 applications MUST NOT
generate more than three digits after the decimal point. User generate more than three digits after the decimal point. User
configuration of these values SHOULD also be limited in this fashion. configuration of these values SHOULD also be limited in this fashion.
qvalue = ( "0" [ "." 0*3DIGIT ] ) qvalue = ( "0" [ "." 0*3DIGIT ] )
/ ( "1" [ "." 0*3("0") ] ) / ( "1" [ "." 0*3("0") ] )
Note: "Quality values" is a misnomer, since these values merely Note: "Quality values" is a misnomer, since these values merely
represent relative degradation in desired quality. represent relative degradation in desired quality.
7. Connections 7. Connections
7.1. Persistent Connections 7.1. Persistent Connections
7.1.1. Purpose 7.1.1. Purpose
Prior to persistent connections, a separate TCP connection was Prior to persistent connections, a separate TCP connection was
established to fetch each URL, increasing the load on HTTP servers established to fetch each URL, increasing the load on HTTP servers
and causing congestion on the Internet. The use of inline images and and causing congestion on the Internet. The use of inline images and
other associated data often require a client to make multiple other associated data often requires a client to make multiple
requests of the same server in a short amount of time. Analysis of requests of the same server in a short amount of time. Analysis of
these performance problems and results from a prototype these performance problems and results from a prototype
implementation are available [Pad1995] [Spe]. Implementation implementation are available [Pad1995] [Spe]. Implementation
experience and measurements of actual HTTP/1.1 implementations show experience and measurements of actual HTTP/1.1 implementations show
good results [Nie1997]. Alternatives have also been explored, for good results [Nie1997]. Alternatives have also been explored, for
example, T/TCP [Tou1998]. example, T/TCP [Tou1998].
Persistent HTTP connections have a number of advantages: Persistent HTTP connections have a number of advantages:
o By opening and closing fewer TCP connections, CPU time is saved in o By opening and closing fewer TCP connections, CPU time is saved in
skipping to change at page 37, line 47 skipping to change at page 37, line 47
close has been signaled, the client MUST NOT send any more requests close has been signaled, the client MUST NOT send any more requests
on that connection. on that connection.
7.1.2.1. Negotiation 7.1.2.1. Negotiation
An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to
maintain a persistent connection unless a Connection header including maintain a persistent connection unless a Connection header including
the connection-token "close" was sent in the request. If the server the connection-token "close" was sent in the request. If the server
chooses to close the connection immediately after sending the chooses to close the connection immediately after sending the
response, it SHOULD send a Connection header including the response, it SHOULD send a Connection header including the
connection-token close. connection-token "close".
An HTTP/1.1 client MAY expect a connection to remain open, but would An HTTP/1.1 client MAY expect a connection to remain open, but would
decide to keep it open based on whether the response from a server decide to keep it open based on whether the response from a server
contains a Connection header with the connection-token close. In contains a Connection header with the connection-token close. In
case the client does not want to maintain a connection for more than case the client does not want to maintain a connection for more than
that request, it SHOULD send a Connection header including the that request, it SHOULD send a Connection header including the
connection-token close. 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, that request becomes the last one for the Connection header, that request becomes the last one for the
skipping to change at page 39, line 11 skipping to change at page 39, line 11
The proxy server MUST signal persistent connections separately with The proxy server MUST signal persistent connections separately with
its clients and the origin servers (or other proxy servers) that it its clients and the origin servers (or other proxy servers) that it
connects to. Each persistent connection applies to only one connects to. Each persistent connection applies to only one
transport link. transport link.
A proxy server MUST NOT establish a HTTP/1.1 persistent connection A proxy server MUST NOT establish a HTTP/1.1 persistent connection
with an HTTP/1.0 client (but see Section 19.7.1 of [RFC2068] for with an HTTP/1.0 client (but see Section 19.7.1 of [RFC2068] for
information and discussion of the problems with the Keep-Alive header information and discussion of the problems with the Keep-Alive header
implemented by many HTTP/1.0 clients). implemented by many HTTP/1.0 clients).
7.1.3.1. End-to-end and Hop-by-hop Headers
[[TODO-end-to-end: Restored from <http://tools.ietf.org/html/
draft-ietf-httpbis-p6-cache-05#section-7.1>. See also
<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/60>. --jre]]
For the purpose of defining the behavior of caches and non-caching
proxies, we divide HTTP headers into two categories:
o End-to-end headers, which are transmitted to the ultimate
recipient of a request or response. End-to-end headers in
responses MUST be stored as part of a cache entry and MUST be
transmitted in any response formed from a cache entry.
o Hop-by-hop headers, which are meaningful only for a single
transport-level connection, and are not stored by caches or
forwarded by proxies.
The following HTTP/1.1 headers are hop-by-hop headers:
o Connection
o Keep-Alive
o Proxy-Authenticate
o Proxy-Authorization
o TE
o Trailer
o Transfer-Encoding
o Upgrade
All other headers defined by HTTP/1.1 are end-to-end headers.
Other hop-by-hop headers MUST be listed in a Connection header
(Section 9.1).
7.1.3.2. Non-modifiable Headers
[[TODO-non-mod-headers: Restored from <http://tools.ietf.org/html/
draft-ietf-httpbis-p6-cache-05#section-7.2>. See also
<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/60>. --jre]]
Some features of HTTP/1.1, such as Digest Authentication, depend on
the value of certain end-to-end headers. A transparent proxy SHOULD
NOT modify an end-to-end header unless the definition of that header
requires or specifically allows that.
A transparent proxy MUST NOT modify any of the following fields in a
request or response, and it MUST NOT add any of these fields if not
already present:
o Content-Location
o Content-MD5
o ETag
o Last-Modified
A transparent proxy MUST NOT modify any of the following fields in a
response:
o Expires
but it MAY add any of these fields if not already present. If an
Expires header is added, it MUST be given a field-value identical to
that of the Date header in that response.
A proxy MUST NOT modify or add any of the following fields in a
message that contains the no-transform cache-control directive, or in
any request:
o Content-Encoding
o Content-Range
o Content-Type
A non-transparent proxy MAY modify or add these fields to a message
that does not include no-transform, but if it does so, it MUST add a
Warning 214 (Transformation applied) if one does not already appear
in the message (see Section 3.6 of [Part6]).
Warning: Unnecessary modification of end-to-end headers might
cause authentication failures if stronger authentication
mechanisms are introduced in later versions of HTTP. Such
authentication mechanisms MAY rely on the values of header fields
not listed here.
The Content-Length field of a request or response is added or deleted
according to the rules in Section 3.4. A transparent proxy MUST
preserve the entity-length (Section 3.2.2 of [Part3]) of the entity-
body, although it MAY change the transfer-length (Section 3.4).
7.1.4. Practical Considerations 7.1.4. Practical Considerations
Servers will usually have some time-out value beyond which they will Servers will usually have some time-out value beyond which they will
no longer maintain an inactive connection. Proxy servers might make no longer maintain an inactive connection. Proxy servers might make
this a higher value since it is likely that the client will be making this a higher value since it is likely that the client will be making
more connections through the same server. The use of persistent more connections through the same server. The use of persistent
connections places no requirements on the length (or existence) of connections places no requirements on the length (or existence) of
this time-out for either the client or the server. this time-out for either the client or the server.
When a client or server wishes to time-out it SHOULD issue a graceful When a client or server wishes to time-out it SHOULD issue a graceful
skipping to change at page 43, line 39 skipping to change at page 45, line 43
o SHOULD NOT continue and o SHOULD NOT continue and
o SHOULD close the connection if it has not completed sending the o SHOULD close the connection if it has not completed sending the
request message. request message.
8. Miscellaneous notes that may disappear 8. Miscellaneous notes that may disappear
8.1. Scheme aliases considered harmful 8.1. Scheme aliases considered harmful
[[anchor2: TBS: describe why aliases like webcal are harmful.]] [[TBD-aliases-harmful: describe why aliases like webcal are
harmful.]]
8.2. Use of HTTP for proxy communication 8.2. Use of HTTP for proxy communication
[[anchor3: TBD: Configured to use HTTP to proxy HTTP or other [[TBD-proxy-other: Configured to use HTTP to proxy HTTP or other
protocols.]] protocols.]]
8.3. Interception of HTTP for access control 8.3. Interception of HTTP for access control
[[anchor4: TBD: Interception of HTTP traffic for initiating access [[TBD-intercept: Interception of HTTP traffic for initiating access
control.]] control.]]
8.4. Use of HTTP by other protocols 8.4. Use of HTTP by other protocols
[[anchor5: TBD: Profiles of HTTP defined by other protocol. [[TBD-profiles: Profiles of HTTP defined by other protocol.
Extensions of HTTP like WebDAV.]] Extensions of HTTP like WebDAV.]]
8.5. Use of HTTP by media type specification 8.5. Use of HTTP by media type specification
[[anchor6: TBD: Instructions on composing HTTP requests via hypertext [[TBD-hypertext: Instructions on composing HTTP requests via
formats.]] hypertext formats.]]
9. Header Field Definitions 9. Header Field Definitions
This section defines the syntax and semantics of HTTP/1.1 header This section defines the syntax and semantics of HTTP/1.1 header
fields related to message framing and transport protocols. fields related to message framing and transport protocols.
For entity-header fields, both sender and recipient refer to either For entity-header fields, both sender and recipient refer to either
the client or the server, depending on who sends and who receives the the client or the server, depending on who sends and who receives the
entity. entity.
skipping to change at page 45, line 4 skipping to change at page 47, line 8
corresponding additional header field(s), since the additional header corresponding additional header field(s), since the additional header
field may not be sent if there are no parameters associated with that field may not be sent if there are no parameters associated with that
connection option. connection option.
Message headers listed in the Connection header MUST NOT include end- Message headers listed in the Connection header MUST NOT include end-
to-end headers, such as Cache-Control. to-end headers, such as Cache-Control.
HTTP/1.1 defines the "close" connection option for the sender to HTTP/1.1 defines the "close" connection option for the sender to
signal that the connection will be closed after completion of the signal that the connection will be closed after completion of the
response. For example, response. For example,
Connection: close Connection: close
in either the request or the response header fields indicates that in either the request or the response header fields indicates that
the connection SHOULD NOT be considered `persistent' (Section 7.1) the connection SHOULD NOT be considered "persistent" (Section 7.1)
after the current request/response is complete. after the current request/response is complete.
An HTTP/1.1 client that does not support persistent connections MUST An HTTP/1.1 client that does not support persistent connections MUST
include the "close" connection option in every request message. include the "close" connection option in every request message.
An HTTP/1.1 server that does not support persistent connections MUST An HTTP/1.1 server that does not support persistent connections MUST
include the "close" connection option in every response message that include the "close" connection option in every response message that
does not have a 1xx (informational) status code. does not have a 1xx (Informational) status code.
A system receiving an HTTP/1.0 (or lower-version) message that A system receiving an HTTP/1.0 (or lower-version) message that
includes a Connection header MUST, for each connection-token in this includes a Connection header MUST, for each connection-token in this
field, remove and ignore any header field(s) from the message with field, remove and ignore any header field(s) from the message with
the same name as the connection-token. This protects against the same name as the connection-token. This protects against
mistaken forwarding of such header fields by pre-HTTP/1.1 proxies. mistaken forwarding of such header fields by pre-HTTP/1.1 proxies.
See Appendix B.2. See Appendix B.2.
9.2. Content-Length 9.2. Content-Length
skipping to change at page 46, line 8 skipping to change at page 48, line 12
Note that the meaning of this field is significantly different from Note that the meaning of this field is significantly different from
the corresponding definition in MIME, where it is an optional field the corresponding definition in MIME, where it is an optional field
used within the "message/external-body" content-type. In HTTP, it used within the "message/external-body" content-type. In HTTP, it
SHOULD be sent whenever the message's length can be determined prior SHOULD be sent whenever the message's length can be determined prior
to being transferred, unless this is prohibited by the rules in to being transferred, unless this is prohibited by the rules in
Section 3.4. Section 3.4.
9.3. Date 9.3. Date
The "Date" general-header field represents the date and time at which The "Date" general-header field represents the date and time at which
the message was originated, having the same semantics as orig-date in the message was originated, having the same semantics as the
Section 3.6.1 of [RFC5322]. The field value is an HTTP-date, as Origination Date Field (orig-date) defined in Section 3.6.1 of
described in Section 6.1; it MUST be sent in rfc1123-date format. [RFC5322]. The field value is an HTTP-date, as described in
Section 6.1; it MUST be sent in rfc1123-date format.
Date = "Date" ":" OWS Date-v Date = "Date" ":" OWS Date-v
Date-v = HTTP-date Date-v = HTTP-date
An example is An example is
Date: Tue, 15 Nov 1994 08:12:31 GMT Date: Tue, 15 Nov 1994 08:12:31 GMT
Origin servers MUST include a Date header field in all responses, Origin servers MUST include a Date header field in all responses,
except in these cases: except in these cases:
1. If the response status code is 100 (Continue) or 101 (Switching 1. If the response status code is 100 (Continue) or 101 (Switching
Protocols), the response MAY include a Date header field, at the Protocols), the response MAY include a Date header field, at the
server's option. server's option.
2. If the response status code conveys a server error, e.g. 500 2. If the response status code conveys a server error, e.g., 500
(Internal Server Error) or 503 (Service Unavailable), and it is (Internal Server Error) or 503 (Service Unavailable), and it is
inconvenient or impossible to generate a valid Date. inconvenient or impossible to generate a valid Date.
3. If the server does not have a clock that can provide a reasonable 3. If the server does not have a clock that can provide a reasonable
approximation of the current time, its responses MUST NOT include approximation of the current time, its responses MUST NOT include
a Date header field. In this case, the rules in Section 9.3.1 a Date header field. In this case, the rules in Section 9.3.1
MUST be followed. MUST be followed.
A received message that does not have a Date header field MUST be A received message that does not have a Date header field MUST be
assigned one by the recipient if the message will be cached by that assigned one by the recipient if the message will be cached by that
skipping to change at page 52, line 51 skipping to change at page 55, line 6
the protocol capabilities of upstream applications remains visible to the protocol capabilities of upstream applications remains visible to
all recipients. all recipients.
The protocol-name is optional if and only if it would be "HTTP". The The protocol-name is optional if and only if it would be "HTTP". The
received-by field is normally the host and optional port number of a received-by field is normally the host and optional port number of a
recipient server or client that subsequently forwarded the message. recipient server or client that subsequently forwarded the message.
However, if the real host is considered to be sensitive information, However, if the real host is considered to be sensitive information,
it MAY be replaced by a pseudonym. If the port is not given, it MAY it MAY be replaced by a pseudonym. If the port is not given, it MAY
be assumed to be the default port of the received-protocol. be assumed to be the default port of the received-protocol.
Multiple Via field values represents each proxy or gateway that has Multiple Via field values represent each proxy or gateway that has
forwarded the message. Each recipient MUST append its information forwarded the message. Each recipient MUST append its information
such that the end result is ordered according to the sequence of such that the end result is ordered according to the sequence of
forwarding applications. forwarding applications.
Comments MAY be used in the Via header field to identify the software Comments MAY be used in the Via header field to identify the software
of the recipient proxy or gateway, analogous to the User-Agent and of the recipient proxy or gateway, analogous to the User-Agent and
Server header fields. However, all comments in the Via field are Server header fields. However, all comments in the Via field are
optional and MAY be removed by any recipient prior to forwarding the optional and MAY be removed by any recipient prior to forwarding the
message. message.
skipping to change at page 57, line 44 skipping to change at page 60, line 8
This section is meant to inform application developers, information This section is meant to inform application developers, information
providers, and users of the security limitations in HTTP/1.1 as providers, and users of the security limitations in HTTP/1.1 as
described by this document. The discussion does not include described by this document. The discussion does not include
definitive solutions to the problems revealed, though it does make definitive solutions to the problems revealed, though it does make
some suggestions for reducing security risks. some suggestions for reducing security risks.
11.1. Personal Information 11.1. Personal Information
HTTP clients are often privy to large amounts of personal information HTTP clients are often privy to large amounts of personal information
(e.g. the user's name, location, mail address, passwords, encryption (e.g., the user's name, location, mail address, passwords, encryption
keys, etc.), and SHOULD be very careful to prevent unintentional keys, etc.), and SHOULD be very careful to prevent unintentional
leakage of this information. We very strongly recommend that a leakage of this information. We very strongly recommend that a
convenient interface be provided for the user to control convenient interface be provided for the user to control
dissemination of such information, and that designers and dissemination of such information, and that designers and
implementors be particularly careful in this area. History shows implementors be particularly careful in this area. History shows
that errors in this area often create serious security and/or privacy that errors in this area often create serious security and/or privacy
problems and generate highly adverse publicity for the implementor's problems and generate highly adverse publicity for the implementor's
company. company.
11.2. Abuse of Server Log Information 11.2. Abuse of Server Log Information
skipping to change at page 59, line 37 skipping to change at page 61, line 47
organizations, and proprietary information belonging to users and organizations, and proprietary information belonging to users and
content providers. A compromised proxy, or a proxy implemented or content providers. A compromised proxy, or a proxy implemented or
configured without regard to security and privacy considerations, configured without regard to security and privacy considerations,
might be used in the commission of a wide range of potential attacks. might be used in the commission of a wide range of potential attacks.
Proxy operators should protect the systems on which proxies run as Proxy operators should protect the systems on which proxies run as
they would protect any system that contains or transports sensitive they would protect any system that contains or transports sensitive
information. In particular, log information gathered at proxies information. In particular, log information gathered at proxies
often contains highly sensitive personal information, and/or often contains highly sensitive personal information, and/or
information about organizations. Log information should be carefully information about organizations. Log information should be carefully
guarded, and appropriate guidelines for use developed and followed. guarded, and appropriate guidelines for use should be developed and
(Section 11.2). followed. (Section 11.2).
Proxy implementors should consider the privacy and security Proxy implementors should consider the privacy and security
implications of their design and coding decisions, and of the implications of their design and coding decisions, and of the
configuration options they provide to proxy operators (especially the configuration options they provide to proxy operators (especially the
default configuration). default configuration).
Users of a proxy need to be aware that they are no trustworthier than Users of a proxy need to be aware that proxies are no trustworthier
the people who run the proxy; HTTP itself cannot solve this problem. than the people who run them; HTTP itself cannot solve this problem.
The judicious use of cryptography, when appropriate, may suffice to The judicious use of cryptography, when appropriate, may suffice to
protect against a broad range of security and privacy attacks. Such protect against a broad range of security and privacy attacks. Such
cryptography is beyond the scope of the HTTP/1.1 specification. cryptography is beyond the scope of the HTTP/1.1 specification.
11.6. Denial of Service Attacks on Proxies 11.6. Denial of Service Attacks on Proxies
They exist. They are hard to defend against. Research continues. They exist. They are hard to defend against. Research continues.
Beware. Beware.
skipping to change at page 61, line 27 skipping to change at page 63, line 37
[ISO-8859-1] [ISO-8859-1]
International Organization for Standardization, International Organization for Standardization,
"Information technology -- 8-bit single-byte coded graphic "Information technology -- 8-bit single-byte coded graphic
character sets -- Part 1: Latin alphabet No. 1", ISO/ character sets -- Part 1: Latin alphabet No. 1", ISO/
IEC 8859-1:1998, 1998. 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., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 2: Message and J. Reschke, Ed., "HTTP/1.1, part 2: Message
Semantics", draft-ietf-httpbis-p2-semantics-08 (work in Semantics", draft-ietf-httpbis-p2-semantics-09 (work in
progress), October 2009. progress), March 2010.
[Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload
and Content Negotiation", draft-ietf-httpbis-p3-payload-08 and Content Negotiation", draft-ietf-httpbis-p3-payload-09
(work in progress), October 2009. (work in progress), March 2010.
[Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and
Partial Responses", draft-ietf-httpbis-p5-range-08 (work Partial Responses", draft-ietf-httpbis-p5-range-09 (work
in progress), October 2009. in progress), March 2010.
[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part
6: Caching", draft-ietf-httpbis-p6-cache-08 (work in 6: Caching", draft-ietf-httpbis-p6-cache-09 (work in
progress), October 2009. progress), March 2010.
[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format
Specification version 3.3", RFC 1950, May 1996. Specification version 3.3", RFC 1950, May 1996.
RFC 1950 is an Informational RFC, thus it may be less RFC 1950 is an Informational RFC, thus it may be less
stable than this specification. On the other hand, this stable than this specification. On the other hand, this
downward reference was present since the publication of downward reference was present since the publication of
RFC 2068 in 1997 ([RFC2068]), therefore it is unlikely to RFC 2068 in 1997 ([RFC2068]), therefore it is unlikely to
cause problems in practice. See also [BCP97]. cause problems in practice. See also [BCP97].
skipping to change at page 64, line 49 skipping to change at page 67, line 14
Appendix A. Tolerant Applications Appendix A. Tolerant Applications
Although this document specifies the requirements for the generation Although this document specifies the requirements for the generation
of HTTP/1.1 messages, not all applications will be correct in their of HTTP/1.1 messages, not all applications will be correct in their
implementation. We therefore recommend that operational applications implementation. We therefore recommend that operational applications
be tolerant of deviations whenever those deviations can be be tolerant of deviations whenever those deviations can be
interpreted unambiguously. interpreted unambiguously.
Clients SHOULD be tolerant in parsing the Status-Line and servers Clients SHOULD be tolerant in parsing the Status-Line and servers
tolerant when parsing the Request-Line. In particular, they SHOULD SHOULD be tolerant when parsing the Request-Line. In particular,
accept any amount of WSP characters between fields, even though only they SHOULD accept any amount of WSP characters between fields, even
a single SP is required. though only a single SP is required.
The line terminator for header fields is the sequence CRLF. However, The line terminator for header fields is the sequence CRLF. However,
we recommend that applications, when parsing such headers, recognize we recommend that applications, when parsing such headers, recognize
a single LF as a line terminator and ignore the leading CR. a single LF as a line terminator and ignore the leading CR.
The character set of an entity-body SHOULD be labeled as the lowest The character set of an entity-body SHOULD be labeled as the lowest
common denominator of the character codes used within that body, with common denominator of the character codes used within that body, with
the exception that not labeling the entity is preferred over labeling the exception that not labeling the entity is preferred over labeling
the entity with the labels US-ASCII or ISO-8859-1. See [Part3]. the entity with the labels US-ASCII or ISO-8859-1. See [Part3].
skipping to change at page 67, line 28 skipping to change at page 69, line 41
o Servers MUST accept absolute URIs. o Servers MUST accept absolute URIs.
B.2. Compatibility with HTTP/1.0 Persistent Connections B.2. Compatibility with HTTP/1.0 Persistent Connections
Some clients and servers might wish to be compatible with some Some clients and servers might wish to be compatible with some
previous implementations of persistent connections in HTTP/1.0 previous implementations of persistent connections in HTTP/1.0
clients and servers. Persistent connections in HTTP/1.0 are clients and servers. Persistent connections in HTTP/1.0 are
explicitly negotiated as they are not the default behavior. HTTP/1.0 explicitly negotiated as they are not the default behavior. HTTP/1.0
experimental implementations of persistent connections are faulty, experimental implementations of persistent connections are faulty,
and the new facilities in HTTP/1.1 are designed to rectify these and the new facilities in HTTP/1.1 are designed to rectify these
problems. The problem was that some existing 1.0 clients may be problems. The problem was that some existing HTTP/1.0 clients may be
sending Keep-Alive to a proxy server that doesn't understand sending Keep-Alive to a proxy server that doesn't understand
Connection, which would then erroneously forward it to the next Connection, which would then erroneously forward it to the next
inbound server, which would establish the Keep-Alive connection and inbound server, which would establish the Keep-Alive connection and
result in a hung HTTP/1.0 proxy waiting for the close on the result in a hung HTTP/1.0 proxy waiting for the close on the
response. The result is that HTTP/1.0 clients must be prevented from response. The result is that HTTP/1.0 clients must be prevented from
using Keep-Alive when talking to proxies. using Keep-Alive when 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
skipping to change at page 68, line 29 skipping to change at page 70, line 42
Transfer-coding had significant problems, particularly with Transfer-coding had significant problems, particularly with
interactions with chunked encoding. The solution is that transfer- interactions with chunked encoding. The solution is that transfer-
codings become as full fledged as content-codings. This involves codings become as full fledged as content-codings. This involves
adding an IANA registry for transfer-codings (separate from content adding an IANA registry for transfer-codings (separate from content
codings), a new header field (TE) and enabling trailer headers in the codings), a new header field (TE) and enabling trailer headers in the
future. Transfer encoding is a major performance benefit, so it was future. Transfer encoding is a major performance benefit, so it was
worth fixing [Nie1997]. TE also solves another, obscure, downward worth fixing [Nie1997]. TE also solves another, obscure, downward
interoperability problem that could have occurred due to interactions interoperability problem that could have occurred due to interactions
between authentication trailers, chunked encoding and HTTP/1.0 between authentication trailers, chunked encoding and HTTP/1.0
clients.(Section 6.2, 6.2.1, and 9.5) clients.(Section 6.2, 6.2.1, 7.1.3.2, and 9.5)
Proxies should be able to add Content-Length when appropriate.
(Section 7.1.3.2)
B.4. Changes from RFC 2616 B.4. Changes from RFC 2616
Empty list elements in list productions have been deprecated. Empty list elements in list productions have been deprecated.
(Section 1.2.1) (Section 1.2.1)
Rules about implicit linear whitespace between certain grammar Rules about implicit linear whitespace between certain grammar
productions have been removed; now it's only allowed when productions have been removed; now it's only allowed when
specifically pointed out in the ABNF. The NUL character is no longer specifically pointed out in the ABNF. The NUL character is no longer
allowed in comment and quoted-string text. The quoted-pair rule no allowed in comment and quoted-string text. The quoted-pair rule no
longer allows escaping control characters other than HTAB. Non-ASCII longer allows escaping control characters other than HTAB. Non-ASCII
content in header fields and reason phrase has been obsoleted and content in header fields and reason phrase has been obsoleted and
made opaque (the TEXT rule was removed) (Section 1.2.2) made opaque (the TEXT rule was removed) (Section 1.2.2)
Clarify that HTTP-Version is case sensitive. (Section 2.5) Clarify that HTTP-Version is case sensitive. (Section 2.5)
Remove reference to non-existant identity transfer-coding value Remove reference to non-existent identity transfer-coding value
tokens. (Sections 6.2 and 3.4) tokens. (Sections 6.2 and 3.4)
Require that invalid whitespace around field-names be rejected. Require that invalid whitespace around field-names be rejected.
(Section 3.2) (Section 3.2)
Update use of abs_path production from RFC1808 to the path-absolute + Update use of abs_path production from RFC1808 to the path-absolute +
query components of RFC3986. (Section 4.1.2) query components of RFC3986. (Section 4.1.2)
Clarification that the chunk length does not include the count of the Clarification that the chunk length does not include the count of the
octets in the chunk header and trailer. Furthermore disallowed line octets in the chunk header and trailer. Furthermore disallowed line
folding in chunk extensions. (Section 6.2.1) folding in chunk extensions. (Section 6.2.1)
Remove hard limit of two connections per server. (Section 7.1.4) Remove hard limit of two connections per server. (Section 7.1.4)
Clarify exactly when close connection options must be sent. Clarify exactly when close connection options must be sent.
skipping to change at page 72, line 43 skipping to change at page 75, line 11
received-protocol = [ protocol-name "/" ] protocol-version received-protocol = [ protocol-name "/" ] protocol-version
relative-part = <relative-part, defined in [RFC3986], Section 4.2> relative-part = <relative-part, defined in [RFC3986], Section 4.2>
request-header = <request-header, defined in [Part2], Section 3> request-header = <request-header, defined in [Part2], Section 3>
request-target = "*" / absolute-URI / ( path-absolute [ "?" query ] ) request-target = "*" / absolute-URI / ( path-absolute [ "?" query ] )
/ authority / authority
response-header = <response-header, defined in [Part2], Section 5> response-header = <response-header, defined in [Part2], Section 5>
rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT
rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT
second = 2DIGIT second = 2DIGIT
special = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" /
DQUOTE / "/" / "[" / "]" / "?" / "=" / "{" / "}"
start-line = Request-Line / Status-Line start-line = Request-Line / Status-Line
t-codings = "trailers" / ( transfer-extension [ te-params ] ) t-codings = "trailers" / ( transfer-extension [ te-params ] )
tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." / tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." /
"^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA
te-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ] te-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ]
te-params = OWS ";" OWS "q=" qvalue *te-ext te-params = OWS ";" OWS "q=" qvalue *te-ext
time-of-day = hour ":" minute ":" second time-of-day = hour ":" minute ":" second
token = 1*tchar token = 1*tchar
trailer-part = *( entity-header CRLF ) trailer-part = *( entity-header CRLF )
skipping to change at page 73, line 29 skipping to change at page 75, line 48
; HTTP-message defined but not used ; HTTP-message defined but not used
; Host defined but not used ; Host defined but not used
; Request defined but not used ; Request defined but not used
; Response defined but not used ; Response defined but not used
; TE defined but not used ; TE defined but not used
; URI defined but not used ; URI defined but not used
; URI-reference defined but not used ; URI-reference 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
Appendix D. Change Log (to be removed by RFC Editor before publication) Appendix D. Change Log (to be removed by RFC Editor before publication)
D.1. Since RFC2616 D.1. Since RFC2616
Extracted relevant partitions from [RFC2616]. Extracted relevant partitions from [RFC2616].
D.2. Since draft-ietf-httpbis-p1-messaging-00 D.2. Since draft-ietf-httpbis-p1-messaging-00
Closed issues: Closed issues:
skipping to change at page 79, line 45 skipping to change at page 82, line 17
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
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/201>: "header
parsing, treatment of leading and trailing OWS"
Partly resolved issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/60>: "Placement of
13.5.1 and 13.5.2"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/200>: "use of term
"word" when talking about header structure"
Index Index
A A
application/http Media Type 55 application/http Media Type 58
C C
cache 12 cache 13
cacheable 13 cacheable 14
chunked (Coding Format) 32 chunked (Coding Format) 32
client 10 client 10
Coding Format Coding Format
chunked 32 chunked 32
compress 34 compress 34
deflate 35 deflate 35
gzip 35 gzip 35
compress (Coding Format) 34 compress (Coding Format) 34
connection 10 connection 10
Connection header 44 Connection header 46
Content-Length header 45 Content-Length header 47
D D
Date header 46 Date header 48
deflate (Coding Format) 35 deflate (Coding Format) 35
downstream 12 downstream 12
G G
gateway 12 gateway 13
Grammar Grammar
absolute-URI 15 absolute-URI 16
ALPHA 7 ALPHA 7
asctime-date 31 asctime-date 31
attribute 31 attribute 32
authority 15 authority 16
BWS 9 BWS 9
chunk 33 chunk 33
chunk-data 33 chunk-data 33
chunk-ext 33 chunk-ext 33
chunk-ext-name 33 chunk-ext-name 33
chunk-ext-val 33 chunk-ext-val 33
chunk-size 33 chunk-size 33
Chunked-Body 33 Chunked-Body 33
comment 21 comment 21
Connection 44 Connection 46
connection-token 44 connection-token 46
Connection-v 44 Connection-v 46
Content-Length 45 Content-Length 47
Content-Length-v 45 Content-Length-v 47
CR 7 CR 7
CRLF 7 CRLF 7
ctext 21 ctext 21
CTL 7 CTL 7
Date 46 Date 48
Date-v 46 Date-v 48
date1 30 date1 30
date2 31 date2 32
date3 31 date3 32
day 30 day 30
day-name 30 day-name 30
day-name-l 30 day-name-l 30
DIGIT 7 DIGIT 7
DQUOTE 7 DQUOTE 7
extension-code 28 extension-code 29
extension-method 24 extension-method 25
field-content 19 field-content 20
field-name 19 field-name 20
field-value 19 field-value 20
general-header 23 general-header 24
GMT 30 GMT 30
header-field 19 header-field 20
HEXDIG 7 HEXDIG 7
Host 47 Host 49
Host-v 47 Host-v 49
hour 30 hour 30
HTTP-date 29 HTTP-date 30
HTTP-message 18 HTTP-message 19
HTTP-Prot-Name 14 HTTP-Prot-Name 15
http-URI 16 http-URI 16
HTTP-Version 14 HTTP-Version 15
https-URI 17 https-URI 18
last-chunk 33 last-chunk 33
LF 7 LF 7
message-body 21 message-body 22
Method 24 Method 25
minute 30 minute 30
month 30 month 30
obs-date 30 obs-date 31
obs-text 9 obs-text 10
OCTET 7 OCTET 7
OWS 9 OWS 9
path-absolute 15 path-absolute 16
port 15 port 16
product 35 product 35
product-version 35 product-version 35
protocol-name 52 protocol-name 54
protocol-version 52 protocol-version 54
pseudonym 52 pseudonym 54
qdtext 9 qdtext 10
qdtext-nf 33 qdtext-nf 33
query 15 query 16
quoted-cpair 21 quoted-cpair 22
quoted-pair 9 quoted-pair 10
quoted-str-nf 33 quoted-str-nf 33
quoted-string 9 quoted-string 10
qvalue 36 qvalue 36
Reason-Phrase 28 Reason-Phrase 29
received-by 52 received-by 54
received-protocol 52 received-protocol 54
Request 24 Request 25
Request-Line 24 Request-Line 25
request-target 24 request-target 25
Response 27 Response 28
rfc850-date 31 rfc850-date 31
rfc1123-date 30 rfc1123-date 30
RWS 9 RWS 9
second 30 second 30
SP 7 SP 7
Status-Code 28 special 9
Status-Line 27 Status-Code 29
t-codings 48 Status-Line 28
t-codings 50
tchar 9 tchar 9
TE 48 TE 50
te-ext 48 te-ext 50
te-params 48 te-params 50
TE-v 48 TE-v 50
time-of-day 30 time-of-day 30
token 9 token 9
Trailer 49 Trailer 51
trailer-part 33 trailer-part 33
Trailer-v 49 Trailer-v 51
transfer-coding 31 transfer-coding 31
Transfer-Encoding 50 Transfer-Encoding 52
Transfer-Encoding-v 50 Transfer-Encoding-v 52
transfer-extension 31 transfer-extension 31
transfer-parameter 31 transfer-parameter 32
Upgrade 50 Upgrade 52
Upgrade-v 50 Upgrade-v 52
uri-host 15 uri-host 16
URI-reference 15 URI-reference 16
value 31 value 32
VCHAR 7 VCHAR 7
Via 52 Via 54
Via-v 52 Via-v 54
WSP 7 WSP 7
year 30 year 30
gzip (Coding Format) 35 gzip (Coding Format) 35
H H
header field 18 header field 19
header section 18 header section 19
Headers Headers
Connection 44 Connection 46
Content-Length 45 Content-Length 47
Date 46 Date 48
Host 47 Host 49
TE 48 TE 50
Trailer 49 Trailer 51
Transfer-Encoding 49 Transfer-Encoding 52
Upgrade 50 Upgrade 52
Via 52 Via 54
headers 18 headers 19
Host header 47 Host header 49
http URI scheme 16 http URI scheme 16
https URI scheme 17 https URI scheme 17
I I
inbound 12 inbound 12
M M
Media Type Media Type
application/http 55 application/http 58
message/http 54 message/http 56
message 10 message 11
message/http Media Type 54 message/http Media Type 56
O O
origin server 10 origin server 11
outbound 12 outbound 12
P P
proxy 12 proxy 12
R R
request 10 request 11
resource 15 resource 16
response 10 response 11
reverse proxy 12 reverse proxy 13
S S
server 10 server 10
T T
TE header 48 TE header 50
Trailer header 49 Trailer header 51
Transfer-Encoding header 49 Transfer-Encoding header 52
tunnel 12 tunnel 13
U U
Upgrade header 50 Upgrade header 52
upstream 12 upstream 12
URI scheme URI scheme
http 16 http 16
https 17 https 17
user agent 10 user agent 11
V V
Via header 52 Via header 54
Authors' Addresses Authors' Addresses
Roy T. Fielding (editor) Roy T. Fielding (editor)
Day Software Day Software
23 Corporate Plaza DR, Suite 280 23 Corporate Plaza DR, Suite 280
Newport Beach, CA 92660 Newport Beach, CA 92660
USA USA
Phone: +1-949-706-5300 Phone: +1-949-706-5300
 End of changes. 104 change blocks. 
286 lines changed or deleted 450 lines changed or added

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