< draft-ietf-httpbis-p1-messaging-22.txt   draft-ietf-httpbis-p1-messaging-23.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 July 15, 2013
Expires: August 27, 2013 Expires: January 16, 2014
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-23
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 January 16, 2014.
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 3, line 4 skipping to change at page 3, line 4
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 . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1. Start Line . . . . . . . . . . . . . . . . . . . . . . . . 19 3.1. Start Line . . . . . . . . . . . . . . . . . . . . . . . . 20
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 . . . . . . . . . . . . . . . . . . . . . . 22
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 . . . . . . . . . . . . . . . . . . . . 24
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 . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.1. Transfer-Encoding . . . . . . . . . . . . . . . . . . 27 3.3.1. Transfer-Encoding . . . . . . . . . . . . . . . . . . 27
3.3.2. Content-Length . . . . . . . . . . . . . . . . . . . . 28 3.3.2. Content-Length . . . . . . . . . . . . . . . . . . . . 29
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 . . . . . . . . . . . . . . . . . . . . . . . 34
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 . . . . . . . . . . . . . . . . . . . 37
4.2.1. Compress Coding . . . . . . . . . . . . . . . . . . . 37 4.2.1. Compress Coding . . . . . . . . . . . . . . . . . . . 37
4.2.2. Deflate Coding . . . . . . . . . . . . . . . . . . . . 37 4.2.2. Deflate Coding . . . . . . . . . . . . . . . . . . . . 37
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
skipping to change at page 3, line 43 skipping to change at page 3, line 43
5.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 5.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.5. Effective Request URI . . . . . . . . . . . . . . . . . . 43 5.5. Effective Request URI . . . . . . . . . . . . . . . . . . 43
5.6. Associating a Response to a Request . . . . . . . . . . . 44 5.6. Associating a Response to a Request . . . . . . . . . . . 44
5.7. Message Forwarding . . . . . . . . . . . . . . . . . . . . 44 5.7. Message Forwarding . . . . . . . . . . . . . . . . . . . . 44
5.7.1. Via . . . . . . . . . . . . . . . . . . . . . . . . . 45 5.7.1. Via . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.7.2. Transformations . . . . . . . . . . . . . . . . . . . 46 5.7.2. Transformations . . . . . . . . . . . . . . . . . . . 46
6. Connection Management . . . . . . . . . . . . . . . . . . . . 47 6. Connection Management . . . . . . . . . . . . . . . . . . . . 47
6.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 48 6.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 48
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 . . . . . . . . . . . . . . . . . . 51
6.3.2. Pipelining . . . . . . . . . . . . . . . . . . . . . . 51 6.3.2. Pipelining . . . . . . . . . . . . . . . . . . . . . . 51
6.4. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 52 6.4. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 52
6.5. Failures and Time-outs . . . . . . . . . . . . . . . . . . 52 6.5. Failures and Time-outs . . . . . . . . . . . . . . . . . . 52
6.6. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 53 6.6. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 53
6.7. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 54 6.7. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 54
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56
7.1. Header Field Registration . . . . . . . . . . . . . . . . 55 7.1. Header Field Registration . . . . . . . . . . . . . . . . 56
7.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 56 7.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 57
7.3. Internet Media Type Registration . . . . . . . . . . . . . 56 7.3. Internet Media Type Registration . . . . . . . . . . . . . 57
7.3.1. Internet Media Type message/http . . . . . . . . . . . 57 7.3.1. Internet Media Type message/http . . . . . . . . . . . 57
7.3.2. Internet Media Type application/http . . . . . . . . . 58 7.3.2. Internet Media Type application/http . . . . . . . . . 58
7.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 59 7.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 60
7.5. Transfer Coding Registration . . . . . . . . . . . . . . . 59 7.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 60
7.6. Upgrade Token Registry . . . . . . . . . . . . . . . . . . 60 7.4.2. Registration . . . . . . . . . . . . . . . . . . . . . 60
7.7. Upgrade Token Registration . . . . . . . . . . . . . . . . 61 7.5. Upgrade Token Registry . . . . . . . . . . . . . . . . . . 61
8. Security Considerations . . . . . . . . . . . . . . . . . . . 61 7.5.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 61
8.1. DNS-related Attacks . . . . . . . . . . . . . . . . . . . 61 7.5.2. Upgrade Token Registration . . . . . . . . . . . . . . 61
8.2. Intermediaries and Caching . . . . . . . . . . . . . . . . 61 8. Security Considerations . . . . . . . . . . . . . . . . . . . 62
8.3. Buffer Overflows . . . . . . . . . . . . . . . . . . . . . 62 8.1. DNS-related Attacks . . . . . . . . . . . . . . . . . . . 62
8.4. Message Integrity . . . . . . . . . . . . . . . . . . . . 62 8.2. Intermediaries and Caching . . . . . . . . . . . . . . . . 62
8.5. Server Log Information . . . . . . . . . . . . . . . . . . 63 8.3. Buffer Overflows . . . . . . . . . . . . . . . . . . . . . 63
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 63 8.4. Message Integrity . . . . . . . . . . . . . . . . . . . . 63
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 65 8.5. Server Log Information . . . . . . . . . . . . . . . . . . 64
10.1. Normative References . . . . . . . . . . . . . . . . . . . 65 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 64
10.2. Informative References . . . . . . . . . . . . . . . . . . 66 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Appendix A. HTTP Version History . . . . . . . . . . . . . . . . 68 10.1. Normative References . . . . . . . . . . . . . . . . . . . 66
A.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 69 10.2. Informative References . . . . . . . . . . . . . . . . . . 67
A.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 69 Appendix A. HTTP Version History . . . . . . . . . . . . . . . . 69
A.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 69 A.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 70
A.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 70 A.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 70
A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 70 A.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 70
Appendix B. ABNF list extension: #rule . . . . . . . . . . . . . 72 A.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 71
Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 73 A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 71
Appendix B. ABNF list extension: #rule . . . . . . . . . . . . . 74
Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 75
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) . . . . . . . . . . . . . . . . . . . . 77
D.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 76 D.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 77
D.2. Since draft-ietf-httpbis-p1-messaging-21 . . . . . . . . . 76 D.2. Since draft-ietf-httpbis-p1-messaging-21 . . . . . . . . . 77
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 D.3. Since draft-ietf-httpbis-p1-messaging-22 . . . . . . . . . 79
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
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 9, line 23 skipping to change at page 9, line 20
erroneous). Spiders, for example, are typically given a start URI erroneous). Spiders, for example, are typically given a start URI
and configured to follow certain behavior while crawling the Web as a and configured to follow certain behavior while crawling the Web as a
hypertext graph. hypertext graph.
The implementation diversity of HTTP means that we cannot assume the The implementation diversity of HTTP means that we cannot assume the
user agent can make interactive suggestions to a user or provide user agent can make interactive suggestions to a user or provide
adequate warning for security or privacy options. In the few cases adequate warning for security or privacy options. In the few cases
where this specification requires reporting of errors to the user, it where this specification requires reporting of errors to the user, it
is acceptable for such reporting to only be observable in an error is acceptable for such reporting to only be observable in an error
console or log file. Likewise, requirements that an automated action console or log file. Likewise, requirements that an automated action
be confirmed by the user before proceeding can be met via advance be confirmed by the user before proceeding might be met via advance
configuration choices, run-time options, or simply not proceeding configuration choices, run-time options, or simple avoidance of the
with the unsafe action. unsafe action; confirmation does not imply any specific user
interface or interruption of normal processing if the user has
already made that choice.
2.3. Intermediaries 2.3. Intermediaries
HTTP enables the use of intermediaries to satisfy requests through a HTTP enables the use of intermediaries to satisfy requests through a
chain of connections. There are three common forms of HTTP chain of connections. There are three common forms of HTTP
intermediary: proxy, gateway, and tunnel. In some cases, a single intermediary: proxy, gateway, and tunnel. In some cases, a single
intermediary might act as an origin server, proxy, gateway, or intermediary might act as an origin server, proxy, gateway, or
tunnel, switching behavior based on the nature of each request. tunnel, switching behavior based on the nature of each request.
> > > > > > > >
skipping to change at page 9, line 49 skipping to change at page 9, line 48
The figure above shows three intermediaries (A, B, and C) between the The figure above shows three intermediaries (A, B, and C) between the
user agent and origin server. A request or response message that user agent and origin server. A request or response message that
travels the whole chain will pass through four separate connections. travels the whole chain will pass through four separate connections.
Some HTTP communication options might apply only to the connection Some HTTP communication options might apply only to the connection
with the nearest, non-tunnel neighbor, only to the end-points of the with the nearest, non-tunnel neighbor, only to the end-points of the
chain, or to all connections along the chain. Although the diagram chain, or to all connections along the chain. Although the diagram
is linear, each participant might be engaged in multiple, is linear, each participant might be engaged in multiple,
simultaneous communications. For example, B might be receiving simultaneous communications. For example, B might be receiving
requests from many clients other than A, and/or forwarding requests requests from many clients other than A, and/or forwarding requests
to servers other than C, at the same time that it is handling A's to servers other than C, at the same time that it is handling A's
request. request. Likewise, later requests might be sent through a different
path of connections, often based on dynamic configuration for load
balancing.
We use the terms "upstream" and "downstream" to describe various We use the terms "upstream" and "downstream" to describe various
requirements in relation to the directional flow of a message: all requirements in relation to the directional flow of a message: all
messages flow from upstream to downstream. Likewise, we use the messages flow from upstream to downstream. Likewise, we use the
terms inbound and outbound to refer to directions in relation to the terms inbound and outbound to refer to directions in relation to the
request path: "inbound" means toward the origin server and "outbound" request path: "inbound" means toward the origin server and "outbound"
means toward the user agent. means toward the user agent.
A "proxy" is a message forwarding agent that is selected by the A "proxy" is a message forwarding agent that is selected by the
client, usually via local configuration rules, to receive requests client, usually via local configuration rules, to receive requests
skipping to change at page 10, line 37 skipping to change at page 10, line 37
responses to include references to a local annotation database), a responses to include references to a local annotation database), a
malware filter, a format transcoder, or an intranet-to-Internet malware filter, a format transcoder, or an intranet-to-Internet
privacy filter. Such transformations are presumed to be desired by privacy filter. Such transformations are presumed to be desired by
the client (or client organization) that selected the proxy and are the client (or client organization) that selected the proxy and are
beyond the scope of this specification. However, when a proxy is not beyond the scope of this specification. However, when a proxy is not
intended to transform a given message, we use the term "non- intended to transform a given message, we use the term "non-
transforming proxy" to target requirements that preserve HTTP message transforming proxy" to target requirements that preserve HTTP message
semantics. See Section 6.3.4 of [Part2] and Section 7.5 of [Part6] semantics. See Section 6.3.4 of [Part2] and Section 7.5 of [Part6]
for status and warning codes related to transformations. for status and warning codes related to transformations.
A "gateway" (a.k.a., "reverse proxy") is a receiving agent that acts A "gateway" (a.k.a., "reverse proxy") is an intermediary that acts as
as a layer above some other server(s) and translates the received an origin server for the outbound connection, but translates received
requests to the underlying server's protocol. Gateways are often requests and forwards them inbound to another server or servers.
used to encapsulate legacy or untrusted information services, to Gateways are often used to encapsulate legacy or untrusted
improve server performance through "accelerator" caching, and to information services, to improve server performance through
enable partitioning or load-balancing of HTTP services across "accelerator" caching, and to enable partitioning or load balancing
multiple machines. of HTTP services across multiple machines.
A gateway behaves as an origin server on its outbound connection and All HTTP requirements applicable to an origin server also apply to
as a user agent on its inbound connection. All HTTP requirements the outbound communication of a gateway. A gateway communicates with
applicable to an origin server also apply to the outbound inbound servers using any protocol that it desires, including private
communication of a gateway. A gateway communicates with inbound
servers using any protocol that it desires, including private
extensions to HTTP that are outside the scope of this specification. extensions to HTTP that are outside the scope of this specification.
However, an HTTP-to-HTTP gateway that wishes to interoperate with However, an HTTP-to-HTTP gateway that wishes to interoperate with
third-party HTTP servers MUST conform to HTTP user agent requirements third-party HTTP servers ought to conform to user agent requirements
on the gateway's inbound connection and MUST implement the Connection on the gateway's inbound connection.
(Section 6.1) and Via (Section 5.7.1) header fields for both
connections.
A "tunnel" acts as a blind relay between two connections without A "tunnel" acts as a blind relay between two connections without
changing the messages. Once active, a tunnel is not considered a changing the messages. Once active, a tunnel is not considered a
party to the HTTP communication, though the tunnel might have been party to the HTTP communication, though the tunnel might have been
initiated by an HTTP request. A tunnel ceases to exist when both initiated by an HTTP request. A tunnel ceases to exist when both
ends of the relayed connection are closed. Tunnels are used to ends of the relayed connection are closed. Tunnels are used to
extend a virtual connection through an intermediary, such as when extend a virtual connection through an intermediary, such as when
Transport Layer Security (TLS, [RFC5246]) is used to establish Transport Layer Security (TLS, [RFC5246]) is used to establish
confidential communication through a shared firewall proxy. confidential communication through a shared firewall proxy.
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 13, line 40 skipping to change at page 13, line 33
The version of an HTTP message is indicated by an HTTP-version field The version of an HTTP message is indicated by an HTTP-version field
in the first line of the message. HTTP-version is case-sensitive. in the first line of the message. HTTP-version is case-sensitive.
HTTP-version = HTTP-name "/" DIGIT "." DIGIT HTTP-version = HTTP-name "/" DIGIT "." DIGIT
HTTP-name = %x48.54.54.50 ; "HTTP", case-sensitive HTTP-name = %x48.54.54.50 ; "HTTP", case-sensitive
The HTTP version number consists of two decimal digits separated by a The HTTP version number consists of two decimal digits separated by a
"." (period or decimal point). The first digit ("major version") "." (period or decimal point). The first digit ("major version")
indicates the HTTP messaging syntax, whereas the second digit ("minor indicates the HTTP messaging syntax, whereas the second digit ("minor
version") indicates the highest minor version to which the sender is version") indicates the highest minor version within that major
conformant and able to understand for future communication. The version to which the sender is conformant and able to understand for
minor version advertises the sender's communication capabilities even future communication. The minor version advertises the sender's
when the sender is only using a backwards-compatible subset of the communication capabilities even when the sender is only using a
protocol, thereby letting the recipient know that more advanced backwards-compatible subset of the protocol, thereby letting the
features can be used in response (by servers) or in future requests recipient know that more advanced features can be used in response
(by clients). (by servers) or in future requests (by clients).
When an HTTP/1.1 message is sent to an HTTP/1.0 recipient [RFC1945] When an HTTP/1.1 message is sent to an HTTP/1.0 recipient [RFC1945]
or a recipient whose version is unknown, the HTTP/1.1 message is or a recipient whose version is unknown, the HTTP/1.1 message is
constructed such that it can be interpreted as a valid HTTP/1.0 constructed such that it can be interpreted as a valid HTTP/1.0
message if all of the newer features are ignored. This specification message if all of the newer features are ignored. This specification
places recipient-version requirements on some new features so that a places recipient-version requirements on some new features so that a
conformant sender will only use compatible features until it has conformant sender will only use compatible features until it has
determined, through configuration or the receipt of a message, that determined, through configuration or the receipt of a message, that
the recipient supports HTTP/1.1. the recipient supports HTTP/1.1.
skipping to change at page 14, line 39 skipping to change at page 14, line 32
other than those acting as tunnels) MUST send their own HTTP-version other than those acting as tunnels) MUST send their own HTTP-version
in forwarded messages. In other words, they MUST NOT blindly forward in forwarded messages. In other words, they MUST NOT blindly forward
the first line of an HTTP message without ensuring that the protocol the first line of an HTTP message without ensuring that the protocol
version in that message matches a version to which that intermediary version in that message matches a version to which that intermediary
is conformant for both the receiving and sending of messages. is conformant for both the receiving and sending of messages.
Forwarding an HTTP message without rewriting the HTTP-version might Forwarding an HTTP message without rewriting the HTTP-version might
result in communication errors when downstream recipients use the result in communication errors when downstream recipients use the
message sender's version to determine what features are safe to use message sender's version to determine what features are safe to use
for later communication with that sender. for later communication with that sender.
An HTTP client SHOULD send a request version equal to the highest A client SHOULD send a request version equal to the highest version
version to which the client is conformant and whose major version is to which the client is conformant and whose major version is no
no higher than the highest version supported by the server, if this higher than the highest version supported by the server, if this is
is known. An HTTP client MUST NOT send a version to which it is not known. A client MUST NOT send a version to which it is not
conformant. conformant.
An HTTP client MAY send a lower request version if it is known that A client MAY send a lower request version if it is known that the
the server incorrectly implements the HTTP specification, but only server incorrectly implements the HTTP specification, but only after
after the client has attempted at least one normal request and the client has attempted at least one normal request and determined
determined from the response status or header fields (e.g., Server) from the response status or header fields (e.g., Server) that the
that the server improperly handles higher request versions. server improperly handles higher request versions.
An HTTP server SHOULD send a response version equal to the highest A server SHOULD send a response version equal to the highest version
version to which the server is conformant and whose major version is to which the server is conformant and whose major version is less
less than or equal to the one received in the request. An HTTP than or equal to the one received in the request. A server MUST NOT
server MUST NOT send a version to which it is not conformant. A send a version to which it is not conformant. A server MAY send a
server MAY send a 505 (HTTP Version Not Supported) response if it 505 (HTTP Version Not Supported) response if it cannot send a
cannot send a response using the major version used in the client's response using the major version used in the client's request.
request.
An HTTP server MAY send an HTTP/1.0 response to an HTTP/1.0 request A server MAY send an HTTP/1.0 response to a request if it is known or
if it is known or suspected that the client incorrectly implements suspected that the client incorrectly implements the HTTP
the HTTP specification and is incapable of correctly processing later specification and is incapable of correctly processing later version
version responses, such as when a client fails to parse the version responses, such as when a client fails to parse the version number
number correctly or when an intermediary is known to blindly forward correctly or when an intermediary is known to blindly forward the
the HTTP-version even when it doesn't conform to the given minor HTTP-version even when it doesn't conform to the given minor version
version of the protocol. Such protocol downgrades SHOULD NOT be of the protocol. Such protocol downgrades SHOULD NOT be performed
performed unless triggered by specific client attributes, such as unless triggered by specific client attributes, such as when one or
when one or more of the request header fields (e.g., User-Agent) more of the request header fields (e.g., User-Agent) uniquely match
uniquely match the values sent by a client known to be in error. 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.
When an HTTP message is received with a major version number that the
recipient implements, but a higher minor version number than what the
recipient implements, the recipient SHOULD process the message as if
it were in the highest minor version within that major version to
which the recipient is conformant. A recipient can assume that a
message with a higher minor version, when sent to a recipient that
has not yet indicated support for that higher version, is
sufficiently backwards-compatible to be safely processed by any
implementation of the same major version.
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", "authority", "port", "host", "path-
"query", "segment", and "authority" from the URI generic syntax. In abempty", "segment", "query", and "fragment" from the URI generic
addition, we define an "absolute-path" rule (that differs from RFC syntax. In addition, we define an "absolute-path" rule (that differs
3986's "path-absolute" in that it allows a leading "//") and a from RFC 3986's "path-absolute" in that it allows a leading "//") and
"partial-URI" rule for protocol elements that allow a relative URI a "partial-URI" rule for protocol elements that allow a relative URI
but not a fragment. but not a fragment.
URI-reference = <URI-reference, defined in [RFC3986], Section 4.1> URI-reference = <URI-reference, defined in [RFC3986], Section 4.1>
absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3> absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3>
relative-part = <relative-part, defined in [RFC3986], Section 4.2> relative-part = <relative-part, defined in [RFC3986], Section 4.2>
authority = <authority, defined in [RFC3986], Section 3.2> authority = <authority, defined in [RFC3986], Section 3.2>
path-abempty = <path-abempty, defined in [RFC3986], Section 3.3> uri-host = <host, defined in [RFC3986], Section 3.2.2>
port = <port, defined in [RFC3986], Section 3.2.3> port = <port, defined in [RFC3986], Section 3.2.3>
query = <query, defined in [RFC3986], Section 3.4> path-abempty = <path-abempty, defined in [RFC3986], Section 3.3>
segment = <segment, defined in [RFC3986], Section 3.3> segment = <segment, defined in [RFC3986], Section 3.3>
uri-host = <host, defined in [RFC3986], Section 3.2.2> query = <query, defined in [RFC3986], Section 3.4>
fragment = <fragment, defined in [RFC3986], Section 3.5>
absolute-path = 1*( "/" segment ) absolute-path = 1*( "/" segment )
partial-URI = relative-part [ "?" query ] partial-URI = relative-part [ "?" query ]
Each protocol element in HTTP that allows a URI reference will Each protocol element in HTTP that allows a URI reference will
indicate in its ABNF production whether the element allows any form indicate in its ABNF production whether the element allows any form
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 ]
[ "#" fragment ]
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.
If the host identifier is provided as an IP address, then the origin If the host identifier is provided as an IP address, then the origin
server is any listener on the indicated TCP port at that IP address. server is any listener on the indicated TCP port at that IP address.
skipping to change at page 17, line 30 skipping to change at page 17, line 33
request. request.
Although HTTP is independent of the transport protocol, the "http" Although HTTP is independent of the transport protocol, the "http"
scheme is specific to TCP-based services because the name delegation scheme is specific to TCP-based services because the name delegation
process depends on TCP for establishing authority. An HTTP service process depends on TCP for establishing authority. An HTTP service
based on some other underlying connection protocol would presumably based on some other underlying connection protocol would presumably
be identified using a different URI scheme, just as the "https" be identified using a different URI scheme, just as the "https"
scheme (below) is used for resources that require an end-to-end scheme (below) is used for resources that require an end-to-end
secured connection. Other protocols might also be used to provide secured connection. Other protocols might also be used to provide
access to "http" identified resources -- it is only the authoritative access to "http" identified resources -- it is only the authoritative
interface used for mapping the namespace that is specific to TCP. interface that is specific to TCP.
The URI generic syntax for authority also includes a deprecated The URI generic syntax for authority also includes a deprecated
userinfo subcomponent ([RFC3986], Section 3.2.1) for including user userinfo subcomponent ([RFC3986], Section 3.2.1) for including user
authentication information in the URI. Some implementations make use authentication information in the URI. Some implementations make use
of the userinfo component for internal configuration of of the userinfo component for internal configuration of
authentication information, such as within command invocation authentication information, such as within command invocation
options, configuration files, or bookmark lists, even though such options, configuration files, or bookmark lists, even though such
usage might expose a user identifier or password. Senders MUST usage might expose a user identifier or password. Senders MUST
exclude the userinfo subcomponent (and its "@" delimiter) when an exclude the userinfo subcomponent (and its "@" delimiter) when an
"http" URI is transmitted within a message as a request target or "http" URI is transmitted within a message as a request target or
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 ]
[ "#" fragment ]
Resources made available via the "https" scheme have no shared Note that the "https" URI scheme depends on both TLS and TCP for
identity with the "http" scheme even if their resource identifiers establishing authority. Resources made available via the "https"
indicate the same authority (the same host listening to the same TCP scheme have no shared identity with the "http" scheme even if their
port). They are distinct name spaces and are considered to be resource identifiers indicate the same authority (the same host
distinct origin servers. However, an extension to HTTP that is listening to the same TCP port). They are distinct name spaces and
defined to apply to entire host domains, such as the Cookie protocol are considered to be distinct origin servers. However, an extension
[RFC6265], can allow information set by one service to impact to HTTP that is defined to apply to entire host domains, such as the
communication with other services within a matching group of host Cookie protocol [RFC6265], can allow information set by one service
domains. to impact communication with other services within a matching group
of host domains.
The process for authoritative access to an "https" identified The process for authoritative access to an "https" identified
resource is defined in [RFC2818]. resource is defined in [RFC2818].
2.7.3. http and https URI Normalization and Comparison 2.7.3. http and https URI Normalization and Comparison
Since the "http" and "https" schemes conform to the URI generic Since the "http" and "https" schemes conform to the URI generic
syntax, such URIs are normalized and compared according to the syntax, such URIs are normalized and compared according to the
algorithm defined in [RFC3986], Section 6, using the defaults algorithm defined in [RFC3986], Section 6, using the defaults
described above for each scheme. described above for each scheme.
If the port is equal to the default port for a scheme, the normal If the port is equal to the default port for a scheme, the normal
form is to elide the port subcomponent. When not being used in form is to omit the port subcomponent. When not being used in
absolute form as the request target of an OPTIONS request, an empty absolute form as the request target of an OPTIONS request, an empty
path component is equivalent to an absolute path of "/", so the path component is equivalent to an absolute path of "/", so the
normal form is to provide a path of "/" instead. The scheme and host normal form is to provide a path of "/" instead. The scheme and host
are case-insensitive and normally provided in lowercase; all other are case-insensitive and normally provided in lowercase; all other
components are compared in a case-sensitive manner. Characters other components are compared in a case-sensitive manner. Characters other
than those in the "reserved" set are equivalent to their percent- than those in the "reserved" set are equivalent to their percent-
encoded octets (see [RFC3986], Section 2.1): the normal form is to encoded octets (see [RFC3986], Section 2.1): the normal form is to
not encode them. not encode them.
For example, the following three URIs are equivalent: For example, the following three URIs are equivalent:
skipping to change at page 19, line 42 skipping to change at page 19, line 43
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 22, line 10
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 37
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 37
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 26
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 31, line 24 skipping to change at page 31, line 34
handled as an error. A sender MUST remove the received Content- handled as an error. A sender MUST remove the received Content-
Length field prior to forwarding such a message downstream. Length field prior to forwarding such a message downstream.
4. If a message is received without Transfer-Encoding and with 4. If a message is received without Transfer-Encoding and with
either multiple Content-Length header fields having differing either multiple Content-Length header fields having differing
field-values or a single Content-Length header field having an field-values or a single Content-Length header field having an
invalid value, then the message framing is invalid and MUST be invalid value, then the message framing is invalid and MUST be
treated as an error to prevent request or response smuggling. If treated as an error to prevent request or response smuggling. If
this is a request message, the server MUST respond with a 400 this is a request message, the server MUST respond with a 400
(Bad Request) status code and then close the connection. If this (Bad Request) status code and then close the connection. If this
is a response message received by a proxy, the proxy MUST discard is a response message received by a proxy, the proxy MUST close
the received response, send a 502 (Bad Gateway) status code as the connection to the server, discard the received response, and
its downstream response, and then close the connection. If this send a 502 (Bad Gateway) response to the client. If this is a
is a response message received by a user agent, it MUST be response message received by a user agent, it MUST be treated as
treated as an error by discarding the message and closing the an error by discarding the message and closing the connection.
connection.
5. If a valid Content-Length header field is present without 5. If a valid Content-Length header field is present without
Transfer-Encoding, its decimal value defines the expected message Transfer-Encoding, its decimal value defines the expected message
body length in octets. If the sender closes the connection or body length in octets. If the sender closes the connection or
the recipient times out before the indicated number of octets are the recipient times out before the indicated number of octets are
received, the recipient MUST consider the message to be received, the recipient MUST consider the message to be
incomplete and close the connection. incomplete and close the connection.
6. If this is a request message and none of the above are true, then 6. If this is a request message and none of the above are true, then
the message body length is zero (no message body is present). the message body length is zero (no message body is present).
skipping to change at page 33, line 16 skipping to change at page 33, line 24
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 34
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 37, line 12 skipping to change at page 37, line 12
transfer coding and MUST ignore chunk-ext extensions they do not transfer coding and MUST ignore chunk-ext extensions they do not
understand. understand.
4.2. Compression Codings 4.2. Compression Codings
The codings defined below can be used to compress the payload of a The codings defined below can be used to compress the payload of a
message. message.
4.2.1. Compress Coding 4.2.1. Compress Coding
The "compress" format is produced by the common UNIX file compression The "compress" coding is an adaptive Lempel-Ziv-Welch (LZW) coding
program "compress". This format is an adaptive Lempel-Ziv-Welch [Welch] that is commonly produced by the UNIX file compression
coding (LZW). Recipients SHOULD consider "x-compress" to be program "compress". Recipients SHOULD consider "x-compress" to be
equivalent to "compress". equivalent to "compress".
4.2.2. Deflate Coding 4.2.2. Deflate Coding
The "deflate" format is defined as the "deflate" compression The "deflate" coding is a "zlib" data format [RFC1950] containing a
mechanism (described in [RFC1951]) used inside the "zlib" data format "deflate" compressed data stream [RFC1951] that uses a combination of
([RFC1950]). the Lempel-Ziv (LZ77) compression algorithm and Huffman coding.
Note: Some incorrect implementations send the "deflate" compressed Note: Some incorrect implementations send the "deflate" compressed
data without the zlib wrapper. data without the zlib wrapper.
4.2.3. Gzip Coding 4.2.3. Gzip Coding
The "gzip" format is produced by the file compression program "gzip" The "gzip" coding is an LZ77 coding with a 32 bit CRC that is
(GNU zip), as described in [RFC1952]. This format is a Lempel-Ziv commonly produced by the gzip file compression program [RFC1952].
coding (LZ77) with a 32 bit CRC. Recipients SHOULD consider "x-gzip" Recipients SHOULD consider "x-gzip" to be equivalent to "gzip".
to be equivalent to "gzip".
4.3. TE 4.3. TE
The "TE" header field in a request indicates what transfer codings, The "TE" header field in a request indicates what transfer codings,
besides chunked, the client is willing to accept in response, and besides chunked, the client is willing to accept in response, and
whether or not the client is willing to accept trailer fields in a whether or not the client is willing to accept trailer fields in a
chunked transfer coding. chunked transfer coding.
The TE field-value consists of a comma-separated list of transfer The TE field-value consists of a comma-separated list of transfer
coding names, each allowing for optional parameters (as described in coding names, each allowing for optional parameters (as described in
skipping to change at page 38, line 12 skipping to change at page 38, line 12
Three examples of TE use are below. Three examples of TE use are below.
TE: deflate TE: deflate
TE: TE:
TE: trailers, deflate;q=0.5 TE: trailers, deflate;q=0.5
The presence of the keyword "trailers" indicates that the client is The presence of the keyword "trailers" indicates that the client is
willing to accept trailer fields in a chunked transfer coding, as willing to accept trailer fields in a chunked transfer coding, as
defined in Section 4.1, on behalf of itself and any downstream defined in Section 4.1, on behalf of itself and any downstream
clients. For chained requests, this implies that either: (a) all clients. For requests from an intermediary, this implies that
downstream clients are willing to accept trailer fields in the either: (a) all downstream clients are willing to accept trailer
forwarded response; or, (b) the client will attempt to buffer the fields in the forwarded response; or, (b) the intermediary will
response on behalf of downstream recipients. Note that HTTP/1.1 does attempt to buffer the response on behalf of downstream recipients.
not define any means to limit the size of a chunked response such Note that HTTP/1.1 does not define any means to limit the size of a
that a client can be assured of buffering the entire response. chunked response such that an intermediary can be assured of
buffering the entire response.
When multiple transfer codings are acceptable, the client MAY rank When multiple transfer codings are acceptable, the client MAY rank
the codings by preference using a case-insensitive "q" parameter the codings by preference using a case-insensitive "q" parameter
(similar to the qvalues used in content negotiation fields, Section (similar to the qvalues used in content negotiation fields, Section
5.3.1 of [Part2]). The rank value is a real number in the range 0 5.3.1 of [Part2]). The rank value is a real number in the range 0
through 1, where 0.001 is the least preferred and 1 is the most through 1, where 0.001 is the least preferred and 1 is the most
preferred; a value of 0 means "not acceptable". preferred; a value of 0 means "not acceptable".
If the TE field-value is empty or if no TE field is present, the only If the TE field-value is empty or if no TE field is present, the only
acceptable transfer coding is chunked. A message with no transfer acceptable transfer coding is chunked. A message with no transfer
skipping to change at page 39, line 4 skipping to change at page 39, line 6
5.1. Identifying a Target Resource 5.1. Identifying a Target Resource
HTTP is used in a wide variety of applications, ranging from general- HTTP is used in a wide variety of applications, ranging from general-
purpose computers to home appliances. In some cases, communication purpose computers to home appliances. In some cases, communication
options are hard-coded in a client's configuration. However, most options are hard-coded in a client's configuration. However, most
HTTP clients rely on the same resource identification mechanism and HTTP clients rely on the same resource identification mechanism and
configuration techniques as general-purpose Web browsers. configuration techniques as general-purpose Web browsers.
HTTP communication is initiated by a user agent for some purpose. HTTP communication is initiated by a user agent for some purpose.
The purpose is a combination of request semantics, which are defined The purpose is a combination of request semantics, which are defined
in [Part2], and a target resource upon which to apply those in [Part2], and a target resource upon which to apply those
semantics. A URI reference (Section 2.7) is typically used as an semantics. A URI reference (Section 2.7) is typically used as an
identifier for the "target resource", which a user agent would identifier for the "target resource", which a user agent would
resolve to its absolute form in order to obtain the "target URI". resolve to its absolute form in order to obtain the "target URI".
The target URI excludes the reference's fragment identifier The target URI excludes the reference's fragment component, if any,
component, if any, since fragment identifiers are reserved for since fragment identifiers are reserved for client-side processing
client-side processing ([RFC3986], Section 3.5). ([RFC3986], Section 3.5).
5.2. Connecting Inbound 5.2. Connecting Inbound
Once the target URI is determined, a client needs to decide whether a Once the target URI is determined, a client needs to decide whether a
network request is necessary to accomplish the desired semantics and, network request is necessary to accomplish the desired semantics and,
if so, where that request is to be directed. if so, where that request is to be directed.
If the client has a response cache and the request semantics can be If the client has a cache [Part6] and the request can be satisfied by
satisfied by a cache ([Part6]), then the request is usually directed it, then the request is usually directed there first.
to the cache first.
If the request is not satisfied by a cache, then a typical client If the request is not satisfied by a cache, then a typical client
will check its configuration to determine whether a proxy is to be will check its configuration to determine whether a proxy is to be
used to satisfy the request. Proxy configuration is implementation- used to satisfy the request. Proxy configuration is implementation-
dependent, but is often based on URI prefix matching, selective dependent, but is often based on URI prefix matching, selective
authority matching, or both, and the proxy itself is usually authority matching, or both, and the proxy itself is usually
identified by an "http" or "https" URI. If a proxy is applicable, identified by an "http" or "https" URI. If a proxy is applicable,
the client connects inbound by establishing (or reusing) a connection the client connects inbound by establishing (or reusing) a connection
to that proxy. to that proxy.
skipping to change at page 45, line 13 skipping to change at page 45, line 13
header field, as specified in Section 6.1, to exclude fields that are header field, as specified in Section 6.1, to exclude fields that are
only intended for the incoming connection. only intended for the incoming connection.
In order to avoid request loops, a proxy that forwards requests to In order to avoid request loops, a proxy that forwards requests to
other proxies MUST be able to recognize and exclude all of its own other proxies MUST be able to recognize and exclude all of its own
server names, including any aliases, local variations, or literal IP server names, including any aliases, local variations, or literal IP
addresses. addresses.
5.7.1. Via 5.7.1. Via
The "Via" header field MUST be sent by a proxy or gateway in The "Via" header field indicates the presence of intermediate
forwarded messages to indicate the intermediate protocols and protocols and recipients between the user agent and the server (on
recipients between the user agent and the server on requests, and requests) or between the origin server and the client (on responses),
between the origin server and the client on responses. It is similar to the "Received" header field in email (Section 3.6.7 of
analogous to the "Received" field used by email systems (Section [RFC5322]). Via can be used for tracking message forwards, avoiding
3.6.7 of [RFC5322]). Via is used in HTTP for tracking message request loops, and identifying the protocol capabilities of senders
forwards, avoiding request loops, and identifying the protocol along the request/response chain.
capabilities of all senders along the request/response chain.
Via = 1#( received-protocol RWS received-by [ RWS comment ] )
Via = 1#( received-protocol RWS received-by
[ RWS comment ] )
received-protocol = [ protocol-name "/" ] protocol-version received-protocol = [ protocol-name "/" ] protocol-version
; see Section 6.7 ; see Section 6.7
received-by = ( uri-host [ ":" port ] ) / pseudonym received-by = ( uri-host [ ":" port ] ) / pseudonym
pseudonym = token pseudonym = token
The received-protocol indicates the protocol version of the message Multiple Via field values represent each proxy or gateway that has
received by the server or client along each segment of the request/ forwarded the message. Each intermediary appends its own information
response chain. The received-protocol version is appended to the Via about how the message was received, such that the end result is
field value when the message is forwarded so that information about ordered according to the sequence of forwarding recipients.
the protocol capabilities of upstream applications remains visible to
all recipients.
The protocol-name is excluded if and only if it would be "HTTP". The A proxy MUST send an appropriate Via header field, as described
received-by field is normally the host and optional port number of a below, in each message that it forwards. An HTTP-to-HTTP gateway
recipient server or client that subsequently forwarded the message. MUST send an appropriate Via header field in each inbound request
However, if the real host is considered to be sensitive information, message and MAY send a Via header field in forwarded response
it MAY be replaced by a pseudonym. If the port is not given, it MAY messages.
be assumed to be the default port of the received-protocol.
Multiple Via field values represent each proxy or gateway that has For each intermediary, the received-protocol indicates the protocol
forwarded the message. Each recipient MUST append its information and protocol version used by the upstream sender of the message.
such that the end result is ordered according to the sequence of Hence, the Via field value records the advertised protocol
forwarding applications. capabilities of the request/response chain such that they remain
visible to downstream recipients; this can be useful for determining
what backwards-incompatible features might be safe to use in
response, or within a later request, as described in Section 2.6.
For brevity, the protocol-name is omitted when the received protocol
is HTTP.
The received-by field is normally the host and optional port number
of a recipient server or client that subsequently forwarded the
message. However, if the real host is considered to be sensitive
information, it MAY be replaced by a pseudonym. If the port is not
given, it MAY be assumed to be the default port of the received-
protocol.
Comments MAY be used in the Via header field to identify the software Comments MAY be used in the Via header field to identify the software
of each recipient, analogous to the User-Agent and Server header of each recipient, analogous to the User-Agent and Server header
fields. However, all comments in the Via field are optional and MAY fields. However, all comments in the Via field are optional and MAY
be removed by any recipient prior to forwarding the message. be removed by any recipient prior to forwarding the message.
For example, a request message could be sent from an HTTP/1.0 user For example, a request message could be sent from an HTTP/1.0 user
agent to an internal proxy code-named "fred", which uses HTTP/1.1 to agent to an internal proxy code-named "fred", which uses HTTP/1.1 to
forward the request to a public proxy at p.example.net, which forward the request to a public proxy at p.example.net, which
completes the request by forwarding it to the origin server at completes the request by forwarding it to the origin server at
www.example.com. The request received by www.example.com would then www.example.com. The request received by www.example.com would then
have the following Via header field: have the following Via header field:
Via: 1.0 fred, 1.1 p.example.net (Apache/1.1) Via: 1.0 fred, 1.1 p.example.net
A proxy or gateway used as a portal through a network firewall SHOULD A proxy or gateway used as a portal through a network firewall SHOULD
NOT forward the names and ports of hosts within the firewall region NOT forward the names and ports of hosts within the firewall region
unless it is explicitly enabled to do so. If not enabled, the unless it is explicitly enabled to do so. If not enabled, the
received-by host of any host behind the firewall SHOULD be replaced received-by host of any host behind the firewall SHOULD be replaced
by an appropriate pseudonym for that host. by an appropriate pseudonym for that host.
A proxy or gateway MAY combine an ordered subsequence of Via header A proxy or gateway MAY combine an ordered subsequence of Via header
field entries into a single such entry if the entries have identical field entries into a single such entry if the entries have identical
received-protocol values. For example, received-protocol values. For example,
skipping to change at page 47, line 13 skipping to change at page 47, line 22
A proxy MUST NOT modify the "absolute-path" and "query" parts of the A proxy MUST NOT modify the "absolute-path" and "query" parts of the
received request-target when forwarding it to the next inbound received request-target when forwarding it to the next inbound
server, except as noted above to replace an empty path with "/" or server, except as noted above to replace an empty path with "/" or
"*". "*".
A proxy MUST NOT modify header fields that provide information about A proxy MUST NOT modify header fields that provide information about
the end points of the communication chain, the resource state, or the the end points of the communication chain, the resource state, or the
selected representation. A proxy MAY change the message body through selected representation. A proxy MAY change the message body through
application or removal of a transfer coding (Section 4). application or removal of a transfer coding (Section 4).
A non-transforming proxy MUST preserve the message payload (Section A non-transforming proxy MUST NOT modify the message payload (Section
3.3 of [Part2]). A transforming proxy MUST preserve the payload of a 3.3 of [Part2]). A transforming proxy MUST NOT modify the payload of
message that contains the no-transform cache-control directive. a message that contains the no-transform cache-control directive.
A transforming proxy MAY transform the payload of a message that does A transforming proxy MAY transform the payload of a message that does
not contain the no-transform cache-control directive; if the payload not contain the no-transform cache-control directive; if the payload
is transformed, the transforming proxy MUST add a Warning 214 is transformed, the transforming proxy MUST add a Warning header
(Transformation applied) header field if one does not already appear field with the warn-code of 214 ("Transformation Applied") if one
in the message (see Section 7.5 of [Part6]). does not already appear in the message (see Section 7.5 of [Part6]).
If the payload of a 200 (OK) response is transformed, the
transforming proxy can also inform downstream recipients that a
transformation has been applied by changing the response status code
to 203 (Non-Authoritative Information) (Section 6.3.4 of [Part2]).
6. Connection Management 6. Connection Management
HTTP messaging is independent of the underlying transport or session- HTTP messaging is independent of the underlying transport or session-
layer connection protocol(s). HTTP only presumes a reliable layer connection protocol(s). HTTP only presumes a reliable
transport with in-order delivery of requests and the corresponding transport with in-order delivery of requests and the corresponding
in-order delivery of responses. The mapping of HTTP request and in-order delivery of responses. The mapping of HTTP request and
response structures onto the data units of an underlying transport response structures onto the data units of an underlying transport
protocol is outside the scope of this specification. protocol is outside the scope of this specification.
skipping to change at page 53, line 9 skipping to change at page 53, line 21
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
more of those protocols before sending the final response. A server more of those protocols, in order of descending preference, before
MUST send an Upgrade header field in 101 (Switching Protocols) sending the final response. A server MAY ignore a received Upgrade
responses to indicate which protocol(s) are being switched to, and header field if it wishes to continue using the current protocol on
MUST send it in 426 (Upgrade Required) responses to indicate that connection.
acceptable protocols. A server MAY send an Upgrade header field in
any other response to indicate that they might be willing to upgrade
to one of the specified protocols for a future request.
Upgrade = 1#protocol Upgrade = 1#protocol
protocol = protocol-name ["/" protocol-version] protocol = protocol-name ["/" protocol-version]
protocol-name = token protocol-name = token
protocol-version = token protocol-version = token
For example, A server that sends a 101 (Switching Protocols) response MUST send an
Upgrade header field to indicate the new protocol(s) to which the
connection is being switched; if multiple protocol layers are being
switched, the new protocols MUST be listed in layer-ascending order.
A server MUST NOT switch to a protocol that was not indicated by the
client in the corresponding request's Upgrade header field. A server
MAY choose to ignore the order of preference indicated by the client
and select the new protocol(s) based on other factors, such as the
nature of the request or the current load on the server.
Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 A server that sends a 426 (Upgrade Required) response MUST send an
Upgrade header field to indicate the acceptable protocols, in order
of descending preference.
Upgrade eases the difficult transition between incompatible protocols A server MAY send an Upgrade header field in any other response to
by allowing the client to initiate a request in the more commonly advertise that it implements support for upgrading to the listed
supported protocol while indicating to the server that it would like protocols, in order of descending preference, when appropriate for a
to use a "better" protocol if available (where "better" is determined future request.
by the server, possibly according to the nature of the request method
or target resource). The following is a hypothetical example sent by a client:
GET /hello.txt HTTP/1.1
Host: www.example.com
Connection: upgrade
Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
Upgrade cannot be used to insist on a protocol change; its acceptance Upgrade cannot be used to insist on a protocol change; its acceptance
and use by the server is optional. The capabilities and nature of and use by the server is optional. The capabilities and nature of
the application-level communication after the protocol change is the application-level communication after the protocol change is
entirely dependent upon the new protocol chosen, although the first entirely dependent upon the new protocol(s) chosen, although the
action after changing the protocol MUST be a response to the initial first action after changing the protocol MUST be a response to the
HTTP request that contained the Upgrade header field. initial HTTP request that contained the Upgrade header field.
For example, if the Upgrade header field is received in a GET request For example, if the Upgrade header field is received in a GET request
and the server decides to switch protocols, then it first responds and the server decides to switch protocols, it first responds with a
with a 101 (Switching Protocols) message in HTTP/1.1 and then 101 (Switching Protocols) message in HTTP/1.1 and then immediately
immediately follows that with the new protocol's equivalent of a follows that with the new protocol's equivalent of a response to a
response to a GET on the target resource. This allows a connection GET on the target resource. This allows a connection to be upgraded
to be upgraded to protocols with the same semantics as HTTP without to protocols with the same semantics as HTTP without the latency cost
the latency cost of an additional round-trip. A server MUST NOT of an additional round-trip. A server MUST NOT switch protocols
switch protocols unless the received message semantics can be honored unless the received message semantics can be honored by the new
by the new protocol; an OPTIONS request can be honored by any protocol; an OPTIONS request can be honored by any protocol.
protocol.
When Upgrade is sent, a sender MUST also send a Connection header The following is an example response to the above hypothetical
field (Section 6.1) that contains the "upgrade" connection option, in request:
HTTP/1.1 101 Switching Protocols
Connection: upgrade
Upgrade: HTTP/2.0
[... data stream switches to HTTP/2.0 with an appropriate response
(as defined by new protocol) to the "GET /hello.txt" request ...]
When Upgrade is sent, the sender MUST also send a Connection header
field (Section 6.1) that contains an "upgrade" connection option, in
order to prevent Upgrade from being accidentally forwarded by order to prevent Upgrade from being accidentally forwarded by
intermediaries that might not implement the listed protocols. A intermediaries that might not implement the listed protocols. A
server MUST ignore an Upgrade header field that is received in an server MUST ignore an Upgrade header field that is received in an
HTTP/1.0 request. HTTP/1.0 request.
The Upgrade header field only applies to switching application-level The Upgrade header field only applies to switching protocols on top
protocols on the existing connection; it cannot be used to switch to of the existing connection; it cannot be used to switch the
a protocol on a different connection. For that purpose, it is more underlying connection (transport) protocol, nor to switch the
appropriate to use a 3xx (Redirection) response (Section 6.4 of existing communication to a different connection. For those
[Part2]). purposes, it is more appropriate to use a 3xx (Redirection) response
(Section 6.4 of [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 58, line 35
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
Required parameters: none Required parameters: none
Optional parameters: version, msgtype Optional parameters: version, msgtype
version: The HTTP-version number of the enclosed messages (e.g., version: The HTTP-version number of the enclosed messages (e.g.,
"1.1"). If not present, the version can be determined from the "1.1"). If not present, the version can be determined from the
first line of the body. first line of the body.
skipping to change at page 59, line 12 skipping to change at page 59, line 45
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
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" data format [Welch] | Section 4.2.1 |
| deflate | "deflate" compression mechanism | Section 4.2.2 | | deflate | "deflate" compressed data | Section 4.2.2 |
| | ([RFC1951]) used inside the "zlib" | | | | ([RFC1951]) inside the "zlib" data | |
| | data format ([RFC1950]) | | | | format ([RFC1950]) | |
| gzip | Same as GNU zip [RFC1952] | Section 4.2.3 | | gzip | GZIP file format [RFC1952] | Section 4.2.3 |
+----------+----------------------------------------+---------------+ | x-compress | Deprecated (alias for compress) | Section 4.2.1 |
| x-gzip | Deprecated (alias for gzip) | 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 61, line 45
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 62, line 28 skipping to change at page 63, line 23
To promote interoperability, this specification makes specific To promote interoperability, this specification makes specific
recommendations for minimum size limits on request-line recommendations for minimum size limits on request-line
(Section 3.1.1) and blocks of header fields (Section 3.2). These are (Section 3.1.1) and blocks of header fields (Section 3.2). These are
minimum recommendations, chosen to be supportable even by minimum recommendations, chosen to be supportable even by
implementations with limited resources; it is expected that most implementations with limited resources; it is expected that most
implementations will choose substantially higher limits. implementations will choose substantially higher limits.
This specification also provides a way for servers to reject messages This specification also provides a way for servers to reject messages
that have request-targets that are too long (Section 6.5.12 of that have request-targets that are too long (Section 6.5.12 of
[Part2]) or request entities that are too large (Section 6.5 of [Part2]) or request entities that are too large (Section 6.5 of
[Part2]). [Part2]). Additional status codes related to capacity limits have
been defined by extensions to HTTP [RFC6585].
Recipients SHOULD carefully limit the extent to which they read other Recipients SHOULD carefully limit the extent to which they read other
fields, including (but not limited to) request methods, response fields, including (but not limited to) request methods, response
status phrases, header field-names, and body chunks, so as to avoid status phrases, header field-names, and body chunks, so as to avoid
denial of service attacks without impeding interoperability. denial of service attacks without impeding interoperability.
8.4. Message Integrity 8.4. Message Integrity
HTTP does not define a specific mechanism for ensuring message HTTP does not define a specific mechanism for ensuring message
integrity, instead relying on the error-detection ability of integrity, instead relying on the error-detection ability of
skipping to change at page 64, line 9 skipping to change at page 65, line 5
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 Akalin, Fred Bohle, Frederic Kayser, Gabor Molnar,
Gabriel Montenegro, Geoffrey Sneddon, Gervase Markham, Gili Tzabari,
Grahame Grieve, Greg Wilkins, Grzegorz Calkowski, Harald Tveit
Alvestrand, Harry Halpin, Helge Hess, Henrik Nordstrom, Henry S. Alvestrand, Harry Halpin, Helge Hess, Henrik Nordstrom, Henry S.
Thompson, Henry Story, Herbert van de Sompel, Howard Melman, Hugo Thompson, Henry Story, Herbert van de Sompel, Herve Ruellan, Howard
Haas, Ian Fette, Ian Hickson, Ido Safruti, Ilya Grigorik, Ingo Melman, Hugo Haas, Ian Fette, Ian Hickson, Ido Safruti, Ilari
Struck, J. Ross Nicoll, James H. Manger, James Lacey, James M. Snell, Liusvaara, Ilya Grigorik, Ingo Struck, J. Ross Nicoll, James Cloos,
Jamie Lokier, Jan Algermissen, Jeff Hodges (who came up with the term James H. Manger, James Lacey, James M. Snell, Jamie Lokier, Jan
'effective Request-URI'), Jeff Walden, Jeroen de Borst, Jim Luther, Algermissen, Jeff Hodges (who came up with the term 'effective
Joe D. Williams, Joe Gregorio, Joe Orton, John C. Klensin, John C. Request-URI'), Jeff Pinner, Jeff Walden, Jim Luther, Jitu Padhye, Joe
D. Williams, Joe Gregorio, Joe Orton, John C. Klensin, John C.
Mallery, John Cowan, John Kemp, John Panzer, John Schneider, John Mallery, John Cowan, John Kemp, John Panzer, John Schneider, John
Stracke, John Sullivan, Jonas Sicking, Jonathan A. Rees, Jonathan Stracke, John Sullivan, Jonas Sicking, Jonathan A. Rees, Jonathan
Billington, Jonathan Moore, Jonathan Rees, Jonathan Silvera, Jordi Billington, Jonathan Moore, Jonathan Silvera, Jordi Ros, Joris
Ros, Joris Dobbelsteen, Josh Cohen, Julien Pierre, Jungshik Shin, Dobbelsteen, Josh Cohen, Julien Pierre, Jungshik Shin, Justin
Justin Chapweske, Justin Erenkrantz, Justin James, Kalvinder Singh, Chapweske, Justin Erenkrantz, Justin James, Kalvinder Singh, Karl
Karl Dubost, Keith Hoffman, Keith Moore, Ken Murchison, Koen Holtman, 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, Michael Sweet,
Kelly, Mike Schinkel, Miles Sabin, Murray S. Kucherawy, Mykyta Mike Amundsen, Mike Belshe, Mike Bishop, Mike Kelly, Mike Schinkel,
Yevstifeyev, Nathan Rixham, Nicholas Shanks, Nico Williams, Nicolas Miles Sabin, Murray S. Kucherawy, Mykyta Yevstifeyev, Nathan Rixham,
Alvarez, Nicolas Mailhot, Noah Slater, Pablo Castro, Pat Hayes, Nicholas Shanks, Nico Williams, Nicolas Alvarez, Nicolas Mailhot,
Patrick R. McManus, Patrik Faltstrom, Paul E. Jones, Paul Hoffman, Noah Slater, Osama Mazahir, Pablo Castro, Pat Hayes, Patrick R.
Paul Marquess, Peter Lepeska, Peter Saint-Andre, Peter Watkins, Phil McManus, Paul E. Jones, Paul Hoffman, Paul Marquess, Peter Lepeska,
Archer, Philippe Mougin, Phillip Hallam-Baker, Poul-Henning Kamp, Peter Occil, Peter Saint-Andre, Peter Watkins, Phil Archer, Philippe
Mougin, Phillip Hallam-Baker, Piotr Dobrogost, Poul-Henning Kamp,
Preethi Natarajan, Rajeev Bector, Ray Polk, Reto Bachmann-Gmuer, Preethi Natarajan, Rajeev Bector, Ray Polk, Reto Bachmann-Gmuer,
Richard Cyganiak, Robert Brewer, Robert Collins, Robert O'Callahan, Richard Cyganiak, Robby Simpson, Robert Brewer, Robert Collins,
Robert Olofsson, Robert Sayre, Robert Siemer, Robert de Wilde, Robert Mattson, Robert O'Callahan, Robert Olofsson, Robert Sayre,
Roberto Javier Godoy, Roberto Peon, Roland Zink, Ronny Widjaja, S. Robert Siemer, Robert de Wilde, Roberto Javier Godoy, Roberto Peon,
Mike Dierken, Salvatore Loreto, Sam Johnston, Sam Ruby, Scott Roland Zink, Ronny Widjaja, S. Mike Dierken, Salvatore Loreto, Sam
Lawrence (who maintained the original issues list), Sean B. Palmer, Johnston, Sam Pullara, Sam Ruby, Scott Lawrence (who maintained the
Shane McCarron, Stefan Eissing, Stefan Tilkov, Stefanos Harhalakis, original issues list), Sean B. Palmer, Shane McCarron, Shigeki Ohtsu,
Stephane Bortzmeyer, Stephen Farrell, Stephen Ludin, Stuart Williams, Stefan Eissing, Stefan Tilkov, Stefanos Harhalakis, Stephane
Subbu Allamaraju, Subramanian Moonesamy, Sylvain Hellegouarch, Tapan Bortzmeyer, Stephen Farrell, Stephen Ludin, Stuart Williams, Subbu
Divekar, Tatsuya Hayashi, Ted Hardie, Thomas Broyer, Thomas Fossati, Allamaraju, Sylvain Hellegouarch, Tapan Divekar, Tatsuya Hayashi, Ted
Thomas Nordin, Thomas Roessler, Tim Bray, Tim Morgan, Tim Olsen, Hardie, Thomas Broyer, Thomas Fossati, Thomas Maslen, Thomas Nordin,
Tobias Oberstein, Tom Zhou, Travis Snoozy, Tyler Close, Vincent Thomas Roessler, Tim Bray, Tim Morgan, Tim Olsen, Tom Zhou, Travis
Murphy, Wenbo Zhu, Werner Baumann, Wilbur Streett, Wilfredo Sanchez Snoozy, Tyler Close, Vincent Murphy, Wenbo Zhu, Werner Baumann,
Vega, William A. Rowe Jr., William Chan, Willy Tarreau, Xiaoshu Wang, Wilbur Streett, Wilfredo Sanchez Vega, William A. Rowe Jr., William
Yaron Goland, Yngve Nysaeter Pettersen, Yoav Nir, Yogesh Bang, Yutaka Chan, Willy Tarreau, Xiaoshu Wang, Yaron Goland, Yngve Nysaeter
Oiwa, Yves Lafon (long-time member of the editor team), Zed A. Shaw, Pettersen, Yoav Nir, Yogesh Bang, Yutaka Oiwa, Yves Lafon (long-time
and Zhong Yu. member of the editor team), Zed A. Shaw, 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-23 (work in progress),
February 2013. July 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-23 (work in
progress), February 2013. progress), July 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-23 (work in
progress), February 2013. progress), July 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-23 (work in progress),
February 2013. July 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-23 (work in progress),
February 2013. July 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 66, line 24 skipping to change at page 67, line 27
STD 66, RFC 3986, January 2005. STD 66, RFC 3986, January 2005.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, RFC 5234, Syntax Specifications: ABNF", STD 68, RFC 5234,
January 2008. January 2008.
[USASCII] American National Standards Institute, "Coded Character [USASCII] American National Standards Institute, "Coded Character
Set -- 7-bit American Standard Code for Information Set -- 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986. Interchange", ANSI X3.4, 1986.
[Welch] Welch, T., "A Technique for High Performance Data
Compression", IEEE Computer 17(6), June 1984.
10.2. Informative References 10.2. Informative References
[BCP115] Hansen, T., Hardie, T., and L. Masinter, "Guidelines [BCP115] Hansen, T., Hardie, T., and L. Masinter, "Guidelines
and Registration Procedures for New URI Schemes", and Registration Procedures for New URI Schemes",
BCP 115, RFC 4395, February 2006. BCP 115, RFC 4395, February 2006.
[BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type [BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, Specifications and Registration Procedures", BCP 13,
RFC 6838, January 2013. RFC 6838, January 2013.
[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, Procedures for Message Header Fields", BCP 90,
RFC 3864, September 2004. RFC 3864, September 2004.
[ISO-8859-1] International Organization for Standardization, [ISO-8859-1] International Organization for Standardization,
"Information technology -- 8-bit single-byte coded "Information technology -- 8-bit single-byte coded
graphic character sets -- Part 1: Latin alphabet No. graphic character sets -- Part 1: Latin alphabet No.
1", ISO/IEC 8859-1:1998, 1998. 1", ISO/IEC 8859-1:1998, 1998.
[Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and [Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and
Politics", ACM Transactions on Internet Technology Vol. Politics", ACM Transactions on Internet
1, #2, November 2001, Technology 1(2), November 2001,
<http://arxiv.org/abs/cs.SE/0105018>. <http://arxiv.org/abs/cs.SE/0105018>.
[RFC1919] Chatel, M., "Classical versus Transparent IP Proxies", [RFC1919] Chatel, M., "Classical versus Transparent IP Proxies",
RFC 1919, March 1996. RFC 1919, March 1996.
[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen,
"Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945,
May 1996. May 1996.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet
skipping to change at page 68, line 9 skipping to change at page 69, line 15
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer
Security (TLS) Protocol Version 1.2", RFC 5246, Security (TLS) Protocol Version 1.2", RFC 5246,
August 2008. August 2008.
[RFC5322] Resnick, P., "Internet Message Format", RFC 5322, [RFC5322] Resnick, P., "Internet Message Format", RFC 5322,
October 2008. October 2008.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
April 2011. April 2011.
[RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status
Codes", RFC 6585, April 2012.
Appendix A. HTTP Version History Appendix A. HTTP Version History
HTTP has been in use by the World-Wide Web global information HTTP has been in use by the World-Wide Web global information
initiative since 1990. The first version of HTTP, later referred to initiative since 1990. The first version of HTTP, later referred to
as HTTP/0.9, was a simple protocol for hypertext data transfer across as HTTP/0.9, was a simple protocol for hypertext data transfer across
the Internet with only a single request method (GET) and no metadata. the Internet with only a single request method (GET) and no metadata.
HTTP/1.0, as defined by [RFC1945], added a range of request methods HTTP/1.0, as defined by [RFC1945], added a range of request methods
and MIME-like messaging that could include metadata about the data and MIME-like messaging that could include metadata about the data
transferred and modifiers on the request/response semantics. transferred and modifiers on the request/response semantics.
However, HTTP/1.0 did not sufficiently take into consideration the However, HTTP/1.0 did not sufficiently take into consideration the
skipping to change at page 70, line 7 skipping to change at page 71, line 12
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 73, line 40
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 Issues with the Keep-Alive and Proxy-Connection header fields in
containing ", ,") have been deprecated. (Appendix B) requests are pointed out, with use of the latter being discouraged
altogether. (Appendix A.1.2)
Issues with the Keep-Alive and Proxy-Connection headers in requests Empty list elements in list productions (e.g., a list header field
are pointed out, with use of the latter being discouraged altogether. containing ", ,") have been deprecated. (Appendix B)
(Appendix A.1.2)
Appendix B. ABNF list extension: #rule Appendix B. ABNF list extension: #rule
A #rule extension to the ABNF rules of [RFC5234] is used to improve A #rule extension to the ABNF rules of [RFC5234] is used to improve
readability in the definitions of some header field values. readability in the definitions of some header field values.
A construct "#" is defined, similar to "*", for defining comma- A construct "#" is defined, similar to "*", for defining comma-
delimited lists of elements. The full form is "<n>#<m>element" delimited lists of elements. The full form is "<n>#<m>element"
indicating at least <n> and at most <m> elements, each separated by a indicating at least <n> and at most <m> elements, each separated by a
single comma (",") and optional whitespace (OWS). single comma (",") and optional whitespace (OWS).
skipping to change at page 75, line 8 skipping to change at page 76, line 18
comment = "(" *( ctext / quoted-cpair / comment ) ")" comment = "(" *( ctext / quoted-cpair / comment ) ")"
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 )
fragment = <fragment, defined in [RFC3986], Section 3.5>
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 ] fragment ]
https-URI = "https://" authority path-abempty [ "?" query ] [ "#"
fragment ]
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
origin-form = absolute-path [ "?" query ] origin-form = absolute-path [ "?" query ]
skipping to change at page 76, line 49 skipping to change at page 78, line 15
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 79, line 14
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/445>: "Ordering in
Upgrade"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/446>: "p1 editorial
feedback"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/447>: "HTTP and TCP
name delegation"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/449>: "Receiving a
higher minor HTTP version number"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/451>: "HTTP(S) URIs
and fragids"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/457>: "Registering
x-gzip and x-deflate"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/460>: "Via and
gateways"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/465>: "Mention 203
Non-Authoritative Information in p1"
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"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/482>: "proxy
handling of a really bad Content-Length"
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 58
asterisk-form (of request-target) 41 asterisk-form (of request-target) 41
authority-form (of request-target) 41 authority-form (of request-target) 41
B B
skipping to change at page 78, line 20 skipping to change at page 80, line 36
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 48, 53
compress (Coding Format) 37 compress (Coding Format) 37
connection 7 connection 7
Connection header field 48, 53 Connection header field 48, 53
Content-Length header field 28 Content-Length header field 29
D D
deflate (Coding Format) 37 deflate (Coding Format) 37
downstream 9 downstream 9
E E
effective request URI 43 effective request URI 43
G G
gateway 10 gateway 10
skipping to change at page 79, line 15 skipping to change at page 81, line 30
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 22
field-name 22 field-name 22
field-value 22 field-value 22
fragment 16
header-field 22 header-field 22
HEXDIG 6 HEXDIG 6
Host 42 Host 42
HTAB 6 HTAB 6
HTTP-message 19 HTTP-message 19
HTTP-name 13 HTTP-name 13
http-URI 16 http-URI 16
HTTP-version 13 HTTP-version 13
https-URI 18 https-URI 18
last-chunk 35 last-chunk 35
LF 6 LF 6
message-body 26 message-body 27
method 20 method 20
obs-fold 22 obs-fold 22
obs-text 26 obs-text 26
OCTET 6 OCTET 6
origin-form 40 origin-form 40
OWS 24 OWS 24
partial-URI 16 partial-URI 16
port 16 port 16
protocol-name 45 protocol-name 45
protocol-version 45 protocol-version 45
skipping to change at page 80, line 6 skipping to change at page 82, line 22
quoted-string 26 quoted-string 26
rank 37 rank 37
reason-phrase 21 reason-phrase 21
received-by 45 received-by 45
received-protocol 45 received-protocol 45
request-line 20 request-line 20
request-target 40 request-target 40
RWS 24 RWS 24
segment 16 segment 16
SP 6 SP 6
special 25 special 26
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 26
TE 37 TE 37
token 25 token 26
Trailer 35 Trailer 35
trailer-part 35 trailer-part 35
transfer-coding 34 transfer-coding 34
Transfer-Encoding 27 Transfer-Encoding 27
transfer-extension 34 transfer-extension 34
transfer-parameter 34 transfer-parameter 34
Upgrade 54 Upgrade 54
uri-host 16 uri-host 16
URI-reference 16 URI-reference 16
value 34 value 34
VCHAR 6 VCHAR 6
Via 45 Via 45
word 25 word 26
gzip (Coding Format) 37 gzip (Coding Format) 37
H H
header field 19 header field 19
header section 19 header section 19
headers 19 headers 19
Host header field 41 Host header field 41
http URI scheme 16 http URI scheme 16
https URI scheme 17 https URI scheme 17
 End of changes. 128 change blocks. 
415 lines changed or deleted 543 lines changed or added

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