draft-ietf-httpbis-p1-messaging-13.txt   draft-ietf-httpbis-p1-messaging-14.txt 
HTTPbis Working Group R. Fielding, Ed. HTTPbis Working Group R. Fielding, Ed.
Internet-Draft Adobe Internet-Draft Adobe
Obsoletes: 2145,2616 J. Gettys Obsoletes: 2145,2616 (if approved) J. Gettys
(if approved) Alcatel-Lucent Updates: 2817 (if approved) Alcatel-Lucent
Updates: 2817 (if approved) J. Mogul Intended status: Standards Track J. Mogul
Intended status: Standards Track HP Expires: October 20, 2011 HP
Expires: September 15, 2011 H. Frystyk H. Frystyk
Microsoft Microsoft
L. Masinter L. Masinter
Adobe Adobe
P. Leach P. Leach
Microsoft Microsoft
T. Berners-Lee T. Berners-Lee
W3C/MIT W3C/MIT
Y. Lafon, Ed. Y. Lafon, Ed.
W3C W3C
J. Reschke, Ed. J. Reschke, Ed.
greenbytes greenbytes
March 14, 2011 April 18, 2011
HTTP/1.1, part 1: URIs, Connections, and Message Parsing HTTP/1.1, part 1: URIs, Connections, and Message Parsing
draft-ietf-httpbis-p1-messaging-13 draft-ietf-httpbis-p1-messaging-14
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), which is archived at
at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
The current issues list is 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.14. The changes in this draft are summarized in Appendix D.15.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
skipping to change at page 2, line 17 skipping to change at page 2, line 22
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 15, 2011. This Internet-Draft will expire on October 20, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 45 skipping to change at page 3, line 49
6.3. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 41 6.3. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 41
6.4. Quality Values . . . . . . . . . . . . . . . . . . . . . . 41 6.4. Quality Values . . . . . . . . . . . . . . . . . . . . . . 41
7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 41 7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 41
7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 42 7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 42
7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 42 7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 42
7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 42 7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 42
7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 44 7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 44
7.1.4. Practical Considerations . . . . . . . . . . . . . . . 46 7.1.4. Practical Considerations . . . . . . . . . . . . . . . 46
7.2. Message Transmission Requirements . . . . . . . . . . . . 47 7.2. Message Transmission Requirements . . . . . . . . . . . . 47
7.2.1. Persistent Connections and Flow Control . . . . . . . 47 7.2.1. Persistent Connections and Flow Control . . . . . . . 47
7.2.2. Monitoring Connections for Error Status Messages . . . 47 7.2.2. Monitoring Connections for Error Status Messages . . . 48
7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 48 7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 48
7.2.4. Client Behavior if Server Prematurely Closes 7.2.4. Client Behavior if Server Prematurely Closes
Connection . . . . . . . . . . . . . . . . . . . . . . 50 Connection . . . . . . . . . . . . . . . . . . . . . . 50
8. Miscellaneous notes that might disappear . . . . . . . . . . . 51 8. Miscellaneous notes that might disappear . . . . . . . . . . . 51
8.1. Scheme aliases considered harmful . . . . . . . . . . . . 51 8.1. Scheme aliases considered harmful . . . . . . . . . . . . 51
8.2. Use of HTTP for proxy communication . . . . . . . . . . . 51 8.2. Use of HTTP for proxy communication . . . . . . . . . . . 51
8.3. Interception of HTTP for access control . . . . . . . . . 51 8.3. Interception of HTTP for access control . . . . . . . . . 51
8.4. Use of HTTP by other protocols . . . . . . . . . . . . . . 51 8.4. Use of HTTP by other protocols . . . . . . . . . . . . . . 51
8.5. Use of HTTP by media type specification . . . . . . . . . 51 8.5. Use of HTTP by media type specification . . . . . . . . . 51
9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 51 9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 51
9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 51 9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 51
9.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 53 9.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 53
9.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 9.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
9.3.1. Clockless Origin Server Operation . . . . . . . . . . 54 9.3.1. Clockless Origin Server Operation . . . . . . . . . . 54
9.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 9.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
9.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 9.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
9.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 57 9.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 57
9.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 58 9.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 57
9.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 58 9.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 58
9.8.1. Upgrade Token Registry . . . . . . . . . . . . . . . . 59 9.8.1. Upgrade Token Registry . . . . . . . . . . . . . . . . 59
9.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 9.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61
10.1. Header Field Registration . . . . . . . . . . . . . . . . 62 10.1. Header Field Registration . . . . . . . . . . . . . . . . 61
10.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 62 10.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 62
10.3. Internet Media Type Registrations . . . . . . . . . . . . 62 10.3. Internet Media Type Registrations . . . . . . . . . . . . 62
10.3.1. Internet Media Type message/http . . . . . . . . . . . 62 10.3.1. Internet Media Type message/http . . . . . . . . . . . 62
10.3.2. Internet Media Type application/http . . . . . . . . . 64 10.3.2. Internet Media Type application/http . . . . . . . . . 63
10.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 65 10.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 64
10.5. Upgrade Token Registration . . . . . . . . . . . . . . . . 65 10.5. Upgrade Token Registration . . . . . . . . . . . . . . . . 65
11. Security Considerations . . . . . . . . . . . . . . . . . . . 65 11. Security Considerations . . . . . . . . . . . . . . . . . . . 65
11.1. Personal Information . . . . . . . . . . . . . . . . . . . 66 11.1. Personal Information . . . . . . . . . . . . . . . . . . . 65
11.2. Abuse of Server Log Information . . . . . . . . . . . . . 66 11.2. Abuse of Server Log Information . . . . . . . . . . . . . 66
11.3. Attacks Based On File and Path Names . . . . . . . . . . . 66 11.3. Attacks Based On File and Path Names . . . . . . . . . . . 66
11.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 66 11.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 66
11.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 67 11.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 67
11.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 68 11.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 68
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 68 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 68
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 69 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 69
13.1. Normative References . . . . . . . . . . . . . . . . . . . 69 13.1. Normative References . . . . . . . . . . . . . . . . . . . 69
13.2. Informative References . . . . . . . . . . . . . . . . . . 71 13.2. Informative References . . . . . . . . . . . . . . . . . . 71
Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 74 Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 73
Appendix B. HTTP Version History . . . . . . . . . . . . . . . . 75 Appendix B. HTTP Version History . . . . . . . . . . . . . . . . 74
B.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 75 B.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 75
B.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 76 B.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 75
B.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 76 B.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 76
B.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 77 B.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 76
Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 77 Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 77
Appendix D. Change Log (to be removed by RFC Editor before Appendix D. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 82 publication) . . . . . . . . . . . . . . . . . . . . 81
D.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 82 D.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 81
D.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 82 D.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 81
D.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 83 D.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 83
D.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 84 D.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 84
D.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 85 D.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 84
D.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 85 D.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 85
D.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 86 D.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 85
D.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 87 D.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 86
D.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 87 D.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 87
D.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 88 D.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 87
D.11. Since draft-ietf-httpbis-p1-messaging-09 . . . . . . . . . 88 D.11. Since draft-ietf-httpbis-p1-messaging-09 . . . . . . . . . 88
D.12. Since draft-ietf-httpbis-p1-messaging-10 . . . . . . . . . 89 D.12. Since draft-ietf-httpbis-p1-messaging-10 . . . . . . . . . 88
D.13. Since draft-ietf-httpbis-p1-messaging-11 . . . . . . . . . 89 D.13. Since draft-ietf-httpbis-p1-messaging-11 . . . . . . . . . 89
D.14. Since draft-ietf-httpbis-p1-messaging-12 . . . . . . . . . 90 D.14. Since draft-ietf-httpbis-p1-messaging-12 . . . . . . . . . 89
D.15. Since draft-ietf-httpbis-p1-messaging-13 . . . . . . . . . 90
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
1. Introduction 1. Introduction
The Hypertext Transfer Protocol (HTTP) is an application-level The Hypertext Transfer Protocol (HTTP) is an application-level
request/response protocol that uses extensible semantics and MIME- request/response protocol that uses extensible semantics and MIME-
like message payloads for flexible interaction with network-based like message payloads for flexible interaction with network-based
hypertext information systems. HTTP relies upon the Uniform Resource hypertext information systems. HTTP relies upon the Uniform Resource
Identifier (URI) standard [RFC3986] to indicate the target resource Identifier (URI) standard [RFC3986] to indicate the target resource
and relationships between resources. Messages are passed in a format and relationships between resources. Messages are passed in a format
skipping to change at page 10, line 33 skipping to change at page 10, line 33
HTTP was created for the World Wide Web architecture and has evolved HTTP was created for the World Wide Web architecture and has evolved
over time to support the scalability needs of a worldwide hypertext over time to support the scalability needs of a worldwide hypertext
system. Much of that architecture is reflected in the terminology system. Much of that architecture is reflected in the terminology
and syntax productions used to define HTTP. and syntax productions used to define HTTP.
2.1. Client/Server Messaging 2.1. Client/Server Messaging
HTTP is a stateless request/response protocol that operates by HTTP is a stateless request/response protocol that operates by
exchanging messages across a reliable transport or session-layer exchanging messages across a reliable transport or session-layer
connection. An HTTP "client" is a program that establishes a "connection". An HTTP "client" is a program that establishes a
connection to a server for the purpose of sending one or more HTTP connection to a server for the purpose of sending one or more HTTP
requests. An HTTP "server" is a program that accepts connections in requests. An HTTP "server" is a program that accepts connections in
order to service HTTP requests by sending HTTP responses. order to service HTTP requests by sending HTTP responses.
Note that the terms client and server refer only to the roles that Note that the terms client and server refer only to the roles that
these programs perform for a particular connection. The same program these programs perform for a particular connection. The same program
might act as a client on some connections and a server on others. We might act as a client on some connections and a server on others. We
use the term "user agent" to refer to the program that initiates a use the term "user agent" to refer to the program that initiates a
request, such as a WWW browser, editor, or spider (web-traversing request, such as a WWW browser, editor, or spider (web-traversing
robot), and the term "origin server" to refer to the program that can robot), and the term "origin server" to refer to the program that can
skipping to change at page 12, line 51 skipping to change at page 12, line 51
chain, or to all connections along the chain. Although the diagram chain, or to all connections along the chain. Although the diagram
is linear, each participant might be engaged in multiple, is linear, each participant might be engaged in multiple,
simultaneous communications. For example, B might be receiving simultaneous communications. For example, B might be receiving
requests from many clients other than A, and/or forwarding requests requests from many clients other than A, and/or forwarding requests
to servers other than C, at the same time that it is handling A's to servers other than C, at the same time that it is handling A's
request. request.
We use the terms "upstream" and "downstream" to describe various We use the terms "upstream" and "downstream" to describe various
requirements in relation to the directional flow of a message: all requirements in relation to the directional flow of a message: all
messages flow from upstream to downstream. Likewise, we use the messages flow from upstream to downstream. Likewise, we use the
terms "inbound" and "outbound" to refer to directions in relation to terms inbound and outbound to refer to directions in relation to the
the request path: "inbound" means toward the origin server and request path: "inbound" means toward the origin server and "outbound"
"outbound" means toward the user agent. means toward the user agent.
A "proxy" is a message forwarding agent that is selected by the A "proxy" is a message forwarding agent that is selected by the
client, usually via local configuration rules, to receive requests client, usually via local configuration rules, to receive requests
for some type(s) of absolute URI and attempt to satisfy those for some type(s) of absolute URI and attempt to satisfy those
requests via translation through the HTTP interface. Some requests via translation through the HTTP interface. Some
translations are minimal, such as for proxy requests for "http" URIs, translations are minimal, such as for proxy requests for "http" URIs,
whereas other requests might require translation to and from entirely whereas other requests might require translation to and from entirely
different application-layer protocols. Proxies are often used to different application-layer protocols. Proxies are often used to
group an organization's HTTP requests through a common intermediary group an organization's HTTP requests through a common intermediary
for the sake of security, annotation services, or shared caching. for the sake of security, annotation services, or shared caching.
skipping to change at page 24, line 40 skipping to change at page 24, line 40
property of the message, not of the payload, and thus MAY be added or property of the message, not of the payload, and thus MAY be added or
removed by any implementation along the request/response chain under removed by any implementation along the request/response chain under
the constraints found in Section 6.2. the constraints found in Section 6.2.
If a message is received that has multiple Content-Length header If a message is received that has multiple Content-Length header
fields (Section 9.2) with field-values consisting of the same decimal fields (Section 9.2) with field-values consisting of the same decimal
value, or a single Content-Length header field with a field value value, or a single Content-Length header field with a field value
containing a list of identical decimal values (e.g., "Content-Length: containing a list of identical decimal values (e.g., "Content-Length:
42, 42"), indicating that duplicate Content-Length header fields have 42, 42"), indicating that duplicate Content-Length header fields have
been generated or combined by an upstream message processor, then the been generated or combined by an upstream message processor, then the
recipient MUST replace the duplicated fields or field-values with a recipient MUST either reject the message as invalid or replace the
single valid Content-Length field containing that decimal value prior duplicated field-values with a single valid Content-Length field
to determining the message-body length. containing that decimal value prior to determining the message-body
length.
The rules for when a message-body is allowed in a message differ for The rules for when a message-body is allowed in a message differ for
requests and responses. requests and responses.
The presence of a message-body in a request is signaled by the The presence of a message-body in a request is signaled by the
inclusion of a Content-Length or Transfer-Encoding header field in inclusion of a Content-Length or Transfer-Encoding header field in
the request's header fields, even if the request method does not the request's header fields, even if the request method does not
define any use for a message-body. This allows the request message define any use for a message-body. This allows the request message
framing algorithm to be independent of method semantics. framing algorithm to be independent of method semantics.
skipping to change at page 45, line 33 skipping to change at page 45, line 33
Some features of HTTP/1.1, such as Digest Authentication, depend on Some features of HTTP/1.1, such as Digest Authentication, depend on
the value of certain end-to-end header fields. A non-transforming the value of certain end-to-end header fields. A non-transforming
proxy SHOULD NOT modify an end-to-end header field unless the proxy SHOULD NOT modify an end-to-end header field unless the
definition of that header field requires or specifically allows that. definition of that header field requires or specifically allows that.
A non-transforming proxy MUST NOT modify any of the following fields A non-transforming proxy MUST NOT modify any of the following fields
in a request or response, and it MUST NOT add any of these fields if in a request or response, and it MUST NOT add any of these fields if
not already present: not already present:
o Allow
o Content-Location o Content-Location
o Content-MD5 o Content-MD5
o ETag o ETag
o Last-Modified o Last-Modified
o Server
A non-transforming proxy MUST NOT modify any of the following fields A non-transforming proxy MUST NOT modify any of the following fields
in a response: in a response:
o Expires o Expires
but it MAY add any of these fields if not already present. If an but it MAY add any of these fields if not already present. If an
Expires header field is added, it MUST be given a field-value Expires header field is added, it MUST be given a field-value
identical to that of the Date header field in that response. identical to that of the Date header field in that response.
A proxy MUST NOT modify or add any of the following fields in a A proxy MUST NOT modify or add any of the following fields in a
skipping to change at page 52, line 5 skipping to change at page 52, line 7
be forwarded downstream by a proxy or gateway. This mechanism also be forwarded downstream by a proxy or gateway. This mechanism also
allows the sender to indicate which HTTP header fields used in the allows the sender to indicate which HTTP header fields used in the
message are only intended for the immediate recipient ("hop-by-hop"), message are only intended for the immediate recipient ("hop-by-hop"),
as opposed to all recipients on the chain ("end-to-end"), enabling as opposed to all recipients on the chain ("end-to-end"), enabling
the message to be self-descriptive and allowing future connection- the message to be self-descriptive and allowing future connection-
specific extensions to be deployed in HTTP without fear that they specific extensions to be deployed in HTTP without fear that they
will be blindly forwarded by previously deployed intermediaries. will be blindly forwarded by previously deployed intermediaries.
The Connection header field's value has the following grammar: The Connection header field's value has the following grammar:
Connection = "Connection" ":" OWS Connection-v Connection = 1#connection-token
Connection-v = 1#connection-token
connection-token = token connection-token = token
A proxy or gateway MUST parse a received Connection header field A proxy or gateway MUST parse a received Connection header field
before a message is forwarded and, for each connection-token in this before a message is forwarded and, for each connection-token in this
field, remove any header field(s) from the message with the same name field, remove any header field(s) from the message with the same name
as the connection-token, and then remove the Connection header field as the connection-token, and then remove the Connection header field
itself or replace it with the sender's own connection options for the itself or replace it with the sender's own connection options for the
forwarded message. forwarded message.
A sender MUST NOT include field-names in the Connection header field- A sender MUST NOT include field-names in the Connection header field-
skipping to change at page 53, line 23 skipping to change at page 53, line 25
body, in decimal number of octets, for any message other than a body, in decimal number of octets, for any message other than a
response to a HEAD request or a response with a status code of 304. response to a HEAD request or a response with a status code of 304.
In the case of a response to a HEAD request, Content-Length indicates In the case of a response to a HEAD request, Content-Length indicates
the size of the payload body (not including any potential transfer- the size of the payload body (not including any potential transfer-
coding) that would have been sent had the request been a GET. In the coding) that would have been sent had the request been a GET. In the
case of a 304 (Not Modified) response to a GET request, Content- case of a 304 (Not Modified) response to a GET request, Content-
Length indicates the size of the payload body (not including any Length indicates the size of the payload body (not including any
potential transfer-coding) that would have been sent in a 200 (OK) potential transfer-coding) that would have been sent in a 200 (OK)
response. response.
Content-Length = "Content-Length" ":" OWS 1*Content-Length-v Content-Length = 1*DIGIT
Content-Length-v = 1*DIGIT
An example is An example is
Content-Length: 3495 Content-Length: 3495
Implementations SHOULD use this field to indicate the message-body Implementations SHOULD use this field to indicate the message-body
length when no transfer-coding is being applied and the payload's length when no transfer-coding is being applied and the payload's
body length can be determined prior to being transferred. body length can be determined prior to being transferred.
Section 3.3 describes how recipients determine the length of a Section 3.3 describes how recipients determine the length of a
message-body. message-body.
skipping to change at page 53, line 50 skipping to change at page 53, line 51
field used within the "message/external-body" content-type. field used within the "message/external-body" content-type.
9.3. Date 9.3. Date
The "Date" header field represents the date and time at which the The "Date" header field represents the date and time at which the
message was originated, having the same semantics as the Origination message was originated, having the same semantics as the Origination
Date Field (orig-date) defined in Section 3.6.1 of [RFC5322]. The Date Field (orig-date) defined in Section 3.6.1 of [RFC5322]. The
field value is an HTTP-date, as described in Section 6.1; it MUST be field value is an HTTP-date, as described in Section 6.1; it MUST be
sent in rfc1123-date format. sent in rfc1123-date format.
Date = "Date" ":" OWS Date-v Date = 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
skipping to change at page 55, line 14 skipping to change at page 55, line 14
9.4. Host 9.4. Host
The "Host" header field in a request provides the host and port The "Host" header field in a request provides the host and port
information from the target resource's URI, enabling the origin information from the target resource's URI, enabling the origin
server to distinguish between resources while servicing requests for server to distinguish between resources while servicing requests for
multiple host names on a single IP address. Since the Host field- multiple host names on a single IP address. Since the Host field-
value is critical information for handling a request, it SHOULD be value is critical information for handling a request, it SHOULD be
sent as the first header field following the Request-Line. sent as the first header field following the Request-Line.
Host = "Host" ":" OWS Host-v Host = uri-host [ ":" port ] ; Section 2.6.1
Host-v = uri-host [ ":" port ] ; Section 2.6.1
A client MUST send a Host header field in all HTTP/1.1 request A client MUST send a Host header field in all HTTP/1.1 request
messages. If the target resource's URI includes an authority messages. If the target resource's URI includes an authority
component, then the Host field-value MUST be identical to that component, then the Host field-value MUST be identical to that
authority component after excluding any userinfo (Section 2.6.1). If authority component after excluding any userinfo (Section 2.6.1). If
the authority component is missing or undefined for the target the authority component is missing or undefined for the target
resource's URI, then the Host header field MUST be sent with an empty resource's URI, then the Host header field MUST be sent with an empty
field-value. field-value.
For example, a GET request to the origin server for For example, a GET request to the origin server for
skipping to change at page 56, line 20 skipping to change at page 56, line 19
9.5. TE 9.5. TE
The "TE" header field indicates what extension transfer-codings it is The "TE" header field indicates what extension transfer-codings it is
willing to accept in the response, and whether or not it is willing willing to accept in the response, and whether or not it is willing
to accept trailer fields in a chunked transfer-coding. to accept trailer fields in a chunked transfer-coding.
Its value consists of the keyword "trailers" and/or a comma-separated Its value consists of the keyword "trailers" and/or a comma-separated
list of extension transfer-coding names with optional accept list of extension transfer-coding names with optional accept
parameters (as described in Section 6.2). parameters (as described in Section 6.2).
TE = "TE" ":" OWS TE-v TE = #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 [ "=" word ] te-ext = OWS ";" OWS token [ "=" word ]
The presence of the keyword "trailers" indicates that the client is The presence of the keyword "trailers" indicates that the client is
willing to accept trailer fields in a chunked transfer-coding, as willing to accept trailer fields in a chunked transfer-coding, as
defined in Section 6.2.1. This keyword is reserved for use with defined in Section 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.
skipping to change at page 57, line 29 skipping to change at page 57, line 28
If the TE field-value is empty or if no TE field is present, the only If the TE field-value is empty or if no TE field is present, the only
transfer-coding is "chunked". A message with no transfer-coding is transfer-coding is "chunked". A message with no transfer-coding is
always acceptable. always acceptable.
9.6. Trailer 9.6. Trailer
The "Trailer" header field indicates that the given set of header The "Trailer" header field indicates that the given set of header
fields is present in the trailer of a message encoded with chunked fields is present in the trailer of a message encoded with chunked
transfer-coding. transfer-coding.
Trailer = "Trailer" ":" OWS Trailer-v Trailer = 1#field-name
Trailer-v = 1#field-name
An HTTP/1.1 message SHOULD include a Trailer header field in a An HTTP/1.1 message SHOULD include a Trailer header field in a
message using chunked transfer-coding with a non-empty trailer. message using chunked transfer-coding with a non-empty trailer.
Doing so allows the recipient to know which header fields to expect Doing so allows the recipient to know which header fields to expect
in the trailer. in the trailer.
If no Trailer header field is present, the trailer SHOULD NOT include If no Trailer header field is present, the trailer SHOULD NOT include
any header fields. See Section 6.2.1 for restrictions on the use of any header fields. See Section 6.2.1 for restrictions on the use of
trailer fields in a "chunked" transfer-coding. trailer fields in a "chunked" transfer-coding.
skipping to change at page 58, line 13 skipping to change at page 58, line 7
o Trailer o Trailer
9.7. Transfer-Encoding 9.7. Transfer-Encoding
The "Transfer-Encoding" header field indicates what transfer-codings The "Transfer-Encoding" header field indicates what transfer-codings
(if any) have been applied to the message body. It differs from (if any) have been applied to the message body. It differs from
Content-Encoding (Section 2.2 of [Part3]) in that transfer-codings Content-Encoding (Section 2.2 of [Part3]) in that transfer-codings
are a property of the message (and therefore are removed by are a property of the message (and therefore are removed by
intermediaries), whereas content-codings are not. intermediaries), whereas content-codings are not.
Transfer-Encoding = "Transfer-Encoding" ":" OWS Transfer-Encoding = 1#transfer-coding
Transfer-Encoding-v
Transfer-Encoding-v = 1#transfer-coding
Transfer-codings are defined in Section 6.2. An example is: Transfer-codings are defined in Section 6.2. An example is:
Transfer-Encoding: chunked Transfer-Encoding: chunked
If multiple encodings have been applied to a representation, the If multiple encodings have been applied to a representation, the
transfer-codings MUST be listed in the order in which they were transfer-codings MUST be listed in the order in which they were
applied. Additional information about the encoding parameters MAY be applied. Additional information about the encoding parameters MAY be
provided by other header fields not defined by this specification. provided by other header fields not defined by this specification.
Many older HTTP/1.0 applications do not understand the Transfer- Many older HTTP/1.0 applications do not understand the Transfer-
Encoding header field. Encoding header field.
9.8. Upgrade 9.8. Upgrade
The "Upgrade" header field allows the client to specify what The "Upgrade" header field allows the client to specify what
additional communication protocols it would like to use, if the additional communication protocols it would like to use, if the
server chooses to switch protocols. Servers can use it to indicate server chooses to switch protocols. Servers can use it to indicate
what protocols they are willing to switch to. what protocols they are willing to switch to.
Upgrade = "Upgrade" ":" OWS Upgrade-v Upgrade = 1#product
Upgrade-v = 1#product
For example, For example,
Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
The Upgrade header field is intended to provide a simple mechanism The Upgrade header field is intended to provide a simple mechanism
for transition from HTTP/1.1 to some other, incompatible protocol. for transition from HTTP/1.1 to some other, incompatible protocol.
It does so by allowing the client to advertise its desire to use It does so by allowing the client to advertise its desire to use
another protocol, such as a later version of HTTP with a higher major another protocol, such as a later version of HTTP with a higher major
version number, even though the current request has been made using version number, even though the current request has been made using
skipping to change at page 60, line 38 skipping to change at page 60, line 28
The "Via" header field MUST be sent by a proxy or gateway to indicate The "Via" header field MUST be sent by a proxy or gateway to indicate
the intermediate protocols and recipients between the user agent and the intermediate protocols and recipients between the user agent and
the server on requests, and between the origin server and the client the server on requests, and between the origin server and the client
on responses. It is analogous to the "Received" field used by email on responses. It is analogous to the "Received" field used by email
systems (Section 3.6.7 of [RFC5322]) and is intended to be used for systems (Section 3.6.7 of [RFC5322]) and is intended to be used for
tracking message forwards, avoiding request loops, and identifying tracking message forwards, avoiding request loops, and identifying
the protocol capabilities of all senders along the request/response the protocol capabilities of all senders along the request/response
chain. chain.
Via = "Via" ":" OWS Via-v Via = 1#( received-protocol RWS received-by
Via-v = 1#( received-protocol RWS received-by
[ RWS comment ] ) [ RWS comment ] )
received-protocol = [ protocol-name "/" ] protocol-version received-protocol = [ protocol-name "/" ] protocol-version
protocol-name = token protocol-name = token
protocol-version = token protocol-version = token
received-by = ( uri-host [ ":" port ] ) / pseudonym received-by = ( uri-host [ ":" port ] ) / pseudonym
pseudonym = token pseudonym = token
The received-protocol indicates the protocol version of the message The received-protocol indicates the protocol version of the message
received by the server or client along each segment of the request/ received by the server or client along each segment of the request/
response chain. The received-protocol version is appended to the Via response chain. The received-protocol version is appended to the Via
skipping to change at page 69, line 40 skipping to change at page 69, line 29
technology -- 8-bit single-byte coded technology -- 8-bit single-byte coded
graphic character sets -- Part 1: graphic character sets -- Part 1:
Latin alphabet No. 1", ISO/ Latin alphabet No. 1", ISO/
IEC 8859-1:1998, 1998. IEC 8859-1:1998, 1998.
[Part2] Fielding, R., Ed., Gettys, J., Mogul, [Part2] Fielding, R., Ed., Gettys, J., Mogul,
J., Frystyk, H., Masinter, L., Leach, J., Frystyk, H., Masinter, L., Leach,
P., Berners-Lee, T., Lafon, Y., Ed., P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part and J. Reschke, Ed., "HTTP/1.1, part
2: Message Semantics", 2: Message Semantics",
draft-ietf-httpbis-p2-semantics-13 draft-ietf-httpbis-p2-semantics-14
(work in progress), March 2011. (work in progress), April 2011.
[Part3] Fielding, R., Ed., Gettys, J., Mogul, [Part3] Fielding, R., Ed., Gettys, J., Mogul,
J., Frystyk, H., Masinter, L., Leach, J., Frystyk, H., Masinter, L., Leach,
P., Berners-Lee, T., Lafon, Y., Ed., P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part and J. Reschke, Ed., "HTTP/1.1, part
3: Message Payload and Content 3: Message Payload and Content
Negotiation", Negotiation",
draft-ietf-httpbis-p3-payload-13 (work draft-ietf-httpbis-p3-payload-14 (work
in progress), March 2011. in progress), April 2011.
[Part6] Fielding, R., Ed., Gettys, J., Mogul, [Part6] Fielding, R., Ed., Gettys, J., Mogul,
J., Frystyk, H., Masinter, L., Leach, J., Frystyk, H., Masinter, L., Leach,
P., Berners-Lee, T., Lafon, Y., Ed., P., Berners-Lee, T., Lafon, Y., Ed.,
Nottingham, M., Ed., and J. Reschke, Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP/1.1, part 6: Caching", Ed., "HTTP/1.1, part 6: Caching",
draft-ietf-httpbis-p6-cache-13 (work draft-ietf-httpbis-p6-cache-14 (work
in progress), March 2011. in progress), April 2011.
[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB
Compressed Data Format Specification Compressed Data Format Specification
version 3.3", RFC 1950, May 1996. version 3.3", RFC 1950, May 1996.
RFC 1950 is an Informational RFC, thus RFC 1950 is an Informational RFC, thus
it might be less stable than this it might be less stable than this
specification. On the other hand, specification. On the other hand,
this downward reference was present this downward reference was present
since the publication of RFC 2068 in since the publication of RFC 2068 in
skipping to change at page 77, line 39 skipping to change at page 77, line 23
Update use of abs_path production from RFC 1808 to the path-absolute Update use of abs_path production from RFC 1808 to the path-absolute
+ query components of RFC 3986. State that the asterisk form is + query components of RFC 3986. State that the asterisk form is
allowed for the OPTIONS request method only. (Section 4.1.2) allowed for the OPTIONS request method only. (Section 4.1.2)
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)
Change ABNF productions for header fields to only define the field
value. (Section 9)
Clarify exactly when close connection options must be sent. Clarify exactly when close connection options must be sent.
(Section 9.1) (Section 9.1)
Define the semantics of the "Upgrade" header field in responses other Define the semantics of the "Upgrade" header field in responses other
than 101 (this was incorporated from [RFC2817]). (Section 9.8) than 101 (this was incorporated from [RFC2817]). (Section 9.8)
Appendix C. Collected ABNF Appendix C. Collected ABNF
BWS = OWS BWS = OWS
Chunked-Body = *chunk last-chunk trailer-part CRLF Chunked-Body = *chunk last-chunk trailer-part CRLF
Connection = "Connection:" OWS Connection-v Connection = *( "," OWS ) connection-token *( OWS "," [ OWS
Connection-v = *( "," OWS ) connection-token *( OWS "," [ OWS
connection-token ] ) connection-token ] )
Content-Length = 1*DIGIT
Content-Length = "Content-Length:" OWS 1*Content-Length-v Date = HTTP-date
Content-Length-v = 1*DIGIT
Date = "Date:" OWS Date-v
Date-v = HTTP-date
GMT = %x47.4D.54 ; GMT GMT = %x47.4D.54 ; GMT
HTTP-Prot-Name = %x48.54.54.50 ; HTTP HTTP-Prot-Name = %x48.54.54.50 ; HTTP
HTTP-Version = HTTP-Prot-Name "/" 1*DIGIT "." 1*DIGIT HTTP-Version = HTTP-Prot-Name "/" 1*DIGIT "." 1*DIGIT
HTTP-date = rfc1123-date / obs-date HTTP-date = rfc1123-date / obs-date
HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body
] ]
Host = "Host:" OWS Host-v Host = uri-host [ ":" port ]
Host-v = uri-host [ ":" port ]
Method = token Method = token
OWS = *( [ obs-fold ] WSP ) OWS = *( [ obs-fold ] WSP )
RWS = 1*( [ obs-fold ] WSP ) RWS = 1*( [ obs-fold ] WSP )
Reason-Phrase = *( WSP / VCHAR / obs-text ) Reason-Phrase = *( WSP / VCHAR / obs-text )
Request = Request-Line *( header-field CRLF ) CRLF [ message-body ] Request = Request-Line *( header-field CRLF ) CRLF [ message-body ]
Request-Line = Method SP request-target SP HTTP-Version CRLF Request-Line = Method SP request-target SP HTTP-Version CRLF
Response = Status-Line *( header-field CRLF ) CRLF [ message-body ] Response = Status-Line *( header-field CRLF ) CRLF [ message-body ]
Status-Code = 3DIGIT Status-Code = 3DIGIT
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
skipping to change at page 78, line 34 skipping to change at page 78, line 15
RWS = 1*( [ obs-fold ] WSP ) RWS = 1*( [ obs-fold ] WSP )
Reason-Phrase = *( WSP / VCHAR / obs-text ) Reason-Phrase = *( WSP / VCHAR / obs-text )
Request = Request-Line *( header-field CRLF ) CRLF [ message-body ] Request = Request-Line *( header-field CRLF ) CRLF [ message-body ]
Request-Line = Method SP request-target SP HTTP-Version CRLF Request-Line = Method SP request-target SP HTTP-Version CRLF
Response = Status-Line *( header-field CRLF ) CRLF [ message-body ] Response = Status-Line *( header-field CRLF ) CRLF [ message-body ]
Status-Code = 3DIGIT Status-Code = 3DIGIT
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
TE = "TE:" OWS TE-v TE = [ ( "," / t-codings ) *( OWS "," [ OWS t-codings ] ) ]
TE-v = [ ( "," / t-codings ) *( OWS "," [ OWS t-codings ] ) ] Trailer = *( "," OWS ) field-name *( OWS "," [ OWS field-name ] )
Trailer = "Trailer:" OWS Trailer-v Transfer-Encoding = *( "," OWS ) transfer-coding *( OWS "," [ OWS
Trailer-v = *( "," OWS ) field-name *( OWS "," [ OWS field-name ] )
Transfer-Encoding = "Transfer-Encoding:" OWS Transfer-Encoding-v
Transfer-Encoding-v = *( "," OWS ) transfer-coding *( OWS "," [ OWS
transfer-coding ] ) transfer-coding ] )
URI-reference = <URI-reference, defined in [RFC3986], Section 4.1> URI-reference = <URI-reference, defined in [RFC3986], Section 4.1>
Upgrade = "Upgrade:" OWS Upgrade-v Upgrade = *( "," OWS ) product *( OWS "," [ OWS product ] )
Upgrade-v = *( "," OWS ) product *( OWS "," [ OWS product ] )
Via = "Via:" OWS Via-v Via = *( "," 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 ] )
] )
absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3> absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3>
asctime-date = day-name SP date3 SP time-of-day SP year asctime-date = day-name SP date3 SP time-of-day SP year
attribute = token attribute = token
authority = <authority, defined in [RFC3986], Section 3.2> authority = <authority, defined in [RFC3986], Section 3.2>
chunk = chunk-size *WSP [ chunk-ext ] CRLF chunk-data CRLF chunk = chunk-size *WSP [ chunk-ext ] CRLF chunk-data CRLF
chunk-data = 1*OCTET chunk-data = 1*OCTET
chunk-ext = *( ";" *WSP chunk-ext-name [ "=" chunk-ext-val ] *WSP ) chunk-ext = *( ";" *WSP chunk-ext-name [ "=" chunk-ext-val ] *WSP )
chunk-ext-name = token chunk-ext-name = token
skipping to change at page 90, line 36 skipping to change at page 90, line 14
o <http://tools.ietf.org/wg/httpbis/trac/ticket/240>: "Migrate o <http://tools.ietf.org/wg/httpbis/trac/ticket/240>: "Migrate
Upgrade details from RFC2817" Upgrade details from RFC2817"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle
ABNFs for header fields" ABNFs for header fields"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/279>: "update RFC o <http://tools.ietf.org/wg/httpbis/trac/ticket/279>: "update RFC
2109 reference" 2109 reference"
D.15. Since draft-ietf-httpbis-p1-messaging-13
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/53>: "Allow is not
in 13.5.2"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle
ABNFs for header fields"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/286>: "Content-
Length ABNF broken"
Index Index
A A
absolute-URI form (of request-target) 29 absolute-URI form (of request-target) 29
accelerator 13 accelerator 13
application/http Media Type 64 application/http Media Type 63
asterisk form (of request-target) 28 asterisk form (of request-target) 28
authority form (of request-target) 29 authority form (of request-target) 29
B B
browser 10 browser 10
C C
cache 14 cache 14
cacheable 14 cacheable 14
captive portal 14 captive portal 14
skipping to change at page 91, line 42 skipping to change at page 91, line 33
chunk 37 chunk 37
chunk-data 37 chunk-data 37
chunk-ext 37 chunk-ext 37
chunk-ext-name 37 chunk-ext-name 37
chunk-ext-val 37 chunk-ext-val 37
chunk-size 37 chunk-size 37
Chunked-Body 37 Chunked-Body 37
comment 23 comment 23
Connection 52 Connection 52
connection-token 52 connection-token 52
Connection-v 52
Content-Length 53 Content-Length 53
Content-Length-v 53
CR 7 CR 7
CRLF 7 CRLF 7
ctext 23 ctext 23
CTL 7 CTL 7
Date 53 Date 53
Date-v 53
date1 35 date1 35
date2 36 date2 36
date3 36 date3 36
day 35 day 35
day-name 35 day-name 35
day-name-l 35 day-name-l 35
DIGIT 7 DIGIT 7
DQUOTE 7 DQUOTE 7
field-content 22 field-content 22
field-name 22 field-name 22
field-value 22 field-value 22
GMT 35 GMT 35
header-field 22 header-field 22
HEXDIG 7 HEXDIG 7
Host 55 Host 55
Host-v 55
hour 35 hour 35
HTTP-date 34 HTTP-date 34
HTTP-message 21 HTTP-message 21
HTTP-Prot-Name 15 HTTP-Prot-Name 15
http-URI 18 http-URI 18
HTTP-Version 15 HTTP-Version 15
https-URI 19 https-URI 19
last-chunk 37 last-chunk 37
LF 7 LF 7
message-body 24 message-body 24
skipping to change at page 93, line 23 skipping to change at page 93, line 10
second 35 second 35
SP 7 SP 7
special 9 special 9
Status-Code 33 Status-Code 33
Status-Line 33 Status-Line 33
t-codings 56 t-codings 56
tchar 9 tchar 9
TE 56 TE 56
te-ext 56 te-ext 56
te-params 56 te-params 56
TE-v 56
time-of-day 35 time-of-day 35
token 9 token 9
Trailer 57 Trailer 57
trailer-part 37 trailer-part 37
Trailer-v 57
transfer-coding 36 transfer-coding 36
Transfer-Encoding 58 Transfer-Encoding 58
Transfer-Encoding-v 58
transfer-extension 36 transfer-extension 36
transfer-parameter 36 transfer-parameter 36
Upgrade 58 Upgrade 58
Upgrade-v 58
uri-host 17 uri-host 17
URI-reference 17 URI-reference 17
value 36 value 36
VCHAR 7 VCHAR 7
Via 60 Via 60
Via-v 60
word 9 word 9
WSP 7 WSP 7
year 35 year 35
gzip (Coding Format) 40 gzip (Coding Format) 40
H H
header field 20 header field 20
Header Fields Header Fields
Connection 51 Connection 51
Content-Length 53 Content-Length 53
Date 53 Date 53
Host 55 Host 55
TE 56 TE 56
Trailer 57 Trailer 57
Transfer-Encoding 58 Transfer-Encoding 57
Upgrade 58 Upgrade 58
Via 60 Via 60
header section 20 header section 20
headers 20 headers 20
Host header field 55 Host header field 55
http URI scheme 18 http URI scheme 18
https URI scheme 19 https URI scheme 19
I I
inbound 12 inbound 12
interception proxy 14 interception proxy 14
intermediary 12 intermediary 12
M M
Media Type Media Type
application/http 64 application/http 63
message/http 62 message/http 62
message 11 message 11
message/http Media Type 62 message/http Media Type 62
N N
non-transforming proxy 13 non-transforming proxy 13
O O
origin form (of request-target) 29 origin form (of request-target) 29
origin server 10 origin server 10
outbound 12 outbound 12
P P
proxy 13 proxy 13
R R
recipient 10
request 11 request 11
resource 17 resource 17
response 11 response 11
reverse proxy 13 reverse proxy 13
S S
sender 10
server 10 server 10
spider 10 spider 10
T T
target resource 31 target resource 31
TE header field 56 TE header field 56
Trailer header field 57 Trailer header field 57
Transfer-Encoding header field 58 Transfer-Encoding header field 57
transforming proxy 13 transforming proxy 13
transparent proxy 14 transparent proxy 14
tunnel 14 tunnel 14
U U
Upgrade header field 58 Upgrade header field 58
upstream 12 upstream 12
URI scheme URI scheme
http 18 http 18
https 19 https 19
 End of changes. 63 change blocks. 
98 lines changed or deleted 96 lines changed or added

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