draft-ietf-httpbis-p1-messaging-09.txt   draft-ietf-httpbis-p1-messaging-10.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) Alcatel-Lucent
Intended status: Standards Track J. Mogul Intended status: Standards Track J. Mogul
Expires: September 9, 2010 HP Expires: January 13, 2011 HP
H. Frystyk H. Frystyk
Microsoft Microsoft
L. Masinter L. Masinter
Adobe Systems Adobe Systems
P. Leach P. Leach
Microsoft Microsoft
T. Berners-Lee T. Berners-Lee
W3C/MIT W3C/MIT
Y. Lafon, Ed. Y. Lafon, Ed.
W3C W3C
J. Reschke, Ed. J. Reschke, Ed.
greenbytes greenbytes
March 8, 2010 July 12, 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-09 draft-ietf-httpbis-p1-messaging-10
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is an application-level The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypertext information protocol for distributed, collaborative, hypertext information
systems. HTTP has been in use by the World Wide Web global systems. HTTP has been in use by the World Wide Web global
information initiative since 1990. This document is Part 1 of the information initiative since 1990. This document is Part 1 of the
seven-part specification that defines the protocol referred to as seven-part specification that defines the protocol referred to as
"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides
an overview of HTTP and its associated terminology, defines the an overview of HTTP and its associated terminology, defines the
"http" and "https" Uniform Resource Identifier (URI) schemes, defines "http" and "https" Uniform Resource Identifier (URI) schemes, defines
the generic message syntax and parsing requirements for HTTP message the generic message syntax and parsing requirements for HTTP message
frames, and describes general security concerns for implementations. frames, and describes general security concerns for implementations.
Editorial Note (To be removed by RFC Editor) Editorial Note (To be removed by RFC Editor)
Discussion of this draft should take place on the HTTPBIS working Discussion of this draft should take place on the HTTPBIS working
group mailing list (ietf-http-wg@w3.org). The current issues list is group mailing list (ietf-http-wg@w3.org). The current issues list is
at <http://tools.ietf.org/wg/httpbis/trac/report/11> and related at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
documents (including fancy diffs) can be found at documents (including fancy diffs) can be found at
<http://tools.ietf.org/wg/httpbis/>. <http://tools.ietf.org/wg/httpbis/>.
The changes in this draft are summarized in Appendix D.10. The changes in this draft are summarized in Appendix D.11.
Status of this Memo Status of This Memo
This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on January 13, 2011.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 9, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
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
skipping to change at page 3, line 14 skipping to change at page 3, line 7
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7
1.2.1. ABNF Extension: #rule . . . . . . . . . . . . . . . . 7 1.2.1. ABNF Extension: #rule . . . . . . . . . . . . . . . . 7
1.2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . 8 1.2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . 8
1.2.3. ABNF Rules defined in other Parts of the 1.2.3. ABNF Rules defined in other Parts of the
Specification . . . . . . . . . . . . . . . . . . . . 10 Specification . . . . . . . . . . . . . . . . . . . . 10
2. HTTP architecture . . . . . . . . . . . . . . . . . . . . . . 10 2. HTTP architecture . . . . . . . . . . . . . . . . . . . . . . 11
2.1. Client/Server Operation . . . . . . . . . . . . . . . . . 10 2.1. Client/Server Operation . . . . . . . . . . . . . . . . . 11
2.2. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 12 2.2. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 12
2.3. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4. Transport Independence . . . . . . . . . . . . . . . . . . 14 2.4. Transport Independence . . . . . . . . . . . . . . . . . . 14
2.5. HTTP Version . . . . . . . . . . . . . . . . . . . . . . . 14 2.5. HTTP Version . . . . . . . . . . . . . . . . . . . . . . . 15
2.6. Uniform Resource Identifiers . . . . . . . . . . . . . . . 16 2.6. Uniform Resource Identifiers . . . . . . . . . . . . . . . 16
2.6.1. http URI scheme . . . . . . . . . . . . . . . . . . . 16 2.6.1. http URI scheme . . . . . . . . . . . . . . . . . . . 17
2.6.2. https URI scheme . . . . . . . . . . . . . . . . . . . 17 2.6.2. https URI scheme . . . . . . . . . . . . . . . . . . . 18
2.6.3. http and https URI Normalization and Comparison . . . 18 2.6.3. http and https URI Normalization and Comparison . . . 18
3. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . . 19 3. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1. Message Parsing Robustness . . . . . . . . . . . . . . . . 19 3.1. Message Parsing Robustness . . . . . . . . . . . . . . . . 20
3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 20 3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 20
3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 22 3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 22
3.4. Message Length . . . . . . . . . . . . . . . . . . . . . . 23 3.4. Message Length . . . . . . . . . . . . . . . . . . . . . . 23
3.5. General Header Fields . . . . . . . . . . . . . . . . . . 24 3.5. General Header Fields . . . . . . . . . . . . . . . . . . 24
4. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 25 4.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 25
4.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 25 4.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 25
4.1.2. request-target . . . . . . . . . . . . . . . . . . . . 25 4.1.2. request-target . . . . . . . . . . . . . . . . . . . . 26
4.2. The Resource Identified by a Request . . . . . . . . . . . 27 4.2. The Resource Identified by a Request . . . . . . . . . . . 28
5. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.3. Effective Request URI . . . . . . . . . . . . . . . . . . 28
5.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 28 5. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 28 5.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 30
6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 29 5.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 30
6.1. Date/Time Formats: Full Date . . . . . . . . . . . . . . . 29 6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 31
6.2. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 31 6.1. Date/Time Formats: Full Date . . . . . . . . . . . . . . . 31
6.2.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 32 6.2. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 33
6.2.2. Compression Codings . . . . . . . . . . . . . . . . . 34 6.2.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 34
6.2.3. Transfer Coding Registry . . . . . . . . . . . . . . . 35 6.2.2. Compression Codings . . . . . . . . . . . . . . . . . 36
6.3. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 35 6.2.3. Transfer Coding Registry . . . . . . . . . . . . . . . 37
6.4. Quality Values . . . . . . . . . . . . . . . . . . . . . . 36 6.3. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 37
7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 36 6.4. Quality Values . . . . . . . . . . . . . . . . . . . . . . 38
7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 36 7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 38
7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 36 7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 38
7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 37 7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 38
7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 38 7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 39
7.1.4. Practical Considerations . . . . . . . . . . . . . . . 41 7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 41
7.2. Message Transmission Requirements . . . . . . . . . . . . 42 7.1.4. Practical Considerations . . . . . . . . . . . . . . . 43
7.2.1. Persistent Connections and Flow Control . . . . . . . 42 7.2. Message Transmission Requirements . . . . . . . . . . . . 44
7.2.2. Monitoring Connections for Error Status Messages . . . 42 7.2.1. Persistent Connections and Flow Control . . . . . . . 44
7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 42 7.2.2. Monitoring Connections for Error Status Messages . . . 44
7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 45
7.2.4. Client Behavior if Server Prematurely Closes 7.2.4. Client Behavior if Server Prematurely Closes
Connection . . . . . . . . . . . . . . . . . . . . . . 44 Connection . . . . . . . . . . . . . . . . . . . . . . 47
8. Miscellaneous notes that may disappear . . . . . . . . . . . . 45
8.1. Scheme aliases considered harmful . . . . . . . . . . . . 45 8. Miscellaneous notes that may disappear . . . . . . . . . . . . 47
8.2. Use of HTTP for proxy communication . . . . . . . . . . . 45 8.1. Scheme aliases considered harmful . . . . . . . . . . . . 47
8.3. Interception of HTTP for access control . . . . . . . . . 46 8.2. Use of HTTP for proxy communication . . . . . . . . . . . 48
8.4. Use of HTTP by other protocols . . . . . . . . . . . . . . 46 8.3. Interception of HTTP for access control . . . . . . . . . 48
8.5. Use of HTTP by media type specification . . . . . . . . . 46 8.4. Use of HTTP by other protocols . . . . . . . . . . . . . . 48
9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 46 8.5. Use of HTTP by media type specification . . . . . . . . . 48
9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 46 9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 48
9.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 47 9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 48
9.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 9.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 49
9.3.1. Clockless Origin Server Operation . . . . . . . . . . 49 9.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
9.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 9.3.1. Clockless Origin Server Operation . . . . . . . . . . 51
9.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 9.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
9.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 51 9.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
9.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 52 9.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 53
9.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 52 9.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 54
9.8.1. Upgrade Token Registry . . . . . . . . . . . . . . . . 53 9.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 54
9.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 9.8.1. Upgrade Token Registry . . . . . . . . . . . . . . . . 55
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56 9.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
10.1. Message Header Registration . . . . . . . . . . . . . . . 56 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58
10.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 56 10.1. Message Header Registration . . . . . . . . . . . . . . . 58
10.3. Internet Media Type Registrations . . . . . . . . . . . . 56 10.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 58
10.3.1. Internet Media Type message/http . . . . . . . . . . . 56 10.3. Internet Media Type Registrations . . . . . . . . . . . . 58
10.3.2. Internet Media Type application/http . . . . . . . . . 58 10.3.1. Internet Media Type message/http . . . . . . . . . . . 58
10.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 59 10.3.2. Internet Media Type application/http . . . . . . . . . 60
10.5. Upgrade Token Registration . . . . . . . . . . . . . . . . 59 10.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 61
11. Security Considerations . . . . . . . . . . . . . . . . . . . 59 10.5. Upgrade Token Registration . . . . . . . . . . . . . . . . 61
11.1. Personal Information . . . . . . . . . . . . . . . . . . . 60 11. Security Considerations . . . . . . . . . . . . . . . . . . . 61
11.2. Abuse of Server Log Information . . . . . . . . . . . . . 60 11.1. Personal Information . . . . . . . . . . . . . . . . . . . 62
11.3. Attacks Based On File and Path Names . . . . . . . . . . . 60 11.2. Abuse of Server Log Information . . . . . . . . . . . . . 62
11.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 60 11.3. Attacks Based On File and Path Names . . . . . . . . . . . 62
11.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 61 11.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 62
11.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 62 11.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 63
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 62 11.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 64
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 63 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 64
13.1. Normative References . . . . . . . . . . . . . . . . . . . 63 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 65
13.2. Informative References . . . . . . . . . . . . . . . . . . 65 13.1. Normative References . . . . . . . . . . . . . . . . . . . 65
Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 67 13.2. Informative References . . . . . . . . . . . . . . . . . . 67
Appendix B. Compatibility with Previous Versions . . . . . . . . 67 Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 69
B.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 68 Appendix B. Compatibility with Previous Versions . . . . . . . . 70
B.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 71
B.1.1. Changes to Simplify Multi-homed Web Servers and B.1.1. Changes to Simplify Multi-homed Web Servers and
Conserve IP Addresses . . . . . . . . . . . . . . . . 68 Conserve IP Addresses . . . . . . . . . . . . . . . . 71
B.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 69 B.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 71
B.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 70 B.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 72
B.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 70 B.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 73
Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 71 Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 73
Appendix D. Change Log (to be removed by RFC Editor before Appendix D. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 76 publication) . . . . . . . . . . . . . . . . . . . . 78
D.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 76
D.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 76 D.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 78
D.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 77 D.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 78
D.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 78 D.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 80
D.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 79 D.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 81
D.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 79 D.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 81
D.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 80 D.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 82
D.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 81 D.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 82
D.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 81 D.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 83
D.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 82 D.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 84
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 D.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 84
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 86 D.11. Since draft-ietf-httpbis-p1-messaging-09 . . . . . . . . . 85
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
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 13 skipping to change at page 7, line 13
the complete set of requirements for message parsers and message- the complete set of requirements for message parsers and message-
forwarding intermediaries. forwarding intermediaries.
1.1. Requirements 1.1. Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
An implementation is not compliant if it fails to satisfy one or more An implementation is not compliant if it fails to satisfy one or more
of the MUST or REQUIRED level requirements for the protocols it of the "MUST" or "REQUIRED" level requirements for the protocols it
implements. An implementation that satisfies all the MUST or implements. An implementation that satisfies all the "MUST" or
REQUIRED level and all the SHOULD level requirements for its "REQUIRED" level and all the "SHOULD" level requirements for its
protocols is said to be "unconditionally compliant"; one that protocols is said to be "unconditionally compliant"; one that
satisfies all the MUST level requirements but not all the SHOULD satisfies all the "MUST" level requirements but not all the "SHOULD"
level requirements for its protocols is said to be "conditionally level requirements for its protocols is said to be "conditionally
compliant." compliant".
1.2. Syntax Notation 1.2. Syntax Notation
This specification uses the Augmented Backus-Naur Form (ABNF) This specification uses the Augmented Backus-Naur Form (ABNF)
notation of [RFC5234]. notation of [RFC5234].
The following core rules are included by reference, as defined in The following core rules are included by reference, as defined in
[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
(CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit
skipping to change at page 9, line 43 skipping to change at page 10, line 5
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- Many HTTP/1.1 header field values consist of words (token or quoted-
string) separated by whitespace or special characters. These special string) separated by whitespace or special characters. These special
characters MUST be in a quoted string to be used within a parameter characters MUST be in a quoted string to be used within a parameter
value (as defined in Section 6.2). value (as defined in Section 6.2).
word = token / quoted-string
token = 1*tchar token = 1*tchar
tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*"
/ "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
/ DIGIT / ALPHA / DIGIT / ALPHA
; any VCHAR, except special ; any VCHAR, except special
special = "(" / ")" / "<" / ">" / "@" / "," special = "(" / ")" / "<" / ">" / "@" / ","
/ ";" / ":" / "\" / DQUOTE / "/" / "[" / ";" / ":" / "\" / DQUOTE / "/" / "["
/ "]" / "?" / "=" / "{" / "}" / "]" / "?" / "=" / "{" / "}"
skipping to change at page 16, line 21 skipping to change at page 16, line 30
interface that can be used to interact with a resource via HTTP. interface that can be used to interact with a resource via HTTP.
More information on the scope of URIs and resources can be found in More information on the scope of URIs and resources can be found in
[RFC3986]. [RFC3986].
This specification adopts the definitions of "URI-reference", This specification adopts the definitions of "URI-reference",
"absolute-URI", "relative-part", "port", "host", "path-abempty", "absolute-URI", "relative-part", "port", "host", "path-abempty",
"path-absolute", "query", and "authority" from [RFC3986]. In "path-absolute", "query", and "authority" from [RFC3986]. In
addition, we define a partial-URI rule for protocol elements that addition, we define a partial-URI rule for protocol elements that
allow a relative URI without a fragment. allow a relative URI without a fragment.
URI = <URI, defined in [RFC3986], Section 3>
URI-reference = <URI-reference, defined in [RFC3986], Section 4.1> URI-reference = <URI-reference, defined in [RFC3986], Section 4.1>
absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3> absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3>
relative-part = <relative-part, defined in [RFC3986], Section 4.2> relative-part = <relative-part, defined in [RFC3986], Section 4.2>
authority = <authority, defined in [RFC3986], Section 3.2> authority = <authority, defined in [RFC3986], Section 3.2>
path-abempty = <path-abempty, defined in [RFC3986], Section 3.3> path-abempty = <path-abempty, defined in [RFC3986], Section 3.3>
path-absolute = <path-absolute, defined in [RFC3986], Section 3.3> path-absolute = <path-absolute, defined in [RFC3986], Section 3.3>
port = <port, defined in [RFC3986], Section 3.2.3> port = <port, defined in [RFC3986], Section 3.2.3>
query = <query, defined in [RFC3986], Section 3.4> query = <query, defined in [RFC3986], Section 3.4>
uri-host = <host, defined in [RFC3986], Section 3.2.2> uri-host = <host, defined in [RFC3986], Section 3.2.2>
skipping to change at page 25, line 45 skipping to change at page 26, line 16
The request-target identifies the resource upon which to apply the The request-target identifies the resource upon which to apply the
request. request.
request-target = "*" request-target = "*"
/ absolute-URI / absolute-URI
/ ( path-absolute [ "?" query ] ) / ( path-absolute [ "?" query ] )
/ authority / authority
The four options for request-target are dependent on the nature of The four options for request-target are dependent on the nature of
the request. The asterisk "*" means that the request does not apply the request.
to a particular resource, but to the server itself, and is only
allowed when the method used does not necessarily apply to a The asterisk "*" means that the request does not apply to a
resource. One example would be particular resource, but to the server itself, and is only allowed
when the method used does not necessarily apply to a resource. One
example would be
OPTIONS * HTTP/1.1 OPTIONS * HTTP/1.1
The absolute-URI form is REQUIRED when the request is being made to a The absolute-URI form is REQUIRED when the request is being made to a
proxy. The proxy is requested to forward the request or service it proxy. The proxy is requested to forward the request or service it
from a valid cache, and return the response. Note that the proxy MAY from a valid cache, and return the response. Note that the proxy MAY
forward the request on to another proxy or directly to the server forward the request on to another proxy or directly to the server
specified by the absolute-URI. In order to avoid request loops, a specified by the absolute-URI. In order to avoid request loops, a
proxy MUST be able to recognize all of its server names, including proxy MUST be able to recognize all of its server names, including
any aliases, local variations, and the numeric IP address. An any aliases, local variations, and the numeric IP address. An
skipping to change at page 27, line 21 skipping to change at page 27, line 37
The request-target is transmitted in the format specified in The request-target is transmitted in the format specified in
Section 2.6.1. If the request-target is percent-encoded ([RFC3986], Section 2.6.1. If the request-target is percent-encoded ([RFC3986],
Section 2.1), the origin server MUST decode the request-target in Section 2.1), the origin server MUST decode the request-target in
order to properly interpret the request. Servers SHOULD respond to order to properly interpret the request. Servers SHOULD respond to
invalid request-targets with an appropriate status code. invalid request-targets with an appropriate status code.
A transparent proxy MUST NOT rewrite the "path-absolute" part of the A transparent proxy MUST NOT rewrite the "path-absolute" part of the
received request-target when forwarding it to the next inbound received request-target when forwarding it to the next inbound
server, except as noted above to replace a null path-absolute with server, except as noted above to replace a null path-absolute with
"/". "/" or "*".
Note: The "no rewrite" rule prevents the proxy from changing the Note: The "no rewrite" rule prevents the proxy from changing the
meaning of the request when the origin server is improperly using meaning of the request when the origin server is improperly using
a non-reserved URI character for a reserved purpose. Implementors a non-reserved URI character for a reserved purpose. Implementors
should be aware that some pre-HTTP/1.1 proxies have been known to should be aware that some pre-HTTP/1.1 proxies have been known to
rewrite the request-target. rewrite the request-target.
HTTP does not place a pre-defined limit on the length of a request- HTTP does not place a pre-defined limit on the length of a request-
target. A server MUST be prepared to receive URIs of unbounded target. A server MUST be prepared to receive URIs of unbounded
length and respond with the 414 (URI Too Long) status if the received length and respond with the 414 (URI Too Long) status if the received
request-target would be longer than the server wishes to handle (see request-target would be longer than the server wishes to handle (see
Section 8.4.15 of [Part2]). Section 8.4.15 of [Part2]).
Various ad-hoc limitations on request-target length are found in Various ad-hoc limitations on request-target length are found in
practice. It is RECOMMENDED that all HTTP senders and recipients practice. It is RECOMMENDED that all HTTP senders and recipients
support request-target lengths of 8000 or more OCTETs. support request-target lengths of 8000 or more OCTETs.
Note: Fragments ([RFC3986], Section 3.5) are not part of the
request-target and thus will not be transmitted in an HTTP
request.
4.2. The Resource Identified by a Request 4.2. The Resource Identified by a Request
The exact resource identified by an Internet request is determined by The exact resource identified by an Internet request is determined by
examining both the request-target and the Host header field. examining both the request-target and the Host header field.
An origin server that does not allow resources to differ by the An origin server that does not allow resources to differ by the
requested host MAY ignore the Host header field value when requested host MAY ignore the Host header field value when
determining the resource identified by an HTTP/1.1 request. (But see determining the resource identified by an HTTP/1.1 request. (But see
Appendix B.1.1 for other requirements on Host support in HTTP/1.1.) Appendix B.1.1 for other requirements on Host support in HTTP/1.1.)
skipping to change at page 28, line 22 skipping to change at page 28, line 42
3. If the host as determined by rule 1 or 2 is not a valid host on 3. If the host as determined by rule 1 or 2 is not a valid host on
the server, the response MUST be a 400 (Bad Request) error the server, the response MUST be a 400 (Bad Request) error
message. message.
Recipients of an HTTP/1.0 request that lacks a Host header field MAY Recipients of an HTTP/1.0 request that lacks a Host header field MAY
attempt to use heuristics (e.g., examination of the URI path for attempt to use heuristics (e.g., examination of the URI path for
something unique to a particular host) in order to determine what something unique to a particular host) in order to determine what
exact resource is being requested. exact resource is being requested.
4.3. Effective Request URI
HTTP requests often do not carry the absolute URI ([RFC3986], Section
4.3) for the resource they are intended for; instead, the value needs
to be inferred from the request-target, Host header and other
context. The result of this process is the "Effective Request URI".
If the request-target is an absolute-URI, then the Effective Request
URI is the request-target.
If the request-target uses the path-absolute (plus optional query)
syntax or if it is just the asterisk "*", then the Effective Request
URI is constructed by concatenating
o the scheme name: "http" if the request was received over an
insecure TCP connection, or "https" when received over SSL/
TLS-secured TCP connection,
o the character sequence "://",
o the authority component, as specified in the Host header
(Section 9.4) and determined by the rules in Section 4.2,
[[effrequri-nohost: Do we need to include the handling of missing
hosts in HTTP/1.0 messages, as described in Section 4.2? --jre]]
and
o the request-target obtained from the Request-Line, unless the
request-target is just the asterisk "*".
Otherwise, when request-target uses the authority form, the Effective
Request URI is undefined.
Example 1: the Effective Request URI for the message
GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.example.org:8080
(received over an insecure TCP connection) is "http", plus "://",
plus the authority component "www.example.org:8080", plus the
request-target "/pub/WWW/TheProject.html", thus
"http://www.example.org:8080/pub/WWW/TheProject.html".
Example 2: the Effective Request URI for the message
GET * HTTP/1.1
Host: www.example.org
(received over an SSL/TLS secured TCP connection) is "https", plus
"://", plus the authority component "www.example.org", thus
"https://www.example.org".
Effective Request URIs are compared using the rules described in
Section 2.6.3, except that empty path components MUST NOT be treated
as equivalent to an absolute path of "/".
5. Response 5. Response
After receiving and interpreting a request message, a server responds After receiving and interpreting a request message, a server responds
with an HTTP response message. with an HTTP response message.
Response = Status-Line ; Section 5.1 Response = Status-Line ; Section 5.1
*(( general-header ; Section 3.5 *(( general-header ; Section 3.5
/ response-header ; [Part2], Section 5 / response-header ; [Part2], Section 5
/ entity-header ) CRLF ) ; [Part3], Section 3.1 / entity-header ) CRLF ) ; [Part3], Section 3.1
CRLF CRLF
skipping to change at page 29, line 32 skipping to change at page 31, line 16
valid request valid request
Status-Code = 3DIGIT Status-Code = 3DIGIT
Reason-Phrase = *( WSP / VCHAR / obs-text ) Reason-Phrase = *( WSP / VCHAR / obs-text )
6. Protocol Parameters 6. Protocol Parameters
6.1. Date/Time Formats: Full Date 6.1. Date/Time Formats: Full Date
HTTP applications have historically allowed three different formats HTTP applications have historically allowed three different formats
for the representation of date/time stamps: for the representation of date/time stamps.
The first format is preferred as an Internet standard and represents
a fixed-length subset of that defined by [RFC1123]:
Sun, 06 Nov 1994 08:49:37 GMT ; RFC 1123 Sun, 06 Nov 1994 08:49:37 GMT ; RFC 1123
The other formats are described here only for compatibility with
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
The first format is preferred as an Internet standard and represents HTTP/1.1 clients and servers that parse the date value MUST accept
a fixed-length subset of that defined by [RFC1123]. The other all three formats (for compatibility with HTTP/1.0), though they MUST
formats are described here only for compatibility with obsolete only generate the RFC 1123 format for representing HTTP-date values
implementations. HTTP/1.1 clients and servers that parse the date in header fields. See Appendix A for further information.
value MUST accept all three formats (for compatibility with
HTTP/1.0), though they MUST only generate the RFC 1123 format for
representing HTTP-date values in header fields. See Appendix A for
further information.
All HTTP date/time stamps MUST be represented in Greenwich Mean Time All HTTP date/time stamps MUST be represented in Greenwich Mean Time
(GMT), without exception. For the purposes of HTTP, GMT is exactly (GMT), without exception. For the purposes of HTTP, GMT is exactly
equal to UTC (Coordinated Universal Time). This is indicated in the equal to UTC (Coordinated Universal Time). This is indicated in the
first two formats by the inclusion of "GMT" as the three-letter first two formats by the inclusion of "GMT" as the three-letter
abbreviation for time zone, and MUST be assumed when reading the abbreviation for time zone, and MUST be assumed when reading the
asctime format. HTTP-date is case sensitive and MUST NOT include asctime format. HTTP-date is case sensitive and MUST NOT include
additional whitespace beyond that specifically included as SP in the additional whitespace beyond that specifically included as SP in the
grammar. grammar.
skipping to change at page 32, line 4 skipping to change at page 33, line 43
transformation that has been, can be, or may need to be applied to an transformation that has been, can be, or may need to be applied to an
entity-body in order to ensure "safe transport" through the network. entity-body in order to ensure "safe transport" through the network.
This differs from a content coding in that the transfer-coding is a This differs from a content coding in that the transfer-coding is a
property of the message, not of the original entity. property of the message, not of the original entity.
transfer-coding = "chunked" ; Section 6.2.1 transfer-coding = "chunked" ; Section 6.2.1
/ "compress" ; Section 6.2.2.1 / "compress" ; Section 6.2.2.1
/ "deflate" ; Section 6.2.2.2 / "deflate" ; Section 6.2.2.2
/ "gzip" ; Section 6.2.2.3 / "gzip" ; Section 6.2.2.3
/ transfer-extension / transfer-extension
transfer-extension = token *( OWS ";" OWS transfer-parameter ) transfer-extension = token *( OWS ";" OWS transfer-parameter )
Parameters are in the form of attribute/value pairs. Parameters are in the form of attribute/value pairs.
transfer-parameter = attribute BWS "=" BWS value transfer-parameter = attribute BWS "=" BWS value
attribute = token attribute = token
value = token / quoted-string value = word
All transfer-coding values are case-insensitive. HTTP/1.1 uses All transfer-coding values are case-insensitive. HTTP/1.1 uses
transfer-coding values in the TE header field (Section 9.5) and in transfer-coding values in the TE header field (Section 9.5) and in
the Transfer-Encoding header field (Section 9.7). the Transfer-Encoding header field (Section 9.7).
Whenever a transfer-coding is applied to a message-body, the set of Whenever a transfer-coding is applied to a message-body, the set of
transfer-codings MUST include "chunked", unless the message indicates transfer-codings MUST include "chunked", unless the message indicates
it is terminated by closing the connection. When the "chunked" it is terminated by closing the connection. When the "chunked"
transfer-coding is used, it MUST be the last transfer-coding applied transfer-coding is used, it MUST be the last transfer-coding applied
to the message-body. The "chunked" transfer-coding MUST NOT be to the message-body. The "chunked" transfer-coding MUST NOT be
skipping to change at page 35, line 7 skipping to change at page 37, line 7
equivalent to "gzip" and "compress" respectively. equivalent to "gzip" and "compress" respectively.
6.2.2.1. Compress Coding 6.2.2.1. Compress Coding
The "compress" format is produced by the common UNIX file compression The "compress" format is produced by the common UNIX file compression
program "compress". This format is an adaptive Lempel-Ziv-Welch program "compress". This format is an adaptive Lempel-Ziv-Welch
coding (LZW). coding (LZW).
6.2.2.2. Deflate Coding 6.2.2.2. Deflate Coding
The "zlib" format is defined in [RFC1950] in combination with the The "deflate" format is defined as the "deflate" compression
"deflate" compression mechanism described in [RFC1951]. mechanism (described in [RFC1951]) used inside the "zlib" data format
([RFC1950]).
Note: Some incorrect implementations send the "deflate" compressed
data without the zlib wrapper.
6.2.2.3. Gzip Coding 6.2.2.3. Gzip Coding
The "gzip" format is produced by the file compression program "gzip" The "gzip" format is produced by the file compression program "gzip"
(GNU zip), as described in [RFC1952]. This format is a Lempel-Ziv (GNU zip), as described in [RFC1952]. This format is a Lempel-Ziv
coding (LZ77) with a 32 bit CRC. coding (LZ77) with a 32 bit CRC.
6.2.3. Transfer Coding Registry 6.2.3. Transfer Coding Registry
The HTTP Transfer Coding Registry defines the name space for the The HTTP Transfer Coding Registry defines the name space for the
transfer coding names. transfer coding names.
Registrations MUST include the following fields: Registrations MUST include the following fields:
o Name o Name
o Description o Description
o Pointer to specification text o Pointer to specification text
Names of transfer codings MUST NOT overlap with names of content
codings (Section 2.2 of [Part3]), unless the encoding transformation
is identical (as it is the case for the compression codings defined
in Section 6.2.2).
Values to be added to this name space require expert review and a Values to be added to this name space require expert review and a
specification (see "Expert Review" and "Specification Required" in specification (see "Expert Review" and "Specification Required" in
Section 4.1 of [RFC5226]), and MUST conform to the purpose of Section 4.1 of [RFC5226]), and MUST conform to the purpose of
transfer coding defined in this section. transfer coding defined in this section.
The registry itself is maintained at The registry itself is maintained at
<http://www.iana.org/assignments/http-parameters>. <http://www.iana.org/assignments/http-parameters>.
6.3. Product Tokens 6.3. Product Tokens
skipping to change at page 39, line 13 skipping to change at page 41, line 25
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 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 For the purpose of defining the behavior of caches and non-caching
proxies, we divide HTTP headers into two categories: proxies, we divide HTTP headers into two categories:
o End-to-end headers, which are transmitted to the ultimate o End-to-end headers, which are transmitted to the ultimate
recipient of a request or response. End-to-end headers in recipient of a request or response. End-to-end headers in
responses MUST be stored as part of a cache entry and MUST be responses MUST be stored as part of a cache entry and MUST be
transmitted in any response formed from a cache entry. transmitted in any response formed from a cache entry.
o Hop-by-hop headers, which are meaningful only for a single o Hop-by-hop headers, which are meaningful only for a single
transport-level connection, and are not stored by caches or transport-level connection, and are not stored by caches or
skipping to change at page 40, line 7 skipping to change at page 42, line 15
o Upgrade o Upgrade
All other headers defined by HTTP/1.1 are end-to-end headers. 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 Other hop-by-hop headers MUST be listed in a Connection header
(Section 9.1). (Section 9.1).
7.1.3.2. Non-modifiable Headers 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 Some features of HTTP/1.1, such as Digest Authentication, depend on
the value of certain end-to-end headers. A transparent proxy SHOULD 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 NOT modify an end-to-end header unless the definition of that header
requires or specifically allows that. requires or specifically allows that.
A transparent proxy MUST NOT modify any of the following fields in a 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 request or response, and it MUST NOT add any of these fields if not
already present: already present:
o Content-Location o Content-Location
skipping to change at page 50, line 26 skipping to change at page 52, line 31
it is willing to accept trailer fields in a chunked transfer-coding. it is willing to accept trailer fields in a chunked transfer-coding.
Its value may consist of the keyword "trailers" and/or a comma- Its value may consist of the keyword "trailers" and/or a comma-
separated list of extension transfer-coding names with optional separated list of extension transfer-coding names with optional
accept parameters (as described in Section 6.2). accept parameters (as described in Section 6.2).
TE = "TE" ":" OWS TE-v TE = "TE" ":" OWS TE-v
TE-v = #t-codings TE-v = #t-codings
t-codings = "trailers" / ( transfer-extension [ te-params ] ) t-codings = "trailers" / ( transfer-extension [ te-params ] )
te-params = OWS ";" OWS "q=" qvalue *( te-ext ) te-params = OWS ";" OWS "q=" qvalue *( te-ext )
te-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ] te-ext = OWS ";" OWS token [ "=" word ]
The presence of the keyword "trailers" indicates that the client is The presence of the keyword "trailers" indicates that the client is
willing to accept trailer fields in a chunked transfer-coding, as willing to accept trailer fields in a chunked transfer-coding, as
defined in Section 6.2.1. This keyword is reserved for use with defined in Section 6.2.1. This keyword is reserved for use with
transfer-coding values even though it does not itself represent a transfer-coding values even though it does not itself represent a
transfer-coding. transfer-coding.
Examples of its use are: Examples of its use are:
TE: deflate TE: deflate
skipping to change at page 59, line 22 skipping to change at page 61, line 22
The HTTP Transfer Codings Registry located at The HTTP Transfer Codings Registry located at
<http://www.iana.org/assignments/http-parameters> should be updated <http://www.iana.org/assignments/http-parameters> should be updated
with the registrations below: with the registrations below:
+----------+--------------------------------------+-----------------+ +----------+--------------------------------------+-----------------+
| Name | Description | Reference | | Name | Description | Reference |
+----------+--------------------------------------+-----------------+ +----------+--------------------------------------+-----------------+
| chunked | Transfer in a series of chunks | Section 6.2.1 | | chunked | Transfer in a series of chunks | Section 6.2.1 |
| compress | UNIX "compress" program method | Section 6.2.2.1 | | compress | UNIX "compress" program method | Section 6.2.2.1 |
| deflate | "zlib" format [RFC1950] with | Section 6.2.2.2 | | deflate | "deflate" compression mechanism | Section 6.2.2.2 |
| | "deflate" compression | | | | ([RFC1951]) used inside the "zlib" | |
| | data format ([RFC1950]) | |
| gzip | Same as GNU zip [RFC1952] | Section 6.2.2.3 | | gzip | Same as GNU zip [RFC1952] | Section 6.2.2.3 |
+----------+--------------------------------------+-----------------+ +----------+--------------------------------------+-----------------+
10.5. Upgrade Token Registration 10.5. Upgrade Token Registration
The registration procedure for HTTP Upgrade Tokens -- previously The registration procedure for HTTP Upgrade Tokens -- previously
defined in Section 7.2 of [RFC2817] -- is now defined by defined in Section 7.2 of [RFC2817] -- is now defined by
Section 9.8.1 of this document. Section 9.8.1 of this document.
The HTTP Status Code Registry located at The HTTP Status Code Registry located at
skipping to change at page 62, line 38 skipping to change at page 64, line 38
Dave Raggett, Tony Sanders, and Marc VanHeyningen deserve special Dave Raggett, Tony Sanders, and Marc VanHeyningen deserve special
recognition for their efforts in defining early aspects of the recognition for their efforts in defining early aspects of the
protocol. protocol.
This document has benefited greatly from the comments of all those This document has benefited greatly from the comments of all those
participating in the HTTP-WG. In addition to those already participating in the HTTP-WG. In addition to those already
mentioned, the following individuals have contributed to this mentioned, the following individuals have contributed to this
specification: specification:
Gary Adams, Harald Tveit Alvestrand, Keith Ball, Brian Behlendorf, Gary Adams, Harald Tveit Alvestrand, Keith Ball, Brian Behlendorf,
Paul Burchard, Maurizio Codogno, Mike Cowlishaw, Roman Czyborra, Paul Burchard, Maurizio Codogno, Josh Cohen, Mike Cowlishaw, Roman
Michael A. Dolan, Daniel DuBois, David J. Fiander, Alan Freier, Marc Czyborra, Michael A. Dolan, Daniel DuBois, David J. Fiander, Alan
Hedlund, Greg Herlihy, Koen Holtman, Alex Hopmann, Bob Jernigan, Shel Freier, Marc Hedlund, Greg Herlihy, Koen Holtman, Alex Hopmann, Bob
Kaphan, Rohit Khare, John Klensin, Martijn Koster, Alexei Kosut, Jernigan, Shel Kaphan, Rohit Khare, John Klensin, Martijn Koster,
David M. Kristol, Daniel LaLiberte, Ben Laurie, Paul J. Leach, Albert Alexei Kosut, David M. Kristol, Daniel LaLiberte, Ben Laurie, Paul J.
Lunde, John C. Mallery, Jean-Philippe Martin-Flatin, Mitra, David Leach, Albert Lunde, John C. Mallery, Jean-Philippe Martin-Flatin,
Morris, Gavin Nicol, Ross Patterson, Bill Perry, Jeffrey Perry, Scott Mitra, David Morris, Gavin Nicol, Ross Patterson, Bill Perry, Jeffrey
Powers, Owen Rees, Luigi Rizzo, David Robinson, Marc Salomon, Rich Perry, Scott Powers, Owen Rees, Luigi Rizzo, David Robinson, Marc
Salz, Allan M. Schiffman, Jim Seidman, Chuck Shotton, Eric W. Sink, Salomon, Rich Salz, Allan M. Schiffman, Jim Seidman, Chuck Shotton,
Simon E. Spero, Richard N. Taylor, Robert S. Thau, Bill (BearHeart) Eric W. Sink, Simon E. Spero, Richard N. Taylor, Robert S. Thau, Bill
Weinman, Francois Yergeau, Mary Ellen Zurko, Josh Cohen. (BearHeart) Weinman, Francois Yergeau, Mary Ellen Zurko.
Thanks to the "cave men" of Palo Alto. You know who you are. Thanks to the "cave men" of Palo Alto. You know who you are.
Jim Gettys (the editor of [RFC2616]) wishes particularly to thank Roy Jim Gettys (the editor of [RFC2616]) wishes particularly to thank Roy
Fielding, the editor of [RFC2068], along with John Klensin, Jeff Fielding, the editor of [RFC2068], along with John Klensin, Jeff
Mogul, Paul Leach, Dave Kristol, Koen Holtman, John Franks, Josh Mogul, Paul Leach, Dave Kristol, Koen Holtman, John Franks, Josh
Cohen, Alex Hopmann, Scott Lawrence, and Larry Masinter for their Cohen, Alex Hopmann, Scott Lawrence, and Larry Masinter for their
help. And thanks go particularly to Jeff Mogul and Scott Lawrence help. And thanks go particularly to Jeff Mogul and Scott Lawrence
for performing the "MUST/MAY/SHOULD" audit. for performing the "MUST/MAY/SHOULD" audit.
skipping to change at page 63, line 28 skipping to change at page 65, line 28
constructs defined by David H. Crocker for [RFC5234]. Similarly, it constructs defined by David H. Crocker for [RFC5234]. Similarly, it
reuses many of the definitions provided by Nathaniel Borenstein and reuses many of the definitions provided by Nathaniel Borenstein and
Ned Freed for MIME [RFC2045]. We hope that their inclusion in this Ned Freed for MIME [RFC2045]. We hope that their inclusion in this
specification will help reduce past confusion over the relationship specification will help reduce past confusion over the relationship
between HTTP and Internet mail message formats. between HTTP and Internet mail message formats.
13. References 13. References
13.1. Normative References 13.1. Normative References
[ISO-8859-1] [ISO-8859-1] International Organization for Standardization,
International Organization for Standardization, "Information technology -- 8-bit single-byte coded
"Information technology -- 8-bit single-byte coded graphic graphic character sets -- Part 1: Latin alphabet No.
character sets -- Part 1: Latin alphabet No. 1", ISO/ 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.,
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-09 (work in Semantics", draft-ietf-httpbis-p2-semantics-10 (work in
progress), March 2010. progress), July 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.,
and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload Ed., and J. Reschke, Ed., "HTTP/1.1, part 3: Message
and Content Negotiation", draft-ietf-httpbis-p3-payload-09 Payload and Content Negotiation",
(work in progress), March 2010. draft-ietf-httpbis-p3-payload-10 (work in progress),
July 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.,
and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and Ed., and J. Reschke, Ed., "HTTP/1.1, part 5: Range
Partial Responses", draft-ietf-httpbis-p5-range-09 (work Requests and Partial Responses",
in progress), March 2010. draft-ietf-httpbis-p5-range-10 (work in progress),
July 2010.
[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part Ed., Nottingham, M., Ed., and J. Reschke, Ed.,
6: Caching", draft-ietf-httpbis-p6-cache-09 (work in "HTTP/1.1, part 6: Caching",
progress), March 2010. draft-ietf-httpbis-p6-cache-10 (work in progress),
July 2010.
[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
Specification version 3.3", RFC 1950, May 1996. Format Specification version 3.3", RFC 1950, May 1996.
RFC 1950 is an Informational RFC, thus it may be less RFC 1950 is an Informational RFC, thus it may be less
stable than this specification. On the other hand, this stable than this specification. On the other hand,
downward reference was present since the publication of this downward reference was present since the
RFC 2068 in 1997 ([RFC2068]), therefore it is unlikely to publication of RFC 2068 in 1997 ([RFC2068]), therefore
cause problems in practice. See also [BCP97]. it is unlikely to cause problems in practice. See also
[BCP97].
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format
version 1.3", RFC 1951, May 1996. Specification version 1.3", RFC 1951, May 1996.
RFC 1951 is an Informational RFC, thus it may be less RFC 1951 is an Informational RFC, thus it may be less
stable than this specification. On the other hand, this stable than this specification. On the other hand,
downward reference was present since the publication of this downward reference was present since the
RFC 2068 in 1997 ([RFC2068]), therefore it is unlikely to publication of RFC 2068 in 1997 ([RFC2068]), therefore
cause problems in practice. See also [BCP97]. it is unlikely to cause problems in practice. See also
[BCP97].
[RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G. [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and
Randers-Pehrson, "GZIP file format specification version G. Randers-Pehrson, "GZIP file format specification
4.3", RFC 1952, May 1996. version 4.3", RFC 1952, May 1996.
RFC 1952 is an Informational RFC, thus it may be less RFC 1952 is an Informational RFC, thus it may be less
stable than this specification. On the other hand, this stable than this specification. On the other hand,
downward reference was present since the publication of this downward reference was present since the
RFC 2068 in 1997 ([RFC2068]), therefore it is unlikely to publication of RFC 2068 in 1997 ([RFC2068]), therefore
cause problems in practice. See also [BCP97]. it is unlikely to cause problems in practice. See also
[BCP97].
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
Resource Identifier (URI): Generic Syntax", RFC 3986, "Uniform Resource Identifier (URI): Generic Syntax",
STD 66, January 2005. RFC 3986, STD 66, January 2005.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for
Specifications: ABNF", STD 68, RFC 5234, January 2008. Syntax Specifications: ABNF", STD 68, RFC 5234,
January 2008.
[USASCII] American National Standards Institute, "Coded Character [USASCII] American National Standards Institute, "Coded Character
Set -- 7-bit American Standard Code for Information Set -- 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986. Interchange", ANSI X3.4, 1986.
13.2. Informative References 13.2. Informative References
[BCP97] Klensin, J. and S. Hartman, "Handling Normative References [BCP97] Klensin, J. and S. Hartman, "Handling Normative
to Standards-Track Documents", BCP 97, RFC 4897, References to Standards-Track Documents", BCP 97,
June 2007. RFC 4897, June 2007.
[Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and [Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and
Politics", ACM Transactions on Internet Technology Vol. 1, Politics", ACM Transactions on Internet Technology Vol.
#2, November 2001, <http://arxiv.org/abs/cs.SE/0105018>. 1, #2, November 2001,
<http://arxiv.org/abs/cs.SE/0105018>.
[Nie1997] Nielsen, H., Gettys, J., Prud'hommeaux, E., Lie, H., and [Nie1997] Frystyk, H., Gettys, J., Prud'hommeaux, E., Lie, H.,
C. Lilley, "Network Performance Effects of HTTP/1.1, CSS1, and C. Lilley, "Network Performance Effects of
and PNG", ACM Proceedings of the ACM SIGCOMM '97 HTTP/1.1, CSS1, and PNG", ACM Proceedings of the ACM
conference on Applications, technologies, architectures, SIGCOMM '97 conference on Applications, technologies,
and protocols for computer communication SIGCOMM '97, architectures, and protocols for computer communication
September 1997, SIGCOMM '97, September 1997,
<http://doi.acm.org/10.1145/263105.263157>. <http://doi.acm.org/10.1145/263105.263157>.
[Pad1995] Padmanabhan, V. and J. Mogul, "Improving HTTP Latency", [Pad1995] Padmanabhan, V. and J. Mogul, "Improving HTTP Latency",
Computer Networks and ISDN Systems v. 28, pp. 25-35, Computer Networks and ISDN Systems v. 28, pp. 25-35,
December 1995, December 1995,
<http://portal.acm.org/citation.cfm?id=219094>. <http://portal.acm.org/citation.cfm?id=219094>.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application [RFC1123] Braden, R., "Requirements for Internet Hosts -
and Support", STD 3, RFC 1123, October 1989. Application and Support", STD 3, RFC 1123,
October 1989.
[RFC1305] Mills, D., "Network Time Protocol (Version 3) [RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation", RFC 1305, March 1992. Specification, Implementation", RFC 1305, March 1992.
[RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", [RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work",
RFC 1900, February 1996. RFC 1900, February 1996.
[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen,
Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945,
May 1996.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet
Extensions (MIME) Part One: Format of Internet Message Mail Extensions (MIME) Part One: Format of Internet
Bodies", RFC 2045, November 1996. Message Bodies", RFC 2045, November 1996.
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail
Part Three: Message Header Extensions for Non-ASCII Text", Extensions) Part Three: Message Header Extensions for
RFC 2047, November 1996. Non-ASCII Text", RFC 2047, November 1996.
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", T. Berners-Lee, "Hypertext Transfer Protocol --
RFC 2068, January 1997. HTTP/1.1", RFC 2068, January 1997.
[RFC2109] Kristol, D. and L. Montulli, "HTTP State Management [RFC2109] Kristol, D. and L. Montulli, "HTTP State Management
Mechanism", RFC 2109, February 1997. Mechanism", RFC 2109, February 1997.
[RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use [RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen,
and Interpretation of HTTP Version Numbers", RFC 2145, "Use and Interpretation of HTTP Version Numbers",
May 1997. RFC 2145, May 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within
HTTP/1.1", RFC 2817, May 2000. HTTP/1.1", RFC 2817, May 2000.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2965] Kristol, D. and L. Montulli, "HTTP State Management [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management
Mechanism", RFC 2965, October 2000. Mechanism", RFC 2965, October 2000.
[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, RFC 3864, Procedures for Message Header Fields", BCP 90,
September 2004. RFC 3864, September 2004.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications
Registration Procedures", BCP 13, RFC 4288, December 2005. and Registration Procedures", BCP 13, RFC 4288,
December 2005.
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines
Registration Procedures for New URI Schemes", BCP 115, and Registration Procedures for New URI Schemes",
RFC 4395, February 2006. BCP 115, RFC 4395, February 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing
IANA Considerations Section in RFCs", BCP 26, RFC 5226, an IANA Considerations Section in RFCs", BCP 26,
May 2008. RFC 5226, May 2008.
[RFC5322] Resnick, P., "Internet Message Format", RFC 5322, [RFC5322] Resnick, P., "Internet Message Format", RFC 5322,
October 2008. October 2008.
[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. 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
skipping to change at page 67, line 34 skipping to change at page 69, line 38
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].
Additional rules for requirements on parsing and encoding of dates Additional rules for requirements on parsing and encoding of dates
and other potential problems with date encodings include: and other potential problems with date encodings include:
o HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date o HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date
which appears to be more than 50 years in the future is in fact in which appears to be more than 50 years in the future is in fact in
the past (this helps solve the "year 2000" problem). the past (this helps solve the "year 2000" problem).
o Although all date formats are specified to be case-sensitive,
recipients SHOULD match day, week and timezone names case-
insensitively.
o An HTTP/1.1 implementation MAY internally represent a parsed o An HTTP/1.1 implementation MAY internally represent a parsed
Expires date as earlier than the proper value, but MUST NOT Expires date as earlier than the proper value, but MUST NOT
internally represent a parsed Expires date as later than the internally represent a parsed Expires date as later than the
proper value. proper value.
o All expiration-related calculations MUST be done in GMT. The o All expiration-related calculations MUST be done in GMT. The
local time zone MUST NOT influence the calculation or comparison local time zone MUST NOT influence the calculation or comparison
of an age or expiration time. of an age or expiration time.
o If an HTTP header incorrectly carries a date value with a time o If an HTTP header incorrectly carries a date value with a time
skipping to change at page 72, line 35 skipping to change at page 74, line 44
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
TE = "TE:" OWS TE-v TE = "TE:" OWS TE-v
TE-v = [ ( "," / t-codings ) *( OWS "," [ OWS t-codings ] ) ] TE-v = [ ( "," / t-codings ) *( OWS "," [ OWS t-codings ] ) ]
Trailer = "Trailer:" OWS Trailer-v Trailer = "Trailer:" OWS Trailer-v
Trailer-v = *( "," OWS ) field-name *( OWS "," [ OWS field-name ] ) Trailer-v = *( "," OWS ) field-name *( OWS "," [ OWS field-name ] )
Transfer-Encoding = "Transfer-Encoding:" OWS Transfer-Encoding-v Transfer-Encoding = "Transfer-Encoding:" OWS Transfer-Encoding-v
Transfer-Encoding-v = *( "," OWS ) transfer-coding *( OWS "," [ OWS Transfer-Encoding-v = *( "," OWS ) transfer-coding *( OWS "," [ OWS
transfer-coding ] ) transfer-coding ] )
URI = <URI, defined in [RFC3986], Section 3>
URI-reference = <URI-reference, defined in [RFC3986], Section 4.1> URI-reference = <URI-reference, defined in [RFC3986], Section 4.1>
Upgrade = "Upgrade:" OWS Upgrade-v Upgrade = "Upgrade:" OWS Upgrade-v
Upgrade-v = *( "," OWS ) product *( OWS "," [ OWS product ] ) Upgrade-v = *( "," OWS ) product *( OWS "," [ OWS product ] )
Via = "Via:" OWS Via-v Via = "Via:" OWS Via-v
Via-v = *( "," OWS ) received-protocol RWS received-by [ RWS comment Via-v = *( "," OWS ) received-protocol RWS received-by [ RWS comment
] *( OWS "," [ OWS received-protocol RWS received-by [ RWS comment ] ] *( OWS "," [ OWS received-protocol RWS received-by [ RWS comment ]
] ) ] )
Warning = <Warning, defined in [Part6], Section 3.6> Warning = <Warning, defined in [Part6], Section 3.6>
skipping to change at page 75, line 18 skipping to change at page 77, line 24
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 = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" / special = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" /
DQUOTE / "/" / "[" / "]" / "?" / "=" / "{" / "}" DQUOTE / "/" / "[" / "]" / "?" / "=" / "{" / "}"
start-line = Request-Line / Status-Line start-line = Request-Line / Status-Line
t-codings = "trailers" / ( transfer-extension [ te-params ] ) t-codings = "trailers" / ( transfer-extension [ te-params ] )
tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." / tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." /
"^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA
te-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ] te-ext = OWS ";" OWS token [ "=" word ]
te-params = OWS ";" OWS "q=" qvalue *te-ext te-params = OWS ";" OWS "q=" qvalue *te-ext
time-of-day = hour ":" minute ":" second time-of-day = hour ":" minute ":" second
token = 1*tchar token = 1*tchar
trailer-part = *( entity-header CRLF ) trailer-part = *( entity-header CRLF )
transfer-coding = "chunked" / "compress" / "deflate" / "gzip" / transfer-coding = "chunked" / "compress" / "deflate" / "gzip" /
transfer-extension transfer-extension
transfer-extension = token *( OWS ";" OWS transfer-parameter ) transfer-extension = token *( OWS ";" OWS transfer-parameter )
transfer-parameter = attribute BWS "=" BWS value transfer-parameter = attribute BWS "=" BWS value
uri-host = <host, defined in [RFC3986], Section 3.2.2> uri-host = <host, defined in [RFC3986], Section 3.2.2>
value = token / quoted-string value = word
year = 4DIGIT word = token / quoted-string
year = 4DIGIT
ABNF diagnostics: ABNF diagnostics:
; Chunked-Body defined but not used ; Chunked-Body defined but not used
; Content-Length defined but not used ; Content-Length defined but not used
; HTTP-message defined but not used ; HTTP-message defined but not used
; Host defined but not used ; Host defined but not used
; Request defined but not used ; Request defined but not used
; Response defined but not used ; Response defined but not used
; TE defined but not used ; TE defined but not used
; URI 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 ; 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
skipping to change at page 82, line 32 skipping to change at page 85, line 8
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
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/73>: "Clarification
of the term 'deflate'"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/83>: "OPTIONS * and
proxies"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/143>: "IANA registry
for content/transfer encodings"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/165>: "Case-
sensitivity of HTTP-date"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/200>: "use of term
"word" when talking about header structure"
Partly resolved issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/196>: "Term for the
requested resource's URI"
Index Index
A A
application/http Media Type 58 application/http Media Type 60
C C
cache 13 cache 13
cacheable 14 cacheable 14
chunked (Coding Format) 32 chunked (Coding Format) 34
client 10 client 11
Coding Format Coding Format
chunked 32 chunked 34
compress 34 compress 36
deflate 35 deflate 37
gzip 35 gzip 37
compress (Coding Format) 34 compress (Coding Format) 36
connection 10 connection 11
Connection header 46 Connection header 48
Content-Length header 47 Content-Length header 49
D D
Date header 48 Date header 50
deflate (Coding Format) 35 deflate (Coding Format) 37
downstream 12 downstream 12
E
Effective Request URI 28
G G
gateway 13 gateway 13
Grammar Grammar
absolute-URI 16 absolute-URI 16
ALPHA 7 ALPHA 7
asctime-date 31 asctime-date 33
attribute 32 attribute 33
authority 16 authority 16
BWS 9 BWS 9
chunk 33 chunk 35
chunk-data 33 chunk-data 35
chunk-ext 33 chunk-ext 35
chunk-ext-name 33 chunk-ext-name 35
chunk-ext-val 33 chunk-ext-val 35
chunk-size 33 chunk-size 35
Chunked-Body 33 Chunked-Body 35
comment 21 comment 22
Connection 46 Connection 48
connection-token 46 connection-token 48
Connection-v 46 Connection-v 48
Content-Length 47 Content-Length 49
Content-Length-v 47 Content-Length-v 49
CR 7 CR 7
CRLF 7 CRLF 7
ctext 21 ctext 22
CTL 7 CTL 7
Date 48 Date 50
Date-v 48 Date-v 50
date1 30 date1 32
date2 32 date2 33
date3 32 date3 33
day 30 day 32
day-name 30 day-name 32
day-name-l 30 day-name-l 32
DIGIT 7 DIGIT 7
DQUOTE 7 DQUOTE 7
extension-code 29 extension-code 31
extension-method 25 extension-method 25
field-content 20 field-content 20
field-name 20 field-name 20
field-value 20 field-value 20
general-header 24 general-header 25
GMT 30 GMT 32
header-field 20 header-field 20
HEXDIG 7 HEXDIG 7
Host 49 Host 51
Host-v 49 Host-v 51
hour 30 hour 32
HTTP-date 30 HTTP-date 31
HTTP-message 19 HTTP-message 19
HTTP-Prot-Name 15 HTTP-Prot-Name 15
http-URI 16 http-URI 17
HTTP-Version 15 HTTP-Version 15
https-URI 18 https-URI 18
last-chunk 33 last-chunk 35
LF 7 LF 7
message-body 22 message-body 22
Method 25 Method 25
minute 30 minute 32
month 30 month 32
obs-date 31 obs-date 32
obs-text 10 obs-text 10
OCTET 7 OCTET 7
OWS 9 OWS 9
path-absolute 16 path-absolute 16
port 16 port 16
product 35 product 38
product-version 35 product-version 38
protocol-name 54 protocol-name 56
protocol-version 54 protocol-version 56
pseudonym 54 pseudonym 56
qdtext 10 qdtext 10
qdtext-nf 33 qdtext-nf 35
query 16 query 16
quoted-cpair 22 quoted-cpair 22
quoted-pair 10 quoted-pair 10
quoted-str-nf 33 quoted-str-nf 35
quoted-string 10 quoted-string 10
qvalue 36 qvalue 38
Reason-Phrase 29 Reason-Phrase 31
received-by 54 received-by 56
received-protocol 54 received-protocol 56
Request 25 Request 25
Request-Line 25 Request-Line 25
request-target 25 request-target 26
Response 28 Response 30
rfc850-date 31 rfc850-date 33
rfc1123-date 30 rfc1123-date 32
RWS 9 RWS 9
second 30 second 32
SP 7 SP 7
special 9 special 10
Status-Code 29 Status-Code 31
Status-Line 28 Status-Line 30
t-codings 50 t-codings 52
tchar 9 tchar 10
TE 50 TE 52
te-ext 50 te-ext 52
te-params 50 te-params 52
TE-v 50 TE-v 52
time-of-day 30 time-of-day 32
token 9 token 10
Trailer 51 Trailer 53
trailer-part 33 trailer-part 35
Trailer-v 51 Trailer-v 53
transfer-coding 31 transfer-coding 33
Transfer-Encoding 52 Transfer-Encoding 54
Transfer-Encoding-v 52 Transfer-Encoding-v 54
transfer-extension 31 transfer-extension 33
transfer-parameter 32 transfer-parameter 33
Upgrade 52 Upgrade 54
Upgrade-v 52 Upgrade-v 54
uri-host 16 uri-host 16
URI-reference 16 URI-reference 16
value 32 value 33
VCHAR 7 VCHAR 7
Via 54 Via 56
Via-v 54 Via-v 56
word 10
WSP 7 WSP 7
year 30 year 32
gzip (Coding Format) 35 gzip (Coding Format) 37
H H
header field 19 header field 19
header section 19 header section 19
Headers Headers
Connection 46 Connection 48
Content-Length 47 Content-Length 49
Date 48 Date 50
Host 49 Host 51
TE 50 TE 52
Trailer 51 Trailer 53
Transfer-Encoding 52 Transfer-Encoding 54
Upgrade 52 Upgrade 54
Via 54 Via 56
headers 19 headers 19
Host header 49 Host header 51
http URI scheme 16 http URI scheme 17
https URI scheme 17 https URI scheme 18
I I
inbound 12 inbound 12
M M
Media Type Media Type
application/http 58 application/http 60
message/http 56 message/http 58
message 11 message 11
message/http Media Type 56 message/http Media Type 58
O O
origin server 11 origin server 11
outbound 12 outbound 12
P P
proxy 12 proxy 13
R R
request 11 request 11
resource 16 resource 16
response 11 response 11
reverse proxy 13 reverse proxy 13
S S
server 10 server 11
T T
TE header 50 TE header 52
Trailer header 51 Trailer header 53
Transfer-Encoding header 52 Transfer-Encoding header 54
tunnel 13 tunnel 13
U U
Upgrade header 52 Upgrade header 54
upstream 12 upstream 12
URI scheme URI scheme
http 16 http 17
https 17 https 18
user agent 11 user agent 11
V V
Via header 54 Via header 56
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
Fax: +1-949-706-5305 Fax: +1-949-706-5305
Email: fielding@gbiv.com EMail: fielding@gbiv.com
URI: http://roy.gbiv.com/ URI: http://roy.gbiv.com/
Jim Gettys Jim Gettys
One Laptop per Child Alcatel-Lucent Bell Labs
21 Oak Knoll Road 21 Oak Knoll Road
Carlisle, MA 01741 Carlisle, MA 01741
USA USA
Email: jg@laptop.org EMail: jg@freedesktop.org
URI: http://www.laptop.org/ URI: http://gettys.wordpress.com/
Jeffrey C. Mogul Jeffrey C. Mogul
Hewlett-Packard Company Hewlett-Packard Company
HP Labs, Large Scale Systems Group HP Labs, Large Scale Systems Group
1501 Page Mill Road, MS 1177 1501 Page Mill Road, MS 1177
Palo Alto, CA 94304 Palo Alto, CA 94304
USA USA
Email: JeffMogul@acm.org EMail: JeffMogul@acm.org
Henrik Frystyk Nielsen Henrik Frystyk Nielsen
Microsoft Corporation Microsoft Corporation
1 Microsoft Way 1 Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
USA USA
Email: henrikn@microsoft.com EMail: henrikn@microsoft.com
Larry Masinter Larry Masinter
Adobe Systems, Incorporated Adobe Systems, Incorporated
345 Park Ave 345 Park Ave
San Jose, CA 95110 San Jose, CA 95110
USA USA
Email: LMM@acm.org EMail: LMM@acm.org
URI: http://larry.masinter.net/ URI: http://larry.masinter.net/
Paul J. Leach Paul J. Leach
Microsoft Corporation Microsoft Corporation
1 Microsoft Way 1 Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
Email: paulle@microsoft.com EMail: paulle@microsoft.com
Tim Berners-Lee Tim Berners-Lee
World Wide Web Consortium World Wide Web Consortium
MIT Computer Science and Artificial Intelligence Laboratory MIT Computer Science and Artificial Intelligence Laboratory
The Stata Center, Building 32 The Stata Center, Building 32
32 Vassar Street 32 Vassar Street
Cambridge, MA 02139 Cambridge, MA 02139
USA USA
Email: timbl@w3.org EMail: timbl@w3.org
URI: http://www.w3.org/People/Berners-Lee/ URI: http://www.w3.org/People/Berners-Lee/
Yves Lafon (editor) Yves Lafon (editor)
World Wide Web Consortium World Wide Web Consortium
W3C / ERCIM W3C / ERCIM
2004, rte des Lucioles 2004, rte des Lucioles
Sophia-Antipolis, AM 06902 Sophia-Antipolis, AM 06902
France France
Email: ylafon@w3.org EMail: ylafon@w3.org
URI: http://www.raubacapeu.net/people/yves/ URI: http://www.raubacapeu.net/people/yves/
Julian F. Reschke (editor) Julian F. Reschke (editor)
greenbytes GmbH greenbytes GmbH
Hafenweg 16 Hafenweg 16
Muenster, NW 48155 Muenster, NW 48155
Germany Germany
Phone: +49 251 2807760 Phone: +49 251 2807760
Fax: +49 251 2807761 Fax: +49 251 2807761
Email: julian.reschke@greenbytes.de EMail: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/ URI: http://greenbytes.de/tech/webdav/
 End of changes. 132 change blocks. 
407 lines changed or deleted 511 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/