draft-ietf-httpbis-p1-messaging-22.txt   draft-ietf-httpbis-p1-messaging-latest.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. Reschke, Ed. Obsoletes: 2145,2616 (if approved) J. Reschke, Ed.
Updates: 2817,2818 (if approved) greenbytes Updates: 2817,2818 (if approved) greenbytes
Intended status: Standards Track February 23, 2013 Intended status: Standards Track May 21, 2013
Expires: August 27, 2013 Expires: November 22, 2013
Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
draft-ietf-httpbis-p1-messaging-22 draft-ietf-httpbis-p1-messaging-latest
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 provides an information initiative since 1990. This document provides an
overview of HTTP architecture and its associated terminology, defines overview of HTTP architecture and its associated terminology, defines
the "http" and "https" Uniform Resource Identifier (URI) schemes, the "http" and "https" Uniform Resource Identifier (URI) schemes,
defines the HTTP/1.1 message syntax and parsing requirements, and defines the HTTP/1.1 message syntax and parsing requirements, and
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Discussion of this draft takes place on the HTTPBIS working group Discussion of this draft takes place on the HTTPBIS working group
mailing list (ietf-http-wg@w3.org), which is archived at mailing list (ietf-http-wg@w3.org), which is archived at
<http://lists.w3.org/Archives/Public/ietf-http-wg/>. <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
The current issues list is at The current issues list is at
<http://tools.ietf.org/wg/httpbis/trac/report/3> and related <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
documents (including fancy diffs) can be found at documents (including fancy diffs) can be found at
<http://tools.ietf.org/wg/httpbis/>. <http://tools.ietf.org/wg/httpbis/>.
The changes in this draft are summarized in Appendix D.2. The changes in this draft are summarized in Appendix D.3.
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 August 27, 2013. This Internet-Draft will expire on November 22, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 2, line 51 skipping to change at page 2, line 51
2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 7 2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 7
2.2. Implementation Diversity . . . . . . . . . . . . . . . . . 8 2.2. Implementation Diversity . . . . . . . . . . . . . . . . . 8
2.3. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 9 2.3. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 9
2.4. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.4. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.5. Conformance and Error Handling . . . . . . . . . . . . . . 12 2.5. Conformance and Error Handling . . . . . . . . . . . . . . 12
2.6. Protocol Versioning . . . . . . . . . . . . . . . . . . . 13 2.6. Protocol Versioning . . . . . . . . . . . . . . . . . . . 13
2.7. Uniform Resource Identifiers . . . . . . . . . . . . . . . 15 2.7. Uniform Resource Identifiers . . . . . . . . . . . . . . . 15
2.7.1. http URI scheme . . . . . . . . . . . . . . . . . . . 16 2.7.1. http URI scheme . . . . . . . . . . . . . . . . . . . 16
2.7.2. https URI scheme . . . . . . . . . . . . . . . . . . . 17 2.7.2. https URI scheme . . . . . . . . . . . . . . . . . . . 17
2.7.3. http and https URI Normalization and Comparison . . . 18 2.7.3. http and https URI Normalization and Comparison . . . 18
3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 19 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1. Start Line . . . . . . . . . . . . . . . . . . . . . . . . 19 3.1. Start Line . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.1. Request Line . . . . . . . . . . . . . . . . . . . . . 20 3.1.1. Request Line . . . . . . . . . . . . . . . . . . . . . 20
3.1.2. Status Line . . . . . . . . . . . . . . . . . . . . . 21 3.1.2. Status Line . . . . . . . . . . . . . . . . . . . . . 21
3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 22 3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 21
3.2.1. Field Extensibility . . . . . . . . . . . . . . . . . 22 3.2.1. Field Extensibility . . . . . . . . . . . . . . . . . 22
3.2.2. Field Order . . . . . . . . . . . . . . . . . . . . . 22 3.2.2. Field Order . . . . . . . . . . . . . . . . . . . . . 22
3.2.3. Whitespace . . . . . . . . . . . . . . . . . . . . . . 23 3.2.3. Whitespace . . . . . . . . . . . . . . . . . . . . . . 23
3.2.4. Field Parsing . . . . . . . . . . . . . . . . . . . . 24 3.2.4. Field Parsing . . . . . . . . . . . . . . . . . . . . 23
3.2.5. Field Limits . . . . . . . . . . . . . . . . . . . . . 25 3.2.5. Field Limits . . . . . . . . . . . . . . . . . . . . . 25
3.2.6. Field value components . . . . . . . . . . . . . . . . 25 3.2.6. Field value components . . . . . . . . . . . . . . . . 25
3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 26 3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 26
3.3.1. Transfer-Encoding . . . . . . . . . . . . . . . . . . 27 3.3.1. Transfer-Encoding . . . . . . . . . . . . . . . . . . 27
3.3.2. Content-Length . . . . . . . . . . . . . . . . . . . . 28 3.3.2. Content-Length . . . . . . . . . . . . . . . . . . . . 28
3.3.3. Message Body Length . . . . . . . . . . . . . . . . . 30 3.3.3. Message Body Length . . . . . . . . . . . . . . . . . 30
3.4. Handling Incomplete Messages . . . . . . . . . . . . . . . 32 3.4. Handling Incomplete Messages . . . . . . . . . . . . . . . 32
3.5. Message Parsing Robustness . . . . . . . . . . . . . . . . 33 3.5. Message Parsing Robustness . . . . . . . . . . . . . . . . 33
4. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . . 33 4. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . . 33
4.1. Chunked Transfer Coding . . . . . . . . . . . . . . . . . 34 4.1. Chunked Transfer Coding . . . . . . . . . . . . . . . . . 34
4.1.1. Trailer . . . . . . . . . . . . . . . . . . . . . . . 35 4.1.1. Trailer . . . . . . . . . . . . . . . . . . . . . . . 35
4.1.2. Decoding chunked . . . . . . . . . . . . . . . . . . . 36 4.1.2. Decoding chunked . . . . . . . . . . . . . . . . . . . 36
4.2. Compression Codings . . . . . . . . . . . . . . . . . . . 37 4.2. Compression Codings . . . . . . . . . . . . . . . . . . . 36
4.2.1. Compress Coding . . . . . . . . . . . . . . . . . . . 37 4.2.1. Compress Coding . . . . . . . . . . . . . . . . . . . 36
4.2.2. Deflate Coding . . . . . . . . . . . . . . . . . . . . 37 4.2.2. Deflate Coding . . . . . . . . . . . . . . . . . . . . 36
4.2.3. Gzip Coding . . . . . . . . . . . . . . . . . . . . . 37 4.2.3. Gzip Coding . . . . . . . . . . . . . . . . . . . . . 37
4.3. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.3. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5. Message Routing . . . . . . . . . . . . . . . . . . . . . . . 38 5. Message Routing . . . . . . . . . . . . . . . . . . . . . . . 38
5.1. Identifying a Target Resource . . . . . . . . . . . . . . 38 5.1. Identifying a Target Resource . . . . . . . . . . . . . . 38
5.2. Connecting Inbound . . . . . . . . . . . . . . . . . . . . 39 5.2. Connecting Inbound . . . . . . . . . . . . . . . . . . . . 38
5.3. Request Target . . . . . . . . . . . . . . . . . . . . . . 39 5.3. Request Target . . . . . . . . . . . . . . . . . . . . . . 39
5.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 5.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.5. Effective Request URI . . . . . . . . . . . . . . . . . . 43 5.5. Effective Request URI . . . . . . . . . . . . . . . . . . 42
5.6. Associating a Response to a Request . . . . . . . . . . . 44 5.6. Associating a Response to a Request . . . . . . . . . . . 43
5.7. Message Forwarding . . . . . . . . . . . . . . . . . . . . 44 5.7. Message Forwarding . . . . . . . . . . . . . . . . . . . . 44
5.7.1. Via . . . . . . . . . . . . . . . . . . . . . . . . . 45 5.7.1. Via . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.7.2. Transformations . . . . . . . . . . . . . . . . . . . 46 5.7.2. Transformations . . . . . . . . . . . . . . . . . . . 46
6. Connection Management . . . . . . . . . . . . . . . . . . . . 47 6. Connection Management . . . . . . . . . . . . . . . . . . . . 46
6.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 48 6.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 47
6.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 49 6.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 49
6.3. Persistence . . . . . . . . . . . . . . . . . . . . . . . 49 6.3. Persistence . . . . . . . . . . . . . . . . . . . . . . . 49
6.3.1. Retrying Requests . . . . . . . . . . . . . . . . . . 50 6.3.1. Retrying Requests . . . . . . . . . . . . . . . . . . 50
6.3.2. Pipelining . . . . . . . . . . . . . . . . . . . . . . 51 6.3.2. Pipelining . . . . . . . . . . . . . . . . . . . . . . 50
6.4. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 52 6.4. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 51
6.5. Failures and Time-outs . . . . . . . . . . . . . . . . . . 52 6.5. Failures and Time-outs . . . . . . . . . . . . . . . . . . 52
6.6. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 53 6.6. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 52
6.7. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 54 6.7. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 53
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55
7.1. Header Field Registration . . . . . . . . . . . . . . . . 55 7.1. Header Field Registration . . . . . . . . . . . . . . . . 55
7.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 56 7.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 56
7.3. Internet Media Type Registration . . . . . . . . . . . . . 56 7.3. Internet Media Type Registration . . . . . . . . . . . . . 56
7.3.1. Internet Media Type message/http . . . . . . . . . . . 57 7.3.1. Internet Media Type message/http . . . . . . . . . . . 56
7.3.2. Internet Media Type application/http . . . . . . . . . 58 7.3.2. Internet Media Type application/http . . . . . . . . . 57
7.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 59 7.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 58
7.5. Transfer Coding Registration . . . . . . . . . . . . . . . 59 7.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 58
7.6. Upgrade Token Registry . . . . . . . . . . . . . . . . . . 60 7.4.2. Registration . . . . . . . . . . . . . . . . . . . . . 59
7.7. Upgrade Token Registration . . . . . . . . . . . . . . . . 61 7.5. Upgrade Token Registry . . . . . . . . . . . . . . . . . . 59
8. Security Considerations . . . . . . . . . . . . . . . . . . . 61 7.5.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 59
7.5.2. Upgrade Token Registration . . . . . . . . . . . . . . 60
8. Security Considerations . . . . . . . . . . . . . . . . . . . 60
8.1. DNS-related Attacks . . . . . . . . . . . . . . . . . . . 61 8.1. DNS-related Attacks . . . . . . . . . . . . . . . . . . . 61
8.2. Intermediaries and Caching . . . . . . . . . . . . . . . . 61 8.2. Intermediaries and Caching . . . . . . . . . . . . . . . . 61
8.3. Buffer Overflows . . . . . . . . . . . . . . . . . . . . . 62 8.3. Buffer Overflows . . . . . . . . . . . . . . . . . . . . . 61
8.4. Message Integrity . . . . . . . . . . . . . . . . . . . . 62 8.4. Message Integrity . . . . . . . . . . . . . . . . . . . . 62
8.5. Server Log Information . . . . . . . . . . . . . . . . . . 63 8.5. Server Log Information . . . . . . . . . . . . . . . . . . 62
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 63 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 63
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 65 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 64
10.1. Normative References . . . . . . . . . . . . . . . . . . . 65 10.1. Normative References . . . . . . . . . . . . . . . . . . . 64
10.2. Informative References . . . . . . . . . . . . . . . . . . 66 10.2. Informative References . . . . . . . . . . . . . . . . . . 66
Appendix A. HTTP Version History . . . . . . . . . . . . . . . . 68 Appendix A. HTTP Version History . . . . . . . . . . . . . . . . 67
A.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 69 A.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 68
A.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 69 A.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 68
A.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 69 A.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 69
A.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 70 A.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 69
A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 70 A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 69
Appendix B. ABNF list extension: #rule . . . . . . . . . . . . . 72 Appendix B. ABNF list extension: #rule . . . . . . . . . . . . . 72
Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 73 Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 73
Appendix D. Change Log (to be removed by RFC Editor before Appendix D. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 76 publication) . . . . . . . . . . . . . . . . . . . . 76
D.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 76 D.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 76
D.2. Since draft-ietf-httpbis-p1-messaging-21 . . . . . . . . . 76 D.2. Since draft-ietf-httpbis-p1-messaging-21 . . . . . . . . . 76
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 D.3. Since draft-ietf-httpbis-p1-messaging-22 . . . . . . . . . 77
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
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 self- request/response protocol that uses extensible semantics and self-
descriptive message payloads for flexible interaction with network- descriptive message payloads for flexible interaction with network-
based hypertext information systems. This document is the first in a based hypertext information systems. This document is the first in a
series of documents that collectively form the HTTP/1.1 series of documents that collectively form the HTTP/1.1
specification: specification:
skipping to change at page 8, line 33 skipping to change at page 8, line 33
Accept-Language: en, mi Accept-Language: en, mi
server response: server response:
HTTP/1.1 200 OK HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache Server: Apache
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00" ETag: "34aa387-d-1568eb00"
Accept-Ranges: bytes Accept-Ranges: bytes
Content-Length: 14 Content-Length: 51
Vary: Accept-Encoding Vary: Accept-Encoding
Content-Type: text/plain Content-Type: text/plain
Hello World! Hello World! My payload includes a trailing CRLF.
(Note that the content length includes the trailing CR/LF sequence of
the body text)
2.2. Implementation Diversity 2.2. Implementation Diversity
When considering the design of HTTP, it is easy to fall into a trap When considering the design of HTTP, it is easy to fall into a trap
of thinking that all user agents are general-purpose browsers and all of thinking that all user agents are general-purpose browsers and all
origin servers are large public websites. That is not the case in origin servers are large public websites. That is not the case in
practice. Common HTTP user agents include household appliances, practice. Common HTTP user agents include household appliances,
stereos, scales, firmware update scripts, command-line programs, stereos, scales, firmware update scripts, command-line programs,
mobile apps, and communication devices in a multitude of shapes and mobile apps, and communication devices in a multitude of shapes and
sizes. Likewise, common HTTP origin servers include home automation sizes. Likewise, common HTTP origin servers include home automation
skipping to change at page 12, line 47 skipping to change at page 12, line 42
depending on what behavior is being constrained by the requirement. depending on what behavior is being constrained by the requirement.
Additional (social) requirements are placed on implementations, Additional (social) requirements are placed on implementations,
resource owners, and protocol element registrations when they apply resource owners, and protocol element registrations when they apply
beyond the scope of a single communication. beyond the scope of a single communication.
The verb "generate" is used instead of "send" where a requirement The verb "generate" is used instead of "send" where a requirement
differentiates between creating a protocol element and merely differentiates between creating a protocol element and merely
forwarding a received element downstream. forwarding a received element downstream.
An implementation is considered conformant if it complies with all of An implementation is considered conformant if it complies with all of
the requirements associated with the roles it partakes in HTTP. Note the requirements associated with the roles it partakes in HTTP.
that SHOULD-level requirements are relevant here, unless one of the
documented exceptions is applicable.
Conformance applies to both the syntax and semantics of HTTP protocol Conformance applies to both the syntax and semantics of HTTP protocol
elements. A sender MUST NOT generate protocol elements that convey a elements. A sender MUST NOT generate protocol elements that convey a
meaning that is known by that sender to be false. A sender MUST NOT meaning that is known by that sender to be false. A sender MUST NOT
generate protocol elements that do not match the grammar defined by generate protocol elements that do not match the grammar defined by
the ABNF rules for those protocol elements that are applicable to the the ABNF rules for those protocol elements that are applicable to the
sender's role. If a received protocol element is processed, the sender's role. If a received protocol element is processed, the
recipient MUST be able to parse any value that would match the ABNF recipient MUST be able to parse any value that would match the ABNF
rules for that protocol element, excluding only those rules not rules for that protocol element, excluding only those rules not
applicable to the recipient's role. applicable to the recipient's role.
skipping to change at page 15, line 29 skipping to change at page 15, line 23
when one or more of the request header fields (e.g., User-Agent) when one or more of the request header fields (e.g., User-Agent)
uniquely match the values sent by a client known to be in error. uniquely match the values sent by a client known to be in error.
The intention of HTTP's versioning design is that the major number The intention of HTTP's versioning design is that the major number
will only be incremented if an incompatible message syntax is will only be incremented if an incompatible message syntax is
introduced, and that the minor number will only be incremented when introduced, and that the minor number will only be incremented when
changes made to the protocol have the effect of adding to the message changes made to the protocol have the effect of adding to the message
semantics or implying additional capabilities of the sender. semantics or implying additional capabilities of the sender.
However, the minor version was not incremented for the changes However, the minor version was not incremented for the changes
introduced between [RFC2068] and [RFC2616], and this revision has introduced between [RFC2068] and [RFC2616], and this revision has
specifically avoiding any such changes to the protocol. specifically avoided any such changes to the protocol.
2.7. Uniform Resource Identifiers 2.7. Uniform Resource Identifiers
Uniform Resource Identifiers (URIs) [RFC3986] are used throughout Uniform Resource Identifiers (URIs) [RFC3986] are used throughout
HTTP as the means for identifying resources (Section 2 of [Part2]). HTTP as the means for identifying resources (Section 2 of [Part2]).
URI references are used to target requests, indicate redirects, and URI references are used to target requests, indicate redirects, and
define relationships. define relationships.
This specification adopts the definitions of "URI-reference", This specification adopts the definitions of "URI-reference",
"absolute-URI", "relative-part", "port", "host", "path-abempty", "absolute-URI", "relative-part", "port", "host", "path-abempty",
skipping to change at page 16, line 30 skipping to change at page 16, line 17
of reference (URI-reference), only a URI in absolute form (absolute- of reference (URI-reference), only a URI in absolute form (absolute-
URI), only the path and optional query components, or some URI), only the path and optional query components, or some
combination of the above. Unless otherwise indicated, URI references combination of the above. Unless otherwise indicated, URI references
are parsed relative to the effective request URI (Section 5.5). are parsed relative to the effective request URI (Section 5.5).
2.7.1. http URI scheme 2.7.1. http URI scheme
The "http" URI scheme is hereby defined for the purpose of minting The "http" URI scheme is hereby defined for the purpose of minting
identifiers according to their association with the hierarchical identifiers according to their association with the hierarchical
namespace governed by a potential HTTP origin server listening for namespace governed by a potential HTTP origin server listening for
TCP connections on a given port. TCP ([RFC0793]) connections on a given port.
http-URI = "http:" "//" authority path-abempty [ "?" query ] http-URI = "http:" "//" authority path-abempty [ "?" query ]
The HTTP origin server is identified by the generic syntax's The HTTP origin server is identified by the generic syntax's
authority component, which includes a host identifier and optional authority component, which includes a host identifier and optional
TCP port ([RFC3986], Section 3.2.2). The remainder of the URI, TCP port ([RFC3986], Section 3.2.2). The remainder of the URI,
consisting of both the hierarchical path component and optional query consisting of both the hierarchical path component and optional query
component, serves as an identifier for a potential resource within component, serves as an identifier for a potential resource within
that origin server's name space. that origin server's name space.
skipping to change at page 17, line 51 skipping to change at page 17, line 38
header field value. Recipients of an "http" URI reference SHOULD header field value. Recipients of an "http" URI reference SHOULD
parse for userinfo and treat its presence as an error, since it is parse for userinfo and treat its presence as an error, since it is
likely being used to obscure the authority for the sake of phishing likely being used to obscure the authority for the sake of phishing
attacks. attacks.
2.7.2. https URI scheme 2.7.2. https URI scheme
The "https" URI scheme is hereby defined for the purpose of minting The "https" URI scheme is hereby defined for the purpose of minting
identifiers according to their association with the hierarchical identifiers according to their association with the hierarchical
namespace governed by a potential HTTP origin server listening to a namespace governed by a potential HTTP origin server listening to a
given TCP port for TLS-secured connections [RFC5246]. given TCP port for TLS-secured connections ([RFC0793], [RFC5246]).
All of the requirements listed above for the "http" scheme are also All of the requirements listed above for the "http" scheme are also
requirements for the "https" scheme, except that a default TCP port requirements for the "https" scheme, except that a default TCP port
of 443 is assumed if the port subcomponent is empty or not given, and of 443 is assumed if the port subcomponent is empty or not given, and
the TCP connection MUST be secured, end-to-end, through the use of the TCP connection MUST be secured, end-to-end, through the use of
strong encryption prior to sending the first HTTP request. strong encryption prior to sending the first HTTP request.
https-URI = "https:" "//" authority path-abempty [ "?" query ] https-URI = "https:" "//" authority path-abempty [ "?" query ]
Resources made available via the "https" scheme have no shared Resources made available via the "https" scheme have no shared
skipping to change at page 19, line 42 skipping to change at page 19, line 26
after the element has been extracted from the message, such as within after the element has been extracted from the message, such as within
a header field-value after message parsing has delineated the a header field-value after message parsing has delineated the
individual fields. individual fields.
An HTTP message can be parsed as a stream for incremental processing An HTTP message can be parsed as a stream for incremental processing
or forwarding downstream. However, recipients cannot rely on or forwarding downstream. However, recipients cannot rely on
incremental delivery of partial messages, since some implementations incremental delivery of partial messages, since some implementations
will buffer or delay message forwarding for the sake of network will buffer or delay message forwarding for the sake of network
efficiency, security checks, or payload transformations. efficiency, security checks, or payload transformations.
A sender MUST NOT send whitespace between the start-line and the
first header field. A recipient that receives whitespace between the
start-line and the first header field MUST either reject the message
as invalid or consume each whitespace-preceded line without further
processing of it (i.e., ignore the entire line, along with any
subsequent lines preceded by whitespace, until a properly formed
header field is received or the header block is terminated).
The presence of such whitespace in a request might be an attempt to
trick a server into ignoring that field or processing the line after
it as a new request, either of which might result in a security
vulnerability if other implementations within the request chain
interpret the same message differently. Likewise, the presence of
such whitespace in a response might be ignored by some clients or
cause others to cease parsing.
3.1. Start Line 3.1. Start Line
An HTTP message can either be a request from client to server or a An HTTP message can either be a request from client to server or a
response from server to client. Syntactically, the two types of response from server to client. Syntactically, the two types of
message differ only in the start-line, which is either a request-line message differ only in the start-line, which is either a request-line
(for requests) or a status-line (for responses), and in the algorithm (for requests) or a status-line (for responses), and in the algorithm
for determining the length of the message body (Section 3.3). for determining the length of the message body (Section 3.3).
In theory, a client could receive requests and a server could receive In theory, a client could receive requests and a server could receive
responses, distinguishing them by their different start-line formats, responses, distinguishing them by their different start-line formats,
but in practice servers are implemented to only expect a request (a but in practice servers are implemented to only expect a request (a
response is interpreted as an unknown or invalid request method) and response is interpreted as an unknown or invalid request method) and
clients are implemented to only expect a response. clients are implemented to only expect a response.
start-line = request-line / status-line start-line = request-line / status-line
A sender MUST NOT send whitespace between the start-line and the
first header field. The presence of such whitespace in a request
might be an attempt to trick a server into ignoring that field or
processing the line after it as a new request, either of which might
result in a security vulnerability if other implementations within
the request chain interpret the same message differently. Likewise,
the presence of such whitespace in a response might be ignored by
some clients or cause others to cease parsing.
A recipient that receives whitespace between the start-line and the
first header field MUST either reject the message as invalid or
consume each whitespace-preceded line without further processing of
it (i.e., ignore the entire line, along with any subsequent lines
preceded by whitespace, until a properly formed header field is
received or the header block is terminated).
3.1.1. Request Line 3.1.1. Request Line
A request-line begins with a method token, followed by a single space A request-line begins with a method token, followed by a single space
(SP), the request-target, another single space (SP), the protocol (SP), the request-target, another single space (SP), the protocol
version, and ending with CRLF. version, and ending with CRLF.
request-line = method SP request-target SP HTTP-version CRLF request-line = method SP request-target SP HTTP-version CRLF
The method token indicates the request method to be performed on the The method token indicates the request method to be performed on the
target resource. The request method is case-sensitive. target resource. The request method is case-sensitive.
method = token method = token
The methods defined by this specification can be found in Section 4 The methods defined by this specification can be found in Section 4
of [Part2], along with information regarding the HTTP method registry of [Part2], along with information regarding the HTTP method registry
and considerations for defining new methods. and considerations for defining new methods.
The request-target identifies the target resource upon which to apply The request-target identifies the target resource upon which to apply
the request, as defined in Section 5.3. the request, as defined in Section 5.3.
No whitespace is allowed inside the method, request-target, and Recipients typically parse the request-line into its component parts
protocol version. Hence, recipients typically parse the request-line by splitting on whitespace (see Section 3.5), since no whitespace is
into its component parts by splitting on whitespace (see allowed in the three components. Unfortunately, some user agents
Section 3.5). fail to properly encode or exclude whitespace found in hypertext
references, resulting in those disallowed characters being sent in a
request-target.
Unfortunately, some user agents fail to properly encode hypertext Recipients of an invalid request-line SHOULD respond with either a
references that have embedded whitespace, sending the characters 400 (Bad Request) error or a 301 (Moved Permanently) redirect with
directly instead of properly encoding or excluding the disallowed the request-target properly encoded. Recipients SHOULD NOT attempt
characters. Recipients of an invalid request-line SHOULD respond to autocorrect and then process the request without a redirect, since
with either a 400 (Bad Request) error or a 301 (Moved Permanently) the invalid request-line might be deliberately crafted to bypass
redirect with the request-target properly encoded. Recipients SHOULD security filters along the request chain.
NOT attempt to autocorrect and then process the request without a
redirect, since the invalid request-line might be deliberately
crafted to bypass security filters along the request chain.
HTTP does not place a pre-defined limit on the length of a request- HTTP does not place a pre-defined limit on the length of a request-
line. A server that receives a method longer than any that it line. A server that receives a method longer than any that it
implements SHOULD respond with a 501 (Not Implemented) status code. implements SHOULD respond with a 501 (Not Implemented) status code.
A server MUST be prepared to receive URIs of unbounded length and A server MUST be prepared to receive URIs of unbounded length and
respond with the 414 (URI Too Long) status code if the received respond with the 414 (URI Too Long) status code if the received
request-target would be longer than the server wishes to handle (see request-target would be longer than the server wishes to handle (see
Section 6.5.12 of [Part2]). Section 6.5.12 of [Part2]).
Various ad-hoc limitations on request-line length are found in Various ad-hoc limitations on request-line length are found in
skipping to change at page 22, line 8 skipping to change at page 21, line 41
textual description associated with the numeric status code, mostly textual description associated with the numeric status code, mostly
out of deference to earlier Internet application protocols that were out of deference to earlier Internet application protocols that were
more frequently used with interactive text clients. A client SHOULD more frequently used with interactive text clients. A client SHOULD
ignore the reason-phrase content. ignore the reason-phrase content.
reason-phrase = *( HTAB / SP / VCHAR / obs-text ) reason-phrase = *( HTAB / SP / VCHAR / obs-text )
3.2. Header Fields 3.2. Header Fields
Each HTTP header field consists of a case-insensitive field name Each HTTP header field consists of a case-insensitive field name
followed by a colon (":"), optional whitespace, and the field value. followed by a colon (":"), optional leading whitespace, the field
value, and optional trailing whitespace.
header-field = field-name ":" OWS field-value BWS header-field = field-name ":" OWS field-value OWS
field-name = token field-name = token
field-value = *( field-content / obs-fold ) field-value = *( field-content / obs-fold )
field-content = *( HTAB / SP / VCHAR / obs-text ) field-content = *( HTAB / SP / VCHAR / obs-text )
obs-fold = CRLF ( SP / HTAB ) obs-fold = CRLF ( SP / HTAB )
; obsolete line folding ; obsolete line folding
; see Section 3.2.4 ; see Section 3.2.4
The field-name token labels the corresponding field-value as having The field-name token labels the corresponding field-value as having
the semantics defined by that header field. For example, the Date the semantics defined by that header field. For example, the Date
header field is defined in Section 7.1.1.2 of [Part2] as containing header field is defined in Section 7.1.1.2 of [Part2] as containing
skipping to change at page 22, line 34 skipping to change at page 22, line 19
HTTP header fields are fully extensible: there is no limit on the HTTP header fields are fully extensible: there is no limit on the
introduction of new field names, each presumably defining new introduction of new field names, each presumably defining new
semantics, nor on the number of header fields used in a given semantics, nor on the number of header fields used in a given
message. Existing fields are defined in each part of this message. Existing fields are defined in each part of this
specification and in many other specifications outside the core specification and in many other specifications outside the core
standard. New header fields can be introduced without changing the standard. New header fields can be introduced without changing the
protocol version if their defined semantics allow them to be safely protocol version if their defined semantics allow them to be safely
ignored by recipients that do not recognize them. ignored by recipients that do not recognize them.
New HTTP header fields ought to be be registered with IANA in the New HTTP header fields ought to be registered with IANA in the
Message Header Field Registry, as described in Section 8.3 of Message Header Field Registry, as described in Section 8.3 of
[Part2]. A proxy MUST forward unrecognized header fields unless the [Part2]. A proxy MUST forward unrecognized header fields unless the
field-name is listed in the Connection header field (Section 6.1) or field-name is listed in the Connection header field (Section 6.1) or
the proxy is specifically configured to block, or otherwise the proxy is specifically configured to block, or otherwise
transform, such fields. Other recipients SHOULD ignore unrecognized transform, such fields. Other recipients SHOULD ignore unrecognized
header fields. header fields.
3.2.2. Field Order 3.2.2. Field Order
The order in which header fields with differing field names are The order in which header fields with differing field names are
skipping to change at page 23, line 34 skipping to change at page 23, line 20
special case while processing header fields. (See Appendix A.2.3 special case while processing header fields. (See Appendix A.2.3
of [Kri2001] for details.) of [Kri2001] for details.)
3.2.3. Whitespace 3.2.3. Whitespace
This specification uses three rules to denote the use of linear This specification uses three rules to denote the use of linear
whitespace: OWS (optional whitespace), RWS (required whitespace), and whitespace: OWS (optional whitespace), RWS (required whitespace), and
BWS ("bad" whitespace). BWS ("bad" whitespace).
The OWS rule is used where zero or more linear whitespace octets The OWS rule is used where zero or more linear whitespace octets
might appear. OWS SHOULD either not be generated or be generated as might appear. For protocol elements where optional whitespace is
a single SP. Multiple OWS octets that occur within field-content preferred to improve readability, a sender SHOULD generate the
SHOULD either be replaced with a single SP or transformed to all SP optional whitespace as a single SP; otherwise, a sender SHOULD NOT
octets (each octet other than SP replaced with SP) before generate optional whitespace except as needed to white-out invalid or
interpreting the field value or forwarding the message downstream. unwanted protocol elements during in-place message filtering.
RWS is used when at least one linear whitespace octet is required to The RWS rule is used when at least one linear whitespace octet is
separate field tokens. RWS SHOULD be generated as a single SP. required to separate field tokens. A sender SHOULD generate RWS as a
Multiple RWS octets that occur within field-content SHOULD either be single SP.
replaced with a single SP or transformed to all SP octets before
interpreting the field value or forwarding the message downstream.
BWS is used where the grammar allows optional whitespace, for The BWS rule is used where the grammar allows optional whitespace
historical reasons, but senders SHOULD NOT generate it in messages; only for historical reasons. A sender MUST NOT generate BWS in
recipients MUST accept such bad optional whitespace and remove it messages. A recipient MUST parse for such bad whitespace and remove
before interpreting the field value or forwarding the message it before interpreting the protocol element.
downstream.
OWS = *( SP / HTAB ) OWS = *( SP / HTAB )
; optional whitespace ; optional whitespace
RWS = 1*( SP / HTAB ) RWS = 1*( SP / HTAB )
; required whitespace ; required whitespace
BWS = OWS BWS = OWS
; "bad" whitespace ; "bad" whitespace
3.2.4. Field Parsing 3.2.4. Field Parsing
skipping to change at page 24, line 26 skipping to change at page 24, line 9
security vulnerabilities in request routing and response handling. A security vulnerabilities in request routing and response handling. A
server MUST reject any received request message that contains server MUST reject any received request message that contains
whitespace between a header field-name and colon with a response code whitespace between a header field-name and colon with a response code
of 400 (Bad Request). A proxy MUST remove any such whitespace from a of 400 (Bad Request). A proxy MUST remove any such whitespace from a
response message before forwarding the message downstream. response message before forwarding the message downstream.
A field value is preceded by optional whitespace (OWS); a single SP A field value is preceded by optional whitespace (OWS); a single SP
is preferred. The field value does not include any leading or is preferred. The field value does not include any leading or
trailing white space: OWS occurring before the first non-whitespace trailing white space: OWS occurring before the first non-whitespace
octet of the field value or after the last non-whitespace octet of octet of the field value or after the last non-whitespace octet of
the field value is ignored and SHOULD be removed before further the field value ought to be excluded by parsers when extracting the
processing (as this does not change the meaning of the header field). field value from a header field.
A recipient of field-content containing multiple sequential octets of
optional (OWS) or required (RWS) whitespace SHOULD either replace the
sequence with a single SP or transform any non-SP octets in the
sequence to SP octets before interpreting the field value or
forwarding the message downstream.
Historically, HTTP header field values could be extended over Historically, HTTP header field values could be extended over
multiple lines by preceding each extra line with at least one space multiple lines by preceding each extra line with at least one space
or horizontal tab (obs-fold). This specification deprecates such or horizontal tab (obs-fold). This specification deprecates such
line folding except within the message/http media type line folding except within the message/http media type
(Section 7.3.1). Senders MUST NOT generate messages that include (Section 7.3.1). Senders MUST NOT generate messages that include
line folding (i.e., that contain any field-value that contains a line folding (i.e., that contain any field-value that contains a
match to the obs-fold rule) unless the message is intended for match to the obs-fold rule) unless the message is intended for
packaging within the message/http media type. When an obs-fold is packaging within the message/http media type.
received in a message, recipients MUST do one of:
o accept the message and replace any embedded obs-fold whitespace
with either a single SP or a matching number of SP octets (to
avoid buffer copying) prior to interpreting the field value or
forwarding the message downstream;
o if it is a request, reject the message by sending a 400 (Bad A server that receives an obs-fold in a request message that is not
Request) response with a representation explaining that obsolete within a message/http container MUST either reject the message by
line folding is unacceptable; or, sending a 400 (Bad Request), preferably with a representation
explaining that obsolete line folding is unacceptable, or replace
each received obs-fold with one or more SP octets prior to
interpreting the field value or forwarding the message downstream.
o if it is a response, discard the message and generate a 502 (Bad A proxy or gateway that receives an obs-fold in a response message
Gateway) response with a representation explaining that that is not within a message/http container MUST either discard the
unacceptable line folding was received. message and replace it with a 502 (Bad Gateway) response, preferably
with a representation explaining that unacceptable line folding was
received, or replace each received obs-fold with one or more SP
octets prior to interpreting the field value or forwarding the
message downstream.
Recipients that choose not to implement obs-fold processing (as A user agent that receives an obs-fold in a response message that is
described above) MUST NOT accept messages containing header fields not within a message/http container MUST replace each received obs-
with leading whitespace, as this can expose them to attacks that fold with one or more SP octets prior to interpreting the field
exploit this difference in processing. value.
Historically, HTTP has allowed field content with text in the ISO- Historically, HTTP has allowed field content with text in the ISO-
8859-1 [ISO-8859-1] charset, supporting other charsets only through 8859-1 [ISO-8859-1] charset, supporting other charsets only through
use of [RFC2047] encoding. In practice, most HTTP header field use of [RFC2047] encoding. In practice, most HTTP header field
values use only a subset of the US-ASCII charset [USASCII]. Newly values use only a subset of the US-ASCII charset [USASCII]. Newly
defined header fields SHOULD limit their field values to US-ASCII defined header fields SHOULD limit their field values to US-ASCII
octets. Recipients SHOULD treat other octets in field content (obs- octets. Recipients SHOULD treat other octets in field content (obs-
text) as opaque data. text) as opaque data.
3.2.5. Field Limits 3.2.5. Field Limits
skipping to change at page 33, line 16 skipping to change at page 33, line 8
if the size of the message body received (in octets) is less than the if the size of the message body received (in octets) is less than the
value given by Content-Length. A response that has neither chunked value given by Content-Length. A response that has neither chunked
transfer coding nor Content-Length is terminated by closure of the transfer coding nor Content-Length is terminated by closure of the
connection, and thus is considered complete regardless of the number connection, and thus is considered complete regardless of the number
of message body octets received, provided that the header block was of message body octets received, provided that the header block was
received intact. received intact.
3.5. Message Parsing Robustness 3.5. Message Parsing Robustness
Older HTTP/1.0 user agent implementations might send an extra CRLF Older HTTP/1.0 user agent implementations might send an extra CRLF
after a POST request as a lame workaround for some early server after a POST request as a workaround for some early server
applications that failed to read message body content that was not applications that failed to read message body content that was not
terminated by a line-ending. An HTTP/1.1 user agent MUST NOT preface terminated by a line-ending. An HTTP/1.1 user agent MUST NOT preface
or follow a request with an extra CRLF. If terminating the request or follow a request with an extra CRLF. If terminating the request
message body with a line-ending is desired, then the user agent MUST message body with a line-ending is desired, then the user agent MUST
count the terminating CRLF octets as part of the message body length. count the terminating CRLF octets as part of the message body length.
In the interest of robustness, servers SHOULD ignore at least one In the interest of robustness, servers SHOULD ignore at least one
empty line received where a request-line is expected. In other empty line received where a request-line is expected. In other
words, if a server is reading the protocol stream at the beginning of words, if a server is reading the protocol stream at the beginning of
a message and receives a CRLF first, the server SHOULD ignore the a message and receives a CRLF first, the server SHOULD ignore the
skipping to change at page 36, line 34 skipping to change at page 36, line 11
The above requirement prevents the need for an infinite buffer when a The above requirement prevents the need for an infinite buffer when a
message is being received by an HTTP/1.1 (or later) proxy and message is being received by an HTTP/1.1 (or later) proxy and
forwarded to an HTTP/1.0 recipient. forwarded to an HTTP/1.0 recipient.
4.1.2. Decoding chunked 4.1.2. Decoding chunked
A process for decoding the chunked transfer coding can be represented A process for decoding the chunked transfer coding can be represented
in pseudo-code as: in pseudo-code as:
length := 0 length := 0
read chunk-size, chunk-ext (if any) and CRLF read chunk-size, chunk-ext (if any), and CRLF
while (chunk-size > 0) { while (chunk-size > 0) {
read chunk-data and CRLF read chunk-data and CRLF
append chunk-data to decoded-body append chunk-data to decoded-body
length := length + chunk-size length := length + chunk-size
read chunk-size and CRLF read chunk-size, chunk-ext (if any), and CRLF
} }
read header-field read header-field
while (header-field not empty) { while (header-field not empty) {
append header-field to existing header fields append header-field to existing header fields
read header-field read header-field
} }
Content-Length := length Content-Length := length
Remove "chunked" from Transfer-Encoding Remove "chunked" from Transfer-Encoding
Remove Trailer from existing header fields Remove Trailer from existing header fields
skipping to change at page 53, line 9 skipping to change at page 52, line 35
closed while it was idle, but from the client's point of view, a closed while it was idle, but from the client's point of view, a
request is in progress. request is in progress.
Servers SHOULD maintain persistent connections and allow the Servers SHOULD maintain persistent connections and allow the
underlying transport's flow control mechanisms to resolve temporary underlying transport's flow control mechanisms to resolve temporary
overloads, rather than terminate connections with the expectation overloads, rather than terminate connections with the expectation
that clients will retry. The latter technique can exacerbate network that clients will retry. The latter technique can exacerbate network
congestion. congestion.
A client sending a message body SHOULD monitor the network connection A client sending a message body SHOULD monitor the network connection
for an error status code while it is transmitting the request. If for an error response while it is transmitting the request. If the
the client sees an error status code, it SHOULD immediately cease client sees an error response, it SHOULD immediately cease
transmitting the body and close the connection. transmitting the body and close the connection.
6.6. Tear-down 6.6. Tear-down
The Connection header field (Section 6.1) provides a "close" The Connection header field (Section 6.1) provides a "close"
connection option that a sender SHOULD send when it wishes to close connection option that a sender SHOULD send when it wishes to close
the connection after the current request/response pair. the connection after the current request/response pair.
A client that sends a close connection option MUST NOT send further A client that sends a close connection option MUST NOT send further
requests on that connection (after the one containing close) and MUST requests on that connection (after the one containing close) and MUST
close the connection after reading the final response message close the connection after reading the final response message
corresponding to this request. corresponding to this request.
A server that receives a close connection option MUST initiate a A server that receives a close connection option MUST initiate a
lingering close (see below) of the connection after it sends the close of the connection (see below) after it sends the final response
final response to the request that contained close. The server to the request that contained close. The server SHOULD send a close
SHOULD send a close connection option in its final response on that connection option in its final response on that connection. The
connection. The server MUST NOT process any further requests server MUST NOT process any further requests received on that
received on that connection. connection.
A server that sends a close connection option MUST initiate a A server that sends a close connection option MUST initiate a close
lingering close of the connection after it sends the response of the connection (see below) after it sends the response containing
containing close. The server MUST NOT process any further requests close. The server MUST NOT process any further requests received on
received on that connection. that connection.
A client that receives a close connection option MUST cease sending A client that receives a close connection option MUST cease sending
requests on that connection and close the connection after reading requests on that connection and close the connection after reading
the response message containing the close; if additional pipelined the response message containing the close; if additional pipelined
requests had been sent on the connection, the client SHOULD assume requests had been sent on the connection, the client SHOULD NOT
that they will not be processed by the server. assume that they will be processed by the server.
If a server performs an immediate close of a TCP connection, there is If a server performs an immediate close of a TCP connection, there is
a significant risk that the client will not be able to read the last a significant risk that the client will not be able to read the last
HTTP response. If the server receives additional data from the HTTP response. If the server receives additional data from the
client on a fully-closed connection, such as another request that was client on a fully-closed connection, such as another request that was
sent by the client before receiving the server's response, the sent by the client before receiving the server's response, the
server's TCP stack will send a reset packet to the client; server's TCP stack will send a reset packet to the client;
unfortunately, the reset packet might erase the client's unfortunately, the reset packet might erase the client's
unacknowledged input buffers before they can be read and interpreted unacknowledged input buffers before they can be read and interpreted
by the client's HTTP parser. by the client's HTTP parser.
To avoid the TCP reset problem, a server can perform a lingering To avoid the TCP reset problem, servers typically close a connection
close on a connection by closing only the write side of the read/ in stages. First, the server performs a half-close by closing only
write connection (a half-close) and continuing to read from the the write side of the read/write connection. The server then
connection until the connection is closed by the client or the server continues to read from the connection until it receives a
is reasonably certain that its own TCP stack has received the corresponding close by the client, or until the server is reasonably
client's acknowledgement of the packet(s) containing the server's certain that its own TCP stack has received the client's
last response. It is then safe for the server to fully close the acknowledgement of the packet(s) containing the server's last
connection. response. Finally, the server fully closes the connection.
It is unknown whether the reset problem is exclusive to TCP or might It is unknown whether the reset problem is exclusive to TCP or might
also be found in other transport connection protocols. also be found in other transport connection protocols.
6.7. Upgrade 6.7. Upgrade
The "Upgrade" header field is intended to provide a simple mechanism The "Upgrade" header field is intended to provide a simple mechanism
for transitioning from HTTP/1.1 to some other protocol on the same for transitioning from HTTP/1.1 to some other protocol on the same
connection. A client MAY send a list of protocols in the Upgrade connection. A client MAY send a list of protocols in the Upgrade
header field of a request to invite the server to switch to one or header field of a request to invite the server to switch to one or
skipping to change at page 55, line 34 skipping to change at page 55, line 11
The Upgrade header field only applies to switching application-level The Upgrade header field only applies to switching application-level
protocols on the existing connection; it cannot be used to switch to protocols on the existing connection; it cannot be used to switch to
a protocol on a different connection. For that purpose, it is more a protocol on a different connection. For that purpose, it is more
appropriate to use a 3xx (Redirection) response (Section 6.4 of appropriate to use a 3xx (Redirection) response (Section 6.4 of
[Part2]). [Part2]).
This specification only defines the protocol name "HTTP" for use by This specification only defines the protocol name "HTTP" for use by
the family of Hypertext Transfer Protocols, as defined by the HTTP the family of Hypertext Transfer Protocols, as defined by the HTTP
version rules of Section 2.6 and future updates to this version rules of Section 2.6 and future updates to this
specification. Additional tokens ought to be registered with IANA specification. Additional tokens ought to be registered with IANA
using the registration procedure defined in Section 7.6. using the registration procedure defined in Section 7.5.
7. IANA Considerations 7. IANA Considerations
7.1. Header Field Registration 7.1. Header Field Registration
HTTP header fields are registered within the Message Header Field HTTP header fields are registered within the Message Header Field
Registry [BCP90] maintained by IANA at <http://www.iana.org/ Registry maintained at <http://www.iana.org/assignments/
assignments/message-headers/message-header-index.html>. message-headers/message-header-index.html>.
This document defines the following HTTP header fields, so their This document defines the following HTTP header fields, so their
associated registry entries shall be updated according to the associated registry entries shall be updated according to the
permanent registrations below: permanent registrations below (see [BCP90]):
+-------------------+----------+----------+---------------+ +-------------------+----------+----------+---------------+
| Header Field Name | Protocol | Status | Reference | | Header Field Name | Protocol | Status | Reference |
+-------------------+----------+----------+---------------+ +-------------------+----------+----------+---------------+
| Connection | http | standard | Section 6.1 | | Connection | http | standard | Section 6.1 |
| Content-Length | http | standard | Section 3.3.2 | | Content-Length | http | standard | Section 3.3.2 |
| Host | http | standard | Section 5.4 | | Host | http | standard | Section 5.4 |
| TE | http | standard | Section 4.3 | | TE | http | standard | Section 4.3 |
| Trailer | http | standard | Section 4.1.1 | | Trailer | http | standard | Section 4.1.1 |
| Transfer-Encoding | http | standard | Section 3.3.1 | | Transfer-Encoding | http | standard | Section 3.3.1 |
skipping to change at page 58, line 4 skipping to change at page 57, line 28
Magic number(s): none Magic number(s): none
File extension(s): none File extension(s): none
Macintosh file type code(s): none Macintosh file type code(s): none
Person and email address to contact for further information: See Person and email address to contact for further information: See
Authors Section. Authors Section.
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: none Restrictions on usage: none
Author/Change controller: IESG Author: See Authors Section.
Change controller: IESG
7.3.2. Internet Media Type application/http 7.3.2. Internet Media Type application/http
The application/http type can be used to enclose a pipeline of one or The application/http type can be used to enclose a pipeline of one or
more HTTP request or response messages (not intermixed). more HTTP request or response messages (not intermixed).
Type name: application Type name: application
Subtype name: http Subtype name: http
skipping to change at page 59, line 12 skipping to change at page 58, line 36
Macintosh file type code(s): none Macintosh file type code(s): none
Person and email address to contact for further information: See Person and email address to contact for further information: See
Authors Section. Authors Section.
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: none Restrictions on usage: none
Author/Change controller: IESG Author: See Authors Section.
Change controller: IESG
7.4. Transfer Coding Registry 7.4. Transfer Coding Registry
The HTTP Transfer Coding Registry defines the name space for transfer The HTTP Transfer Coding Registry defines the name space for transfer
coding names. coding names. It is maintained at
<http://www.iana.org/assignments/http-parameters>.
7.4.1. Procedure
Registrations MUST include the following fields: Registrations MUST include the following fields:
o Name o Name
o Description o Description
o Pointer to specification text o Pointer to specification text
Names of transfer codings MUST NOT overlap with names of content Names of transfer codings MUST NOT overlap with names of content
codings (Section 3.1.2.1 of [Part2]) unless the encoding codings (Section 3.1.2.1 of [Part2]) unless the encoding
transformation is identical, as is the case for the compression transformation is identical, as is the case for the compression
codings defined in Section 4.2. codings defined in Section 4.2.
Values to be added to this name space require IETF Review (see Values to be added to this name space require IETF Review (see
skipping to change at page 59, line 34 skipping to change at page 59, line 15
o Pointer to specification text o Pointer to specification text
Names of transfer codings MUST NOT overlap with names of content Names of transfer codings MUST NOT overlap with names of content
codings (Section 3.1.2.1 of [Part2]) unless the encoding codings (Section 3.1.2.1 of [Part2]) unless the encoding
transformation is identical, as is the case for the compression transformation is identical, as is the case for the compression
codings defined in Section 4.2. codings defined in Section 4.2.
Values to be added to this name space require IETF Review (see Values to be added to this name space require IETF Review (see
Section 4.1 of [RFC5226]), and MUST conform to the purpose of Section 4.1 of [RFC5226]), and MUST conform to the purpose of
transfer coding defined in this section. Use of program names for transfer coding defined in this specification.
the identification of encoding formats is not desirable and is
discouraged for future encodings.
The registry itself is maintained at Use of program names for the identification of encoding formats is
<http://www.iana.org/assignments/http-parameters>. not desirable and is discouraged for future encodings.
7.5. Transfer Coding Registration 7.4.2. Registration
The HTTP Transfer Coding Registry shall be updated with the The HTTP Transfer Coding Registry shall be updated with the
registrations below: registrations below:
+----------+----------------------------------------+---------------+ +----------+----------------------------------------+---------------+
| Name | Description | Reference | | Name | Description | Reference |
+----------+----------------------------------------+---------------+ +----------+----------------------------------------+---------------+
| chunked | Transfer in a series of chunks | Section 4.1 | | chunked | Transfer in a series of chunks | Section 4.1 |
| compress | UNIX "compress" program method | Section 4.2.1 | | compress | UNIX "compress" program method | Section 4.2.1 |
| deflate | "deflate" compression mechanism | Section 4.2.2 | | deflate | "deflate" compression mechanism | Section 4.2.2 |
| | ([RFC1951]) used inside the "zlib" | | | | ([RFC1951]) used inside the "zlib" | |
| | data format ([RFC1950]) | | | | data format ([RFC1950]) | |
| gzip | Same as GNU zip [RFC1952] | Section 4.2.3 | | gzip | Same as GNU zip [RFC1952] | Section 4.2.3 |
+----------+----------------------------------------+---------------+ +----------+----------------------------------------+---------------+
7.6. Upgrade Token Registry 7.5. Upgrade Token Registry
The HTTP Upgrade Token Registry defines the name space for protocol- The HTTP Upgrade Token Registry defines the name space for protocol-
name tokens used to identify protocols in the Upgrade header field. name tokens used to identify protocols in the Upgrade header field.
The registry is maintained at
<http://www.iana.org/assignments/http-upgrade-tokens>.
7.5.1. Procedure
Each registered protocol name is associated with contact information Each registered protocol name is associated with contact information
and an optional set of specifications that details how the connection and an optional set of specifications that details how the connection
will be processed after it has been upgraded. will be processed after it has been upgraded.
Registrations happen on a "First Come First Served" basis (see Registrations happen on a "First Come First Served" basis (see
Section 4.1 of [RFC5226]) and are subject to the following rules: Section 4.1 of [RFC5226]) and are subject to the following rules:
1. A protocol-name token, once registered, stays registered forever. 1. A protocol-name token, once registered, stays registered forever.
2. The registration MUST name a responsible party for the 2. The registration MUST name a responsible party for the
skipping to change at page 61, line 5 skipping to change at page 60, line 29
The IANA will keep a record of all such changes, and make them The IANA will keep a record of all such changes, and make them
available upon request. available upon request.
7. The IESG MAY reassign responsibility for a protocol token. This 7. The IESG MAY reassign responsibility for a protocol token. This
will normally only be used in the case when a responsible party will normally only be used in the case when a responsible party
cannot be contacted. cannot be contacted.
This registration procedure for HTTP Upgrade Tokens replaces that This registration procedure for HTTP Upgrade Tokens replaces that
previously defined in Section 7.2 of [RFC2817]. previously defined in Section 7.2 of [RFC2817].
7.7. Upgrade Token Registration 7.5.2. Upgrade Token Registration
The HTTP Upgrade Token Registry shall be updated with the The HTTP Upgrade Token Registry shall be updated with the
registration below: registration below:
+-------+----------------------+----------------------+-------------+ +-------+----------------------+----------------------+-------------+
| Value | Description | Expected Version | Reference | | Value | Description | Expected Version | Reference |
| | | Tokens | | | | | Tokens | |
+-------+----------------------+----------------------+-------------+ +-------+----------------------+----------------------+-------------+
| HTTP | Hypertext Transfer | any DIGIT.DIGIT | Section 2.6 | | HTTP | Hypertext Transfer | any DIGIT.DIGIT | Section 2.6 |
| | Protocol | (e.g, "2.0") | | | | Protocol | (e.g, "2.0") | |
skipping to change at page 64, line 9 skipping to change at page 63, line 35
Since 1999, the following contributors have helped improve the HTTP Since 1999, the following contributors have helped improve the HTTP
specification by reporting bugs, asking smart questions, drafting or specification by reporting bugs, asking smart questions, drafting or
reviewing text, and evaluating open issues: reviewing text, and evaluating open issues:
Adam Barth, Adam Roach, Addison Phillips, Adrian Chadd, Adrien W. de Adam Barth, Adam Roach, Addison Phillips, Adrian Chadd, Adrien W. de
Croy, Alan Ford, Alan Ruttenberg, Albert Lunde, Alek Storm, Alex Croy, Alan Ford, Alan Ruttenberg, Albert Lunde, Alek Storm, Alex
Rousskov, Alexandre Morgaut, Alexey Melnikov, Alisha Smith, Amichai Rousskov, Alexandre Morgaut, Alexey Melnikov, Alisha Smith, Amichai
Rothman, Amit Klein, Amos Jeffries, Andreas Maier, Andreas Petersson, Rothman, Amit Klein, Amos Jeffries, Andreas Maier, Andreas Petersson,
Anil Sharma, Anne van Kesteren, Anthony Bryan, Asbjorn Ulsberg, Ashok Anil Sharma, Anne van Kesteren, Anthony Bryan, Asbjorn Ulsberg, Ashok
Kumar, Balachander Krishnamurthy, Barry Leiba, Ben Laurie, Benjamin Kumar, Balachander Krishnamurthy, Barry Leiba, Ben Laurie, Benjamin
Niven-Jenkins, Bil Corry, Bill Burke, Bjoern Hoehrmann, Bob Carlyle, Benjamin Niven-Jenkins, Bil Corry, Bill Burke, Bjoern
Scheifler, Boris Zbarsky, Brett Slatkin, Brian Kell, Brian McBarron, Hoehrmann, Bob Scheifler, Boris Zbarsky, Brett Slatkin, Brian Kell,
Brian Pane, Brian Smith, Bryce Nesbitt, Cameron Heavon-Jones, Carl Brian McBarron, Brian Pane, Brian Raymor, Brian Smith, Bryce Nesbitt,
Kugler, Carsten Bormann, Charles Fry, Chris Newman, Chris Weber, Cameron Heavon-Jones, Carl Kugler, Carsten Bormann, Charles Fry,
Cyrus Daboo, Dale Robert Anderson, Dan Wing, Dan Winship, Daniel Chris Newman, Cyrus Daboo, Dale Robert Anderson, Dan Wing, Dan
Stenberg, Darrel Miller, Dave Cridland, Dave Crocker, Dave Kristol, Winship, Daniel Stenberg, Darrel Miller, Dave Cridland, Dave Crocker,
David Booth, David Singer, David W. Morris, Diwakar Shetty, Dmitry Dave Kristol, Dave Thaler, David Booth, David Singer, David W.
Kurochkin, Drummond Reed, Duane Wessels, Duncan Cragg, Edward Lee, Morris, Diwakar Shetty, Dmitry Kurochkin, Drummond Reed, Duane
Eliot Lear, Eran Hammer-Lahav, Eric D. Williams, Eric J. Bowman, Eric Wessels, Edward Lee, Eitan Adler, Eliot Lear, Eran Hammer-Lahav, Eric
Lawrence, Eric Rescorla, Erik Aronesty, Evan Prodromou, Florian D. Williams, Eric J. Bowman, Eric Lawrence, Eric Rescorla, Erik
Weimer, Frank Ellermann, Fred Bohle, Gabriel Montenegro, Geoffrey Aronesty, Evan Prodromou, Felix Geisendoerfer, Florian Weimer, Frank
Sneddon, Gervase Markham, Grahame Grieve, Greg Wilkins, Harald Tveit Ellermann, Fred Bohle, Frederic Kayser, Gabriel Montenegro, Geoffrey
Alvestrand, Harry Halpin, Helge Hess, Henrik Nordstrom, Henry S. Sneddon, Gervase Markham, Grahame Grieve, Greg Wilkins, Grzegorz
Thompson, Henry Story, Herbert van de Sompel, Howard Melman, Hugo Calkowski, Harald Tveit Alvestrand, Harry Halpin, Helge Hess, Henrik
Haas, Ian Fette, Ian Hickson, Ido Safruti, Ilya Grigorik, Ingo Nordstrom, Henry S. Thompson, Henry Story, Herbert van de Sompel,
Struck, J. Ross Nicoll, James H. Manger, James Lacey, James M. Snell, Herve Ruellan, Howard Melman, Hugo Haas, Ian Fette, Ian Hickson, Ido
Jamie Lokier, Jan Algermissen, Jeff Hodges (who came up with the term Safruti, Ilari Liusvaara, Ilya Grigorik, Ingo Struck, J. Ross Nicoll,
'effective Request-URI'), Jeff Walden, Jeroen de Borst, Jim Luther, James Cloos, James H. Manger, James Lacey, James M. Snell, Jamie
Joe D. Williams, Joe Gregorio, Joe Orton, John C. Klensin, John C. Lokier, Jan Algermissen, Jeff Hodges (who came up with the term
Mallery, John Cowan, John Kemp, John Panzer, John Schneider, John 'effective Request-URI'), Jeff Pinner, Jeff Walden, Jim Luther, Jitu
Stracke, John Sullivan, Jonas Sicking, Jonathan A. Rees, Jonathan Padhye, Joe D. Williams, Joe Gregorio, Joe Orton, John C. Klensin,
Billington, Jonathan Moore, Jonathan Rees, Jonathan Silvera, Jordi John C. Mallery, John Cowan, John Kemp, John Panzer, John Schneider,
Ros, Joris Dobbelsteen, Josh Cohen, Julien Pierre, Jungshik Shin, John Stracke, John Sullivan, Jonas Sicking, Jonathan A. Rees,
Justin Chapweske, Justin Erenkrantz, Justin James, Kalvinder Singh, Jonathan Billington, Jonathan Moore, Jonathan Silvera, Jordi Ros,
Karl Dubost, Keith Hoffman, Keith Moore, Ken Murchison, Koen Holtman, Joris Dobbelsteen, Josh Cohen, Julien Pierre, Jungshik Shin, Justin
Chapweske, Justin Erenkrantz, Justin James, Kalvinder Singh, Karl
Dubost, Keith Hoffman, Keith Moore, Ken Murchison, Koen Holtman,
Konstantin Voronkov, Kris Zyp, Lisa Dusseault, Maciej Stachowiak, Konstantin Voronkov, Kris Zyp, Lisa Dusseault, Maciej Stachowiak,
Marc Schneider, Marc Slemko, Mark Baker, Mark Pauley, Mark Watson, Manu Sporny, Marc Schneider, Marc Slemko, Mark Baker, Mark Pauley,
Markus Isomaki, Markus Lanthaler, Martin J. Duerst, Martin Musatov, Mark Watson, Markus Isomaki, Markus Lanthaler, Martin J. Duerst,
Martin Nilsson, Martin Thomson, Matt Lynch, Matthew Cox, Max Clark, Martin Musatov, Martin Nilsson, Martin Thomson, Matt Lynch, Matthew
Michael Burrows, Michael Hausenblas, Mike Amundsen, Mike Belshe, Mike Cox, Max Clark, Michael Burrows, Michael Hausenblas, Mike Amundsen,
Kelly, Mike Schinkel, Miles Sabin, Murray S. Kucherawy, Mykyta Mike Belshe, Mike Kelly, Mike Schinkel, Miles Sabin, Murray S.
Yevstifeyev, Nathan Rixham, Nicholas Shanks, Nico Williams, Nicolas Kucherawy, Mykyta Yevstifeyev, Nathan Rixham, Nicholas Shanks, Nico
Alvarez, Nicolas Mailhot, Noah Slater, Pablo Castro, Pat Hayes, Williams, Nicolas Alvarez, Nicolas Mailhot, Noah Slater, Osama
Patrick R. McManus, Patrik Faltstrom, Paul E. Jones, Paul Hoffman, Mazahir, Pablo Castro, Pat Hayes, Patrick R. McManus, Paul E. Jones,
Paul Marquess, Peter Lepeska, Peter Saint-Andre, Peter Watkins, Phil Paul Hoffman, Paul Marquess, Peter Lepeska, Peter Saint-Andre, Peter
Archer, Philippe Mougin, Phillip Hallam-Baker, Poul-Henning Kamp, Watkins, Phil Archer, Philippe Mougin, Phillip Hallam-Baker, Piotr
Preethi Natarajan, Rajeev Bector, Ray Polk, Reto Bachmann-Gmuer, Dobrogost, Poul-Henning Kamp, Preethi Natarajan, Rajeev Bector, Ray
Richard Cyganiak, Robert Brewer, Robert Collins, Robert O'Callahan, Polk, Reto Bachmann-Gmuer, Richard Cyganiak, Robby Simpson, Robert
Robert Olofsson, Robert Sayre, Robert Siemer, Robert de Wilde, Brewer, Robert Collins, Robert Mattson, Robert O'Callahan, Robert
Roberto Javier Godoy, Roberto Peon, Roland Zink, Ronny Widjaja, S. Olofsson, Robert Sayre, Robert Siemer, Robert de Wilde, Roberto
Mike Dierken, Salvatore Loreto, Sam Johnston, Sam Ruby, Scott Javier Godoy, Roberto Peon, Roland Zink, Ronny Widjaja, S. Mike
Lawrence (who maintained the original issues list), Sean B. Palmer, Dierken, Salvatore Loreto, Sam Johnston, Sam Ruby, Scott Lawrence
Shane McCarron, Stefan Eissing, Stefan Tilkov, Stefanos Harhalakis, (who maintained the original issues list), Sean B. Palmer, Shane
McCarron, Stefan Eissing, Stefan Tilkov, Stefanos Harhalakis,
Stephane Bortzmeyer, Stephen Farrell, Stephen Ludin, Stuart Williams, Stephane Bortzmeyer, Stephen Farrell, Stephen Ludin, Stuart Williams,
Subbu Allamaraju, Subramanian Moonesamy, Sylvain Hellegouarch, Tapan Subbu Allamaraju, Sylvain Hellegouarch, Tapan Divekar, Tatsuya
Divekar, Tatsuya Hayashi, Ted Hardie, Thomas Broyer, Thomas Fossati, Hayashi, Ted Hardie, Thomas Broyer, Thomas Fossati, Thomas Maslen,
Thomas Nordin, Thomas Roessler, Tim Bray, Tim Morgan, Tim Olsen, Thomas Nordin, Thomas Roessler, Tim Bray, Tim Morgan, Tim Olsen, Tom
Tobias Oberstein, Tom Zhou, Travis Snoozy, Tyler Close, Vincent Zhou, Travis Snoozy, Tyler Close, Vincent Murphy, Wenbo Zhu, Werner
Murphy, Wenbo Zhu, Werner Baumann, Wilbur Streett, Wilfredo Sanchez Baumann, Wilbur Streett, Wilfredo Sanchez Vega, William A. Rowe Jr.,
Vega, William A. Rowe Jr., William Chan, Willy Tarreau, Xiaoshu Wang, William Chan, Willy Tarreau, Xiaoshu Wang, Yaron Goland, Yngve
Yaron Goland, Yngve Nysaeter Pettersen, Yoav Nir, Yogesh Bang, Yutaka Nysaeter Pettersen, Yoav Nir, Yogesh Bang, Yutaka Oiwa, Yves Lafon
Oiwa, Yves Lafon (long-time member of the editor team), Zed A. Shaw, (long-time member of the editor team), Zed A. Shaw, and Zhong Yu.
and Zhong Yu.
See Section 16 of [RFC2616] for additional acknowledgements from See Section 16 of [RFC2616] for additional acknowledgements from
prior revisions. prior revisions.
10. References 10. References
10.1. Normative References 10.1. Normative References
[Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext [Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Semantics and Content", Transfer Protocol (HTTP/1.1): Semantics and Content",
draft-ietf-httpbis-p2-semantics-22 (work in progress), draft-ietf-httpbis-p2-semantics-latest (work in
February 2013. progress), May 2013.
[Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext [Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Conditional Requests", Transfer Protocol (HTTP/1.1): Conditional Requests",
draft-ietf-httpbis-p4-conditional-22 (work in draft-ietf-httpbis-p4-conditional-latest (work in
progress), February 2013. progress), May 2013.
[Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., [Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
"Hypertext Transfer Protocol (HTTP/1.1): Range "Hypertext Transfer Protocol (HTTP/1.1): Range
Requests", draft-ietf-httpbis-p5-range-22 (work in Requests", draft-ietf-httpbis-p5-range-latest (work in
progress), February 2013. progress), May 2013.
[Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
draft-ietf-httpbis-p6-cache-22 (work in progress), draft-ietf-httpbis-p6-cache-latest (work in progress),
February 2013. May 2013.
[Part7] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext [Part7] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Authentication", Transfer Protocol (HTTP/1.1): Authentication",
draft-ietf-httpbis-p7-auth-22 (work in progress), draft-ietf-httpbis-p7-auth-latest (work in progress),
February 2013. May 2013.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[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.
[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.
[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.
skipping to change at page 70, line 7 skipping to change at page 69, line 36
One attempted solution was the introduction of a Proxy-Connection One attempted solution was the introduction of a Proxy-Connection
header field, targeted specifically at proxies. In practice, this header field, targeted specifically at proxies. In practice, this
was also unworkable, because proxies are often deployed in multiple was also unworkable, because proxies are often deployed in multiple
layers, bringing about the same problem discussed above. layers, bringing about the same problem discussed above.
As a result, clients are encouraged not to send the Proxy-Connection As a result, clients are encouraged not to send the Proxy-Connection
header field in any requests. header field in any requests.
Clients are also encouraged to consider the use of Connection: keep- Clients are also encouraged to consider the use of Connection: keep-
alive in requests carefully; while they can enable persistent alive in requests carefully; while they can enable persistent
connections with HTTP/1.0 servers, clients using them need will need connections with HTTP/1.0 servers, clients using them will need to
to monitor the connection for "hung" requests (which indicate that monitor the connection for "hung" requests (which indicate that the
the client ought stop sending the header field), and this mechanism client ought stop sending the header field), and this mechanism ought
ought not be used by clients at all when a proxy is being used. not be used by clients at all when a proxy is being used.
A.1.3. Introduction of Transfer-Encoding A.1.3. Introduction of Transfer-Encoding
HTTP/1.1 introduces the Transfer-Encoding header field HTTP/1.1 introduces the Transfer-Encoding header field
(Section 3.3.1). Transfer codings need to be decoded prior to (Section 3.3.1). Transfer codings need to be decoded prior to
forwarding an HTTP message over a MIME-compliant protocol. forwarding an HTTP message over a MIME-compliant protocol.
A.2. Changes from RFC 2616 A.2. Changes from RFC 2616
HTTP's approach to error handling has been explained. (Section 2.5) HTTP's approach to error handling has been explained. (Section 2.5)
skipping to change at page 72, line 33 skipping to change at page 72, line 14
The semantics of the Upgrade header field is now defined in responses The semantics of the Upgrade header field is now defined in responses
other than 101 (this was incorporated from [RFC2817]). (Section 6.7) other than 101 (this was incorporated from [RFC2817]). (Section 6.7)
Registration of Transfer Codings now requires IETF Review Registration of Transfer Codings now requires IETF Review
(Section 7.4) (Section 7.4)
The meaning of the "deflate" content coding has been clarified. The meaning of the "deflate" content coding has been clarified.
(Section 4.2.2) (Section 4.2.2)
This specification now defines the Upgrade Token Registry, previously This specification now defines the Upgrade Token Registry, previously
defined in Section 7.2 of [RFC2817]. (Section 7.6) defined in Section 7.2 of [RFC2817]. (Section 7.5)
Empty list elements in list productions (e.g., a list header Empty list elements in list productions (e.g., a list header
containing ", ,") have been deprecated. (Appendix B) containing ", ,") have been deprecated. (Appendix B)
Issues with the Keep-Alive and Proxy-Connection headers in requests Issues with the Keep-Alive and Proxy-Connection headers in requests
are pointed out, with use of the latter being discouraged altogether. are pointed out, with use of the latter being discouraged altogether.
(Appendix A.1.2) (Appendix A.1.2)
Appendix B. ABNF list extension: #rule Appendix B. ABNF list extension: #rule
skipping to change at page 75, line 9 skipping to change at page 74, line 38
connection-option = token connection-option = token
ctext = HTAB / SP / %x21-27 ; '!'-''' ctext = HTAB / SP / %x21-27 ; '!'-'''
/ %x2A-5B ; '*'-'[' / %x2A-5B ; '*'-'['
/ %x5D-7E ; ']'-'~' / %x5D-7E ; ']'-'~'
/ obs-text / obs-text
field-content = *( HTAB / SP / VCHAR / obs-text ) field-content = *( HTAB / SP / VCHAR / obs-text )
field-name = token field-name = token
field-value = *( field-content / obs-fold ) field-value = *( field-content / obs-fold )
header-field = field-name ":" OWS field-value BWS header-field = field-name ":" OWS field-value OWS
http-URI = "http://" authority path-abempty [ "?" query ] http-URI = "http://" authority path-abempty [ "?" query ]
https-URI = "https://" authority path-abempty [ "?" query ] https-URI = "https://" authority path-abempty [ "?" query ]
last-chunk = 1*"0" [ chunk-ext ] CRLF last-chunk = 1*"0" [ chunk-ext ] CRLF
message-body = *OCTET message-body = *OCTET
method = token method = token
obs-fold = CRLF ( SP / HTAB ) obs-fold = CRLF ( SP / HTAB )
obs-text = %x80-FF obs-text = %x80-FF
skipping to change at page 76, line 49 skipping to change at page 76, line 28
o <http://tools.ietf.org/wg/httpbis/trac/ticket/128>: "Cite HTTPS o <http://tools.ietf.org/wg/httpbis/trac/ticket/128>: "Cite HTTPS
URI scheme definition" (the spec now includes the HTTPs scheme URI scheme definition" (the spec now includes the HTTPs scheme
definition and thus updates RFC 2818) definition and thus updates RFC 2818)
o <http://tools.ietf.org/wg/httpbis/trac/ticket/389>: "mention of o <http://tools.ietf.org/wg/httpbis/trac/ticket/389>: "mention of
'proxies' in section about caches" 'proxies' in section about caches"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/390>: "use of ABNF o <http://tools.ietf.org/wg/httpbis/trac/ticket/390>: "use of ABNF
terms from RFC 3986" terms from RFC 3986"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/391>: "transferring
URIs with userinfo in payload"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/392>: "editorial o <http://tools.ietf.org/wg/httpbis/trac/ticket/392>: "editorial
improvements to message length definition" improvements to message length definition"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/395>: "Connection o <http://tools.ietf.org/wg/httpbis/trac/ticket/395>: "Connection
header field MUST vs SHOULD" header field MUST vs SHOULD"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/396>: "editorial o <http://tools.ietf.org/wg/httpbis/trac/ticket/396>: "editorial
improvements to persistent connections section" improvements to persistent connections section"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/397>: "URI o <http://tools.ietf.org/wg/httpbis/trac/ticket/397>: "URI
skipping to change at page 77, line 47 skipping to change at page 77, line 30
o <http://tools.ietf.org/wg/httpbis/trac/ticket/420>: "Content- o <http://tools.ietf.org/wg/httpbis/trac/ticket/420>: "Content-
Length SHOULD be sent" Length SHOULD be sent"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/431>: "origin-form o <http://tools.ietf.org/wg/httpbis/trac/ticket/431>: "origin-form
does not allow path starting with "//"" does not allow path starting with "//""
o <http://tools.ietf.org/wg/httpbis/trac/ticket/433>: "ambiguity in o <http://tools.ietf.org/wg/httpbis/trac/ticket/433>: "ambiguity in
part 1 example" part 1 example"
D.3. Since draft-ietf-httpbis-p1-messaging-22
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/435>: "Part1 should
have a reference to TCP (RFC 793)"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/438>: "media type
registration template issues"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/442>: "BWS" (vs
conformance)
o <http://tools.ietf.org/wg/httpbis/trac/ticket/444>: "obs-fold
language"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/476>: "SHOULD and
conformance"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/477>: "Pipelining
language"
Index Index
A A
absolute-form (of request-target) 40 absolute-form (of request-target) 40
accelerator 10 accelerator 10
application/http Media Type 58 application/http Media Type 57
asterisk-form (of request-target) 41 asterisk-form (of request-target) 40
authority-form (of request-target) 41 authority-form (of request-target) 40
B B
browser 7 browser 7
C C
cache 11 cache 11
cacheable 12 cacheable 12
captive portal 11 captive portal 11
chunked (Coding Format) 27, 30, 34 chunked (Coding Format) 27, 30, 34
client 7 client 7
close 48, 53 close 47, 52
compress (Coding Format) 37 compress (Coding Format) 36
connection 7 connection 7
Connection header field 48, 53 Connection header field 47, 52
Content-Length header field 28 Content-Length header field 28
D D
deflate (Coding Format) 37 deflate (Coding Format) 36
downstream 9 downstream 9
E E
effective request URI 43 effective request URI 42
G G
gateway 10 gateway 10
Grammar Grammar
absolute-form 40 absolute-form 39
absolute-path 16 absolute-path 15
absolute-URI 16 absolute-URI 15
ALPHA 6 ALPHA 6
asterisk-form 40 asterisk-form 39
attribute 34 attribute 34
authority 16 authority 15
authority-form 40 authority-form 39
BWS 24 BWS 23
chunk 35 chunk 34
chunk-data 35 chunk-data 34
chunk-ext 35 chunk-ext 34
chunk-ext-name 35 chunk-ext-name 34
chunk-ext-val 35 chunk-ext-val 34
chunk-size 35 chunk-size 34
chunked-body 35 chunked-body 34
comment 26 comment 26
Connection 48 Connection 48
connection-option 48 connection-option 48
Content-Length 29 Content-Length 28
CR 6 CR 6
CRLF 6 CRLF 6
ctext 26 ctext 26
CTL 6 CTL 6
date2 34 date2 34
date3 34 date3 34
DIGIT 6 DIGIT 6
DQUOTE 6 DQUOTE 6
field-content 22 field-content 21
field-name 22 field-name 21
field-value 22 field-value 21
header-field 22 header-field 21
HEXDIG 6 HEXDIG 6
Host 42 Host 41
HTAB 6 HTAB 6
HTTP-message 19 HTTP-message 18
HTTP-name 13 HTTP-name 13
http-URI 16 http-URI 16
HTTP-version 13 HTTP-version 13
https-URI 18 https-URI 17
last-chunk 35 last-chunk 34
LF 6 LF 6
message-body 26 message-body 26
method 20 method 20
obs-fold 22 obs-fold 21
obs-text 26 obs-text 25
OCTET 6 OCTET 6
origin-form 40 origin-form 39
OWS 24 OWS 23
partial-URI 16 partial-URI 15
port 16 port 15
protocol-name 45 protocol-name 44
protocol-version 45 protocol-version 44
pseudonym 45 pseudonym 44
qdtext 26 qdtext 25
qdtext-nf 35 qdtext-nf 34
query 16 query 15
quoted-cpair 26 quoted-cpair 26
quoted-pair 26 quoted-pair 26
quoted-str-nf 35 quoted-str-nf 34
quoted-string 26 quoted-string 25
rank 37 rank 37
reason-phrase 21 reason-phrase 21
received-by 45 received-by 44
received-protocol 45 received-protocol 44
request-line 20 request-line 20
request-target 40 request-target 39
RWS 24 RWS 23
segment 16 segment 15
SP 6 SP 6
special 25 special 25
start-line 20 start-line 20
status-code 21 status-code 21
status-line 21 status-line 21
t-codings 37 t-codings 37
t-ranking 37 t-ranking 37
tchar 25 tchar 25
TE 37 TE 37
token 25 token 25
Trailer 35 Trailer 35
trailer-part 35 trailer-part 34
transfer-coding 34 transfer-coding 33
Transfer-Encoding 27 Transfer-Encoding 27
transfer-extension 34 transfer-extension 33
transfer-parameter 34 transfer-parameter 34
Upgrade 54 Upgrade 54
uri-host 16 uri-host 15
URI-reference 16 URI-reference 15
value 34 value 34
VCHAR 6 VCHAR 6
Via 45 Via 44
word 25 word 25
gzip (Coding Format) 37 gzip (Coding Format) 37
H H
header field 19 header field 18
header section 19 header section 18
headers 19 headers 18
Host header field 41 Host header field 41
http URI scheme 16 http URI scheme 16
https URI scheme 17 https URI scheme 17
I I
inbound 9 inbound 9
interception proxy 11 interception proxy 11
intermediary 9 intermediary 9
M M
Media Type Media Type
application/http 58 application/http 57
message/http 57 message/http 56
message 7 message 7
message/http Media Type 57 message/http Media Type 56
method 20 method 20
N N
non-transforming proxy 10 non-transforming proxy 10
O O
origin server 7 origin server 7
origin-form (of request-target) 40 origin-form (of request-target) 39
outbound 9 outbound 9
P P
proxy 10 proxy 10
R R
recipient 7 recipient 7
request 7 request 7
request-target 20 request-target 20
resource 15 resource 15
skipping to change at page 81, line 38 skipping to change at page 81, line 44
target resource 38 target resource 38
target URI 38 target URI 38
TE header field 37 TE header field 37
Trailer header field 35 Trailer header field 35
Transfer-Encoding header field 27 Transfer-Encoding header field 27
transforming proxy 10 transforming proxy 10
transparent proxy 11 transparent proxy 11
tunnel 11 tunnel 11
U U
Upgrade header field 54 Upgrade header field 53
upstream 9 upstream 9
URI scheme URI scheme
http 16 http 16
https 17 https 17
user agent 7 user agent 7
V V
Via header field 45 Via header field 44
Authors' Addresses Authors' Addresses
Roy T. Fielding (editor) Roy T. Fielding (editor)
Adobe Systems Incorporated Adobe Systems Incorporated
345 Park Ave 345 Park Ave
San Jose, CA 95110 San Jose, CA 95110
USA USA
EMail: fielding@gbiv.com EMail: fielding@gbiv.com
 End of changes. 105 change blocks. 
287 lines changed or deleted 329 lines changed or added

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