draft-ietf-httpbis-p1-messaging-17.txt   draft-ietf-httpbis-p1-messaging-18.txt 
HTTPbis Working Group R. Fielding, Ed. HTTPbis Working Group R. Fielding, Ed.
Internet-Draft Adobe Internet-Draft Adobe
Obsoletes: 2145,2616 (if approved) J. Gettys Obsoletes: 2145,2616 (if approved) J. Gettys
Updates: 2817 (if approved) Alcatel-Lucent Updates: 2817 (if approved) Alcatel-Lucent
Intended status: Standards Track J. Mogul Intended status: Standards Track J. Mogul
Expires: May 3, 2012 HP Expires: July 7, 2012 HP
H. Frystyk H. Frystyk
Microsoft Microsoft
L. Masinter L. Masinter
Adobe Adobe
P. Leach P. Leach
Microsoft Microsoft
T. Berners-Lee T. Berners-Lee
W3C/MIT W3C/MIT
Y. Lafon, Ed. Y. Lafon, Ed.
W3C W3C
J. Reschke, Ed. J. Reschke, Ed.
greenbytes greenbytes
October 31, 2011 January 4, 2012
HTTP/1.1, part 1: URIs, Connections, and Message Parsing HTTP/1.1, part 1: URIs, Connections, and Message Parsing
draft-ietf-httpbis-p1-messaging-17 draft-ietf-httpbis-p1-messaging-18
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is an application-level The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypertext information protocol for distributed, collaborative, hypertext information
systems. HTTP has been in use by the World Wide Web global systems. HTTP has been in use by the World Wide Web global
information initiative since 1990. This document is Part 1 of the information initiative since 1990. This document is Part 1 of the
seven-part specification that defines the protocol referred to as seven-part specification that defines the protocol referred to as
"HTTP/1.1" and, taken together, obsoletes RFC 2616 and moves it to "HTTP/1.1" and, taken together, obsoletes RFC 2616 and moves it to
historic status, along with its predecessor RFC 2068. historic status, along with its predecessor RFC 2068.
skipping to change at page 2, line 11 skipping to change at page 2, line 11
Discussion of this draft should take place on the HTTPBIS working Discussion of this draft should take place on the HTTPBIS working
group mailing list (ietf-http-wg@w3.org), which is archived at group mailing list (ietf-http-wg@w3.org), which is archived at
<http://lists.w3.org/Archives/Public/ietf-http-wg/>. <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
The current issues list is at The current issues list is at
<http://tools.ietf.org/wg/httpbis/trac/report/3> and related <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
documents (including fancy diffs) can be found at documents (including fancy diffs) can be found at
<http://tools.ietf.org/wg/httpbis/>. <http://tools.ietf.org/wg/httpbis/>.
The changes in this draft are summarized in Appendix C.18. The changes in this draft are summarized in Appendix C.19.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 3, 2012. This Internet-Draft will expire on July 7, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
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
skipping to change at page 3, line 27 skipping to change at page 3, line 27
2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 10 2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 10
2.2. Message Orientation and Buffering . . . . . . . . . . . . 11 2.2. Message Orientation and Buffering . . . . . . . . . . . . 11
2.3. Connections and Transport Independence . . . . . . . . . . 12 2.3. Connections and Transport Independence . . . . . . . . . . 12
2.4. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 12 2.4. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 12
2.5. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.5. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.6. Protocol Versioning . . . . . . . . . . . . . . . . . . . 15 2.6. Protocol Versioning . . . . . . . . . . . . . . . . . . . 15
2.7. Uniform Resource Identifiers . . . . . . . . . . . . . . . 17 2.7. Uniform Resource Identifiers . . . . . . . . . . . . . . . 17
2.7.1. http URI scheme . . . . . . . . . . . . . . . . . . . 18 2.7.1. http URI scheme . . . . . . . . . . . . . . . . . . . 18
2.7.2. https URI scheme . . . . . . . . . . . . . . . . . . . 19 2.7.2. https URI scheme . . . . . . . . . . . . . . . . . . . 19
2.7.3. http and https URI Normalization and Comparison . . . 20 2.7.3. http and https URI Normalization and Comparison . . . 20
3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 20 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1. Start Line . . . . . . . . . . . . . . . . . . . . . . . . 21 3.1. Start Line . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1.1. Request-Line . . . . . . . . . . . . . . . . . . . . . 22 3.1.1. Request-Line . . . . . . . . . . . . . . . . . . . . . 22
3.1.2. Response Status-Line . . . . . . . . . . . . . . . . . 23 3.1.2. Response Status-Line . . . . . . . . . . . . . . . . . 23
3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 23 3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 23
3.2.1. Field Parsing . . . . . . . . . . . . . . . . . . . . 24 3.2.1. Field Parsing . . . . . . . . . . . . . . . . . . . . 25
3.2.2. Field Length . . . . . . . . . . . . . . . . . . . . . 25 3.2.2. Field Length . . . . . . . . . . . . . . . . . . . . . 25
3.2.3. Common Field ABNF Rules . . . . . . . . . . . . . . . 25 3.2.3. Common Field ABNF Rules . . . . . . . . . . . . . . . 26
3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 27 3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 27
3.4. Handling Incomplete Messages . . . . . . . . . . . . . . . 30 3.4. Handling Incomplete Messages . . . . . . . . . . . . . . . 30
3.5. Message Parsing Robustness . . . . . . . . . . . . . . . . 30 3.5. Message Parsing Robustness . . . . . . . . . . . . . . . . 31
4. Message Routing . . . . . . . . . . . . . . . . . . . . . . . 31 4. Message Routing . . . . . . . . . . . . . . . . . . . . . . . 31
4.1. Types of Request Target . . . . . . . . . . . . . . . . . 31 4.1. Types of Request Target . . . . . . . . . . . . . . . . . 31
4.2. The Resource Identified by a Request . . . . . . . . . . . 33 4.2. The Resource Identified by a Request . . . . . . . . . . . 33
4.3. Effective Request URI . . . . . . . . . . . . . . . . . . 34 4.3. Effective Request URI . . . . . . . . . . . . . . . . . . 34
5. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 35 5. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 35
5.1. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 35 5.1. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 35
5.1.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 36 5.1.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 36
5.1.2. Compression Codings . . . . . . . . . . . . . . . . . 38 5.1.2. Compression Codings . . . . . . . . . . . . . . . . . 38
5.1.3. Transfer Coding Registry . . . . . . . . . . . . . . . 39 5.1.3. Transfer Coding Registry . . . . . . . . . . . . . . . 39
5.2. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 39 5.2. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 39
skipping to change at page 4, line 47 skipping to change at page 4, line 47
10.1. Personal Information . . . . . . . . . . . . . . . . . . . 63 10.1. Personal Information . . . . . . . . . . . . . . . . . . . 63
10.2. Abuse of Server Log Information . . . . . . . . . . . . . 63 10.2. Abuse of Server Log Information . . . . . . . . . . . . . 63
10.3. Attacks Based On File and Path Names . . . . . . . . . . . 63 10.3. Attacks Based On File and Path Names . . . . . . . . . . . 63
10.4. DNS-related Attacks . . . . . . . . . . . . . . . . . . . 63 10.4. DNS-related Attacks . . . . . . . . . . . . . . . . . . . 63
10.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 64 10.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 64
10.6. Protocol Element Size Overflows . . . . . . . . . . . . . 64 10.6. Protocol Element Size Overflows . . . . . . . . . . . . . 64
10.7. Denial of Service Attacks on Proxies . . . . . . . . . . . 65 10.7. Denial of Service Attacks on Proxies . . . . . . . . . . . 65
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 65 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 65
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 66 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 66
12.1. Normative References . . . . . . . . . . . . . . . . . . . 66 12.1. Normative References . . . . . . . . . . . . . . . . . . . 66
12.2. Informative References . . . . . . . . . . . . . . . . . . 68 12.2. Informative References . . . . . . . . . . . . . . . . . . 67
Appendix A. HTTP Version History . . . . . . . . . . . . . . . . 70 Appendix A. HTTP Version History . . . . . . . . . . . . . . . . 69
A.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 71 A.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 70
A.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 71 A.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 70
A.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 71 A.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 71
A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 72 A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 71
Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 73 Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 72
Appendix C. Change Log (to be removed by RFC Editor before Appendix C. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 76 publication) . . . . . . . . . . . . . . . . . . . . 75
C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 76 C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 75
C.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 76 C.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 75
C.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 78 C.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 77
C.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 79 C.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 78
C.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 79 C.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 78
C.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 80 C.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 79
C.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 80 C.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 79
C.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 81 C.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 80
C.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 82 C.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 81
C.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 82 C.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 82
C.11. Since draft-ietf-httpbis-p1-messaging-09 . . . . . . . . . 83 C.11. Since draft-ietf-httpbis-p1-messaging-09 . . . . . . . . . 82
C.12. Since draft-ietf-httpbis-p1-messaging-10 . . . . . . . . . 83 C.12. Since draft-ietf-httpbis-p1-messaging-10 . . . . . . . . . 82
C.13. Since draft-ietf-httpbis-p1-messaging-11 . . . . . . . . . 84 C.13. Since draft-ietf-httpbis-p1-messaging-11 . . . . . . . . . 83
C.14. Since draft-ietf-httpbis-p1-messaging-12 . . . . . . . . . 84 C.14. Since draft-ietf-httpbis-p1-messaging-12 . . . . . . . . . 83
C.15. Since draft-ietf-httpbis-p1-messaging-13 . . . . . . . . . 85 C.15. Since draft-ietf-httpbis-p1-messaging-13 . . . . . . . . . 84
C.16. Since draft-ietf-httpbis-p1-messaging-14 . . . . . . . . . 85 C.16. Since draft-ietf-httpbis-p1-messaging-14 . . . . . . . . . 84
C.17. Since draft-ietf-httpbis-p1-messaging-15 . . . . . . . . . 85 C.17. Since draft-ietf-httpbis-p1-messaging-15 . . . . . . . . . 85
C.18. Since draft-ietf-httpbis-p1-messaging-16 . . . . . . . . . 86 C.18. Since draft-ietf-httpbis-p1-messaging-16 . . . . . . . . . 85
C.19. Since draft-ietf-httpbis-p1-messaging-17 . . . . . . . . . 85
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
1. Introduction 1. Introduction
The Hypertext Transfer Protocol (HTTP) is an application-level The Hypertext Transfer Protocol (HTTP) is an application-level
request/response protocol that uses extensible semantics and MIME- request/response protocol that uses extensible semantics and MIME-
like message payloads for flexible interaction with network-based like message payloads for flexible interaction with network-based
hypertext information systems. HTTP relies upon the Uniform Resource hypertext information systems. HTTP relies upon the Uniform Resource
Identifier (URI) standard [RFC3986] to indicate 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 27 skipping to change at page 10, line 27
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
originate authoritative responses to a request. For general originate authoritative responses to a request. For general
requirements, we use the term "sender" to refer to whichever requirements, we use the term "sender" to refer to whichever
component sent a given message and the term "recipient" to refer to component sent a given message and the term "recipient" to refer to
any component that receives the message. any component that receives the message.
Note: The term 'user agent' covers both those situations where
there is a user (human) interacting with the software agent (and
for which user interface or interactive suggestions might be made,
e.g., warning the user or given the user an option in the case of
security or privacy options) and also those where the software
agent may act autonomously.
Most HTTP communication consists of a retrieval request (GET) for a Most HTTP communication consists of a retrieval request (GET) for a
representation of some resource identified by a URI. In the simplest representation of some resource identified by a URI. In the simplest
case, this might be accomplished via a single bidirectional case, this might be accomplished via a single bidirectional
connection (===) between the user agent (UA) and the origin server connection (===) between the user agent (UA) and the origin server
(O). (O).
request > request >
UA ======================================= O UA ======================================= O
< response < response
skipping to change at page 11, line 6 skipping to change at page 11, line 14
A server responds to the client's request by sending an HTTP response A server responds to the client's request by sending an HTTP response
message, beginning with a status line that includes the protocol message, beginning with a status line that includes the protocol
version, a success or error code, and textual reason phrase version, a success or error code, and textual reason phrase
(Section 3.1.2), followed by MIME-like header fields containing (Section 3.1.2), followed by MIME-like header fields containing
server information, resource metadata, and payload metadata server information, resource metadata, and payload metadata
(Section 3.2), an empty line to indicate the end of the header (Section 3.2), an empty line to indicate the end of the header
section, and finally a message body containing the payload body (if section, and finally a message body containing the payload body (if
any, Section 3.3). any, Section 3.3).
Note that 1xx responses (Section 7.1 of [Part2]) are not final;
therefore, a server can send zero or more 1xx responses, followed by
exactly one final response (with any other status code).
The following example illustrates a typical message exchange for a The following example illustrates a typical message exchange for a
GET request on the URI "http://www.example.com/hello.txt": GET request on the URI "http://www.example.com/hello.txt":
client request: client request:
GET /hello.txt HTTP/1.1 GET /hello.txt HTTP/1.1
User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
Host: www.example.com Host: www.example.com
Accept: */* Accept: */*
skipping to change at page 33, line 18 skipping to change at page 33, line 22
Host: www.example.org:8001 Host: www.example.org:8001
after connecting to port 8001 of host "www.example.org". after connecting to port 8001 of host "www.example.org".
The request-target is transmitted in the format specified in The request-target is transmitted in the format specified in
Section 2.7.1. If the request-target is percent-encoded ([RFC3986], Section 2.7.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 non-transforming proxy MUST NOT rewrite the "path-absolute" part of A non-transforming proxy MUST NOT rewrite the "path-absolute" and
the received request-target when forwarding it to the next inbound "query" parts of the received request-target when forwarding it to
server, except as noted above to replace a null path-absolute with the next inbound server, except as noted above to replace a null
"/" or "*". 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
need to be aware that some pre-HTTP/1.1 proxies have been known to need to be aware that some pre-HTTP/1.1 proxies have been known to
rewrite the request-target. rewrite the request-target.
4.2. The Resource Identified by a Request 4.2. The Resource Identified by a Request
The exact resource identified by an Internet request is determined by The exact resource identified by an Internet request is determined by
skipping to change at page 34, line 26 skipping to change at page 34, line 30
HTTP requests often do not carry the absolute URI ([RFC3986], Section HTTP requests often do not carry the absolute URI ([RFC3986], Section
4.3) for the target resource; instead, the URI needs to be inferred 4.3) for the target resource; instead, the URI needs to be inferred
from the request-target, Host header field, and connection context. from the request-target, Host header field, and connection context.
The result of this process is called the "effective request URI". The result of this process is called the "effective request URI".
The "target resource" is the resource identified by the effective The "target resource" is the resource identified by the effective
request URI. request URI.
If the request-target is an absolute-URI, then the effective request If the request-target is an absolute-URI, then the effective request
URI is the request-target. URI is the request-target.
If the request-target uses the path-absolute form or the asterisk If the request-target uses the origin form or the asterisk form, and
form, and the Host header field is present, then the effective the Host header field is present, then the effective request URI is
request URI is constructed by concatenating constructed by concatenating
o the scheme name: "http" if the request was received over an o the scheme name: "http" if the request was received over an
insecure TCP connection, or "https" when received over a SSL/ insecure TCP connection, or "https" when received over a SSL/
TLS-secured TCP connection, TLS-secured TCP connection,
o the octet sequence "://", o the octet sequence "://",
o the authority component, as specified in the Host header field o the authority component, as specified in the Host header field
(Section 8.3), and (Section 8.3), and
o the request-target obtained from the Request-Line, unless the o the request-target obtained from the Request-Line, unless the
request-target is just the asterisk "*". request-target is just the asterisk "*".
If the request-target uses the path-absolute form or the asterisk If the request-target uses the origin form or the asterisk form, and
form, and the Host header field is not present, then the effective the Host header field is not present, then the effective request URI
request URI is undefined. is undefined.
Otherwise, when request-target uses the authority form, the effective Otherwise, when request-target uses the authority form, the effective
request URI is undefined. request URI is undefined.
Example 1: the effective request URI for the message Example 1: the effective request URI for the message
GET /pub/WWW/TheProject.html HTTP/1.1 GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.example.org:8080 Host: www.example.org:8080
(received over an insecure TCP connection) is "http", plus "://", (received over an insecure TCP connection) is "http", plus "://",
skipping to change at page 65, line 37 skipping to change at page 65, line 37
smart questions, drafting and reviewing text, and discussing open smart questions, drafting and reviewing text, and discussing open
issues: issues:
Adam Barth, Adam Roach, Addison Phillips, Adrian Chadd, Adrien de Adam Barth, Adam Roach, Addison Phillips, Adrian Chadd, Adrien de
Croy, Alan Ford, Alan Ruttenberg, Albert Lunde, Alex Rousskov, Alexey Croy, Alan Ford, Alan Ruttenberg, Albert Lunde, Alex Rousskov, Alexey
Melnikov, Alisha Smith, Amichai Rothman, Amit Klein, Amos Jeffries, Melnikov, Alisha Smith, Amichai Rothman, Amit Klein, Amos Jeffries,
Andreas Maier, Andreas Petersson, Anne van Kesteren, Anthony Bryan, Andreas Maier, Andreas Petersson, Anne van Kesteren, Anthony Bryan,
Asbjorn Ulsberg, Balachander Krishnamurthy, Barry Leiba, Ben Laurie, Asbjorn Ulsberg, Balachander Krishnamurthy, Barry Leiba, Ben Laurie,
Benjamin Niven-Jenkins, Bil Corry, Bill Burke, Bjoern Hoehrmann, Bob Benjamin Niven-Jenkins, Bil Corry, Bill Burke, Bjoern Hoehrmann, Bob
Scheifler, Boris Zbarsky, Brett Slatkin, Brian Kell, Brian McBarron, Scheifler, Boris Zbarsky, Brett Slatkin, Brian Kell, Brian McBarron,
Brian Pane, Brian Smith, Bryce Nesbitt, Carl Kugler, Charles Fry, Brian Pane, Brian Smith, Bryce Nesbitt, Cameron Heavon-Jones, Carl
Chris Newman, Cyrus Daboo, Dale Robert Anderson, Dan Winship, Daniel Kugler, Charles Fry, Chris Newman, Cyrus Daboo, Dale Robert Anderson,
Stenberg, Dave Cridland, Dave Crocker, Dave Kristol, David Booth, Dan Winship, Daniel Stenberg, Dave Cridland, Dave Crocker, Dave
David Singer, David W. Morris, Diwakar Shetty, Drummond Reed, Duane Kristol, David Booth, David Singer, David W. Morris, Diwakar Shetty,
Wessels, Edward Lee, Eliot Lear, Eran Hammer-Lahav, Eric D. Williams, Dmitry Kurochkin, Drummond Reed, Duane Wessels, Edward Lee, Eliot
Eric J. Bowman, Eric Lawrence, Erik Aronesty, Florian Weimer, Frank Lear, Eran Hammer-Lahav, Eric D. Williams, Eric J. Bowman, Eric
Ellermann, Fred Bohle, Geoffrey Sneddon, Gervase Markham, Greg Lawrence, Erik Aronesty, Florian Weimer, Frank Ellermann, Fred Bohle,
Wilkins, Harald Tveit Alvestrand, Harry Halpin, Helge Hess, Henrik Geoffrey Sneddon, Gervase Markham, Greg Wilkins, Harald Tveit
Nordstrom, Henry S. Thompson, Henry Story, Howard Melman, Hugo Haas, Alvestrand, Harry Halpin, Helge Hess, Henrik Nordstrom, Henry S.
Ian Hickson, Ingo Struck, J. Ross Nicoll, James H. Manger, James Thompson, Henry Story, Herbert van de Sompel, Howard Melman, Hugo
Lacey, James M. Snell, Jamie Lokier, Jan Algermissen, Jeff Hodges Haas, Ian Hickson, Ingo Struck, J. Ross Nicoll, James H. Manger,
(for coming up with the term 'effective Request-URI'), Jeff Walden, James Lacey, James M. Snell, Jamie Lokier, Jan Algermissen, Jeff
Jim Luther, Joe D. Williams, Joe Gregorio, Joe Orton, John C. Hodges (for coming up with the term 'effective Request-URI'), Jeff
Walden, Jim Luther, Joe D. Williams, Joe Gregorio, Joe Orton, John C.
Klensin, John C. Mallery, John Cowan, John Kemp, John Panzer, John Klensin, John C. Mallery, John Cowan, John Kemp, John Panzer, John
Schneider, John Stracke, Jonas Sicking, Jonathan Moore, Jonathan Schneider, John Stracke, Jonas Sicking, Jonathan Moore, Jonathan
Rees, Jordi Ros, Joris Dobbelsteen, Josh Cohen, Julien Pierre, Rees, Jordi Ros, Joris Dobbelsteen, Josh Cohen, Julien Pierre,
Jungshik Shin, Justin Chapweske, Justin Erenkrantz, Justin James, Jungshik Shin, Justin Chapweske, Justin Erenkrantz, Justin James,
Kalvinder Singh, Karl Dubost, Keith Hoffman, Keith Moore, Koen Kalvinder Singh, Karl Dubost, Keith Hoffman, Keith Moore, Koen
Holtman, Konstantin Voronkov, Kris Zyp, Lisa Dusseault, Maciej Holtman, Konstantin Voronkov, Kris Zyp, Lisa Dusseault, Maciej
Stachowiak, Marc Schneider, Marc Slemko, Mark Baker, Mark Nottingham Stachowiak, Marc Schneider, Marc Slemko, Mark Baker, Mark Nottingham
(Working Group chair), Mark Pauley, Martin J. Duerst, Martin Thomson, (Working Group chair), Mark Pauley, Martin J. Duerst, Martin Thomson,
Matt Lynch, Matthew Cox, Max Clark, Michael Burrows, Michael Matt Lynch, Matthew Cox, Max Clark, Michael Burrows, Michael
Hausenblas, Mike Amundsen, Mike Kelly, Mike Schinkel, Miles Sabin, Hausenblas, Mike Amundsen, Mike Kelly, Mike Schinkel, Miles Sabin,
skipping to change at page 66, line 41 skipping to change at page 66, line 42
12.1. Normative References 12.1. Normative References
[ISO-8859-1] International Organization for Standardization, [ISO-8859-1] International Organization for Standardization,
"Information technology -- 8-bit single-byte coded "Information technology -- 8-bit single-byte coded
graphic character sets -- Part 1: Latin alphabet No. graphic character sets -- Part 1: Latin alphabet No.
1", ISO/IEC 8859-1:1998, 1998. 1", ISO/IEC 8859-1:1998, 1998.
[Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
Ed., and J. Reschke, Ed., "HTTP/1.1, part 2: Message Ed., and J. Reschke, Ed., "HTTP/1.1, part 2: Message
Semantics", draft-ietf-httpbis-p2-semantics-17 (work in Semantics", draft-ietf-httpbis-p2-semantics-18 (work in
progress), October 2011. progress), January 2012.
[Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
Ed., and J. Reschke, Ed., "HTTP/1.1, part 3: Message Ed., and J. Reschke, Ed., "HTTP/1.1, part 3: Message
Payload and Content Negotiation", Payload and Content Negotiation",
draft-ietf-httpbis-p3-payload-17 (work in progress), draft-ietf-httpbis-p3-payload-18 (work in progress),
October 2011. January 2012.
[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
Ed., Nottingham, M., Ed., and J. Reschke, Ed., Ed., Nottingham, M., Ed., and J. Reschke, Ed.,
"HTTP/1.1, part 6: Caching", "HTTP/1.1, part 6: Caching",
draft-ietf-httpbis-p6-cache-17 (work in progress), draft-ietf-httpbis-p6-cache-18 (work in progress),
October 2011. January 2012.
[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
Format Specification version 3.3", RFC 1950, May 1996. Format Specification version 3.3", RFC 1950, May 1996.
RFC 1950 is an Informational RFC, thus it might be less
stable than this specification. On the other hand,
this downward reference was present since the
publication of RFC 2068 in 1997, therefore it is
unlikely to cause problems in practice. See also
[BCP97].
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format
Specification version 1.3", RFC 1951, May 1996. Specification version 1.3", RFC 1951, May 1996.
RFC 1951 is an Informational RFC, thus it might be less
stable than this specification. On the other hand,
this downward reference was present since the
publication of RFC 2068 in 1997, therefore it is
unlikely to cause problems in practice. See also
[BCP97].
[RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and
G. Randers-Pehrson, "GZIP file format specification G. Randers-Pehrson, "GZIP file format specification
version 4.3", RFC 1952, May 1996. version 4.3", RFC 1952, May 1996.
RFC 1952 is an Informational RFC, thus it might be less
stable than this specification. On the other hand,
this downward reference was present since the
publication of RFC 2068 in 1997, therefore 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, [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
"Uniform Resource Identifier (URI): Generic Syntax", "Uniform Resource Identifier (URI): Generic Syntax",
STD 66, RFC 3986, January 2005. STD 66, RFC 3986, January 2005.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, RFC 5234, Syntax Specifications: ABNF", STD 68, RFC 5234,
January 2008. 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.
12.2. Informative References 12.2. Informative References
[BCP97] Klensin, J. and S. Hartman, "Handling Normative
References to Standards-Track Documents", BCP 97,
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. Politics", ACM Transactions on Internet Technology Vol.
1, #2, November 2001, 1, #2, November 2001,
<http://arxiv.org/abs/cs.SE/0105018>. <http://arxiv.org/abs/cs.SE/0105018>.
[Nie1997] Frystyk, H., Gettys, J., Prud'hommeaux, E., Lie, H., [Nie1997] Frystyk, H., Gettys, J., Prud'hommeaux, E., Lie, H.,
and C. Lilley, "Network Performance Effects of and C. Lilley, "Network Performance Effects of
HTTP/1.1, CSS1, and PNG", ACM Proceedings of the ACM HTTP/1.1, CSS1, and PNG", ACM Proceedings of the ACM
SIGCOMM '97 conference on Applications, technologies, SIGCOMM '97 conference on Applications, technologies,
architectures, and protocols for computer communication architectures, and protocols for computer communication
skipping to change at page 71, line 31 skipping to change at page 71, line 8
to which that request was directed. The Host header field was to which that request was directed. The Host header field was
introduced during the development of HTTP/1.1 and, though it was introduced during the development of HTTP/1.1 and, though it was
quickly implemented by most HTTP/1.0 browsers, additional quickly implemented by most HTTP/1.0 browsers, additional
requirements were placed on all HTTP/1.1 requests in order to ensure requirements were placed on all HTTP/1.1 requests in order to ensure
complete adoption. At the time of this writing, most HTTP-based complete adoption. At the time of this writing, most HTTP-based
services are dependent upon the Host header field for targeting services are dependent upon the Host header field for targeting
requests. requests.
A.1.2. Keep-Alive Connections A.1.2. Keep-Alive Connections
For most implementations of HTTP/1.0, each connection is established In HTTP/1.0, each connection is established by the client prior to
by the client prior to the request and closed by the server after the request and closed by the server after sending the response.
sending the response. However, some implementations implement the However, some implementations implement the explicitly negotiated
Keep-Alive version of persistent connections described in Section ("Keep-Alive") version of persistent connections described in Section
19.7.1 of [RFC2068]. 19.7.1 of [RFC2068].
Some clients and servers might wish to be compatible with some Some clients and servers might wish to be compatible with these
previous implementations of persistent connections in HTTP/1.0 previous approaches to persistent connections, by explicitly
clients and servers. Persistent connections in HTTP/1.0 are negotiating for them with a "Connection: keep-alive" request header
explicitly negotiated as they are not the default behavior. HTTP/1.0 field. However, some experimental implementations of HTTP/1.0
experimental implementations of persistent connections are faulty, persistent connections are faulty; for example, if a HTTP/1.0 proxy
and the new facilities in HTTP/1.1 are designed to rectify these server doesn't understand Connection, it will erroneously forward
problems. The problem was that some existing HTTP/1.0 clients might that header to the next inbound server, which would result in a hung
send Keep-Alive to a proxy server that doesn't understand Connection, connection.
which would then erroneously forward it to the next inbound server,
which would establish the Keep-Alive connection and result in a hung
HTTP/1.0 proxy waiting for the close on the response. The result is
that HTTP/1.0 clients must be prevented from using Keep-Alive when
talking to proxies.
However, talking to proxies is the most important use of persistent One attempted solution was the introduction of a Proxy-Connection
connections, so that prohibition is clearly unacceptable. Therefore, header, targeted specifically at proxies. In practice, this was also
we need some other mechanism for indicating a persistent connection unworkable, because proxies are often deployed in multiple layers,
is desired, which is safe to use even when talking to an old proxy bringing about the same problem discussed above.
that ignores Connection. Persistent connections are the default for
HTTP/1.1 messages; we introduce a new keyword (Connection: close) for As a result, clients are encouraged not to send the Proxy-Connection
declaring non-persistence. See Section 8.1. header in any requests.
Clients are also encouraged to consider the use of Connection: keep-
alive in requests carefully; while they can enable persistent
connections with HTTP/1.0 servers, clients using them need will need
to monitor the connection for "hung" requests (which indicate that
the client ought stop sending the header), and this mechanism ought
not be used by clients at all when a proxy is being used.
A.2. Changes from RFC 2616 A.2. Changes from RFC 2616
Empty list elements in list productions have been deprecated. Empty list elements in list productions have been deprecated.
(Section 1.2.1) (Section 1.2.1)
Rules about implicit linear whitespace between certain grammar Rules about implicit linear whitespace between certain grammar
productions have been removed; now it's only allowed when productions have been removed; now it's only allowed when
specifically pointed out in the ABNF. (Section 1.2.2) specifically pointed out in the ABNF. (Section 1.2.2)
skipping to change at page 86, line 30 skipping to change at page 85, line 43
o <http://tools.ietf.org/wg/httpbis/trac/ticket/219>: "Revise o <http://tools.ietf.org/wg/httpbis/trac/ticket/219>: "Revise
Acknowledgements Sections" Acknowledgements Sections"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/297>: "Retrying o <http://tools.ietf.org/wg/httpbis/trac/ticket/297>: "Retrying
Requests" Requests"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/318>: "Closing the o <http://tools.ietf.org/wg/httpbis/trac/ticket/318>: "Closing the
connection on server error" connection on server error"
C.19. Since draft-ietf-httpbis-p1-messaging-17
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/166>: "Clarify 'User
Agent'"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/300>: "Define non-
final responses"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/323>: "intended
maturity level vs normative references"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/324>: "Intermediary
rewriting of queries"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/158>: "Proxy-
Connection and Keep-Alive"
Index Index
A A
absolute-URI form (of request-target) 31 absolute-URI form (of request-target) 32
accelerator 13 accelerator 13
application/http Media Type 61 application/http Media Type 61
asterisk form (of request-target) 31 asterisk form (of request-target) 31
authority form (of request-target) 32 authority form (of request-target) 32
B B
browser 10 browser 10
C C
cache 14 cache 14
skipping to change at page 87, line 20 skipping to change at page 86, line 52
D D
deflate (Coding Format) 38 deflate (Coding Format) 38
downstream 13 downstream 13
E E
effective request URI 34 effective request URI 34
G G
gateway 13 gateway 13
Grammar Grammar
absolute-URI 17 absolute-URI 18
ALPHA 7 ALPHA 7
attribute 35 attribute 35
authority 17 authority 18
BWS 9 BWS 9
chunk 36 chunk 36
chunk-data 36 chunk-data 36
chunk-ext 36 chunk-ext 36
chunk-ext-name 36 chunk-ext-name 36
chunk-ext-val 36 chunk-ext-val 36
chunk-size 36 chunk-size 36
Chunked-Body 36 Chunked-Body 36
comment 26 comment 26
Connection 50 Connection 50
skipping to change at page 88, line 6 skipping to change at page 87, line 38
field-name 23 field-name 23
field-value 23 field-value 23
header-field 23 header-field 23
HEXDIG 7 HEXDIG 7
Host 52 Host 52
HTAB 7 HTAB 7
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 20
last-chunk 36 last-chunk 36
LF 7 LF 7
message-body 27 message-body 27
Method 22 Method 22
obs-text 26 obs-text 26
OCTET 7 OCTET 7
OWS 9 OWS 9
path-absolute 17 path-absolute 18
port 17 port 18
product 39 product 39
product-version 39 product-version 39
protocol-name 57 protocol-name 57
protocol-version 57 protocol-version 57
pseudonym 57 pseudonym 57
qdtext 26 qdtext 26
qdtext-nf 36 qdtext-nf 36
query 17 query 18
quoted-cpair 26 quoted-cpair 27
quoted-pair 26 quoted-pair 26
quoted-str-nf 36 quoted-str-nf 36
quoted-string 26 quoted-string 26
qvalue 40 qvalue 40
Reason-Phrase 23 Reason-Phrase 23
received-by 57 received-by 57
received-protocol 57 received-protocol 57
Request-Line 22 Request-Line 22
request-target 22 request-target 22
RWS 9 RWS 9
skipping to change at page 89, line 5 skipping to change at page 88, line 37
te-ext 53 te-ext 53
te-params 53 te-params 53
token 26 token 26
Trailer 54 Trailer 54
trailer-part 36 trailer-part 36
transfer-coding 35 transfer-coding 35
Transfer-Encoding 54 Transfer-Encoding 54
transfer-extension 35 transfer-extension 35
transfer-parameter 35 transfer-parameter 35
Upgrade 55 Upgrade 55
uri-host 17 uri-host 18
URI-reference 17 URI-reference 18
value 35 value 35
VCHAR 7 VCHAR 7
Via 57 Via 57
word 26 word 26
gzip (Coding Format) 39 gzip (Coding Format) 39
H H
header field 20 header field 21
Header Fields Header Fields
Connection 49 Connection 49
Content-Length 51 Content-Length 51
Host 51 Host 51
TE 53 TE 53
Trailer 54 Trailer 54
Transfer-Encoding 54 Transfer-Encoding 54
Upgrade 55 Upgrade 55
Via 57 Via 57
header section 20 header section 21
headers 20 headers 21
Host header field 51 Host header field 51
http URI scheme 18 http URI scheme 18
https URI scheme 19 https URI scheme 19
I I
inbound 13 inbound 13
interception proxy 14 interception proxy 14
intermediary 12 intermediary 12
M M
 End of changes. 41 change blocks. 
124 lines changed or deleted 133 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/