p1-messaging.unpg.txt   rfc7230-to-be.unpg.txt 
HTTPbis Working Group R. Fielding, Ed. Internet Engineering Task Force (IETF) R. Fielding, Ed.
Internet-Draft Adobe Request for Comments: 7230 Adobe
Obsoletes: 2145,2616 (if approved) J. Reschke, Ed. Obsoletes: 2145, 2616 J. Reschke, Ed.
Updates: 2817,2818 (if approved) greenbytes Updates: 2817, 2818 greenbytes
Intended status: Standards Track May 6, 2014 Category: Standards Track May 2014
Expires: November 7, 2014 ISSN: 2070-1721
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-latest
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is a stateless application- The Hypertext Transfer Protocol (HTTP) is a stateless application-
level protocol for distributed, collaborative, hypertext information level protocol for distributed, collaborative, hypertext information
systems. This document provides an overview of HTTP architecture and systems. This document provides an overview of HTTP architecture and
its associated terminology, defines the "http" and "https" Uniform its associated terminology, defines the "http" and "https" Uniform
Resource Identifier (URI) schemes, defines the HTTP/1.1 message Resource Identifier (URI) schemes, defines the HTTP/1.1 message
syntax and parsing requirements, and describes related security syntax and parsing requirements, and describes related security
concerns for implementations. concerns for implementations.
Editorial Note (To be removed by RFC Editor)
Discussion of this draft takes place on the HTTPBIS working group
mailing list (ietf-http-wg@w3.org), which is archived at
<http://lists.w3.org/Archives/Public/ietf-http-wg/>.
The current issues list is at
<http://tools.ietf.org/wg/httpbis/trac/report/3> and related
documents (including fancy diffs) can be found at
<http://tools.ietf.org/wg/httpbis/>.
The changes in this draft are summarized in Appendix C.4.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is a product of the Internet Engineering Task Force
Task Force (IETF). Note that other groups may also distribute (IETF). It represents the consensus of the IETF community. It has
working documents as Internet-Drafts. The list of current Internet- received public review and has been approved for publication by the
Drafts is at http://datatracker.ietf.org/drafts/current/. Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Internet-Drafts are draft documents valid for a maximum of six months Information about the current status of this document, any errata,
and may be updated, replaced, or obsoleted by other documents at any and how to provide feedback on it may be obtained at
time. It is inappropriate to use Internet-Drafts as reference http://www.rfc-editor.org/info/rfc7230.
material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 7, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 36 skipping to change at page 2, line 20
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Requirement Notation . . . . . . . . . . . . . . . . . . . 6 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 6
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6
2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 7 2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 7
2.2. Implementation Diversity . . . . . . . . . . . . . . . . . 8 2.2. Implementation Diversity . . . . . . . . . . . . . . . . . 8
2.3. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 9 2.3. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 9
2.4. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.4. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.5. Conformance and Error Handling . . . . . . . . . . . . . . 12 2.5. Conformance and Error Handling . . . . . . . . . . . . . . 12
2.6. Protocol Versioning . . . . . . . . . . . . . . . . . . . 13 2.6. Protocol Versioning . . . . . . . . . . . . . . . . . . . 13
2.7. Uniform Resource Identifiers . . . . . . . . . . . . . . . 16 2.7. Uniform Resource Identifiers . . . . . . . . . . . . . . . 16
2.7.1. http URI scheme . . . . . . . . . . . . . . . . . . . 16 2.7.1. http URI Scheme . . . . . . . . . . . . . . . . . . . 16
2.7.2. https URI scheme . . . . . . . . . . . . . . . . . . . 18 2.7.2. https URI Scheme . . . . . . . . . . . . . . . . . . . 18
2.7.3. http and https URI Normalization and Comparison . . . 19 2.7.3. http and https URI Normalization and Comparison . . . 19
3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 19 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1. Start Line . . . . . . . . . . . . . . . . . . . . . . . . 20 3.1. Start Line . . . . . . . . . . . . . . . . . . . . . . . . 20
3.1.1. Request Line . . . . . . . . . . . . . . . . . . . . . 21 3.1.1. Request Line . . . . . . . . . . . . . . . . . . . . . 21
3.1.2. Status Line . . . . . . . . . . . . . . . . . . . . . 22 3.1.2. Status Line . . . . . . . . . . . . . . . . . . . . . 22
3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 22 3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 22
3.2.1. Field Extensibility . . . . . . . . . . . . . . . . . 23 3.2.1. Field Extensibility . . . . . . . . . . . . . . . . . 23
3.2.2. Field Order . . . . . . . . . . . . . . . . . . . . . 23 3.2.2. Field Order . . . . . . . . . . . . . . . . . . . . . 23
3.2.3. Whitespace . . . . . . . . . . . . . . . . . . . . . . 24 3.2.3. Whitespace . . . . . . . . . . . . . . . . . . . . . . 24
3.2.4. Field Parsing . . . . . . . . . . . . . . . . . . . . 25 3.2.4. Field Parsing . . . . . . . . . . . . . . . . . . . . 25
3.2.5. Field Limits . . . . . . . . . . . . . . . . . . . . . 26 3.2.5. Field Limits . . . . . . . . . . . . . . . . . . . . . 26
3.2.6. Field value components . . . . . . . . . . . . . . . . 26 3.2.6. Field Value Components . . . . . . . . . . . . . . . . 26
3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 27 3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.1. Transfer-Encoding . . . . . . . . . . . . . . . . . . 28 3.3.1. Transfer-Encoding . . . . . . . . . . . . . . . . . . 28
3.3.2. Content-Length . . . . . . . . . . . . . . . . . . . . 30 3.3.2. Content-Length . . . . . . . . . . . . . . . . . . . . 30
3.3.3. Message Body Length . . . . . . . . . . . . . . . . . 31 3.3.3. Message Body Length . . . . . . . . . . . . . . . . . 31
3.4. Handling Incomplete Messages . . . . . . . . . . . . . . . 33 3.4. Handling Incomplete Messages . . . . . . . . . . . . . . . 33
3.5. Message Parsing Robustness . . . . . . . . . . . . . . . . 34 3.5. Message Parsing Robustness . . . . . . . . . . . . . . . . 34
4. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . . 35 4. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . . 35
4.1. Chunked Transfer Coding . . . . . . . . . . . . . . . . . 35 4.1. Chunked Transfer Coding . . . . . . . . . . . . . . . . . 35
4.1.1. Chunk Extensions . . . . . . . . . . . . . . . . . . . 36 4.1.1. Chunk Extensions . . . . . . . . . . . . . . . . . . . 36
4.1.2. Chunked Trailer Part . . . . . . . . . . . . . . . . . 36 4.1.2. Chunked Trailer Part . . . . . . . . . . . . . . . . . 36
skipping to change at page 3, line 50 skipping to change at page 3, line 33
5.7. Message Forwarding . . . . . . . . . . . . . . . . . . . . 46 5.7. Message Forwarding . . . . . . . . . . . . . . . . . . . . 46
5.7.1. Via . . . . . . . . . . . . . . . . . . . . . . . . . 47 5.7.1. Via . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.7.2. Transformations . . . . . . . . . . . . . . . . . . . 48 5.7.2. Transformations . . . . . . . . . . . . . . . . . . . 48
6. Connection Management . . . . . . . . . . . . . . . . . . . . 49 6. Connection Management . . . . . . . . . . . . . . . . . . . . 49
6.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 50 6.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 50
6.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 51 6.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 51
6.3. Persistence . . . . . . . . . . . . . . . . . . . . . . . 52 6.3. Persistence . . . . . . . . . . . . . . . . . . . . . . . 52
6.3.1. Retrying Requests . . . . . . . . . . . . . . . . . . 53 6.3.1. Retrying Requests . . . . . . . . . . . . . . . . . . 53
6.3.2. Pipelining . . . . . . . . . . . . . . . . . . . . . . 53 6.3.2. Pipelining . . . . . . . . . . . . . . . . . . . . . . 53
6.4. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 54 6.4. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 54
6.5. Failures and Time-outs . . . . . . . . . . . . . . . . . . 54 6.5. Failures and Timeouts . . . . . . . . . . . . . . . . . . 54
6.6. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 55 6.6. Teardown . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.7. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 56 6.7. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 56
7. ABNF list extension: #rule . . . . . . . . . . . . . . . . . . 58 7. ABNF List Extension: #rule . . . . . . . . . . . . . . . . . . 58
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60
8.1. Header Field Registration . . . . . . . . . . . . . . . . 60 8.1. Header Field Registration . . . . . . . . . . . . . . . . 60
8.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 60 8.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 60
8.3. Internet Media Type Registration . . . . . . . . . . . . . 61 8.3. Internet Media Type Registration . . . . . . . . . . . . . 61
8.3.1. Internet Media Type message/http . . . . . . . . . . . 61 8.3.1. Internet Media Type message/http . . . . . . . . . . . 61
8.3.2. Internet Media Type application/http . . . . . . . . . 62 8.3.2. Internet Media Type application/http . . . . . . . . . 62
8.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 63 8.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 63
8.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 63 8.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 63
8.4.2. Registration . . . . . . . . . . . . . . . . . . . . . 64 8.4.2. Registration . . . . . . . . . . . . . . . . . . . . . 64
8.5. Content Coding Registration . . . . . . . . . . . . . . . 64 8.5. Content Coding Registration . . . . . . . . . . . . . . . 64
skipping to change at page 4, line 33 skipping to change at page 4, line 16
9.4. Response Splitting . . . . . . . . . . . . . . . . . . . . 68 9.4. Response Splitting . . . . . . . . . . . . . . . . . . . . 68
9.5. Request Smuggling . . . . . . . . . . . . . . . . . . . . 69 9.5. Request Smuggling . . . . . . . . . . . . . . . . . . . . 69
9.6. Message Integrity . . . . . . . . . . . . . . . . . . . . 69 9.6. Message Integrity . . . . . . . . . . . . . . . . . . . . 69
9.7. Message Confidentiality . . . . . . . . . . . . . . . . . 70 9.7. Message Confidentiality . . . . . . . . . . . . . . . . . 70
9.8. Privacy of Server Log Information . . . . . . . . . . . . 70 9.8. Privacy of Server Log Information . . . . . . . . . . . . 70
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 71 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 71
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 72 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 72
11.1. Normative References . . . . . . . . . . . . . . . . . . . 72 11.1. Normative References . . . . . . . . . . . . . . . . . . . 72
11.2. Informative References . . . . . . . . . . . . . . . . . . 74 11.2. Informative References . . . . . . . . . . . . . . . . . . 74
Appendix A. HTTP Version History . . . . . . . . . . . . . . . . 76 Appendix A. HTTP Version History . . . . . . . . . . . . . . . . 76
A.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 77 A.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 76
A.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 77 A.1.1. Multihomed Web Servers . . . . . . . . . . . . . . . . 77
A.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 77 A.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 77
A.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 78 A.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 78
A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 78 A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 78
Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 80 Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 80
Appendix C. Change Log (to be removed by RFC Editor before Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
publication) . . . . . . . . . . . . . . . . . . . . 82
C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 82
C.2. Since draft-ietf-httpbis-p1-messaging-24 . . . . . . . . . 83
C.3. Since draft-ietf-httpbis-p1-messaging-25 . . . . . . . . . 83
C.4. Since draft-ietf-httpbis-p1-messaging-26 . . . . . . . . . 84
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
1. Introduction 1. Introduction
The Hypertext Transfer Protocol (HTTP) is a stateless application- The Hypertext Transfer Protocol (HTTP) is a stateless application-
level request/response protocol that uses extensible semantics and level request/response protocol that uses extensible semantics and
self-descriptive message payloads for flexible interaction with self-descriptive message payloads for flexible interaction with
network-based hypertext information systems. This document is the network-based hypertext information systems. This document is the
first in a series of documents that collectively form the HTTP/1.1 first in a series of documents that collectively form the HTTP/1.1
specification: specification:
skipping to change at page 5, line 26 skipping to change at page 5, line 26
RFC 7231: Semantics and Content RFC 7231: Semantics and Content
RFC 7232: Conditional Requests RFC 7232: Conditional Requests
RFC 7233: Range Requests RFC 7233: Range Requests
RFC 7234: Caching RFC 7234: Caching
RFC 7235: Authentication RFC 7235: Authentication
This HTTP/1.1 specification obsoletes RFC 2616 and RFC 2145 (on HTTP This HTTP/1.1 specification obsoletes [RFC2616] and [RFC2145] (on
versioning). This specification also updates the use of CONNECT to HTTP versioning). This specification also updates the use of
establish a tunnel, previously defined in RFC 2817, and defines the CONNECT, previously defined in RFC 2817, to establish a tunnel, and
"https" URI scheme that was described informally in RFC 2818. defines the "https" URI scheme that was described informally in RFC
2818.
HTTP is a generic interface protocol for information systems. It is HTTP is a generic interface protocol for information systems. It is
designed to hide the details of how a service is implemented by designed to hide the details of how a service is implemented by
presenting a uniform interface to clients that is independent of the presenting a uniform interface to clients that is independent of the
types of resources provided. Likewise, servers do not need to be types of resources provided. Likewise, servers do not need to be
aware of each client's purpose: an HTTP request can be considered in aware of each client's purpose: an HTTP request can be considered in
isolation rather than being associated with a specific type of client isolation rather than being associated with a specific type of client
or a predetermined sequence of application steps. The result is a or a predetermined sequence of application steps. The result is a
protocol that can be used effectively in many different contexts and protocol that can be used effectively in many different contexts and
for which implementations can evolve independently over time. for which implementations can evolve independently over time.
skipping to change at page 6, line 18 skipping to change at page 6, line 19
This document describes the architectural elements that are used or This document describes the architectural elements that are used or
referred to in HTTP, defines the "http" and "https" URI schemes, referred to in HTTP, defines the "http" and "https" URI schemes,
describes overall network operation and connection management, and describes overall network operation and connection management, and
defines HTTP message framing and forwarding requirements. Our goal defines HTTP message framing and forwarding requirements. Our goal
is to define all of the mechanisms necessary for HTTP message is to define all of the mechanisms necessary for HTTP message
handling that are independent of message semantics, thereby defining handling that are independent of message semantics, thereby defining
the complete set of requirements for message parsers and message- the complete set of requirements for message parsers and message-
forwarding intermediaries. forwarding intermediaries.
1.1. Requirement Notation 1.1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Conformance criteria and considerations regarding error handling are Conformance criteria and considerations regarding error handling are
defined in Section 2.5. defined in Section 2.5.
1.2. Syntax Notation 1.2. Syntax Notation
skipping to change at page 7, line 8 skipping to change at page 7, line 9
2. Architecture 2. Architecture
HTTP was created for the World Wide Web (WWW) architecture and has HTTP was created for the World Wide Web (WWW) architecture and has
evolved over time to support the scalability needs of a worldwide evolved over time to support the scalability needs of a worldwide
hypertext system. Much of that architecture is reflected in the hypertext system. Much of that architecture is reflected in the
terminology and syntax productions used to define HTTP. terminology and syntax productions used to define HTTP.
2.1. Client/Server Messaging 2.1. Client/Server Messaging
HTTP is a stateless request/response protocol that operates by HTTP is a stateless request/response protocol that operates by
exchanging messages (Section 3) across a reliable transport or exchanging messages (Section 3) across a reliable transport- or
session-layer "connection" (Section 6). An HTTP "client" is a session-layer "connection" (Section 6). An HTTP "client" is a
program that establishes a connection to a server for the purpose of program that establishes a connection to a server for the purpose of
sending one or more HTTP requests. An HTTP "server" is a program sending one or more HTTP requests. An HTTP "server" is a program
that accepts connections in order to service HTTP requests by sending that accepts connections in order to service HTTP requests by sending
HTTP responses. HTTP responses.
The terms client and server refer only to the roles that these The terms "client" and "server" refer only to the roles that these
programs perform for a particular connection. The same program might programs perform for a particular connection. The same program might
act as a client on some connections and a server on others. The term act as a client on some connections and a server on others. The term
"user agent" refers to any of the various client programs that "user agent" refers to any of the various client programs that
initiate a request, including (but not limited to) browsers, spiders initiate a request, including (but not limited to) browsers, spiders
(web-based robots), command-line tools, custom applications, and (web-based robots), command-line tools, custom applications, and
mobile apps. The term "origin server" refers to the program that can mobile apps. The term "origin server" refers to the program that can
originate authoritative responses for a given target resource. The originate authoritative responses for a given target resource. The
terms "sender" and "recipient" refer to any implementation that sends terms "sender" and "recipient" refer to any implementation that sends
or receives a given message, respectively. or receives a given message, respectively.
skipping to change at page 8, line 50 skipping to change at page 9, line 5
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
units, configurable networking components, office machines, units, configurable networking components, office machines,
autonomous robots, news feeds, traffic cameras, ad selectors, and autonomous robots, news feeds, traffic cameras, ad selectors, and
video delivery platforms. video-delivery platforms.
The term "user agent" does not imply that there is a human user The term "user agent" does not imply that there is a human user
directly interacting with the software agent at the time of a directly interacting with the software agent at the time of a
request. In many cases, a user agent is installed or configured to request. In many cases, a user agent is installed or configured to
run in the background and save its results for later inspection (or run in the background and save its results for later inspection (or
save only a subset of those results that might be interesting or save only a subset of those results that might be interesting or
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.
skipping to change at page 9, line 42 skipping to change at page 9, line 44
tunnel, switching behavior based on the nature of each request. tunnel, switching behavior based on the nature of each request.
> > > > > > > >
UA =========== A =========== B =========== C =========== O UA =========== A =========== B =========== C =========== O
< < < < < < < <
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 endpoints 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. Likewise, later requests might be sent through a different request. Likewise, later requests might be sent through a different
path of connections, often based on dynamic configuration for load path of connections, often based on dynamic configuration for load
balancing. balancing.
The terms "upstream" and "downstream" are used to describe The terms "upstream" and "downstream" are used to describe
directional requirements in relation to the message flow: all directional requirements in relation to the message flow: all
messages flow from upstream to downstream. The terms inbound and messages flow from upstream to downstream. The terms "inbound" and
outbound are used to describe directional requirements in relation to "outbound" are used to describe directional requirements in relation
the request route: "inbound" means toward the origin server and to the request route: "inbound" means toward the origin server and
"outbound" means toward the user agent. "outbound" means toward the user agent.
A "proxy" is a message forwarding agent that is selected by the A "proxy" is a message-forwarding agent that is selected by the
client, usually via local configuration rules, to receive requests client, usually via local configuration rules, to receive requests
for some type(s) of absolute URI and attempt to satisfy those for some type(s) of absolute URI and attempt to satisfy those
requests via translation through the HTTP interface. Some requests via translation through the HTTP interface. Some
translations are minimal, such as for proxy requests for "http" URIs, translations are minimal, such as for proxy requests for "http" URIs,
whereas other requests might require translation to and from entirely whereas other requests might require translation to and from entirely
different application-level protocols. Proxies are often used to different application-level protocols. Proxies are often used to
group an organization's HTTP requests through a common intermediary group an organization's HTTP requests through a common intermediary
for the sake of security, annotation services, or shared caching. for the sake of security, annotation services, or shared caching.
Some proxies are designed to apply transformations to selected Some proxies are designed to apply transformations to selected
messages or payloads while they are being forwarded, as described in messages or payloads while they are being forwarded, as described in
Section 5.7.2. Section 5.7.2.
A "gateway" (a.k.a., "reverse proxy") is an intermediary that acts as A "gateway" (a.k.a. "reverse proxy") is an intermediary that acts as
an origin server for the outbound connection, but translates received an origin server for the outbound connection but translates received
requests and forwards them inbound to another server or servers. requests and forwards them inbound to another server or servers.
Gateways are often used to encapsulate legacy or untrusted Gateways are often used to encapsulate legacy or untrusted
information services, to improve server performance through information services, to improve server performance through
"accelerator" caching, and to enable partitioning or load balancing "accelerator" caching, and to enable partitioning or load balancing
of HTTP services across multiple machines. of HTTP services across multiple machines.
All HTTP requirements applicable to an origin server also apply to All HTTP requirements applicable to an origin server also apply to
the outbound communication of a gateway. A gateway communicates with the outbound communication of a gateway. A gateway communicates with
inbound servers using any protocol that it desires, including private 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 ought to conform to user agent requirements third-party HTTP servers ought to conform to user-agent requirements
on the gateway's inbound connection. on the gateway's inbound connection.
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 11, line 22 skipping to change at page 11, line 25
interception proxy filters or redirects outgoing TCP port 80 packets interception proxy filters or redirects outgoing TCP port 80 packets
(and occasionally other common port traffic). Interception proxies (and occasionally other common port traffic). Interception proxies
are commonly found on public network access points, as a means of are commonly found on public network access points, as a means of
enforcing account subscription prior to allowing use of non-local enforcing account subscription prior to allowing use of non-local
Internet services, and within corporate firewalls to enforce network Internet services, and within corporate firewalls to enforce network
usage policies. usage policies.
HTTP is defined as a stateless protocol, meaning that each request HTTP is defined as a stateless protocol, meaning that each request
message can be understood in isolation. Many implementations depend message can be understood in isolation. Many implementations depend
on HTTP's stateless design in order to reuse proxied connections or on HTTP's stateless design in order to reuse proxied connections or
dynamically load-balance requests across multiple servers. Hence, a dynamically load balance requests across multiple servers. Hence, a
server MUST NOT assume that two requests on the same connection are server MUST NOT assume that two requests on the same connection are
from the same user agent unless the connection is secured and from the same user agent unless the connection is secured and
specific to that agent. Some non-standard HTTP extensions (e.g., specific to that agent. Some non-standard HTTP extensions (e.g.,
[RFC4559]) have been known to violate this requirement, resulting in [RFC4559]) have been known to violate this requirement, resulting in
security and interoperability problems. security and interoperability problems.
2.4. Caches 2.4. Caches
A "cache" is a local store of previous response messages and the A "cache" is a local store of previous response messages and the
subsystem that controls its message storage, retrieval, and deletion. subsystem that controls its message storage, retrieval, and deletion.
skipping to change at page 12, line 8 skipping to change at page 12, line 11
< < < <
A response is "cacheable" if a cache is allowed to store a copy of A response is "cacheable" if a cache is allowed to store a copy of
the response message for use in answering subsequent requests. Even the response message for use in answering subsequent requests. Even
when a response is cacheable, there might be additional constraints when a response is cacheable, there might be additional constraints
placed by the client or by the origin server on when that cached placed by the client or by the origin server on when that cached
response can be used for a particular request. HTTP requirements for response can be used for a particular request. HTTP requirements for
cache behavior and cacheable responses are defined in Section 2 of cache behavior and cacheable responses are defined in Section 2 of
[RFC7234]. [RFC7234].
There are a wide variety of architectures and configurations of There is a wide variety of architectures and configurations of caches
caches deployed across the World Wide Web and inside large deployed across the World Wide Web and inside large organizations.
organizations. These include national hierarchies of proxy caches to These include national hierarchies of proxy caches to save
save transoceanic bandwidth, collaborative systems that broadcast or transoceanic bandwidth, collaborative systems that broadcast or
multicast cache entries, archives of pre-fetched cache entries for multicast cache entries, archives of pre-fetched cache entries for
use in off-line or high-latency environments, and so on. use in off-line or high-latency environments, and so on.
2.5. Conformance and Error Handling 2.5. Conformance and Error Handling
This specification targets conformance criteria according to the role This specification targets conformance criteria according to the role
of a participant in HTTP communication. Hence, HTTP requirements are of a participant in HTTP communication. Hence, HTTP requirements are
placed on senders, recipients, clients, servers, user agents, placed on senders, recipients, clients, servers, user agents,
intermediaries, origin servers, proxies, gateways, or caches, intermediaries, origin servers, proxies, gateways, or caches,
depending on what behavior is being constrained by the requirement. depending on what behavior is being constrained by the requirement.
skipping to change at page 12, line 44 skipping to change at page 12, line 47
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 corresponding ABNF rules. Within a given message, a sender MUST the corresponding ABNF rules. Within a given message, a sender MUST
NOT generate protocol elements or syntax alternatives that are only NOT generate protocol elements or syntax alternatives that are only
allowed to be generated by participants in other roles (i.e., a role allowed to be generated by participants in other roles (i.e., a role
that the sender does not have for that message). that the sender does not have for that message).
When a received protocol element is parsed, the recipient MUST be When a received protocol element is parsed, the recipient MUST be
able to parse any value of reasonable length that is applicable to able to parse any value of reasonable length that is applicable to
the recipient's role and matches the grammar defined by the the recipient's role and that matches the grammar defined by the
corresponding ABNF rules. Note, however, that some received protocol corresponding ABNF rules. Note, however, that some received protocol
elements might not be parsed. For example, an intermediary elements might not be parsed. For example, an intermediary
forwarding a message might parse a header-field into generic field- forwarding a message might parse a header-field into generic field-
name and field-value components, but then forward the header field name and field-value components, but then forward the header field
without further parsing inside the field-value. without further parsing inside the field-value.
HTTP does not have specific length limitations for many of its HTTP does not have specific length limitations for many of its
protocol elements because the lengths that might be appropriate will protocol elements because the lengths that might be appropriate will
vary widely, depending on the deployment context and purpose of the vary widely, depending on the deployment context and purpose of the
implementation. Hence, interoperability between senders and implementation. Hence, interoperability between senders and
recipients depends on shared expectations regarding what is a recipients depends on shared expectations regarding what is a
reasonable length for each protocol element. Furthermore, what is reasonable length for each protocol element. Furthermore, what is
commonly understood to be a reasonable length for some protocol commonly understood to be a reasonable length for some protocol
elements has changed over the course of the past two decades of HTTP elements has changed over the course of the past two decades of HTTP
use, and is expected to continue changing in the future. use and is expected to continue changing in the future.
At a minimum, a recipient MUST be able to parse and process protocol At a minimum, a recipient MUST be able to parse and process protocol
element lengths that are at least as long as the values that it element lengths that are at least as long as the values that it
generates for those same protocol elements in other messages. For generates for those same protocol elements in other messages. For
example, an origin server that publishes very long URI references to example, an origin server that publishes very long URI references to
its own resources needs to be able to parse and process those same its own resources needs to be able to parse and process those same
references when received as a request target. references when received as a request target.
A recipient MUST interpret a received protocol element according to A recipient MUST interpret a received protocol element according to
the semantics defined for it by this specification, including the semantics defined for it by this specification, including
skipping to change at page 13, line 49 skipping to change at page 14, line 4
2.6. Protocol Versioning 2.6. Protocol Versioning
HTTP uses a "<major>.<minor>" numbering scheme to indicate versions HTTP uses a "<major>.<minor>" numbering scheme to indicate versions
of the protocol. This specification defines version "1.1". The of the protocol. This specification defines version "1.1". The
protocol version as a whole indicates the sender's conformance with protocol version as a whole indicates the sender's conformance with
the set of requirements laid out in that version's corresponding the set of requirements laid out in that version's corresponding
specification of HTTP. specification of HTTP.
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 within that major version") indicates the highest minor version within that major
version to which the sender is conformant and able to understand for version to which the sender is conformant and able to understand for
future communication. The minor version advertises the sender's future communication. The minor version advertises the sender's
communication capabilities even when the sender is only using a communication capabilities even when the sender is only using a
backwards-compatible subset of the protocol, thereby letting the backwards-compatible subset of the protocol, thereby letting the
recipient know that more advanced features can be used in response recipient know that more advanced features can be used in response
skipping to change at page 14, line 36 skipping to change at page 14, line 39
The interpretation of a header field does not change between minor The interpretation of a header field does not change between minor
versions of the same major HTTP version, though the default behavior versions of the same major HTTP version, though the default behavior
of a recipient in the absence of such a field can change. Unless of a recipient in the absence of such a field can change. Unless
specified otherwise, header fields defined in HTTP/1.1 are defined specified otherwise, header fields defined in HTTP/1.1 are defined
for all versions of HTTP/1.x. In particular, the Host and Connection for all versions of HTTP/1.x. In particular, the Host and Connection
header fields ought to be implemented by all HTTP/1.x implementations header fields ought to be implemented by all HTTP/1.x implementations
whether or not they advertise conformance with HTTP/1.1. whether or not they advertise conformance with HTTP/1.1.
New header fields can be introduced without changing the protocol New header fields can be introduced without changing the protocol
version if their defined semantics allow them to be safely ignored by version if their defined semantics allow them to be safely ignored by
recipients that do not recognize them. Header field extensibility is recipients that do not recognize them. Header-field extensibility is
discussed in Section 3.2.1. discussed in Section 3.2.1.
Intermediaries that process HTTP messages (i.e., all intermediaries Intermediaries that process HTTP messages (i.e., all intermediaries
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 are not allowed to in forwarded messages. In other words, they are not allowed to
blindly forward the first line of an HTTP message without ensuring blindly forward the first line of an HTTP message without ensuring
that the protocol version in that message matches a version to which that the protocol version in that message matches a version to which
that intermediary is conformant for both the receiving and sending of that intermediary is conformant for both the receiving and sending of
messages. Forwarding an HTTP message without rewriting the HTTP- messages. Forwarding an HTTP message without rewriting the HTTP-
version might result in communication errors when downstream version might result in communication errors when downstream
skipping to change at page 15, line 48 skipping to change at page 15, line 51
introduced between [RFC2068] and [RFC2616], and this revision has introduced between [RFC2068] and [RFC2616], and this revision has
specifically avoided 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 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, but a higher minor version number than what the
recipient implements, the recipient SHOULD process the message as if recipient implements, the recipient SHOULD process the message as if
it were in the highest minor version within that major version to it were in the highest minor version within that major version to
which the recipient is conformant. A recipient can assume that a which the recipient is conformant. A recipient can assume that a
message with a higher minor version, when sent to a recipient that message with a higher minor version, when sent to a recipient that
has not yet indicated support for that higher version, is has not yet indicated support for that higher version, is
sufficiently backwards-compatible to be safely processed by any sufficiently backwards compatible to be safely processed by any
implementation of the same major version. 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 [RFC7231]). HTTP as the means for identifying resources (Section 2 of [RFC7231]).
URI references are used to target requests, indicate redirects, and URI references are used to target requests, indicate redirects, and
define relationships. define relationships.
The definitions of "URI-reference", "absolute-URI", "relative-part", The definitions of "URI-reference", "absolute-URI", "relative-part",
"scheme", "authority", "port", "host", "path-abempty", "segment", "scheme", "authority", "port", "host", "path-abempty", "segment",
"query", and "fragment" are adopted from the URI generic syntax. An "query", and "fragment" are adopted from the URI generic syntax. An
"absolute-path" rule is defined for protocol elements that can "absolute-path" rule is defined for protocol elements that can
contain a non-empty path component. (This rule differs slightly from contain a non-empty path component. (This rule differs slightly from
RFC 3986's path-abempty rule, which allows for an empty path to be the path-abempty rule of RFC 3986, which allows for an empty path to
used in references, and path-absolute rule, which does not allow be used in references, and path-absolute rule, which does not allow
paths that begin with "//".) A "partial-URI" rule is defined for paths that begin with "//".) A "partial-URI" rule is defined for
protocol elements that can contain a relative URI but not a fragment protocol elements that can contain a relative URI but not a fragment
component. component.
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>
scheme = <scheme, defined in [RFC3986], Section 3.1> scheme = <scheme, defined in [RFC3986], Section 3.1>
authority = <authority, defined in [RFC3986], Section 3.2> authority = <authority, defined in [RFC3986], Section 3.2>
uri-host = <host, defined in [RFC3986], Section 3.2.2> uri-host = <host, defined in [RFC3986], Section 3.2.2>
skipping to change at page 16, line 45 skipping to change at page 16, line 45
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 ([RFC0793]) connections on a given port. TCP ([RFC793]) connections on a given port.
http-URI = "http:" "//" authority path-abempty [ "?" query ] http-URI = "http:" "//" authority path-abempty [ "?" query ]
[ "#" fragment ] [ "#" fragment ]
The origin server for an "http" URI is identified by the authority The origin server for an "http" URI is identified by the authority
component, which includes a host identifier and optional TCP port component, which includes a host identifier and optional TCP port
([RFC3986], Section 3.2.2). The hierarchical path component and ([RFC3986], Section 3.2.2). The hierarchical path component and
optional query component serve as an identifier for a potential optional query component serve as an identifier for a potential
target resource within that origin server's name space. The optional target resource within that origin server's name space. The optional
skipping to change at page 18, line 23 skipping to change at page 18, line 23
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. A sender MUST NOT usage might expose a user identifier or password. A sender MUST NOT
generate the userinfo subcomponent (and its "@" delimiter) when an generate the userinfo subcomponent (and its "@" delimiter) when an
"http" URI reference is generated within a message as a request "http" URI reference is generated within a message as a request
target or header field value. Before making use of an "http" URI target or header field value. Before making use of an "http" URI
reference received from an untrusted source, a recipient SHOULD parse reference received from an untrusted source, a recipient SHOULD parse
for userinfo and treat its presence as an error; it is likely being for userinfo and treat its presence as an error; it is likely being
used to obscure the authority for the sake of phishing attacks. used to obscure the authority for the sake of phishing 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 ([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 TCP port 443 is the requirements for the "https" scheme, except that TCP port 443 is the
default if the port subcomponent is empty or not given, and the user default if the port subcomponent is empty or not given, and the user
agent MUST ensure that its connection to the origin server is secured agent MUST ensure that its connection to the origin server is secured
through the use of strong encryption, end-to-end, prior to sending through the use of strong encryption, end-to-end, prior to sending
the first HTTP request. the first HTTP request.
https-URI = "https:" "//" authority path-abempty [ "?" query ] https-URI = "https:" "//" authority path-abempty [ "?" query ]
[ "#" fragment ] [ "#" fragment ]
Note that the "https" URI scheme depends on both TLS and TCP for Note that the "https" URI scheme depends on both TLS and TCP for
establishing authority. Resources made available via the "https" establishing authority. Resources made available via the "https"
scheme have no shared identity with the "http" scheme even if their scheme have no shared identity with the "http" scheme even if their
resource identifiers indicate the same authority (the same host resource identifiers indicate the same authority (the same host
listening to the same TCP port). They are distinct name spaces and listening to the same TCP port). They are distinct namespaces and
are considered to be distinct origin servers. However, an extension are considered to be distinct origin servers. However, an extension
to HTTP that is defined to apply to entire host domains, such as the to HTTP that is defined to apply to entire host domains, such as the
Cookie protocol [RFC6265], can allow information set by one service Cookie protocol [RFC6265], can allow information set by one service
to impact communication with other services within a matching group to impact communication with other services within a matching group
of host domains. 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
skipping to change at page 19, line 18 skipping to change at page 19, line 18
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 Section 6 of [RFC3986], using the defaults algorithm defined in Section 6 of [RFC3986], 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 omit 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: the normal form is to not encode them (see Sections encoded octets: the normal form is to not encode them (see Sections
2.1 and 2.2 of [RFC3986]). 2.1 and 2.2 of [RFC3986]).
For example, the following three URIs are equivalent: For example, the following three URIs are equivalent:
http://example.com:80/~smith/home.html http://example.com:80/~smith/home.html
http://EXAMPLE.com/%7Esmith/home.html http://EXAMPLE.com/%7Esmith/home.html
http://EXAMPLE.com:/%7esmith/home.html http://EXAMPLE.com:/%7esmith/home.html
skipping to change at page 20, line 37 skipping to change at page 20, line 37
The presence of such whitespace in a request might be an attempt to 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 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 it as a new request, either of which might result in a security
vulnerability if other implementations within the request chain vulnerability if other implementations within the request chain
interpret the same message differently. Likewise, the presence of interpret the same message differently. Likewise, the presence of
such whitespace in a response might be ignored by some clients or such whitespace in a response might be ignored by some clients or
cause others to cease parsing. 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 be either 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 only to 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
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 and is followed by a single
(SP), the request-target, another single space (SP), the protocol space (SP), the request-target, another single space (SP), the
version, and ending with CRLF. protocol version, and ends 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 request methods defined by this specification can be found in The request methods defined by this specification can be found in
Section 4 of [RFC7231], along with information regarding the HTTP Section 4 of [RFC7231], along with information regarding the HTTP
method registry and considerations for defining new methods. method registry 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.
skipping to change at page 21, line 39 skipping to change at page 21, line 39
references, resulting in those disallowed characters being sent in a references, resulting in those disallowed characters being sent in a
request-target. request-target.
Recipients of an invalid request-line SHOULD respond with either a Recipients of an invalid request-line SHOULD respond with either a
400 (Bad Request) error or a 301 (Moved Permanently) redirect with 400 (Bad Request) error or a 301 (Moved Permanently) redirect with
the request-target properly encoded. A recipient SHOULD NOT attempt the request-target properly encoded. A recipient SHOULD NOT attempt
to autocorrect and then process the request without a redirect, since to autocorrect and then process the request without a redirect, since
the invalid request-line might be deliberately crafted to bypass the invalid request-line might be deliberately crafted to bypass
security filters along the request chain. 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 predefined limit on the length of a request-
line, as described in Section 2.5. A server that receives a method line, as described in Section 2.5. A server that receives a method
longer than any that it implements SHOULD respond with a 501 (Not longer than any that it implements SHOULD respond with a 501 (Not
Implemented) status code. A server that receives a request-target Implemented) status code. A server that receives a request-target
longer than any URI it wishes to parse MUST respond with a 414 (URI longer than any URI it wishes to parse MUST respond with a 414 (URI
Too Long) status code (see Section 6.5.12 of [RFC7231]). Too Long) status code (see Section 6.5.12 of [RFC7231]).
Various ad-hoc limitations on request-line length are found in Various ad hoc limitations on request-line length are found in
practice. It is RECOMMENDED that all HTTP senders and recipients practice. It is RECOMMENDED that all HTTP senders and recipients
support, at a minimum, request-line lengths of 8000 octets. support, at a minimum, request-line lengths of 8000 octets.
3.1.2. Status Line 3.1.2. Status Line
The first line of a response message is the status-line, consisting The first line of a response message is the status-line, consisting
of the protocol version, a space (SP), the status code, another of the protocol version, a space (SP), the status code, another space
space, a possibly-empty textual phrase describing the status code, (SP), a possibly empty textual phrase describing the status code,
and ending with CRLF. and, finally, CRLF.
status-line = HTTP-version SP status-code SP reason-phrase CRLF status-line = HTTP-version SP status-code SP reason-phrase CRLF
The status-code element is a 3-digit integer code describing the The status-code element is a 3-digit integer code describing the
result of the server's attempt to understand and satisfy the client's result of the server's attempt to understand and satisfy the client's
corresponding request. The rest of the response message is to be corresponding request. The rest of the response message is to be
interpreted in light of the semantics defined for that status code. interpreted in light of the semantics defined for that status code.
See Section 6 of [RFC7231] for information about the semantics of See Section 6 of [RFC7231] for information about the semantics of
status codes, including the classes of status code (indicated by the status codes, including the classes of status code (indicated by the
first digit), the status codes defined by this specification, first digit), the status codes defined by this specification,
skipping to change at page 23, line 29 skipping to change at page 23, line 29
evaluation, or refine the meaning of responses. evaluation, or refine the meaning of responses.
A proxy MUST forward unrecognized header fields unless the field-name A proxy MUST forward unrecognized header fields unless the field-name
is listed in the Connection header field (Section 6.1) or the proxy is listed in the Connection header field (Section 6.1) or the proxy
is specifically configured to block, or otherwise transform, such is specifically configured to block, or otherwise transform, such
fields. Other recipients SHOULD ignore unrecognized header fields. fields. Other recipients SHOULD ignore unrecognized header fields.
These requirements allow HTTP's functionality to be enhanced without These requirements allow HTTP's functionality to be enhanced without
requiring prior update of deployed intermediaries. requiring prior update of deployed intermediaries.
All defined header fields ought to be registered with IANA in the All defined header fields ought to be registered with IANA in the
Message Header Field Registry, as described in Section 8.3 of "Message Headers" field registry, as described in Section 8.3 of
[RFC7231]. [RFC7231].
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
received is not significant. However, it is good practice to send received is not significant. However, it is good practice to send
header fields that contain control data first, such as Host on header fields that contain control data first, such as Host on
requests and Date on responses, so that implementations can decide requests and Date on responses, so that implementations can decide
when not to handle a message as early as possible. A server MUST NOT when not to handle a message as early as possible. A server MUST NOT
apply a request to the target resource until the entire request apply a request to the target resource until the entire request
skipping to change at page 24, line 14 skipping to change at page 24, line 14
the combined field value in order, separated by a comma. The order the combined field value in order, separated by a comma. The order
in which header fields with the same field name are received is in which header fields with the same field name are received is
therefore significant to the interpretation of the combined field therefore significant to the interpretation of the combined field
value; a proxy MUST NOT change the order of these field values when value; a proxy MUST NOT change the order of these field values when
forwarding a message. forwarding a message.
Note: In practice, the "Set-Cookie" header field ([RFC6265]) often Note: In practice, the "Set-Cookie" header field ([RFC6265]) often
appears multiple times in a response message and does not use the appears multiple times in a response message and does not use the
list syntax, violating the above requirements on multiple header list syntax, violating the above requirements on multiple header
fields with the same name. Since it cannot be combined into a fields with the same name. Since it cannot be combined into a
single field-value, recipients ought to handle "Set-Cookie" as a single field-value, recipients ought to handle Set-Cookie as a
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. For protocol elements where optional whitespace is might appear. For protocol elements where optional whitespace is
preferred to improve readability, a sender SHOULD generate the preferred to improve readability, a sender SHOULD generate the
optional whitespace as a single SP; otherwise, a sender SHOULD NOT optional whitespace as a single SP; otherwise, a sender SHOULD NOT
generate optional whitespace except as needed to white-out invalid or generate optional whitespace except as needed to white out invalid or
unwanted protocol elements during in-place message filtering. unwanted protocol elements during in-place message filtering.
The RWS rule is used when at least one linear whitespace octet is The RWS rule is used when at least one linear whitespace octet is
required to separate field tokens. A sender SHOULD generate RWS as a required to separate field tokens. A sender SHOULD generate RWS as a
single SP. single SP.
The BWS rule is used where the grammar allows optional whitespace The BWS rule is used where the grammar allows optional whitespace
only for historical reasons. A sender MUST NOT generate BWS in only for historical reasons. A sender MUST NOT generate BWS in
messages. A recipient MUST parse for such bad whitespace and remove messages. A recipient MUST parse for such bad whitespace and remove
it before interpreting the protocol element. it before interpreting the protocol element.
skipping to change at page 25, line 12 skipping to change at page 25, line 12
BWS = OWS BWS = OWS
; "bad" whitespace ; "bad" whitespace
3.2.4. Field Parsing 3.2.4. Field Parsing
Messages are parsed using a generic algorithm, independent of the Messages are parsed using a generic algorithm, independent of the
individual header field names. The contents within a given field individual header field names. The contents within a given field
value are not parsed until a later stage of message interpretation value are not parsed until a later stage of message interpretation
(usually after the message's entire header section has been (usually after the message's entire header section has been
processed). Consequently, this specification does not use ABNF rules processed). Consequently, this specification does not use ABNF rules
to define each "Field-Name: Field Value" pair, as was done in to define each "field-name: field-value" pair, as was done in
previous editions. Instead, this specification uses ABNF rules which previous editions. Instead, this specification uses ABNF rules that
are named according to each registered field name, wherein the rule are named according to each registered field name, wherein the rule
defines the valid grammar for that field's corresponding field values defines the valid grammar for that field's corresponding field values
(i.e., after the field-value has been extracted from the header (i.e., after the field-value has been extracted from the header
section by a generic field parser). section by a generic field parser).
No whitespace is allowed between the header field-name and colon. In No whitespace is allowed between the header field-name and colon. In
the past, differences in the handling of such whitespace have led to the past, differences in the handling of such whitespace have led to
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 might be preceded and/or followed by optional A field value might be preceded and/or followed by optional
whitespace (OWS); a single SP preceding the field-value is preferred whitespace (OWS); a single SP preceding the field-value is preferred
for consistent readability by humans. The field value does not for consistent readability by humans. The field value does not
include any leading or trailing white space: OWS occurring before the include any leading or trailing whitespace: OWS occurring before the
first non-whitespace octet of the field value or after the last non- first non-whitespace octet of the field value or after the last non-
whitespace octet of the field value ought to be excluded by parsers whitespace octet of the field value ought to be excluded by parsers
when extracting the field value from a header field. when extracting the field value from a header field.
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 8.3.1). A sender MUST NOT generate a message that includes (Section 8.3.1). A sender MUST NOT generate a message that includes
line folding (i.e., that has any field-value that contains a match to line folding (i.e., that has any field-value that contains a match to
skipping to change at page 26, line 15 skipping to change at page 26, line 15
with a representation explaining that unacceptable line folding was with a representation explaining that unacceptable line folding was
received, or replace each received obs-fold with one or more SP received, or replace each received obs-fold with one or more SP
octets prior to interpreting the field value or forwarding the octets prior to interpreting the field value or forwarding the
message downstream. message downstream.
A user agent that receives an obs-fold in a response message that is A user agent that receives an obs-fold in a response message that is
not within a message/http container MUST replace each received obs- not within a message/http container MUST replace each received obs-
fold with one or more SP octets prior to interpreting the field fold with one or more SP octets prior to interpreting the field
value. value.
Historically, HTTP has allowed field content with text in the ISO- Historically, HTTP has allowed field content with text in the
8859-1 [ISO-8859-1] charset, supporting other charsets only through ISO-8859-1 [ISO-8859-1] charset, supporting other charsets only
use of [RFC2047] encoding. In practice, most HTTP header field through use of [RFC2047] encoding. In practice, most HTTP header
values use only a subset of the US-ASCII charset [USASCII]. Newly field values use only a subset of the US-ASCII charset [USASCII].
defined header fields SHOULD limit their field values to US-ASCII Newly defined header fields SHOULD limit their field values to
octets. A recipient SHOULD treat other octets in field content (obs- US-ASCII octets. A recipient SHOULD treat other octets in field
text) as opaque data. content (obs-text) as opaque data.
3.2.5. Field Limits 3.2.5. Field Limits
HTTP does not place a pre-defined limit on the length of each header HTTP does not place a predefined limit on the length of each header
field or on the length of the header section as a whole, as described field or on the length of the header section as a whole, as described
in Section 2.5. Various ad-hoc limitations on individual header in Section 2.5. Various ad hoc limitations on individual header
field length are found in practice, often depending on the specific field length are found in practice, often depending on the specific
field semantics. field semantics.
A server that receives a request header field, or set of fields, A server that receives a request header field, or set of fields,
larger than it wishes to process MUST respond with an appropriate 4xx larger than it wishes to process MUST respond with an appropriate 4xx
(Client Error) status code. Ignoring such header fields would (Client Error) status code. Ignoring such header fields would
increase the server's vulnerability to request smuggling attacks increase the server's vulnerability to request smuggling attacks
(Section 9.5). (Section 9.5).
A client MAY discard or truncate received header fields that are A client MAY discard or truncate received header fields that are
larger than the client wishes to process if the field semantics are larger than the client wishes to process if the field semantics are
such that the dropped value(s) can be safely ignored without changing such that the dropped value(s) can be safely ignored without changing
the message framing or response semantics. the message framing or response semantics.
3.2.6. Field value components 3.2.6. Field Value Components
Most HTTP header field values are defined using common syntax Most HTTP header field values are defined using common syntax
components (token, quoted-string, and comment) separated by components (token, quoted-string, and comment) separated by
whitespace or specific delimiting characters. Delimiters are chosen whitespace or specific delimiting characters. Delimiters are chosen
from the set of US-ASCII visual characters not allowed in a token from the set of US-ASCII visual characters not allowed in a token
(DQUOTE and "(),/:;<=>?@[\]{}"). (DQUOTE and "(),/:;<=>?@[\]{}").
token = 1*tchar token = 1*tchar
tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*"
skipping to change at page 33, line 6 skipping to change at page 33, line 6
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).
7. Otherwise, this is a response message without a declared message 7. Otherwise, this is a response message without a declared message
body length, so the message body length is determined by the body length, so the message body length is determined by the
number of octets received prior to the server closing the number of octets received prior to the server closing the
connection. connection.
Since there is no way to distinguish a successfully completed, close- Since there is no way to distinguish a successfully completed, close-
delimited message from a partially-received message interrupted by delimited message from a partially received message interrupted by
network failure, a server SHOULD generate encoding or length- network failure, a server SHOULD generate encoding or length-
delimited messages whenever possible. The close-delimiting feature delimited messages whenever possible. The close-delimiting feature
exists primarily for backwards compatibility with HTTP/1.0. exists primarily for backwards compatibility with HTTP/1.0.
A server MAY reject a request that contains a message body but not a A server MAY reject a request that contains a message body but not a
Content-Length by responding with 411 (Length Required). Content-Length by responding with 411 (Length Required).
Unless a transfer coding other than chunked has been applied, a Unless a transfer coding other than chunked has been applied, a
client that sends a request containing a message body SHOULD use a client that sends a request containing a message body SHOULD use a
valid Content-Length header field if the message body length is known valid Content-Length header field if the message body length is known
skipping to change at page 33, line 43 skipping to change at page 33, line 43
agent MAY discard the remaining data or attempt to determine if that agent MAY discard the remaining data or attempt to determine if that
data belongs as part of the prior response body, which might be the data belongs as part of the prior response body, which might be the
case if the prior message's Content-Length value is incorrect. A case if the prior message's Content-Length value is incorrect. A
client MUST NOT process, cache, or forward such extra data as a client MUST NOT process, cache, or forward such extra data as a
separate response, since such behavior would be vulnerable to cache separate response, since such behavior would be vulnerable to cache
poisoning. poisoning.
3.4. Handling Incomplete Messages 3.4. Handling Incomplete Messages
A server that receives an incomplete request message, usually due to A server that receives an incomplete request message, usually due to
a canceled request or a triggered time-out exception, MAY send an a canceled request or a triggered timeout exception, MAY send an
error response prior to closing the connection. error response prior to closing the connection.
A client that receives an incomplete response message, which can A client that receives an incomplete response message, which can
occur when a connection is closed prematurely or when decoding a occur when a connection is closed prematurely or when decoding a
supposedly chunked transfer coding fails, MUST record the message as supposedly chunked transfer coding fails, MUST record the message as
incomplete. Cache requirements for incomplete responses are defined incomplete. Cache requirements for incomplete responses are defined
in Section 3 of [RFC7234]. in Section 3 of [RFC7234].
If a response terminates in the middle of the header section (before If a response terminates in the middle of the header section (before
the empty line is received) and the status code might rely on header the empty line is received) and the status code might rely on header
fields to convey the full meaning of the response, then the client fields to convey the full meaning of the response, then the client
cannot assume that meaning has been conveyed; the client might need cannot assume that meaning has been conveyed; the client might need
to repeat the request in order to determine what action to take next. to repeat the request in order to determine what action to take next.
A message body that uses the chunked transfer coding is incomplete if A message body that uses the chunked transfer coding is incomplete if
the zero-sized chunk that terminates the encoding has not been the zero-sized chunk that terminates the encoding has not been
received. A message that uses a valid Content-Length is incomplete received. A message that uses a valid Content-Length is incomplete
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 section was of message body octets received, provided that the header section 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 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
skipping to change at page 35, line 26 skipping to change at page 35, line 26
/ "compress" ; Section 4.2.1 / "compress" ; Section 4.2.1
/ "deflate" ; Section 4.2.2 / "deflate" ; Section 4.2.2
/ "gzip" ; Section 4.2.3 / "gzip" ; Section 4.2.3
/ transfer-extension / transfer-extension
transfer-extension = token *( OWS ";" OWS transfer-parameter ) transfer-extension = token *( OWS ";" OWS transfer-parameter )
Parameters are in the form of a name or name=value pair. Parameters are in the form of a name or name=value pair.
transfer-parameter = token BWS "=" BWS ( token / quoted-string ) transfer-parameter = token BWS "=" BWS ( token / quoted-string )
All transfer-coding names are case-insensitive and ought to be All transfer-coding names are case insensitive and ought to be
registered within the HTTP Transfer Coding registry, as defined in registered within the "HTTP Transfer Coding" registry, as defined in
Section 8.4. They are used in the TE (Section 4.3) and Transfer- Section 8.4. They are used in the TE (Section 4.3) and Transfer-
Encoding (Section 3.3.1) header fields. Encoding (Section 3.3.1) header fields.
4.1. Chunked Transfer Coding 4.1. Chunked Transfer Coding
The chunked transfer coding wraps the payload body in order to The chunked transfer coding wraps the payload body in order to
transfer it as a series of chunks, each with its own size indicator, transfer it as a series of chunks, each with its own size indicator,
followed by an OPTIONAL trailer containing header fields. Chunked followed by an OPTIONAL trailer containing header fields. Chunked
enables content streams of unknown size to be transferred as a enables content streams of unknown size to be transferred as a
sequence of length-delimited buffers, which enables the sender to sequence of length-delimited buffers, which enables the sender to
skipping to change at page 38, line 28 skipping to change at page 38, line 28
The "deflate" coding is a "zlib" data format [RFC1950] containing a The "deflate" coding is a "zlib" data format [RFC1950] containing a
"deflate" compressed data stream [RFC1951] that uses a combination of "deflate" compressed data stream [RFC1951] that uses a combination of
the Lempel-Ziv (LZ77) compression algorithm and Huffman coding. the Lempel-Ziv (LZ77) compression algorithm and Huffman coding.
Note: Some non-conformant implementations send the "deflate" Note: Some non-conformant implementations send the "deflate"
compressed data without the zlib wrapper. compressed data without the zlib wrapper.
4.2.3. Gzip Coding 4.2.3. Gzip Coding
The "gzip" coding is an LZ77 coding with a 32 bit CRC that is The "gzip" coding is an LZ77 coding with a 32-bit Cyclic Redundancy
commonly produced by the gzip file compression program [RFC1952]. A Check (CRC) that is commonly produced by the gzip file compression
recipient SHOULD consider "x-gzip" to be equivalent to "gzip". program [RFC1952]. A recipient SHOULD consider "x-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 48, line 5 skipping to change at page 48, line 5
optional port number of a recipient server or client that optional port number of a recipient server or client that
subsequently forwarded the message. However, if the real host is subsequently forwarded the message. However, if the real host is
considered to be sensitive information, a sender MAY replace it with considered to be sensitive information, a sender MAY replace it with
a pseudonym. If a port is not provided, a recipient MAY interpret a pseudonym. If a port is not provided, a recipient MAY interpret
that as meaning it was received on the default TCP port, if any, for that as meaning it was received on the default TCP port, if any, for
the received-protocol. the received-protocol.
A sender MAY generate comments in the Via header field to identify A sender MAY generate comments in the Via header field to identify
the software of each recipient, analogous to the User-Agent and the software of each recipient, analogous to the User-Agent and
Server header fields. However, all comments in the Via field are Server header fields. However, all comments in the Via field are
optional and a recipient MAY remove them prior to forwarding the optional, and a recipient MAY remove them prior to forwarding the
message. 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 Via: 1.0 fred, 1.1 p.example.net
skipping to change at page 49, line 29 skipping to change at page 49, line 29
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 MAY modify the message body through application or removal of A proxy MAY modify the message body through application or removal of
a transfer coding (Section 4). a transfer coding (Section 4).
A proxy MUST NOT transform the payload (Section 3.3 of [RFC7231]) of A proxy MUST NOT transform the payload (Section 3.3 of [RFC7231]) of
a message that contains a no-transform cache-control directive a message that contains a no-transform Cache-Control directive
(Section 5.2 of [RFC7234]). (Section 5.2 of [RFC7234]).
A proxy MAY transform the payload of a message that does not contain A proxy MAY transform the payload of a message that does not contain
a no-transform cache-control directive. A proxy that transforms a a no-transform Cache-Control directive. A proxy that transforms a
payload MUST add a Warning header field with the warn-code of 214 payload MUST add a Warning header field with the warn-code of 214
("Transformation Applied") if one is not already in the message (see ("Transformation Applied") if one is not already in the message (see
Section 5.5 of [RFC7234]). A proxy that transforms the payload of a Section 5.5 of [RFC7234]). A proxy that transforms the payload of a
200 (OK) response can further inform downstream recipients that a 200 (OK) response can further inform downstream recipients that a
transformation has been applied by changing the response status code transformation has been applied by changing the response status code
to 203 (Non-Authoritative Information) (Section 6.3.4 of [RFC7231]). to 203 (Non-Authoritative Information) (Section 6.3.4 of [RFC7231]).
A proxy SHOULD NOT modify header fields that provide information A proxy SHOULD NOT modify header fields that provide information
about the end points of the communication chain, the resource state, about the endpoints of the communication chain, the resource state,
or the selected representation (other than the payload) unless the or the selected representation (other than the payload) unless the
field's definition specifically allows such modification or the field's definition specifically allows such modification or the
modification is deemed necessary for privacy or security. modification is deemed necessary for privacy or security.
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
layer connection protocol(s). HTTP only presumes a reliable session-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.
As described in Section 5.2, the specific connection protocols to be As described in Section 5.2, the specific connection protocols to be
used for an HTTP interaction are determined by client configuration used for an HTTP interaction are determined by client configuration
and the target URI. For example, the "http" URI scheme and the target URI. For example, the "http" URI scheme
(Section 2.7.1) indicates a default connection of TCP over IP, with a (Section 2.7.1) indicates a default connection of TCP over IP, with a
default TCP port of 80, but the client might be configured to use a default TCP port of 80, but the client might be configured to use a
proxy via some other connection, port, or protocol. proxy via some other connection, port, or protocol.
HTTP implementations are expected to engage in connection management, HTTP implementations are expected to engage in connection management,
which includes maintaining the state of current connections, which includes maintaining the state of current connections,
establishing a new connection or reusing an existing connection, establishing a new connection or reusing an existing connection,
processing messages received on a connection, detecting connection processing messages received on a connection, detecting connection
failures, and closing each connection. Most clients maintain failures, and closing each connection. Most clients maintain
multiple connections in parallel, including more than one connection multiple connections in parallel, including more than one connection
per server endpoint. Most servers are designed to maintain thousands per server endpoint. Most servers are designed to maintain thousands
of concurrent connections, while controlling request queues to enable of concurrent connections, while controlling request queues to enable
fair use and detect denial of service attacks. fair use and detect denial-of-service attacks.
6.1. Connection 6.1. Connection
The "Connection" header field allows the sender to indicate desired The "Connection" header field allows the sender to indicate desired
control options for the current connection. In order to avoid control options for the current connection. In order to avoid
confusing downstream recipients, a proxy or gateway MUST remove or confusing downstream recipients, a proxy or gateway MUST remove or
replace any received connection options before forwarding the replace any received connection options before forwarding the
message. message.
When a header field aside from Connection is used to supply control When a header field aside from Connection is used to supply control
skipping to change at page 51, line 8 skipping to change at page 51, line 8
recipients on the chain ("end-to-end"), enabling the message to be recipients on the chain ("end-to-end"), enabling the message to be
self-descriptive and allowing future connection-specific extensions self-descriptive and allowing future connection-specific extensions
to be deployed without fear that they will be blindly forwarded by to be deployed without fear that they will be blindly forwarded by
older intermediaries. older intermediaries.
The Connection header field's value has the following grammar: The Connection header field's value has the following grammar:
Connection = 1#connection-option Connection = 1#connection-option
connection-option = token connection-option = token
Connection options are case-insensitive. Connection options are case insensitive.
A sender MUST NOT send a connection option corresponding to a header A sender MUST NOT send a connection option corresponding to a header
field that is intended for all recipients of the payload. For field that is intended for all recipients of the payload. For
example, Cache-Control is never appropriate as a connection option example, Cache-Control is never appropriate as a connection option
(Section 5.2 of [RFC7234]). (Section 5.2 of [RFC7234]).
The connection options do not always correspond to a header field The connection options do not always correspond to a header field
present in the message, since a connection-specific header field present in the message, since a connection-specific header field
might not be needed if there are no parameters associated with a might not be needed if there are no parameters associated with a
connection option. In contrast, a connection-specific header field connection option. In contrast, a connection-specific header field
skipping to change at page 51, line 51 skipping to change at page 51, line 51
A client that does not support persistent connections MUST send the A client that does not support persistent connections MUST send the
"close" connection option in every request message. "close" connection option in every request message.
A server that does not support persistent connections MUST send the A server that does not support persistent connections MUST send the
"close" connection option in every response message that does not "close" connection option in every response message that does not
have a 1xx (Informational) status code. have a 1xx (Informational) status code.
6.2. Establishment 6.2. Establishment
It is beyond the scope of this specification to describe how It is beyond the scope of this specification to describe how
connections are established via various transport or session-layer connections are established via various transport- or session-layer
protocols. Each connection applies to only one transport link. protocols. Each connection applies to only one transport link.
6.3. Persistence 6.3. Persistence
HTTP/1.1 defaults to the use of "persistent connections", allowing HTTP/1.1 defaults to the use of "persistent connections", allowing
multiple requests and responses to be carried over a single multiple requests and responses to be carried over a single
connection. The "close" connection-option is used to signal that a connection. The "close" connection option is used to signal that a
connection will not persist after the current request/response. HTTP connection will not persist after the current request/response. HTTP
implementations SHOULD support persistent connections. implementations SHOULD support persistent connections.
A recipient determines whether a connection is persistent or not A recipient determines whether a connection is persistent or not
based on the most recently received message's protocol version and based on the most recently received message's protocol version and
Connection header field (if any): Connection header field (if any):
o If the close connection option is present, the connection will not o If the "close" connection option is present, the connection will
persist after the current response; else, not persist after the current response; else,
o If the received protocol is HTTP/1.1 (or later), the connection o If the received protocol is HTTP/1.1 (or later), the connection
will persist after the current response; else, will persist after the current response; else,
o If the received protocol is HTTP/1.0, the "keep-alive" connection o If the received protocol is HTTP/1.0, the "keep-alive" connection
option is present, the recipient is not a proxy, and the recipient option is present, the recipient is not a proxy, and the recipient
wishes to honor the HTTP/1.0 "keep-alive" mechanism, the wishes to honor the HTTP/1.0 "keep-alive" mechanism, the
connection will persist after the current response; otherwise, connection will persist after the current response; otherwise,
o The connection will close after the current response. o The connection will close after the current response.
A client MAY send additional requests on a persistent connection A client MAY send additional requests on a persistent connection
until it sends or receives a close connection option or receives an until it sends or receives a "close" connection option or receives an
HTTP/1.0 response without a "keep-alive" connection option. HTTP/1.0 response without a "keep-alive" connection option.
In order to remain persistent, all messages on a connection need to In order to remain persistent, all messages on a connection need to
have a self-defined message length (i.e., one not defined by closure have a self-defined message length (i.e., one not defined by closure
of the connection), as described in Section 3.3. A server MUST read of the connection), as described in Section 3.3. A server MUST read
the entire request message body or close the connection after sending the entire request message body or close the connection after sending
its response, since otherwise the remaining data on a persistent its response, since otherwise the remaining data on a persistent
connection would be misinterpreted as the next request. Likewise, a connection would be misinterpreted as the next request. Likewise, a
client MUST read the entire response message body if it intends to client MUST read the entire response message body if it intends to
reuse the same connection for a subsequent request. reuse the same connection for a subsequent request.
A proxy server MUST NOT maintain a persistent connection with an A proxy server MUST NOT maintain a persistent connection with an
HTTP/1.0 client (see Section 19.7.1 of [RFC2068] for information and HTTP/1.0 client (see Section 19.7.1 of [RFC2068] for information and
discussion of the problems with the Keep-Alive header field discussion of the problems with the Keep-Alive header field
implemented by many HTTP/1.0 clients). implemented by many HTTP/1.0 clients).
See Appendix A.1.2 for more information on backward compatibility See Appendix A.1.2 for more information on backwards compatibility
with HTTP/1.0 clients. with HTTP/1.0 clients.
6.3.1. Retrying Requests 6.3.1. Retrying Requests
Connections can be closed at any time, with or without intention. Connections can be closed at any time, with or without intention.
Implementations ought to anticipate the need to recover from Implementations ought to anticipate the need to recover from
asynchronous close events. asynchronous close events.
When an inbound connection is closed prematurely, a client MAY open a When an inbound connection is closed prematurely, a client MAY open a
new connection and automatically retransmit an aborted sequence of new connection and automatically retransmit an aborted sequence of
skipping to change at page 53, line 38 skipping to change at page 53, line 38
the requests that failed. the requests that failed.
A client SHOULD NOT automatically retry a failed automatic retry. A client SHOULD NOT automatically retry a failed automatic retry.
6.3.2. Pipelining 6.3.2. Pipelining
A client that supports persistent connections MAY "pipeline" its A client that supports persistent connections MAY "pipeline" its
requests (i.e., send multiple requests without waiting for each requests (i.e., send multiple requests without waiting for each
response). A server MAY process a sequence of pipelined requests in response). A server MAY process a sequence of pipelined requests in
parallel if they all have safe methods (Section 4.2.1 of [RFC7231]), parallel if they all have safe methods (Section 4.2.1 of [RFC7231]),
but MUST send the corresponding responses in the same order that the but it MUST send the corresponding responses in the same order that
requests were received. the requests were received.
A client that pipelines requests SHOULD retry unanswered requests if A client that pipelines requests SHOULD retry unanswered requests if
the connection closes before it receives all of the corresponding the connection closes before it receives all of the corresponding
responses. When retrying pipelined requests after a failed responses. When retrying pipelined requests after a failed
connection (a connection not explicitly closed by the server in its connection (a connection not explicitly closed by the server in its
last complete response), a client MUST NOT pipeline immediately after last complete response), a client MUST NOT pipeline immediately after
connection establishment, since the first remaining request in the connection establishment, since the first remaining request in the
prior pipeline might have caused an error response that can be lost prior pipeline might have caused an error response that can be lost
again if multiple requests are sent on a prematurely closed again if multiple requests are sent on a prematurely closed
connection (see the TCP reset problem described in Section 6.6). connection (see the TCP reset problem described in Section 6.6).
skipping to change at page 54, line 29 skipping to change at page 54, line 29
agent(s) can recover accordingly. agent(s) can recover accordingly.
6.4. Concurrency 6.4. Concurrency
A client ought to limit the number of simultaneous open connections A client ought to limit the number of simultaneous open connections
that it maintains to a given server. that it maintains to a given server.
Previous revisions of HTTP gave a specific number of connections as a Previous revisions of HTTP gave a specific number of connections as a
ceiling, but this was found to be impractical for many applications. ceiling, but this was found to be impractical for many applications.
As a result, this specification does not mandate a particular maximum As a result, this specification does not mandate a particular maximum
number of connections, but instead encourages clients to be number of connections but, instead, encourages clients to be
conservative when opening multiple connections. conservative when opening multiple connections.
Multiple connections are typically used to avoid the "head-of-line Multiple connections are typically used to avoid the "head-of-line
blocking" problem, wherein a request that takes significant server- blocking" problem, wherein a request that takes significant server-
side processing and/or has a large payload blocks subsequent requests side processing and/or has a large payload blocks subsequent requests
on the same connection. However, each connection consumes server on the same connection. However, each connection consumes server
resources. Furthermore, using multiple connections can cause resources. Furthermore, using multiple connections can cause
undesirable side effects in congested networks. undesirable side effects in congested networks.
Note that a server might reject traffic that it deems abusive or Note that a server might reject traffic that it deems abusive or
characteristic of a denial of service attack, such as an excessive characteristic of a denial-of-service attack, such as an excessive
number of open connections from a single client. number of open connections from a single client.
6.5. Failures and Time-outs 6.5. Failures and Timeouts
Servers will usually have some time-out value beyond which they will Servers will usually have some timeout value beyond which they will
no longer maintain an inactive connection. Proxy servers might make no longer maintain an inactive connection. Proxy servers might make
this a higher value since it is likely that the client will be making this a higher value since it is likely that the client will be making
more connections through the same proxy server. The use of more connections through the same proxy server. The use of
persistent connections places no requirements on the length (or persistent connections places no requirements on the length (or
existence) of this time-out for either the client or the server. existence) of this timeout for either the client or the server.
A client or server that wishes to time-out SHOULD issue a graceful A client or server that wishes to time out SHOULD issue a graceful
close on the connection. Implementations SHOULD constantly monitor close on the connection. Implementations SHOULD constantly monitor
open connections for a received closure signal and respond to it as open connections for a received closure signal and respond to it as
appropriate, since prompt closure of both sides of a connection appropriate, since prompt closure of both sides of a connection
enables allocated system resources to be reclaimed. enables allocated system resources to be reclaimed.
A client, server, or proxy MAY close the transport connection at any A client, server, or proxy MAY close the transport connection at any
time. For example, a client might have started to send a new request time. For example, a client might have started to send a new request
at the same time that the server has decided to close the "idle" at the same time that the server has decided to close the "idle"
connection. From the server's point of view, the connection is being connection. From the server's point of view, the connection is being
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.
A server SHOULD sustain persistent connections, when possible, and A server SHOULD sustain persistent connections, when possible, and
allow the underlying transport's flow control mechanisms to resolve allow the underlying transport's flow-control mechanisms to resolve
temporary overloads, rather than terminate connections with the temporary overloads, rather than terminate connections with the
expectation that clients will retry. The latter technique can expectation that clients will retry. The latter technique can
exacerbate network congestion. exacerbate network 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 response while it is transmitting the request. If the for an error response while it is transmitting the request. If the
client sees a response that indicates the server does not wish to client sees a response that indicates the server does not wish to
receive the message body and is closing the connection, the client receive the message body and is closing the connection, the client
SHOULD immediately cease transmitting the body and close its side of SHOULD immediately cease transmitting the body and close its side of
the connection. the connection.
6.6. Tear-down 6.6. Teardown
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
close of the connection (see below) after it sends the final response close of the connection (see below) after it sends the final response
to the request that contained close. The server SHOULD send a close to the request that contained close. The server SHOULD send a close
connection option in its final response on that connection. The connection option in its final response on that connection. The
server MUST NOT process any further requests received on that server MUST NOT process any further requests received on that
connection. connection.
A server that sends a close connection option MUST initiate a close A server that sends a "close" connection option MUST initiate a close
of the connection (see below) after it sends the response containing of the connection (see below) after it sends the response containing
close. The server MUST NOT process any further requests received on close. The server MUST NOT process any further requests 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 NOT requests had been sent on the connection, the client SHOULD NOT
assume that they will 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, servers typically close a connection To avoid the TCP reset problem, servers typically close a connection
in stages. First, the server performs a half-close by closing only in stages. First, the server performs a half-close by closing only
the write side of the read/write connection. The server then the write side of the read/write connection. The server then
continues to read from the connection until it receives a continues to read from the connection until it receives a
skipping to change at page 57, line 31 skipping to change at page 57, line 31
The following is a hypothetical example sent by a client: The following is a hypothetical example sent by a client:
GET /hello.txt HTTP/1.1 GET /hello.txt HTTP/1.1
Host: www.example.com Host: www.example.com
Connection: upgrade Connection: upgrade
Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
The capabilities and nature of the application-level communication The capabilities and nature of the application-level communication
after the protocol change is entirely dependent upon the new after the protocol change is entirely dependent upon the new
protocol(s) chosen. However, immediately after sending the 101 protocol(s) chosen. However, immediately after sending the 101
response, the server is expected to continue responding to the (Switching Protocols) response, the server is expected to continue
original request as if it had received its equivalent within the new responding to the original request as if it had received its
protocol (i.e., the server still has an outstanding request to equivalent within the new protocol (i.e., the server still has an
satisfy after the protocol has been changed, and is expected to do so outstanding request to satisfy after the protocol has been changed,
without requiring the request to be repeated). and is expected to do so without requiring the request to be
repeated).
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, it first responds with a and the server decides to switch protocols, it first responds with a
101 (Switching Protocols) message in HTTP/1.1 and then immediately 101 (Switching Protocols) message in HTTP/1.1 and then immediately
follows that with the new protocol's equivalent of a response to a follows that with the new protocol's equivalent of a response to a
GET on the target resource. This allows a connection to be upgraded GET on the target resource. This allows a connection to be upgraded
to protocols with the same semantics as HTTP without the latency cost to protocols with the same semantics as HTTP without the latency cost
of an additional round-trip. A server MUST NOT switch protocols of an additional round trip. A server MUST NOT switch protocols
unless the received message semantics can be honored by the new unless the received message semantics can be honored by the new
protocol; an OPTIONS request can be honored by any protocol. protocol; an OPTIONS request can be honored by any protocol.
The following is an example response to the above hypothetical The following is an example response to the above hypothetical
request: request:
HTTP/1.1 101 Switching Protocols HTTP/1.1 101 Switching Protocols
Connection: upgrade Connection: upgrade
Upgrade: HTTP/2.0 Upgrade: HTTP/2.0
skipping to change at page 58, line 25 skipping to change at page 58, line 25
When Upgrade is sent, the sender MUST also send a Connection header When Upgrade is sent, the sender MUST also send a Connection header
field (Section 6.1) that contains an "upgrade" connection option, in 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.
A client cannot begin using an upgraded protocol on the connection A client cannot begin using an upgraded protocol on the connection
until it has completely sent the request message (i.e., the client until it has completely sent the request message (i.e., the client
can't change the protocol it is sending in the middle of a message). can't change the protocol it is sending in the middle of a message).
If a server receives both Upgrade and an Expect header field with the If a server receives both an Upgrade and an Expect header field with
"100-continue" expectation (Section 5.1.1 of [RFC7231]), the server the "100-continue" expectation (Section 5.1.1 of [RFC7231]), the
MUST send a 100 (Continue) response before sending a 101 (Switching server MUST send a 100 (Continue) response before sending a 101
Protocols) response. (Switching Protocols) response.
The Upgrade header field only applies to switching protocols on top The Upgrade header field only applies to switching protocols on top
of the existing connection; it cannot be used to switch the of the existing connection; it cannot be used to switch the
underlying connection (transport) protocol, nor to switch the underlying connection (transport) protocol, nor to switch the
existing communication to a different connection. For those existing communication to a different connection. For those
purposes, it is more appropriate to use a 3xx (Redirection) response purposes, it is more appropriate to use a 3xx (Redirection) response
(Section 6.4 of [RFC7231]). (Section 6.4 of [RFC7231]).
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 8.6. using the registration procedure defined in Section 8.6.
7. ABNF list extension: #rule 7. 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).
In any production that uses the list construct, a sender MUST NOT In any production that uses the list construct, a sender MUST NOT
skipping to change at page 59, line 22 skipping to change at page 59, line 22
#element => [ 1#element ] #element => [ 1#element ]
and for n >= 1 and m > 1: and for n >= 1 and m > 1:
<n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element ) <n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element )
For compatibility with legacy list rules, a recipient MUST parse and For compatibility with legacy list rules, a recipient MUST parse and
ignore a reasonable number of empty list elements: enough to handle ignore a reasonable number of empty list elements: enough to handle
common mistakes by senders that merge values, but not so much that common mistakes by senders that merge values, but not so much that
they could be used as a denial of service mechanism. In other words, they could be used as a denial-of-service mechanism. In other words,
a recipient MUST accept lists that satisfy the following syntax: a recipient MUST accept lists that satisfy the following syntax:
#element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ] #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ]
1#element => *( "," OWS ) element *( OWS "," [ OWS element ] ) 1#element => *( "," OWS ) element *( OWS "," [ OWS element ] )
Empty elements do not contribute to the count of elements present. Empty elements do not contribute to the count of elements present.
For example, given these ABNF productions: For example, given these ABNF productions:
example-list = 1#example-list-elmt example-list = 1#example-list-elmt
example-list-elmt = token ; see Section 3.2.6 example-list-elmt = token ; see Section 3.2.6
Then the following are valid values for example-list (not including Then, the following are valid values for example-list (not including
the double quotes, which are present for delimitation only): the double quotes, which are present for delimitation only):
"foo,bar" "foo,bar"
"foo ,bar," "foo ,bar,"
"foo , ,bar,charlie " "foo , ,bar,charlie "
In contrast, the following values would be invalid, since at least In contrast, the following values would be invalid, since at least
one non-empty element is required by the example-list production: one non-empty element is required by the example-list production:
"" ""
"," ","
", ," ", ,"
Appendix B shows the collected ABNF for recipients after the list Appendix B shows the collected ABNF for recipients after the list
constructs have been expanded. constructs have been expanded.
8. IANA Considerations 8. IANA Considerations
8.1. Header Field Registration 8.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 maintained at registry maintained at
<http://www.iana.org/assignments/message-headers/>. <http://www.iana.org/assignments/message-headers/>.
This document defines the following HTTP header fields, so their This document defines the following HTTP header fields, so the
associated registry entries shall be updated according to the "Permanent Message Header Field Names" registry has been updated
permanent registrations below (see [BCP90]): accordingly (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.4 | | Trailer | http | standard | Section 4.4 |
| Transfer-Encoding | http | standard | Section 3.3.1 | | Transfer-Encoding | http | standard | Section 3.3.1 |
| Upgrade | http | standard | Section 6.7 | | Upgrade | http | standard | Section 6.7 |
| Via | http | standard | Section 5.7.1 | | Via | http | standard | Section 5.7.1 |
+-------------------+----------+----------+---------------+ +-------------------+----------+----------+---------------+
Furthermore, the header field-name "Close" shall be registered as Furthermore, the header field-name "Close" has been registered as
"reserved", since using that name as an HTTP header field might "reserved", since using that name as an HTTP header field might
conflict with the "close" connection option of the "Connection" conflict with the "close" connection option of the "Connection"
header field (Section 6.1). header field (Section 6.1).
+-------------------+----------+----------+-------------+ +-------------------+----------+----------+-------------+
| Header Field Name | Protocol | Status | Reference | | Header Field Name | Protocol | Status | Reference |
+-------------------+----------+----------+-------------+ +-------------------+----------+----------+-------------+
| Close | http | reserved | Section 8.1 | | Close | http | reserved | Section 8.1 |
+-------------------+----------+----------+-------------+ +-------------------+----------+----------+-------------+
The change controller is: "IETF (iesg@ietf.org) - Internet The change controller is: "IETF (iesg@ietf.org) - Internet
Engineering Task Force". Engineering Task Force".
8.2. URI Scheme Registration 8.2. URI Scheme Registration
IANA maintains the registry of URI Schemes [BCP115] at IANA maintains the registry of URI Schemes [BCP115] at
<http://www.iana.org/assignments/uri-schemes/>. <http://www.iana.org/assignments/uri-schemes/>.
This document defines the following URI schemes, so their associated This document defines the following URI schemes, so the "Permanent
registry entries shall be updated according to the permanent URI Schemes" registry has been updated accordingly.
registrations below:
+------------+------------------------------------+---------------+ +------------+------------------------------------+---------------+
| URI Scheme | Description | Reference | | URI Scheme | Description | Reference |
+------------+------------------------------------+---------------+ +------------+------------------------------------+---------------+
| http | Hypertext Transfer Protocol | Section 2.7.1 | | http | Hypertext Transfer Protocol | Section 2.7.1 |
| https | Hypertext Transfer Protocol Secure | Section 2.7.2 | | https | Hypertext Transfer Protocol Secure | Section 2.7.2 |
+------------+------------------------------------+---------------+ +------------+------------------------------------+---------------+
8.3. Internet Media Type Registration 8.3. Internet Media Type Registration
IANA maintains the registry of Internet media types [BCP13] at IANA maintains the registry of Internet media types [BCP13] at
<http://www.iana.org/assignments/media-types>. <http://www.iana.org/assignments/media-types>.
This document serves as the specification for the Internet media This document serves as the specification for the Internet media
types "message/http" and "application/http". The following is to be types "message/http" and "application/http". The following has been
registered with IANA. registered with IANA.
8.3.1. Internet Media Type message/http 8.3.1. Internet Media Type message/http
The message/http type can be used to enclose a single HTTP request or The message/http type can be used to enclose a single HTTP request or
response message, provided that it obeys the MIME restrictions for response message, provided that it obeys the MIME restrictions for
all "message" types regarding line length and encodings. all "message" types regarding line length and encodings.
Type name: message Type name: message
skipping to change at page 62, line 20 skipping to change at page 62, line 20
Additional information: Additional information:
Magic number(s): N/A Magic number(s): N/A
Deprecated alias names for this type: N/A Deprecated alias names for this type: N/A
File extension(s): N/A File extension(s): N/A
Macintosh file type code(s): N/A Macintosh file type code(s): N/A
Person and email address to contact for further information: See Person and email address to contact for further information:
Authors Section. See Authors' Addresses Section.
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: N/A Restrictions on usage: N/A
Author: See Authors Section. Author: See Authors' Addresses Section.
Change controller: IESG Change controller: IESG
8.3.2. Internet Media Type application/http 8.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
skipping to change at page 63, line 7 skipping to change at page 63, line 7
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.
msgtype: The message type -- "request" or "response". If not msgtype: The message type -- "request" or "response". If not
present, the type can be determined from the first line of the present, the type can be determined from the first line of the
body. body.
Encoding considerations: HTTP messages enclosed by this type are in Encoding considerations: HTTP messages enclosed by this type are in
"binary" format; use of an appropriate Content-Transfer-Encoding "binary" format; use of an appropriate Content-Transfer-Encoding
is required when transmitted via E-mail. is required when transmitted via email.
Security considerations: see Section 9 Security considerations: see Section 9
Interoperability considerations: N/A Interoperability considerations: N/A
Published specification: This specification (see Section 8.3.2). Published specification: This specification (see Section 8.3.2).
Applications that use this media type: N/A Applications that use this media type: N/A
Fragment identifier considerations: N/A Fragment identifier considerations: N/A
skipping to change at page 63, line 29 skipping to change at page 63, line 29
Additional information: Additional information:
Deprecated alias names for this type: N/A Deprecated alias names for this type: N/A
Magic number(s): N/A Magic number(s): N/A
File extension(s): N/A File extension(s): N/A
Macintosh file type code(s): N/A Macintosh file type code(s): N/A
Person and email address to contact for further information: See Person and email address to contact for further information:
Authors Section. See Authors' Addresses Section.
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: N/A Restrictions on usage: N/A
Author: See Authors Section. Author: See Authors' Addresses Section.
Change controller: IESG Change controller: IESG
8.4. Transfer Coding Registry 8.4. Transfer Coding Registry
The HTTP Transfer Coding Registry defines the name space for transfer The "HTTP Transfer Coding" registry defines the namespace for
coding names. It is maintained at transfer coding names. It is maintained at
<http://www.iana.org/assignments/http-parameters>. <http://www.iana.org/assignments/http-parameters>.
8.4.1. Procedure 8.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 [RFC7231]) unless the encoding codings (Section 3.1.2.1 of [RFC7231]) 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 namespace require IETF Review (see Section
Section 4.1 of [RFC5226]), and MUST conform to the purpose of 4.1 of [RFC5226]), and MUST conform to the purpose of transfer coding
transfer coding defined in this specification. defined in this specification.
Use of program names for the identification of encoding formats is Use of program names for the identification of encoding formats is
not desirable and is discouraged for future encodings. not desirable and is discouraged for future encodings.
8.4.2. Registration 8.4.2. Registration
The HTTP Transfer Coding Registry shall be updated with the The "HTTP Transfer Coding Registry" has been 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" data format [Welch] | Section 4.2.1 | | compress | UNIX "compress" data format [Welch] | Section 4.2.1 |
| deflate | "deflate" compressed data | Section 4.2.2 | | deflate | "deflate" compressed data | Section 4.2.2 |
| | ([RFC1951]) inside the "zlib" data | | | | ([RFC1951]) inside the "zlib" data | |
| | format ([RFC1950]) | | | | format ([RFC1950]) | |
| gzip | GZIP file format [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-compress | Deprecated (alias for compress) | Section 4.2.1 |
| x-gzip | Deprecated (alias for gzip) | Section 4.2.3 | | x-gzip | Deprecated (alias for gzip) | Section 4.2.3 |
+------------+--------------------------------------+---------------+ +------------+--------------------------------------+---------------+
8.5. Content Coding Registration 8.5. Content Coding Registration
IANA maintains the registry of HTTP Content Codings at IANA maintains the "HTTP Content Coding Registry" at
<http://www.iana.org/assignments/http-parameters>. <http://www.iana.org/assignments/http-parameters>.
The HTTP Content Codings Registry shall be updated with the The "HTTP Content Codings Registry" has been updated with the
registrations below: registrations below:
+------------+--------------------------------------+---------------+ +------------+--------------------------------------+---------------+
| Name | Description | Reference | | Name | Description | Reference |
+------------+--------------------------------------+---------------+ +------------+--------------------------------------+---------------+
| compress | UNIX "compress" data format [Welch] | Section 4.2.1 | | compress | UNIX "compress" data format [Welch] | Section 4.2.1 |
| deflate | "deflate" compressed data | Section 4.2.2 | | deflate | "deflate" compressed data | Section 4.2.2 |
| | ([RFC1951]) inside the "zlib" data | | | | ([RFC1951]) inside the "zlib" data | |
| | format ([RFC1950]) | | | | format ([RFC1950]) | |
| gzip | GZIP file format [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-compress | Deprecated (alias for compress) | Section 4.2.1 |
| x-gzip | Deprecated (alias for gzip) | Section 4.2.3 | | x-gzip | Deprecated (alias for gzip) | Section 4.2.3 |
+------------+--------------------------------------+---------------+ +------------+--------------------------------------+---------------+
8.6. Upgrade Token Registry 8.6. Upgrade Token Registry
The HTTP Upgrade Token Registry defines the name space for protocol- The "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry"
name tokens used to identify protocols in the Upgrade header field. defines the namespace for protocol-name tokens used to identify
The registry is maintained at protocols in the Upgrade header field. The registry is maintained at
<http://www.iana.org/assignments/http-upgrade-tokens>. <http://www.iana.org/assignments/http-upgrade-tokens>.
8.6.1. Procedure 8.6.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:
skipping to change at page 66, line 10 skipping to change at page 66, line 10
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].
8.6.2. Upgrade Token Registration 8.6.2. Upgrade Token Registration
The "HTTP" entry in the HTTP Upgrade Token Registry shall be updated The "HTTP" entry in the "HTTP Upgrade Token" registry shall be
with the registration below: updated with the 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") | |
+-------+----------------------+----------------------+-------------+ +-------+----------------------+----------------------+-------------+
The responsible party is: "IETF (iesg@ietf.org) - Internet The responsible party is: "IETF (iesg@ietf.org) - Internet
skipping to change at page 67, line 13 skipping to change at page 67, line 13
unknown or untrusted source. unknown or untrusted source.
When a registered name is used in the authority component, the "http" When a registered name is used in the authority component, the "http"
URI scheme (Section 2.7.1) relies on the user's local name resolution URI scheme (Section 2.7.1) relies on the user's local name resolution
service to determine where it can find authoritative responses. This service to determine where it can find authoritative responses. This
means that any attack on a user's network host table, cached names, means that any attack on a user's network host table, cached names,
or name resolution libraries becomes an avenue for attack on or name resolution libraries becomes an avenue for attack on
establishing authority. Likewise, the user's choice of server for establishing authority. Likewise, the user's choice of server for
Domain Name Service (DNS), and the hierarchy of servers from which it Domain Name Service (DNS), and the hierarchy of servers from which it
obtains resolution results, could impact the authenticity of address obtains resolution results, could impact the authenticity of address
mappings; DNSSEC ([RFC4033]) is one way to improve authenticity. mappings; DNS Security Extensions (DNSSEC) ([RFC4033]) is one way to
improve authenticity.
Furthermore, after an IP address is obtained, establishing authority Furthermore, after an IP address is obtained, establishing authority
for an "http" URI is vulnerable to attacks on Internet Protocol for an "http" URI is vulnerable to attacks on Internet Protocol
routing. routing.
The "https" scheme (Section 2.7.2) is intended to prevent (or at The "https" scheme (Section 2.7.2) is intended to prevent (or at
least reveal) many of these potential attacks on establishing least reveal) many of these potential attacks on establishing
authority, provided that the negotiated TLS connection is secured and authority, provided that the negotiated TLS connection is secured and
the client properly verifies that the communicating server's identity the client properly verifies that the communicating server's identity
matches the target URI's authority component (see [RFC2818]). matches the target URI's authority component (see [RFC2818]).
Correctly implementing such verification can be difficult (see Correctly implementing such verification can be difficult (see
[Georgiev]). [Georgiev]).
9.2. Risks of Intermediaries 9.2. Risks of Intermediaries
By their very nature, HTTP intermediaries are men-in-the-middle, and By their very nature, HTTP intermediaries are men in the middle and,
thus represent an opportunity for man-in-the-middle attacks. thus, represent an opportunity for man-in-the-middle attacks.
Compromise of the systems on which the intermediaries run can result Compromise of the systems on which the intermediaries run can result
in serious security and privacy problems. Intermediaries might have in serious security and privacy problems. Intermediaries might have
access to security-related information, personal information about access to security-related information, personal information about
individual users and organizations, and proprietary information individual users and organizations, and proprietary information
belonging to users and content providers. A compromised belonging to users and content providers. A compromised
intermediary, or an intermediary implemented or configured without intermediary, or an intermediary implemented or configured without
regard to security and privacy considerations, might be used in the regard to security and privacy considerations, might be used in the
commission of a wide range of potential attacks. commission of a wide range of potential attacks.
Intermediaries that contain a shared cache are especially vulnerable Intermediaries that contain a shared cache are especially vulnerable
skipping to change at page 68, line 29 skipping to change at page 68, line 29
A server can reject a message that has a request-target that is too A server can reject a message that has a request-target that is too
long (Section 6.5.12 of [RFC7231]) or a request payload that is too long (Section 6.5.12 of [RFC7231]) or a request payload that is too
large (Section 6.5.11 of [RFC7231]). Additional status codes related large (Section 6.5.11 of [RFC7231]). Additional status codes related
to capacity limits have been defined by extensions to HTTP [RFC6585]. to capacity limits have been defined by extensions to HTTP [RFC6585].
Recipients ought to carefully limit the extent to which they process Recipients ought to carefully limit the extent to which they process
other protocol elements, including (but not limited to) request other protocol elements, including (but not limited to) request
methods, response status phrases, header field-names, numeric values, methods, response status phrases, header field-names, numeric values,
and body chunks. Failure to limit such processing can result in and body chunks. Failure to limit such processing can result in
buffer overflows, arithmetic overflows, or increased vulnerability to buffer overflows, arithmetic overflows, or increased vulnerability to
denial of service attacks. denial-of-service attacks.
9.4. Response Splitting 9.4. Response Splitting
Response splitting (a.k.a, CRLF injection) is a common technique, Response splitting (a.k.a, CRLF injection) is a common technique,
used in various attacks on Web usage, that exploits the line-based used in various attacks on Web usage, that exploits the line-based
nature of HTTP message framing and the ordered association of nature of HTTP message framing and the ordered association of
requests to responses on persistent connections [Klein]. This requests to responses on persistent connections [Klein]. This
technique can be particularly damaging when the requests pass through technique can be particularly damaging when the requests pass through
a shared cache. a shared cache.
skipping to change at page 70, line 9 skipping to change at page 70, line 9
access mechanism has resulted in its increasing use within access mechanism has resulted in its increasing use within
environments where verification of message integrity is crucial. environments where verification of message integrity is crucial.
User agents are encouraged to implement configurable means for User agents are encouraged to implement configurable means for
detecting and reporting failures of message integrity such that those detecting and reporting failures of message integrity such that those
means can be enabled within environments for which integrity is means can be enabled within environments for which integrity is
necessary. For example, a browser being used to view medical history necessary. For example, a browser being used to view medical history
or drug interaction information needs to indicate to the user when or drug interaction information needs to indicate to the user when
such information is detected by the protocol to be incomplete, such information is detected by the protocol to be incomplete,
expired, or corrupted during transfer. Such mechanisms might be expired, or corrupted during transfer. Such mechanisms might be
selectively enabled via user agent extensions or the presence of selectively enabled via user-agent extensions or the presence of
message integrity metadata in a response. At a minimum, user agents message integrity metadata in a response. At a minimum, user agents
ought to provide some indication that allows a user to distinguish ought to provide some indication that allows a user to distinguish
between a complete and incomplete response message (Section 3.4) when between a complete and incomplete response message (Section 3.4) when
such verification is desired. such verification is desired.
9.7. Message Confidentiality 9.7. Message Confidentiality
HTTP relies on underlying transport protocols to provide message HTTP relies on underlying transport protocols to provide message
confidentiality when that is desired. HTTP has been specifically confidentiality when that is desired. HTTP has been specifically
designed to be independent of the transport protocol, such that it designed to be independent of the transport protocol, such that it
skipping to change at page 70, line 39 skipping to change at page 70, line 39
A server is in the position to save personal data about a user's A server is in the position to save personal data about a user's
requests over time, which might identify their reading patterns or requests over time, which might identify their reading patterns or
subjects of interest. In particular, log information gathered at an subjects of interest. In particular, log information gathered at an
intermediary often contains a history of user agent interaction, intermediary often contains a history of user agent interaction,
across a multitude of sites, that can be traced to individual users. across a multitude of sites, that can be traced to individual users.
HTTP log information is confidential in nature; its handling is often HTTP log information is confidential in nature; its handling is often
constrained by laws and regulations. Log information needs to be constrained by laws and regulations. Log information needs to be
securely stored and appropriate guidelines followed for its analysis. securely stored and appropriate guidelines followed for its analysis.
Anonymization of personal information within individual entries Anonymization of personal information within individual entries
helps, but is generally not sufficient to prevent real log traces helps, but it is generally not sufficient to prevent real log traces
from being re-identified based on correlation with other access from being re-identified based on correlation with other access
characteristics. As such, access traces that are keyed to a specific characteristics. As such, access traces that are keyed to a specific
client are unsafe to publish even if the key is pseudonymous. client are unsafe to publish even if the key is pseudonymous.
To minimize the risk of theft or accidental publication, log To minimize the risk of theft or accidental publication, log
information ought to be purged of personally identifiable information ought to be purged of personally identifiable
information, including user identifiers, IP addresses, and user- information, including user identifiers, IP addresses, and user-
provided query parameters, as soon as that information is no longer provided query parameters, as soon as that information is no longer
necessary to support operational needs for security, auditing, or necessary to support operational needs for security, auditing, or
fraud control. fraud control.
10. Acknowledgments 10. Acknowledgments
This edition of HTTP/1.1 builds on the many contributions that went This edition of HTTP/1.1 builds on the many contributions that went
into RFC 1945, RFC 2068, RFC 2145, and RFC 2616, including into RFC 1945, RFC 2068, RFC 2145, and RFC 2616, including
substantial contributions made by the previous authors, editors, and substantial contributions made by the previous authors, editors, and
working group chairs: Tim Berners-Lee, Ari Luotonen, Roy T. Fielding, Working Group Chairs: Tim Berners-Lee, Ari Luotonen, Roy T. Fielding,
Henrik Frystyk Nielsen, Jim Gettys, Jeffrey C. Mogul, Larry Masinter, Henrik Frystyk Nielsen, Jim Gettys, Jeffrey C. Mogul, Larry Masinter,
and Paul J. Leach. Mark Nottingham oversaw this effort as working and Paul J. Leach. Mark Nottingham oversaw this effort as Working
group chair. Group Chair.
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, Adrian Cole, Adam Barth, Adam Roach, Addison Phillips, Adrian Chadd, Adrian Cole,
Adrien W. de Croy, Alan Ford, Alan Ruttenberg, Albert Lunde, Alek Adrien W. de Croy, Alan Ford, Alan Ruttenberg, Albert Lunde, Alek
Storm, Alex Rousskov, Alexandre Morgaut, Alexey Melnikov, Alisha Storm, Alex Rousskov, Alexandre Morgaut, Alexey Melnikov, Alisha
Smith, Amichai Rothman, Amit Klein, Amos Jeffries, Andreas Maier, Smith, Amichai Rothman, Amit Klein, Amos Jeffries, Andreas Maier,
Andreas Petersson, Andrei Popov, Anil Sharma, Anne van Kesteren, Andreas Petersson, Andrei Popov, Anil Sharma, Anne van Kesteren,
skipping to change at page 72, line 50 skipping to change at page 72, line 50
Yuchung Cheng, Yutaka Oiwa, Yves Lafon (long-time member of the Yuchung Cheng, Yutaka Oiwa, Yves Lafon (long-time member of the
editor team), Zed A. Shaw, and Zhong Yu. 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.
11. References 11. References
11.1. Normative References 11.1. Normative References
[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 73, line 28 skipping to change at page 73, line 25
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
"Uniform Resource Identifier (URI): Generic Syntax", "Uniform Resource Identifier (URI): Generic Syntax",
STD 66, RFC 3986, January 2005. STD 66, RFC 3986, January 2005.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, RFC 5234, Syntax Specifications: ABNF", STD 68, RFC 5234,
January 2008. January 2008.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext [RFC7231] 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-latest (work in RFC 7231, May 2014.
progress), May 2014.
[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext [RFC7232] 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-latest (work in RFC 7232, May 2014.
progress), May 2014.
[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., [RFC7233] 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-latest (work in Requests", RFC 7233, May 2014.
progress), May 2014.
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [RFC7234] 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-latest (work in progress), RFC 7234, May 2014.
May 2014.
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext [RFC7235] 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-latest (work in progress), RFC 7235, May 2014.
May 2014.
[RFC793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[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 [Welch] Welch, T., "A Technique for High-Performance Data
Compression", IEEE Computer 17(6), June 1984. Compression", IEEE Computer 17(6), June 1984.
11.2. Informative References 11.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,
skipping to change at page 76, line 25 skipping to change at page 76, line 22
HTTP has been in use since 1990. The first version, later referred HTTP has been in use since 1990. The first version, later referred
to as HTTP/0.9, was a simple protocol for hypertext data transfer to as HTTP/0.9, was a simple protocol for hypertext data transfer
across the Internet, using only a single request method (GET) and no across the Internet, using only a single request method (GET) and no
metadata. HTTP/1.0, as defined by [RFC1945], added a range of metadata. HTTP/1.0, as defined by [RFC1945], added a range of
request methods and MIME-like messaging, allowing for metadata to be request methods and MIME-like messaging, allowing for metadata to be
transferred and modifiers placed on the request/response semantics. transferred and modifiers placed 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
effects of hierarchical proxies, caching, the need for persistent effects of hierarchical proxies, caching, the need for persistent
connections, or name-based virtual hosts. The proliferation of connections, or name-based virtual hosts. The proliferation of
incompletely-implemented applications calling themselves "HTTP/1.0" incompletely implemented applications calling themselves "HTTP/1.0"
further necessitated a protocol version change in order for two further necessitated a protocol version change in order for two
communicating applications to determine each other's true communicating applications to determine each other's true
capabilities. capabilities.
HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent
requirements that enable reliable implementations, adding only those requirements that enable reliable implementations, adding only those
features that can either be safely ignored by an HTTP/1.0 recipient features that can either be safely ignored by an HTTP/1.0 recipient
or only sent when communicating with a party advertising conformance or only be sent when communicating with a party advertising
with HTTP/1.1. conformance with HTTP/1.1.
HTTP/1.1 has been designed to make supporting previous versions easy. HTTP/1.1 has been designed to make supporting previous versions easy.
A general-purpose HTTP/1.1 server ought to be able to understand any A general-purpose HTTP/1.1 server ought to be able to understand any
valid request in the format of HTTP/1.0, responding appropriately valid request in the format of HTTP/1.0, responding appropriately
with an HTTP/1.1 message that only uses features understood (or with an HTTP/1.1 message that only uses features understood (or
safely ignored) by HTTP/1.0 clients. Likewise, an HTTP/1.1 client safely ignored) by HTTP/1.0 clients. Likewise, an HTTP/1.1 client
can be expected to understand any valid HTTP/1.0 response. can be expected to understand any valid HTTP/1.0 response.
Since HTTP/0.9 did not support header fields in a request, there is Since HTTP/0.9 did not support header fields in a request, there is
no mechanism for it to support name-based virtual hosts (selection of no mechanism for it to support name-based virtual hosts (selection of
skipping to change at page 77, line 10 skipping to change at page 77, line 5
implements name-based virtual hosts ought to disable support for implements name-based virtual hosts ought to disable support for
HTTP/0.9. Most requests that appear to be HTTP/0.9 are, in fact, HTTP/0.9. Most requests that appear to be HTTP/0.9 are, in fact,
badly constructed HTTP/1.x requests caused by a client failing to badly constructed HTTP/1.x requests caused by a client failing to
properly encode the request-target. properly encode the request-target.
A.1. Changes from HTTP/1.0 A.1. Changes from HTTP/1.0
This section summarizes major differences between versions HTTP/1.0 This section summarizes major differences between versions HTTP/1.0
and HTTP/1.1. and HTTP/1.1.
A.1.1. Multi-homed Web Servers A.1.1. Multihomed Web Servers
The requirements that clients and servers support the Host header The requirements that clients and servers support the Host header
field (Section 5.4), report an error if it is missing from an field (Section 5.4), report an error if it is missing from an
HTTP/1.1 request, and accept absolute URIs (Section 5.3) are among HTTP/1.1 request, and accept absolute URIs (Section 5.3) are among
the most important changes defined by HTTP/1.1. the most important changes defined by HTTP/1.1.
Older HTTP/1.0 clients assumed a one-to-one relationship of IP Older HTTP/1.0 clients assumed a one-to-one relationship of IP
addresses and servers; there was no other established mechanism for addresses and servers; there was no other established mechanism for
distinguishing the intended server of a request than the IP address distinguishing the intended server of a request than the IP address
to which that request was directed. The Host header field was to which that request was directed. The Host header field was
skipping to change at page 78, line 20 skipping to change at page 78, line 14
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).
The HTTP-version ABNF production has been clarified to be case- The HTTP-version ABNF production has been clarified to be case
sensitive. Additionally, version numbers has been restricted to sensitive. Additionally, version numbers have been restricted to
single digits, due to the fact that implementations are known to single digits, due to the fact that implementations are known to
handle multi-digit version numbers incorrectly. (Section 2.6) handle multi-digit version numbers incorrectly (Section 2.6).
Userinfo (i.e., username and password) are now disallowed in HTTP and Userinfo (i.e., username and password) are now disallowed in HTTP and
HTTPS URIs, because of security issues related to their transmission HTTPS URIs, because of security issues related to their transmission
on the wire. (Section 2.7.1) on the wire (Section 2.7.1).
The HTTPS URI scheme is now defined by this specification; The HTTPS URI scheme is now defined by this specification;
previously, it was done in Section 2.4 of [RFC2818]. Furthermore, it previously, it was defined in Section 2.4 of [RFC2818]. Furthermore,
implies end-to-end security. (Section 2.7.2) it implies end-to-end security (Section 2.7.2).
HTTP messages can be (and often are) buffered by implementations; HTTP messages can be (and often are) buffered by implementations;
despite it sometimes being available as a stream, HTTP is despite it sometimes being available as a stream, HTTP is
fundamentally a message-oriented protocol. Minimum supported sizes fundamentally a message-oriented protocol. Minimum supported sizes
for various protocol elements have been suggested, to improve for various protocol elements have been suggested, to improve
interoperability. (Section 3) interoperability (Section 3).
Invalid whitespace around field-names is now required to be rejected, Invalid whitespace around field-names is now required to be rejected,
because accepting it represents a security vulnerability. The ABNF because accepting it represents a security vulnerability. The ABNF
productions defining header fields now only list the field value. productions defining header fields now only list the field value
(Section 3.2) (Section 3.2).
Rules about implicit linear whitespace between certain grammar Rules about implicit linear whitespace between certain grammar
productions have been removed; now whitespace is only allowed where productions have been removed; now whitespace is only allowed where
specifically defined in the ABNF. (Section 3.2.3) specifically defined in the ABNF (Section 3.2.3).
Header fields that span multiple lines ("line folding") are Header fields that span multiple lines ("line folding") are
deprecated. (Section 3.2.4) deprecated (Section 3.2.4).
The NUL octet is no longer allowed in comment and quoted-string text, The NUL octet is no longer allowed in comment and quoted-string text,
and handling of backslash-escaping in them has been clarified. The and handling of backslash-escaping in them has been clarified. The
quoted-pair rule no longer allows escaping control characters other quoted-pair rule no longer allows escaping control characters other
than HTAB. Non-ASCII content in header fields and the reason phrase than HTAB. Non-US-ASCII content in header fields and the reason
has been obsoleted and made opaque (the TEXT rule was removed). phrase has been obsoleted and made opaque (the TEXT rule was removed)
(Section 3.2.6) (Section 3.2.6).
Bogus "Content-Length" header fields are now required to be handled Bogus "Content-Length" header fields are now required to be handled
as errors by recipients. (Section 3.3.2) as errors by recipients (Section 3.3.2).
The algorithm for determining the message body length has been The algorithm for determining the message body length has been
clarified to indicate all of the special cases (e.g., driven by clarified to indicate all of the special cases (e.g., driven by
methods or status codes) that affect it, and that new protocol methods or status codes) that affect it, and that new protocol
elements cannot define such special cases. CONNECT is a new, special elements cannot define such special cases. CONNECT is a new, special
case in determining message body length. "multipart/byteranges" is no case in determining message body length. "multipart/byteranges" is no
longer a way of determining message body length detection. longer a way of determining message body length detection
(Section 3.3.3) (Section 3.3.3).
The "identity" transfer coding token has been removed. (Sections 3.3 The "identity" transfer coding token has been removed (Sections 3.3
and 4) and 4).
Chunk length does not include the count of the octets in the chunk Chunk length does not include the count of the octets in the chunk
header and trailer. Line folding in chunk extensions is disallowed. header and trailer. Line folding in chunk extensions is disallowed
(Section 4.1) (Section 4.1).
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).
The segment + query components of RFC 3986 have been used to define The segment + query components of RFC 3986 have been used to define
the request-target, instead of abs_path from RFC 1808. The asterisk- the request-target, instead of abs_path from RFC 1808. The asterisk-
form of the request-target is only allowed with the OPTIONS method. form of the request-target is only allowed with the OPTIONS method
(Section 5.3) (Section 5.3).
The term "Effective Request URI" has been introduced. (Section 5.5) The term "Effective Request URI" has been introduced (Section 5.5).
Gateways do not need to generate Via header fields anymore. Gateways do not need to generate Via header fields anymore
(Section 5.7.1) (Section 5.7.1).
Exactly when "close" connection options have to be sent has been Exactly when "close" connection options have to be sent has been
clarified. Also, "hop-by-hop" header fields are required to appear clarified. Also, "hop-by-hop" header fields are required to appear
in the Connection header field; just because they're defined as hop- in the Connection header field; just because they're defined as hop-
by-hop in this specification doesn't exempt them. (Section 6.1) by-hop in this specification doesn't exempt them (Section 6.1).
The limit of two connections per server has been removed. An The limit of two connections per server has been removed. An
idempotent sequence of requests is no longer required to be retried. idempotent sequence of requests is no longer required to be retried.
The requirement to retry requests under certain circumstances when The requirement to retry requests under certain circumstances when
the server prematurely closes the connection has been removed. Also, the server prematurely closes the connection has been removed. Also,
some extraneous requirements about when servers are allowed to close some extraneous requirements about when servers are allowed to close
connections prematurely have been removed. (Section 6.3) connections prematurely have been removed (Section 6.3).
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]). Furthermore, other than 101 (this was incorporated from [RFC2817]). Furthermore,
the ordering in the field value is now significant. (Section 6.7) the ordering in the field value is now significant (Section 6.7).
Empty list elements in list productions (e.g., a list header field Empty list elements in list productions (e.g., a list header field
containing ", ,") have been deprecated. (Section 7) containing ", ,") have been deprecated (Section 7).
Registration of Transfer Codings now requires IETF Review Registration of Transfer Codings now requires IETF Review
(Section 8.4) (Section 8.4).
This specification now defines the Upgrade Token Registry, previously This specification now defines the "HTTP Upgrade Tokens" registry,
defined in Section 7.2 of [RFC2817]. (Section 8.6) previously defined in Section 7.2 of [RFC2817] (Section 8.6).
The expectation to support HTTP/0.9 requests has been removed. The expectation to support HTTP/0.9 requests has been removed
(Appendix A) (Appendix A).
Issues with the Keep-Alive and Proxy-Connection header fields in Issues with the Keep-Alive and Proxy-Connection header fields in
requests are pointed out, with use of the latter being discouraged requests are pointed out, with use of the latter being discouraged
altogether. (Appendix A.1.2) altogether (Appendix A.1.2).
Appendix B. Collected ABNF Appendix B. Collected ABNF
BWS = OWS BWS = OWS
Connection = *( "," OWS ) connection-option *( OWS "," [ OWS Connection = *( "," OWS ) connection-option *( OWS "," [ OWS
connection-option ] ) connection-option ] )
Content-Length = 1*DIGIT Content-Length = 1*DIGIT
HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body
skipping to change at page 82, line 45 skipping to change at page 82, line 39
"^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA
token = 1*tchar token = 1*tchar
trailer-part = *( header-field CRLF ) trailer-part = *( header-field CRLF )
transfer-coding = "chunked" / "compress" / "deflate" / "gzip" / transfer-coding = "chunked" / "compress" / "deflate" / "gzip" /
transfer-extension transfer-extension
transfer-extension = token *( OWS ";" OWS transfer-parameter ) transfer-extension = token *( OWS ";" OWS transfer-parameter )
transfer-parameter = token BWS "=" BWS ( token / quoted-string ) transfer-parameter = token BWS "=" BWS ( token / quoted-string )
uri-host = <host, defined in [RFC3986], Section 3.2.2> uri-host = <host, defined in [RFC3986], Section 3.2.2>
Appendix C. Change Log (to be removed by RFC Editor before publication)
C.1. Since RFC 2616
Changes up to the IETF Last Call draft are summarized in <http://
trac.tools.ietf.org/html/
draft-ietf-httpbis-p1-messaging-24#appendix-C>.
C.2. Since draft-ietf-httpbis-p1-messaging-24
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/502>: "APPSDIR
review of draft-ietf-httpbis-p1-messaging-24"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/507>: "integer value
parsing"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/517>: "move IANA
registrations to correct draft"
C.3. Since draft-ietf-httpbis-p1-messaging-25
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/526>: "check media
type registration templates"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/528>: "Redundant
rule quoted-str-nf"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/531>: "IESG ballot
on draft-ietf-httpbis-p1-messaging-25"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/538>: "add
'stateless' to Abstract"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/540>: "clarify ABNF
layering"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/541>: "use of 'word'
ABNF production"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/542>: "improve
introduction of list rule"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/544>: "moving 2616/
2068/2145 to historic"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/549>: "augment
security considerations with pointers to current research"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/551>:
"intermediaries handling trailers"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/552>: "allow privacy
proxies to be conformant"
C.4. Since draft-ietf-httpbis-p1-messaging-26
None yet.
Index Index
A A
absolute-form (of request-target) 42 absolute-form (of request-target) 42
accelerator 10 accelerator 10
application/http Media Type 62 application/http Media Type 62
asterisk-form (of request-target) 42 asterisk-form (of request-target) 42
authoritative response 66 authoritative response 66
authority-form (of request-target) 42 authority-form (of request-target) 42
skipping to change at page 84, line 40 skipping to change at page 83, line 20
client 7 client 7
close 50, 55 close 50, 55
compress (Coding Format) 38 compress (Coding Format) 38
connection 7 connection 7
Connection header field 50, 55 Connection header field 50, 55
Content-Length header field 30 Content-Length header field 30
D D
deflate (Coding Format) 38 deflate (Coding Format) 38
Delimiters 26 Delimiters 26
downstream 9 downstream 10
E E
effective request URI 44 effective request URI 44
G G
gateway 10 gateway 10
Grammar Grammar
absolute-form 41-42 absolute-form 41-42
absolute-path 16 absolute-path 16
absolute-URI 16 absolute-URI 16
skipping to change at page 85, line 34 skipping to change at page 84, line 14
field-content 22 field-content 22
field-name 22, 39 field-name 22, 39
field-value 22 field-value 22
field-vchar 22 field-vchar 22
fragment 16 fragment 16
header-field 22, 36 header-field 22, 36
HEXDIG 6 HEXDIG 6
Host 43 Host 43
HTAB 6 HTAB 6
HTTP-message 19 HTTP-message 19
HTTP-name 13 HTTP-name 14
http-URI 16 http-URI 16
HTTP-version 13 HTTP-version 14
https-URI 18 https-URI 18
last-chunk 35 last-chunk 35
LF 6 LF 6
message-body 27 message-body 27
method 21 method 21
obs-fold 22 obs-fold 22
obs-text 27 obs-text 27
OCTET 6 OCTET 6
origin-form 41 origin-form 41
OWS 24 OWS 24
skipping to change at page 86, line 48 skipping to change at page 85, line 28
H H
header field 19 header field 19
header section 19 header section 19
headers 19 headers 19
Host header field 43 Host header field 43
http URI scheme 16 http URI scheme 16
https URI scheme 18 https URI scheme 18
I I
inbound 9 inbound 10
interception proxy 11 interception proxy 11
intermediary 9 intermediary 9
M M
Media Type Media Type
application/http 62 application/http 62
message/http 61 message/http 61
message 7 message 7
message/http Media Type 61 message/http Media Type 61
method 21 method 21
N N
non-transforming proxy 48 non-transforming proxy 48
O O
origin server 7 origin server 7
origin-form (of request-target) 41 origin-form (of request-target) 41
outbound 9 outbound 10
P P
phishing 66 phishing 66
proxy 10 proxy 10
R R
recipient 7 recipient 7
request 7 request 7
request-target 21 request-target 21
resource 16 resource 16
skipping to change at page 87, line 50 skipping to change at page 86, line 30
target URI 40 target URI 40
TE header field 38 TE header field 38
Trailer header field 39 Trailer header field 39
Transfer-Encoding header field 28 Transfer-Encoding header field 28
transforming proxy 48 transforming proxy 48
transparent proxy 11 transparent proxy 11
tunnel 10 tunnel 10
U U
Upgrade header field 56 Upgrade header field 56
upstream 9 upstream 10
URI scheme URI scheme
http 16 http 16
https 18 https 18
user agent 7 user agent 7
V V
Via header field 47 Via header field 47
Authors' Addresses Authors' Addresses
 End of changes. 157 change blocks. 
322 lines changed or deleted 237 lines changed or added

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