rfc7230.txt   draft-ietf-httpbis-messaging-00.txt 
Internet Engineering Task Force (IETF) R. Fielding, Ed. HTTP Working Group R. Fielding, Ed.
Request for Comments: 7230 Adobe Internet-Draft Adobe
Obsoletes: 2145, 2616 J. Reschke, Ed. Obsoletes: 7230 (if approved) M. Nottingham, Ed.
Updates: 2817, 2818 greenbytes Intended status: Standards Track Fastly
Category: Standards Track June 2014 Expires: October 5, 2018 J. Reschke, Ed.
ISSN: 2070-1721 greenbytes
April 3, 2018
Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
draft-ietf-httpbis-messaging-00
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.
This document obsoletes RFC 7230.
Editorial Note
This note is to be removed before publishing as an RFC.
Discussion of this draft takes place on the HTTP working group
mailing list (ietf-http-wg@w3.org), which is archived at
<http://lists.w3.org/Archives/Public/ietf-http-wg/>.
Working Group information can be found at <http://httpwg.github.io/>;
source code and issues list for this draft can be found at
<https://github.com/httpwg/http-core>.
The changes in this draft are summarized in Appendix C.1.
Status of This Memo Status of This Memo
This is an Internet Standards Track document. This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
This document is a product of the Internet Engineering Task Force Internet-Drafts are working documents of the Internet Engineering
(IETF). It represents the consensus of the IETF community. It has Task Force (IETF). Note that other groups may also distribute
received public review and has been approved for publication by the working documents as Internet-Drafts. The list of current Internet-
Internet Engineering Steering Group (IESG). Further information on Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata, Internet-Drafts are draft documents valid for a maximum of six months
and how to provide feedback on it may be obtained at and may be updated, replaced, or obsoleted by other documents at any
http://www.rfc-editor.org/info/rfc7230. time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 5, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2018 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 (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
skipping to change at page 2, line 34 skipping to change at page 2, line 41
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
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. Requirements 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 ....................................17 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 . . . . . . . . . . . . . . . . . . . . 24
3.2.5. Field Limits .......................................26 3.2.5. Field Limits . . . . . . . . . . . . . . . . . . . . 26
3.2.6. Field Value Components .............................27 3.2.6. Field Value Components . . . . . . . . . . . . . . . 26
3.3. Message Body ..............................................28 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 . . . . . . . . . . . . . . . . . . . 29
3.3.3. Message Body Length ................................32 3.3.3. Message Body Length . . . . . . . . . . . . . . . . . 31
3.4. Handling Incomplete Messages ..............................34 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 . . . . . . . . . . . . . . . . . . . . . . 34
4.1. Chunked Transfer Coding ...................................36 4.1. Chunked Transfer Coding . . . . . . . . . . . . . . . . . 35
4.1.1. Chunk Extensions ...................................36 4.1.1. Chunk Extensions . . . . . . . . . . . . . . . . . . 36
4.1.2. Chunked Trailer Part ...............................37 4.1.2. Chunked Trailer Part . . . . . . . . . . . . . . . . 36
4.1.3. Decoding Chunked ...................................38 4.1.3. Decoding Chunked . . . . . . . . . . . . . . . . . . 37
4.2. Compression Codings .......................................38 4.2. Compression Codings . . . . . . . . . . . . . . . . . . . 37
4.2.1. Compress Coding ....................................38 4.2.1. Compress Coding . . . . . . . . . . . . . . . . . . . 38
4.2.2. Deflate Coding .....................................38 4.2.2. Deflate Coding . . . . . . . . . . . . . . . . . . . 38
4.2.3. Gzip Coding ........................................39 4.2.3. Gzip Coding . . . . . . . . . . . . . . . . . . . . . 38
4.3. TE ........................................................39 4.3. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.4. Trailer ...................................................40 4.4. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 39
5. Message Routing ................................................40 5. Message Routing . . . . . . . . . . . . . . . . . . . . . . . 39
5.1. Identifying a Target Resource .............................40 5.1. Identifying a Target Resource . . . . . . . . . . . . . . 40
5.2. Connecting Inbound ........................................41 5.2. Connecting Inbound . . . . . . . . . . . . . . . . . . . 40
5.3. Request Target ............................................41 5.3. Request Target . . . . . . . . . . . . . . . . . . . . . 41
5.3.1. origin-form ........................................42 5.3.1. origin-form . . . . . . . . . . . . . . . . . . . . . 41
5.3.2. absolute-form ......................................42 5.3.2. absolute-form . . . . . . . . . . . . . . . . . . . . 41
5.3.3. authority-form .....................................43 5.3.3. authority-form . . . . . . . . . . . . . . . . . . . 42
5.3.4. asterisk-form ......................................43 5.3.4. asterisk-form . . . . . . . . . . . . . . . . . . . . 42
5.4. Host ......................................................44 5.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.5. Effective Request URI .....................................45 5.5. Effective Request URI . . . . . . . . . . . . . . . . . . 44
5.6. Associating a Response to a Request .......................46 5.6. Associating a Response to a Request . . . . . . . . . . . 46
5.7. Message Forwarding ........................................47 5.7. Message Forwarding . . . . . . . . . . . . . . . . . . . 46
5.7.1. Via ................................................47 5.7.1. Via . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.7.2. Transformations ....................................49 5.7.2. Transformations . . . . . . . . . . . . . . . . . . . 48
6. Connection Management ..........................................50 6. Connection Management . . . . . . . . . . . . . . . . . . . . 49
6.1. Connection ................................................51 6.1. Connection . . . . . . . . . . . . . . . . . . . . . . . 50
6.2. Establishment .............................................52 6.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 51
6.3. Persistence ...............................................52 6.3. Persistence . . . . . . . . . . . . . . . . . . . . . . . 51
6.3.1. Retrying Requests ..................................53 6.3.1. Retrying Requests . . . . . . . . . . . . . . . . . . 52
6.3.2. Pipelining .........................................54 6.3.2. Pipelining . . . . . . . . . . . . . . . . . . . . . 53
6.4. Concurrency ...............................................55 6.4. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 54
6.5. Failures and Timeouts .....................................55 6.5. Failures and Timeouts . . . . . . . . . . . . . . . . . . 54
6.6. Tear-down .................................................56 6.6. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 55
6.7. Upgrade ...................................................57 6.7. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 56
7. ABNF List Extension: #rule .....................................59 7. ABNF List Extension: #rule . . . . . . . . . . . . . . . . . 58
8. IANA Considerations ............................................61 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59
8.1. Header Field Registration .................................61 8.1. Header Field Registration . . . . . . . . . . . . . . . . 59
8.2. URI Scheme Registration ...................................62 8.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 60
8.3. Internet Media Type Registration ..........................62 8.3. Internet Media Type Registration . . . . . . . . . . . . 60
8.3.1. Internet Media Type message/http ...................62 8.3.1. Internet Media Type message/http . . . . . . . . . . 61
8.3.2. Internet Media Type application/http ...............63 8.3.2. Internet Media Type application/http . . . . . . . . 62
8.4. Transfer Coding Registry ..................................64 8.4. Transfer Coding Registry . . . . . . . . . . . . . . . . 63
8.4.1. Procedure ..........................................65 8.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 63
8.4.2. Registration .......................................65 8.4.2. Registration . . . . . . . . . . . . . . . . . . . . 64
8.5. Content Coding Registration ...............................66 8.5. Content Coding Registration . . . . . . . . . . . . . . . 64
8.6. Upgrade Token Registry ....................................66 8.6. Upgrade Token Registry . . . . . . . . . . . . . . . . . 65
8.6.1. Procedure ..........................................66 8.6.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 65
8.6.2. Upgrade Token Registration .........................67 8.6.2. Upgrade Token Registration . . . . . . . . . . . . . 65
9. Security Considerations ........................................67 9. Security Considerations . . . . . . . . . . . . . . . . . . . 66
9.1. Establishing Authority ....................................67 9.1. Establishing Authority . . . . . . . . . . . . . . . . . 66
9.2. Risks of Intermediaries ...................................68 9.2. Risks of Intermediaries . . . . . . . . . . . . . . . . . 67
9.3. Attacks via Protocol Element Length .......................69 9.3. Attacks via Protocol Element Length . . . . . . . . . . . 67
9.4. Response Splitting ........................................69 9.4. Response Splitting . . . . . . . . . . . . . . . . . . . 68
9.5. Request Smuggling .........................................70 9.5. Request Smuggling . . . . . . . . . . . . . . . . . . . . 69
9.6. Message Integrity .........................................70 9.6. Message Integrity . . . . . . . . . . . . . . . . . . . . 69
9.7. Message Confidentiality ...................................71 9.7. Message Confidentiality . . . . . . . . . . . . . . . . . 70
9.8. Privacy of Server Log Information .........................71 9.8. Privacy of Server Log Information . . . . . . . . . . . . 70
10. Acknowledgments ...............................................72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 70
11. References ....................................................74 10.1. Normative References . . . . . . . . . . . . . . . . . . 70
11.1. Normative References .....................................74 10.2. Informative References . . . . . . . . . . . . . . . . . 72
11.2. Informative References ...................................75 Appendix A. HTTP Version History . . . . . . . . . . . . . . . . 75
Appendix A. HTTP Version History ..................................78 A.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 75
A.1. Changes from HTTP/1.0 ....................................78 A.1.1. Multihomed Web Servers . . . . . . . . . . . . . . . 75
A.1.1. Multihomed Web Servers ............................78 A.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . 76
A.1.2. Keep-Alive Connections ............................79 A.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 76
A.1.3. Introduction of Transfer-Encoding .................79 A.2. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 77
A.2. Changes from RFC 2616 ....................................80 Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 77
Appendix B. Collected ABNF ........................................82 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 79
Index .............................................................85 C.1. Since RFC 7230 . . . . . . . . . . . . . . . . . . . . . 79
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 84
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 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:
1. "Message Syntax and Routing" (this document) 1. "Message Syntax and Routing" (this document)
2. "Semantics and Content" [RFC7231] 2. "Semantics and Content" [SEMNTCS]
3. "Conditional Requests" [RFC7232] 3. "Conditional Requests" [CONDTNL]
4. "Range Requests" [RFC7233] 4. "Range Requests" [RANGERQ]
5. "Caching" [RFC7234] 5. "Caching" [CACHING]
6. "Authentication" [RFC7235] 6. "Authentication" [AUTHFRM]
This HTTP/1.1 specification obsoletes RFC 2616 and RFC 2145 (on HTTP This specification obsoletes RFC 7230, with the changes being
versioning). This specification also updates the use of CONNECT to summarized in Appendix A.2.
establish a tunnel, previously defined in RFC 2817, and 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 7, line 31 skipping to change at page 7, line 31
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.
HTTP relies upon the Uniform Resource Identifier (URI) standard HTTP relies upon the Uniform Resource Identifier (URI) standard
[RFC3986] to indicate the target resource (Section 5.1) and [RFC3986] to indicate the target resource (Section 5.1) and
relationships between resources. Messages are passed in a format relationships between resources. Messages are passed in a format
similar to that used by Internet mail [RFC5322] and the Multipurpose similar to that used by Internet mail [RFC5322] and the Multipurpose
Internet Mail Extensions (MIME) [RFC2045] (see Appendix A of Internet Mail Extensions (MIME) [RFC2045] (see Appendix A of
[RFC7231] for the differences between HTTP and MIME messages). [SEMNTCS] for the differences between HTTP and MIME messages).
Most HTTP communication consists of a retrieval request (GET) for a Most HTTP communication consists of a retrieval request (GET) for a
representation of some resource identified by a URI. In the simplest representation of some resource identified by a URI. In the simplest
case, this might be accomplished via a single bidirectional case, this might be accomplished via a single bidirectional
connection (===) between the user agent (UA) and the origin connection (===) between the user agent (UA) and the origin server
server (O). (O).
request > request >
UA ======================================= O UA ======================================= O
< response < response
A client sends an HTTP request to a server in the form of a request A client sends an HTTP request to a server in the form of a request
message, beginning with a request-line that includes a method, URI, message, beginning with a request-line that includes a method, URI,
and protocol version (Section 3.1.1), followed by header fields and protocol version (Section 3.1.1), followed by header fields
containing request modifiers, client information, and representation containing request modifiers, client information, and representation
metadata (Section 3.2), an empty line to indicate the end of the metadata (Section 3.2), an empty line to indicate the end of the
skipping to change at page 8, line 18 skipping to change at page 8, line 15
phrase (Section 3.1.2), possibly followed by header fields containing phrase (Section 3.1.2), possibly followed by header fields containing
server information, resource metadata, and representation metadata server information, resource metadata, and representation metadata
(Section 3.2), an empty line to indicate the end of the header (Section 3.2), an empty line to indicate the end of the header
section, and finally a message body containing the payload body (if section, and finally a message body containing the payload body (if
any, Section 3.3). any, Section 3.3).
A connection might be used for multiple request/response exchanges, A connection might be used for multiple request/response exchanges,
as defined in Section 6.3. as defined in Section 6.3.
The following example illustrates a typical message exchange for a The following example illustrates a typical message exchange for a
GET request (Section 4.3.1 of [RFC7231]) on the URI GET request (Section 4.3.1 of [SEMNTCS]) on the URI
"http://www.example.com/hello.txt": "http://www.example.com/hello.txt":
Client request: Client request:
GET /hello.txt HTTP/1.1 GET /hello.txt HTTP/1.1
User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
Host: www.example.com Host: www.example.com
Accept-Language: en, mi Accept-Language: en, mi
Server response: Server response:
skipping to change at page 12, line 11 skipping to change at page 12, line 7
> > > >
UA =========== A =========== B - - - - - - C - - - - - - O UA =========== A =========== B - - - - - - C - - - - - - O
< < < <
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]. [CACHING].
There is a wide variety of architectures and configurations of caches There is a wide variety of architectures and configurations of caches
deployed across the World Wide Web and inside large organizations. deployed across the World Wide Web and inside large organizations.
These include national hierarchies of proxy caches to save These include national hierarchies of proxy caches to 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
skipping to change at page 13, line 4 skipping to change at page 12, line 48
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 that 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 forwarding a message might parse a header-field into generic field-
field-name and field-value components, but then forward the header name and field-value components, but then forward the header field
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.
skipping to change at page 13, line 30 skipping to change at page 13, line 27
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
extensions to this specification, unless the recipient has determined extensions to this specification, unless the recipient has determined
(through experience or configuration) that the sender incorrectly (through experience or configuration) that the sender incorrectly
implements what is implied by those semantics. For example, an implements what is implied by those semantics. For example, an
origin server might disregard the contents of a received origin server might disregard the contents of a received Accept-
Accept-Encoding header field if inspection of the User-Agent header Encoding header field if inspection of the User-Agent header field
field indicates a specific implementation version that is known to indicates a specific implementation version that is known to fail on
fail on receipt of certain content codings. receipt of certain content codings.
Unless noted otherwise, a recipient MAY attempt to recover a usable Unless noted otherwise, a recipient MAY attempt to recover a usable
protocol element from an invalid construct. HTTP does not define protocol element from an invalid construct. HTTP does not define
specific error handling mechanisms except when they have a direct specific error handling mechanisms except when they have a direct
impact on security, since different applications of the protocol impact on security, since different applications of the protocol
require different error handling strategies. For example, a Web require different error handling strategies. For example, a Web
browser might wish to transparently recover from a response where the browser might wish to transparently recover from a response where the
Location header field doesn't parse according to the ABNF, whereas a Location header field doesn't parse according to the ABNF, whereas a
systems control client might consider any form of error recovery to systems control client might consider any form of error recovery to
be dangerous. be dangerous.
skipping to change at page 14, line 50 skipping to change at page 14, line 47
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 messages. Forwarding an HTTP message without rewriting the HTTP-
HTTP-version might result in communication errors when downstream version might result in communication errors when downstream
recipients use the message sender's version to determine what recipients use the message sender's version to determine what
features are safe to use for later communication with that sender. features are safe to use for later communication with that sender.
A client SHOULD send a request version equal to the highest version A client SHOULD send a request version equal to the highest version
to which the client is conformant and whose major version is no to which the client is conformant and whose major version is no
higher than the highest version supported by the server, if this is higher than the highest version supported by the server, if this is
known. A client MUST NOT send a version to which it is not known. A client MUST NOT send a version to which it is not
conformant. conformant.
A client MAY send a lower request version if it is known that the A client MAY send a lower request version if it is known that the
skipping to change at page 16, line 12 skipping to change at page 16, line 8
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 [SEMNTCS]).
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
the path-abempty rule of RFC 3986, which allows for an empty path to the path-abempty rule of RFC 3986, which allows for an empty path to
be used in references, and path-absolute rule, which does not allow be used in references, and path-absolute rule, which does not allow
skipping to change at page 16, line 44 skipping to change at page 16, line 40
path-abempty = <path-abempty, see [RFC3986], Section 3.3> path-abempty = <path-abempty, see [RFC3986], Section 3.3>
segment = <segment, see [RFC3986], Section 3.3> segment = <segment, see [RFC3986], Section 3.3>
query = <query, see [RFC3986], Section 3.4> query = <query, see [RFC3986], Section 3.4>
fragment = <fragment, see [RFC3986], Section 3.5> fragment = <fragment, see [RFC3986], Section 3.5>
absolute-path = 1*( "/" segment ) absolute-path = 1*( "/" segment )
partial-URI = relative-part [ "?" query ] partial-URI = relative-part [ "?" query ]
Each protocol element in HTTP that allows a URI reference will Each protocol element in HTTP that allows a URI reference will
indicate in its ABNF production whether the element allows any form indicate in its ABNF production whether the element allows any form
of reference (URI-reference), only a URI in absolute form of reference (URI-reference), only a URI in absolute form (absolute-
(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 ([RFC0793]) connections on a given port.
skipping to change at page 18, line 4 skipping to change at page 17, line 45
federated namespace, based on control over the indicated host and federated namespace, based on control over the indicated host and
port, whether or not an HTTP server is present. See Section 9.1 for port, whether or not an HTTP server is present. See Section 9.1 for
security considerations related to establishing authority. security considerations related to establishing authority.
When an "http" URI is used within a context that calls for access to When an "http" URI is used within a context that calls for access to
the indicated resource, a client MAY attempt access by resolving the the indicated resource, a client MAY attempt access by resolving the
host to an IP address, establishing a TCP connection to that address host to an IP address, establishing a TCP connection to that address
on the indicated port, and sending an HTTP request message on the indicated port, and sending an HTTP request message
(Section 3) containing the URI's identifying data (Section 5) to the (Section 3) containing the URI's identifying data (Section 5) to the
server. If the server responds to that request with a non-interim server. If the server responds to that request with a non-interim
HTTP response message, as described in Section 6 of [RFC7231], then HTTP response message, as described in Section 6 of [SEMNTCS], then
that response is considered an authoritative answer to the client's that response is considered an authoritative answer to the client's
request. request.
Although HTTP is independent of the transport protocol, the "http" Although HTTP is independent of the transport protocol, the "http"
scheme is specific to TCP-based services because the name delegation scheme is specific to TCP-based services because the name delegation
process depends on TCP for establishing authority. An HTTP service process depends on TCP for establishing authority. An HTTP service
based on some other underlying connection protocol would presumably based on some other underlying connection protocol would presumably
be identified using a different URI scheme, just as the "https" be identified using a different URI scheme, just as the "https"
scheme (below) is used for resources that require an end-to-end scheme (below) is used for resources that require an end-to-end
secured connection. Other protocols might also be used to provide secured connection. Other protocols might also be used to provide
skipping to change at page 19, line 29 skipping to change at page 19, line 22
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 than those in the "reserved" set are equivalent to their percent-
percent-encoded octets: the normal form is to not encode them (see encoded octets: the normal form is to not encode them (see Sections
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
3. Message Format 3. Message Format
All HTTP/1.1 messages consist of a start-line followed by a sequence All HTTP/1.1 messages consist of a start-line followed by a sequence
skipping to change at page 21, line 27 skipping to change at page 21, line 19
version, and ends with CRLF. 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 [SEMNTCS], 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.
Recipients typically parse the request-line into its component parts Recipients typically parse the request-line into its component parts
by splitting on whitespace (see Section 3.5), since no whitespace is by splitting on whitespace (see Section 3.5), since no whitespace is
allowed in the three components. Unfortunately, some user agents allowed in the three components. Unfortunately, some user agents
fail to properly encode or exclude whitespace found in hypertext fail to properly encode or exclude whitespace found in hypertext
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 predefined limit on the length of a HTTP does not place a predefined limit on the length of a request-
request-line, as described in Section 2.5. A server that receives a line, as described in Section 2.5. A server that receives a method
method longer than any that it implements SHOULD respond with a 501 longer than any that it implements SHOULD respond with a 501 (Not
(Not Implemented) status code. A server that receives a Implemented) status code. A server that receives a request-target
request-target longer than any URI it wishes to parse MUST respond longer than any URI it wishes to parse MUST respond with a 414 (URI
with a 414 (URI Too Long) status code (see Section 6.5.12 of Too Long) status code (see Section 6.5.12 of [SEMNTCS]).
[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, a possibly empty textual phrase describing the status code, space, a possibly empty textual phrase describing the status code,
and ending with CRLF. and ending with 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 [SEMNTCS] 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,
considerations for the definition of new status codes, and the IANA considerations for the definition of new status codes, and the IANA
registry. registry.
status-code = 3DIGIT status-code = 3DIGIT
The reason-phrase element exists for the sole purpose of providing a The reason-phrase element exists for the sole purpose of providing a
textual description associated with the numeric status code, mostly textual description associated with the numeric status code, mostly
out of deference to earlier Internet application protocols that were out of deference to earlier Internet application protocols that were
skipping to change at page 23, line 18 skipping to change at page 23, line 4
field-value = *( field-content / obs-fold ) field-value = *( field-content / obs-fold )
field-content = field-vchar [ 1*( SP / HTAB ) field-vchar ] field-content = field-vchar [ 1*( SP / HTAB ) field-vchar ]
field-vchar = VCHAR / obs-text field-vchar = VCHAR / obs-text
obs-fold = CRLF 1*( SP / HTAB ) obs-fold = CRLF 1*( SP / HTAB )
; obsolete line folding ; obsolete line folding
; see Section 3.2.4 ; see Section 3.2.4
The field-name token labels the corresponding field-value as having The field-name token labels the corresponding field-value as having
the semantics defined by that header field. For example, the Date the semantics defined by that header field. For example, the Date
header field is defined in Section 7.1.1.2 of [RFC7231] as containing header field is defined in Section 7.1.1.2 of [SEMNTCS] as containing
the origination timestamp for the message in which it appears. the origination timestamp for the message in which it appears.
3.2.1. Field Extensibility 3.2.1. Field Extensibility
Header fields are fully extensible: there is no limit on the Header fields are fully extensible: there is no limit on the
introduction of new field names, each presumably defining new introduction of new field names, each presumably defining new
semantics, nor on the number of header fields used in a given semantics, nor on the number of header fields used in a given
message. Existing fields are defined in each part of this message. Existing fields are defined in each part of this
specification and in many other specifications outside this document specification and in many other specifications outside this document
set. set.
skipping to change at page 23, line 43 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 Headers" registry, as described in Section 8.3 of [RFC7231]. "Message Headers" registry, as described in Section 8.3 of [SEMNTCS].
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
header section is received, since later header fields might include header section is received, since later header fields might include
skipping to change at page 25, line 38 skipping to change at page 25, line 24
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 whitespace: 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 first non-whitespace octet of the field value or after the last non-
non-whitespace octet of the field value ought to be excluded by whitespace octet of the field value ought to be excluded by parsers
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
the obs-fold rule) unless the message is intended for packaging the obs-fold rule) unless the message is intended for packaging
within the message/http media type. within the message/http media type.
skipping to change at page 26, line 21 skipping to change at page 26, line 6
A proxy or gateway that receives an obs-fold in a response message A proxy or gateway that receives an obs-fold in a response message
that is not within a message/http container MUST either discard the that is not within a message/http container MUST either discard the
message and replace it with a 502 (Bad Gateway) response, preferably message and replace it with a 502 (Bad Gateway) response, preferably
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 not within a message/http container MUST replace each received obs-
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 Historically, HTTP has allowed field content with text in the
ISO-8859-1 charset [ISO-8859-1], supporting other charsets only ISO-8859-1 charset [ISO-8859-1], supporting other charsets only
through use of [RFC2047] encoding. In practice, most HTTP header through use of [RFC2047] encoding. In practice, most HTTP header
field values use only a subset of the US-ASCII charset [USASCII]. field values use only a subset of the US-ASCII charset [USASCII].
Newly defined header fields SHOULD limit their field values to Newly defined header fields SHOULD limit their field values to
US-ASCII octets. A recipient SHOULD treat other octets in field US-ASCII octets. A recipient SHOULD treat other octets in field
content (obs-text) as opaque data. content (obs-text) as opaque data.
skipping to change at page 28, line 17 skipping to change at page 27, line 44
The message body (if any) of an HTTP message is used to carry the The message body (if any) of an HTTP message is used to carry the
payload body of that request or response. The message body is payload body of that request or response. The message body is
identical to the payload body unless a transfer coding has been identical to the payload body unless a transfer coding has been
applied, as described in Section 3.3.1. applied, as described in Section 3.3.1.
message-body = *OCTET message-body = *OCTET
The rules for when a message body is allowed in a message differ for The rules for when a message body is allowed in a message differ for
requests and responses. requests and responses.
The presence of a message body in a request is signaled by a The presence of a message body in a request is signaled by a Content-
Content-Length or Transfer-Encoding header field. Request message Length or Transfer-Encoding header field. Request message framing is
framing is independent of method semantics, even if the method does independent of method semantics, even if the method does not define
not define any use for a message body. any use for a message body.
The presence of a message body in a response depends on both the The presence of a message body in a response depends on both the
request method to which it is responding and the response status code request method to which it is responding and the response status code
(Section 3.1.2). Responses to the HEAD request method (Section 4.3.2 (Section 3.1.2). Responses to the HEAD request method (Section 4.3.2
of [RFC7231]) never include a message body because the associated of [SEMNTCS]) never include a message body because the associated
response header fields (e.g., Transfer-Encoding, Content-Length, response header fields (e.g., Transfer-Encoding, Content-Length,
etc.), if present, indicate only what their values would have been if etc.), if present, indicate only what their values would have been if
the request method had been GET (Section 4.3.1 of [RFC7231]). 2xx the request method had been GET (Section 4.3.1 of [SEMNTCS]). 2xx
(Successful) responses to a CONNECT request method (Section 4.3.6 of (Successful) responses to a CONNECT request method (Section 4.3.6 of
[RFC7231]) switch to tunnel mode instead of having a message body. [SEMNTCS]) switch to tunnel mode instead of having a message body.
All 1xx (Informational), 204 (No Content), and 304 (Not Modified) All 1xx (Informational), 204 (No Content), and 304 (Not Modified)
responses do not include a message body. All other responses do responses do not include a message body. All other responses do
include a message body, although the body might be of zero length. include a message body, although the body might be of zero length.
3.3.1. Transfer-Encoding 3.3.1. Transfer-Encoding
The Transfer-Encoding header field lists the transfer coding names The Transfer-Encoding header field lists the transfer coding names
corresponding to the sequence of transfer codings that have been (or corresponding to the sequence of transfer codings that have been (or
will be) applied to the payload body in order to form the message will be) applied to the payload body in order to form the message
body. Transfer codings are defined in Section 4. body. Transfer codings are defined in Section 4.
skipping to change at page 29, line 25 skipping to change at page 29, line 5
by closing the connection. by closing the connection.
For example, For example,
Transfer-Encoding: gzip, chunked Transfer-Encoding: gzip, chunked
indicates that the payload body has been compressed using the gzip indicates that the payload body has been compressed using the gzip
coding and then chunked using the chunked coding while forming the coding and then chunked using the chunked coding while forming the
message body. message body.
Unlike Content-Encoding (Section 3.1.2.1 of [RFC7231]), Unlike Content-Encoding (Section 3.1.2.1 of [SEMNTCS]), Transfer-
Transfer-Encoding is a property of the message, not of the Encoding is a property of the message, not of the representation, and
representation, and any recipient along the request/response chain any recipient along the request/response chain MAY decode the
MAY decode the received transfer coding(s) or apply additional received transfer coding(s) or apply additional transfer coding(s) to
transfer coding(s) to the message body, assuming that corresponding the message body, assuming that corresponding changes are made to the
changes are made to the Transfer-Encoding field-value. Additional Transfer-Encoding field-value. Additional information about the
information about the encoding parameters can be provided by other encoding parameters can be provided by other header fields not
header fields not defined by this specification. defined by this specification.
Transfer-Encoding MAY be sent in a response to a HEAD request or in a Transfer-Encoding MAY be sent in a response to a HEAD request or in a
304 (Not Modified) response (Section 4.1 of [RFC7232]) to a GET 304 (Not Modified) response (Section 4.1 of [CONDTNL]) to a GET
request, neither of which includes a message body, to indicate that request, neither of which includes a message body, to indicate that
the origin server would have applied a transfer coding to the message the origin server would have applied a transfer coding to the message
body if the request had been an unconditional GET. This indication body if the request had been an unconditional GET. This indication
is not required, however, because any recipient on the response chain is not required, however, because any recipient on the response chain
(including the origin server) can remove transfer codings when they (including the origin server) can remove transfer codings when they
are not needed. are not needed.
A server MUST NOT send a Transfer-Encoding header field in any A server MUST NOT send a Transfer-Encoding header field in any
response with a status code of 1xx (Informational) or 204 (No response with a status code of 1xx (Informational) or 204 (No
Content). A server MUST NOT send a Transfer-Encoding header field in Content). A server MUST NOT send a Transfer-Encoding header field in
any 2xx (Successful) response to a CONNECT request (Section 4.3.6 of any 2xx (Successful) response to a CONNECT request (Section 4.3.6 of
[RFC7231]). [SEMNTCS]).
Transfer-Encoding was added in HTTP/1.1. It is generally assumed Transfer-Encoding was added in HTTP/1.1. It is generally assumed
that implementations advertising only HTTP/1.0 support will not that implementations advertising only HTTP/1.0 support will not
understand how to process a transfer-encoded payload. A client MUST understand how to process a transfer-encoded payload. A client MUST
NOT send a request containing Transfer-Encoding unless it knows the NOT send a request containing Transfer-Encoding unless it knows the
server will handle HTTP/1.1 (or later) requests; such knowledge might server will handle HTTP/1.1 (or later) requests; such knowledge might
be in the form of specific user configuration or by remembering the be in the form of specific user configuration or by remembering the
version of a prior received response. A server MUST NOT send a version of a prior received response. A server MUST NOT send a
response containing Transfer-Encoding unless the corresponding response containing Transfer-Encoding unless the corresponding
request indicates HTTP/1.1 (or later). request indicates HTTP/1.1 (or later).
skipping to change at page 30, line 22 skipping to change at page 29, line 51
3.3.2. Content-Length 3.3.2. Content-Length
When a message does not have a Transfer-Encoding header field, a When a message does not have a Transfer-Encoding header field, a
Content-Length header field can provide the anticipated size, as a Content-Length header field can provide the anticipated size, as a
decimal number of octets, for a potential payload body. For messages decimal number of octets, for a potential payload body. For messages
that do include a payload body, the Content-Length field-value that do include a payload body, the Content-Length field-value
provides the framing information necessary for determining where the provides the framing information necessary for determining where the
body (and message) ends. For messages that do not include a payload body (and message) ends. For messages that do not include a payload
body, the Content-Length indicates the size of the selected body, the Content-Length indicates the size of the selected
representation (Section 3 of [RFC7231]). representation (Section 3 of [SEMNTCS]).
Content-Length = 1*DIGIT Content-Length = 1*DIGIT
An example is An example is
Content-Length: 3495 Content-Length: 3495
A sender MUST NOT send a Content-Length header field in any message A sender MUST NOT send a Content-Length header field in any message
that contains a Transfer-Encoding header field. that contains a Transfer-Encoding header field.
A user agent SHOULD send a Content-Length in a request message when A user agent SHOULD send a Content-Length in a request message when
no Transfer-Encoding is sent and the request method defines a meaning no Transfer-Encoding is sent and the request method defines a meaning
for an enclosed payload body. For example, a Content-Length header for an enclosed payload body. For example, a Content-Length header
field is normally sent in a POST request even when the value is 0 field is normally sent in a POST request even when the value is 0
(indicating an empty payload body). A user agent SHOULD NOT send a (indicating an empty payload body). A user agent SHOULD NOT send a
Content-Length header field when the request message does not contain Content-Length header field when the request message does not contain
a payload body and the method semantics do not anticipate such a a payload body and the method semantics do not anticipate such a
body. body.
A server MAY send a Content-Length header field in a response to a A server MAY send a Content-Length header field in a response to a
HEAD request (Section 4.3.2 of [RFC7231]); a server MUST NOT send HEAD request (Section 4.3.2 of [SEMNTCS]); a server MUST NOT send
Content-Length in such a response unless its field-value equals the Content-Length in such a response unless its field-value equals the
decimal number of octets that would have been sent in the payload decimal number of octets that would have been sent in the payload
body of a response if the same request had used the GET method. body of a response if the same request had used the GET method.
A server MAY send a Content-Length header field in a 304 (Not A server MAY send a Content-Length header field in a 304 (Not
Modified) response to a conditional GET request (Section 4.1 of Modified) response to a conditional GET request (Section 4.1 of
[RFC7232]); a server MUST NOT send Content-Length in such a response [CONDTNL]); a server MUST NOT send Content-Length in such a response
unless its field-value equals the decimal number of octets that would unless its field-value equals the decimal number of octets that would
have been sent in the payload body of a 200 (OK) response to the same have been sent in the payload body of a 200 (OK) response to the same
request. request.
A server MUST NOT send a Content-Length header field in any response A server MUST NOT send a Content-Length header field in any response
with a status code of 1xx (Informational) or 204 (No Content). A with a status code of 1xx (Informational) or 204 (No Content). A
server MUST NOT send a Content-Length header field in any 2xx server MUST NOT send a Content-Length header field in any 2xx
(Successful) response to a CONNECT request (Section 4.3.6 of (Successful) response to a CONNECT request (Section 4.3.6 of
[RFC7231]). [SEMNTCS]).
Aside from the cases defined above, in the absence of Aside from the cases defined above, in the absence of Transfer-
Transfer-Encoding, an origin server SHOULD send a Content-Length Encoding, an origin server SHOULD send a Content-Length header field
header field when the payload body size is known prior to sending the when the payload body size is known prior to sending the complete
complete header section. This will allow downstream recipients to header section. This will allow downstream recipients to measure
measure transfer progress, know when a received message is complete, transfer progress, know when a received message is complete, and
and potentially reuse the connection for additional requests. potentially reuse the connection for additional requests.
Any Content-Length field value greater than or equal to zero is Any Content-Length field value greater than or equal to zero is
valid. Since there is no predefined limit to the length of a valid. Since there is no predefined limit to the length of a
payload, a recipient MUST anticipate potentially large decimal payload, a recipient MUST anticipate potentially large decimal
numerals and prevent parsing errors due to integer conversion numerals and prevent parsing errors due to integer conversion
overflows (Section 9.3). overflows (Section 9.3).
If a message is received that has multiple Content-Length header If a message is received that has multiple Content-Length header
fields with field-values consisting of the same decimal value, or a fields with field-values consisting of the same decimal value, or a
single Content-Length header field with a field value containing a single Content-Length header field with a field value containing a
list of identical decimal values (e.g., "Content-Length: 42, 42"), list of identical decimal values (e.g., "Content-Length: 42, 42"),
indicating that duplicate Content-Length header fields have been indicating that duplicate Content-Length header fields have been
generated or combined by an upstream message processor, then the generated or combined by an upstream message processor, then the
recipient MUST either reject the message as invalid or replace the recipient MUST either reject the message as invalid or replace the
duplicated field-values with a single valid Content-Length field duplicated field-values with a single valid Content-Length field
containing that decimal value prior to determining the message body containing that decimal value prior to determining the message body
length or forwarding the message. length or forwarding the message.
Note: HTTP's use of Content-Length for message framing differs Note: HTTP's use of Content-Length for message framing differs
significantly from the same field's use in MIME, where it is an significantly from the same field's use in MIME, where it is an
optional field used only within the "message/external-body" optional field used only within the "message/external-body" media-
media-type. type.
3.3.3. Message Body Length 3.3.3. Message Body Length
The length of a message body is determined by one of the following The length of a message body is determined by one of the following
(in order of precedence): (in order of precedence):
1. Any response to a HEAD request and any response with a 1xx 1. Any response to a HEAD request and any response with a 1xx
(Informational), 204 (No Content), or 304 (Not Modified) status (Informational), 204 (No Content), or 304 (Not Modified) status
code is always terminated by the first empty line after the code is always terminated by the first empty line after the
header fields, regardless of the header fields present in the header fields, regardless of the header fields present in the
skipping to change at page 33, line 23 skipping to change at page 32, line 43
incomplete and close the connection. incomplete and close the connection.
6. If this is a request message and none of the above are true, then 6. If this is a request message and none of the above are true, then
the message body length is zero (no message body is present). the message body length is zero (no message body is present).
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, Since there is no way to distinguish a successfully completed, close-
close-delimited message from a partially received message interrupted delimited message from a partially received message interrupted by
by network failure, a server SHOULD generate encoding or network failure, a server SHOULD generate encoding or length-
length-delimited messages whenever possible. The close-delimiting delimited messages whenever possible. The close-delimiting feature
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
in advance, rather than the chunked transfer coding, since some in advance, rather than the chunked transfer coding, since some
existing services respond to chunked with a 411 (Length Required) existing services respond to chunked with a 411 (Length Required)
status code even though they understand the chunked transfer coding. status code even though they understand the chunked transfer coding.
skipping to change at page 34, line 20 skipping to change at page 33, line 41
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 timeout 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 [CACHING].
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
skipping to change at page 35, line 48 skipping to change at page 35, line 20
/ "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 Section 8.4. They are used in the TE (Section 4.3) and Transfer-
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
retain connection persistence and the recipient to know when it has retain connection persistence and the recipient to know when it has
received the entire message. received the entire message.
skipping to change at page 36, line 39 skipping to change at page 36, line 9
when a chunk with a chunk-size of zero is received, possibly followed when a chunk with a chunk-size of zero is received, possibly followed
by a trailer, and finally terminated by an empty line. by a trailer, and finally terminated by an empty line.
A recipient MUST be able to parse and decode the chunked transfer A recipient MUST be able to parse and decode the chunked transfer
coding. coding.
4.1.1. Chunk Extensions 4.1.1. Chunk Extensions
The chunked encoding allows each chunk to include zero or more chunk The chunked encoding allows each chunk to include zero or more chunk
extensions, immediately following the chunk-size, for the sake of extensions, immediately following the chunk-size, for the sake of
supplying per-chunk metadata (such as a signature or hash), supplying per-chunk metadata (such as a signature or hash), mid-
mid-message control information, or randomization of message body message control information, or randomization of message body size.
size.
chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-val ] ) chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
chunk-ext-name = token chunk-ext-name = token
chunk-ext-val = token / quoted-string chunk-ext-val = token / quoted-string
The chunked encoding is specific to each connection and is likely to The chunked encoding is specific to each connection and is likely to
be removed or recoded by each recipient (including intermediaries) be removed or recoded by each recipient (including intermediaries)
before any higher-level application would have a chance to inspect before any higher-level application would have a chance to inspect
the extensions. Hence, use of chunk extensions is generally limited the extensions. Hence, use of chunk extensions is generally limited
skipping to change at page 37, line 30 skipping to change at page 36, line 47
message integrity check, digital signature, or post-processing message integrity check, digital signature, or post-processing
status. The trailer fields are identical to header fields, except status. The trailer fields are identical to header fields, except
they are sent in a chunked trailer instead of the message's header they are sent in a chunked trailer instead of the message's header
section. section.
trailer-part = *( header-field CRLF ) trailer-part = *( header-field CRLF )
A sender MUST NOT generate a trailer that contains a field necessary A sender MUST NOT generate a trailer that contains a field necessary
for message framing (e.g., Transfer-Encoding and Content-Length), for message framing (e.g., Transfer-Encoding and Content-Length),
routing (e.g., Host), request modifiers (e.g., controls and routing (e.g., Host), request modifiers (e.g., controls and
conditionals in Section 5 of [RFC7231]), authentication (e.g., see conditionals in Section 5 of [SEMNTCS]), authentication (e.g., see
[RFC7235] and [RFC6265]), response control data (e.g., see Section [AUTHFRM] and [RFC6265]), response control data (e.g., see
7.1 of [RFC7231]), or determining how to process the payload (e.g., Section 7.1 of [SEMNTCS]), or determining how to process the payload
Content-Encoding, Content-Type, Content-Range, and Trailer). (e.g., Content-Encoding, Content-Type, Content-Range, and Trailer).
When a chunked message containing a non-empty trailer is received, When a chunked message containing a non-empty trailer is received,
the recipient MAY process the fields (aside from those forbidden the recipient MAY process the fields (aside from those forbidden
above) as if they were appended to the message's header section. A above) as if they were appended to the message's header section. A
recipient MUST ignore (or consider as an error) any fields that are recipient MUST ignore (or consider as an error) any fields that are
forbidden to be sent in a trailer, since processing them as if they forbidden to be sent in a trailer, since processing them as if they
were present in the header section might bypass external security were present in the header section might bypass external security
filters. filters.
Unless the request includes a TE header field indicating "trailers" Unless the request includes a TE header field indicating "trailers"
skipping to change at page 39, line 50 skipping to change at page 39, line 18
clients. For requests from an intermediary, this implies that clients. For requests from an intermediary, this implies that
either: (a) all downstream clients are willing to accept trailer either: (a) all downstream clients are willing to accept trailer
fields in the forwarded response; or, (b) the intermediary will fields in the forwarded response; or, (b) the intermediary will
attempt to buffer the response on behalf of downstream recipients. attempt to buffer the response on behalf of downstream recipients.
Note that HTTP/1.1 does not define any means to limit the size of a Note that HTTP/1.1 does not define any means to limit the size of a
chunked response such that an intermediary can be assured of chunked response such that an intermediary can be assured of
buffering the entire response. buffering the entire response.
When multiple transfer codings are acceptable, the client MAY rank When multiple transfer codings are acceptable, the client MAY rank
the codings by preference using a case-insensitive "q" parameter the codings by preference using a case-insensitive "q" parameter
(similar to the qvalues used in content negotiation fields, Section (similar to the qvalues used in content negotiation fields,
5.3.1 of [RFC7231]). The rank value is a real number in the range 0 Section 5.3.1 of [SEMNTCS]). The rank value is a real number in the
through 1, where 0.001 is the least preferred and 1 is the most range 0 through 1, where 0.001 is the least preferred and 1 is the
preferred; a value of 0 means "not acceptable". most preferred; a value of 0 means "not acceptable".
If the TE field-value is empty or if no TE field is present, the only If the TE field-value is empty or if no TE field is present, the only
acceptable transfer coding is chunked. A message with no transfer acceptable transfer coding is chunked. A message with no transfer
coding is always acceptable. coding is always acceptable.
Since the TE header field only applies to the immediate connection, a Since the TE header field only applies to the immediate connection, a
sender of TE MUST also send a "TE" connection option within the sender of TE MUST also send a "TE" connection option within the
Connection header field (Section 6.1) in order to prevent the TE Connection header field (Section 6.1) in order to prevent the TE
field from being forwarded by intermediaries that do not support its field from being forwarded by intermediaries that do not support its
semantics. semantics.
skipping to change at page 40, line 41 skipping to change at page 40, line 7
5. Message Routing 5. Message Routing
HTTP request message routing is determined by each client based on HTTP request message routing is determined by each client based on
the target resource, the client's proxy configuration, and the target resource, the client's proxy configuration, and
establishment or reuse of an inbound connection. The corresponding establishment or reuse of an inbound connection. The corresponding
response routing follows the same connection chain back to the response routing follows the same connection chain back to the
client. client.
5.1. Identifying a Target Resource 5.1. Identifying a Target Resource
HTTP is used in a wide variety of applications, ranging from HTTP is used in a wide variety of applications, ranging from general-
general-purpose computers to home appliances. In some cases, purpose computers to home appliances. In some cases, communication
communication options are hard-coded in a client's configuration. options are hard-coded in a client's configuration. However, most
However, most HTTP clients rely on the same resource identification HTTP clients rely on the same resource identification mechanism and
mechanism and configuration techniques as general-purpose Web configuration techniques as general-purpose Web browsers.
browsers.
HTTP communication is initiated by a user agent for some purpose. HTTP communication is initiated by a user agent for some purpose.
The purpose is a combination of request semantics, which are defined The purpose is a combination of request semantics, which are defined
in [RFC7231], and a target resource upon which to apply those in [SEMNTCS], and a target resource upon which to apply those
semantics. A URI reference (Section 2.7) is typically used as an semantics. A URI reference (Section 2.7) is typically used as an
identifier for the "target resource", which a user agent would identifier for the "target resource", which a user agent would
resolve to its absolute form in order to obtain the "target URI". resolve to its absolute form in order to obtain the "target URI".
The target URI excludes the reference's fragment component, if any, The target URI excludes the reference's fragment component, if any,
since fragment identifiers are reserved for client-side processing since fragment identifiers are reserved for client-side processing
([RFC3986], Section 3.5). ([RFC3986], Section 3.5).
5.2. Connecting Inbound 5.2. Connecting Inbound
Once the target URI is determined, a client needs to decide whether a Once the target URI is determined, a client needs to decide whether a
network request is necessary to accomplish the desired semantics and, network request is necessary to accomplish the desired semantics and,
if so, where that request is to be directed. if so, where that request is to be directed.
If the client has a cache [RFC7234] and the request can be satisfied If the client has a cache [CACHING] and the request can be satisfied
by it, then the request is usually directed there first. by it, then the request is usually directed there first.
If the request is not satisfied by a cache, then a typical client If the request is not satisfied by a cache, then a typical client
will check its configuration to determine whether a proxy is to be will check its configuration to determine whether a proxy is to be
used to satisfy the request. Proxy configuration is implementation- used to satisfy the request. Proxy configuration is implementation-
dependent, but is often based on URI prefix matching, selective dependent, but is often based on URI prefix matching, selective
authority matching, or both, and the proxy itself is usually authority matching, or both, and the proxy itself is usually
identified by an "http" or "https" URI. If a proxy is applicable, identified by an "http" or "https" URI. If a proxy is applicable,
the client connects inbound by establishing (or reusing) a connection the client connects inbound by establishing (or reusing) a connection
to that proxy. to that proxy.
skipping to change at page 43, line 13 skipping to change at page 42, line 23
GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1 GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
To allow for transition to the absolute-form for all requests in some To allow for transition to the absolute-form for all requests in some
future version of HTTP, a server MUST accept the absolute-form in future version of HTTP, a server MUST accept the absolute-form in
requests, even though HTTP/1.1 clients will only send them in requests, even though HTTP/1.1 clients will only send them in
requests to proxies. requests to proxies.
5.3.3. authority-form 5.3.3. authority-form
The authority-form of request-target is only used for CONNECT The authority-form of request-target is only used for CONNECT
requests (Section 4.3.6 of [RFC7231]). requests (Section 4.3.6 of [SEMNTCS]).
authority-form = authority authority-form = authority
When making a CONNECT request to establish a tunnel through one or When making a CONNECT request to establish a tunnel through one or
more proxies, a client MUST send only the target URI's authority more proxies, a client MUST send only the target URI's authority
component (excluding any userinfo and its "@" delimiter) as the component (excluding any userinfo and its "@" delimiter) as the
request-target. For example, request-target. For example,
CONNECT www.example.com:80 HTTP/1.1 CONNECT www.example.com:80 HTTP/1.1
5.3.4. asterisk-form 5.3.4. asterisk-form
The asterisk-form of request-target is only used for a server-wide The asterisk-form of request-target is only used for a server-wide
OPTIONS request (Section 4.3.7 of [RFC7231]). OPTIONS request (Section 4.3.7 of [SEMNTCS]).
asterisk-form = "*" asterisk-form = "*"
When a client wishes to request OPTIONS for the server as a whole, as When a client wishes to request OPTIONS for the server as a whole, as
opposed to a specific named resource of that server, the client MUST opposed to a specific named resource of that server, the client MUST
send only "*" (%x2A) as the request-target. For example, send only "*" (%x2A) as the request-target. For example,
OPTIONS * HTTP/1.1 OPTIONS * HTTP/1.1
If a proxy receives an OPTIONS request with an absolute-form of If a proxy receives an OPTIONS request with an absolute-form of
skipping to change at page 44, line 37 skipping to change at page 43, line 48
<http://www.example.org/pub/WWW/> would begin with: <http://www.example.org/pub/WWW/> would begin with:
GET /pub/WWW/ HTTP/1.1 GET /pub/WWW/ HTTP/1.1
Host: www.example.org Host: www.example.org
A client MUST send a Host header field in an HTTP/1.1 request even if A client MUST send a Host header field in an HTTP/1.1 request even if
the request-target is in the absolute-form, since this allows the the request-target is in the absolute-form, since this allows the
Host information to be forwarded through ancient HTTP/1.0 proxies Host information to be forwarded through ancient HTTP/1.0 proxies
that might not have implemented Host. that might not have implemented Host.
When a proxy receives a request with an absolute-form of When a proxy receives a request with an absolute-form of request-
request-target, the proxy MUST ignore the received Host header field target, the proxy MUST ignore the received Host header field (if any)
(if any) and instead replace it with the host information of the and instead replace it with the host information of the request-
request-target. A proxy that forwards such a request MUST generate a target. A proxy that forwards such a request MUST generate a new
new Host field-value based on the received request-target rather than Host field-value based on the received request-target rather than
forward the received Host field-value. forward the received Host field-value.
Since the Host header field acts as an application-level routing Since the Host header field acts as an application-level routing
mechanism, it is a frequent target for malware seeking to poison a mechanism, it is a frequent target for malware seeking to poison a
shared cache or redirect a request to an unintended server. An shared cache or redirect a request to an unintended server. An
interception proxy is particularly vulnerable if it relies on the interception proxy is particularly vulnerable if it relies on the
Host field-value for redirecting requests to internal servers, or for Host field-value for redirecting requests to internal servers, or for
use as a cache key in a shared cache, without first verifying that use as a cache key in a shared cache, without first verifying that
the intercepted connection is targeting a valid IP address for that the intercepted connection is targeting a valid IP address for that
host. host.
skipping to change at page 46, line 50 skipping to change at page 46, line 13
considerations regarding message routing. considerations regarding message routing.
5.6. Associating a Response to a Request 5.6. Associating a Response to a Request
HTTP does not include a request identifier for associating a given HTTP does not include a request identifier for associating a given
request message with its corresponding one or more response messages. request message with its corresponding one or more response messages.
Hence, it relies on the order of response arrival to correspond Hence, it relies on the order of response arrival to correspond
exactly to the order in which requests are made on the same exactly to the order in which requests are made on the same
connection. More than one response message per request only occurs connection. More than one response message per request only occurs
when one or more informational responses (1xx, see Section 6.2 of when one or more informational responses (1xx, see Section 6.2 of
[RFC7231]) precede a final response to the same request. [SEMNTCS]) precede a final response to the same request.
A client that has more than one outstanding request on a connection A client that has more than one outstanding request on a connection
MUST maintain a list of outstanding requests in the order sent and MUST maintain a list of outstanding requests in the order sent and
MUST associate each received response message on that connection to MUST associate each received response message on that connection to
the highest ordered request that has not yet received a final the highest ordered request that has not yet received a final (non-
(non-1xx) response. 1xx) response.
5.7. Message Forwarding 5.7. Message Forwarding
As described in Section 2.3, intermediaries can serve a variety of As described in Section 2.3, intermediaries can serve a variety of
roles in the processing of HTTP requests and responses. Some roles in the processing of HTTP requests and responses. Some
intermediaries are used to improve performance or availability. intermediaries are used to improve performance or availability.
Others are used for access control or to filter content. Since an Others are used for access control or to filter content. Since an
HTTP stream has characteristics similar to a pipe-and-filter HTTP stream has characteristics similar to a pipe-and-filter
architecture, there are no inherent limits to the extent an architecture, there are no inherent limits to the extent an
intermediary can enhance (or interfere) with either direction of the intermediary can enhance (or interfere) with either direction of the
skipping to change at page 50, line 13 skipping to change at page 49, line 19
domain name. domain name.
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 [SEMNTCS]) 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 [CACHING]).
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 [CACHING]). 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 [SEMNTCS]).
A proxy SHOULD NOT modify header fields that provide information A proxy SHOULD NOT modify header fields that provide information
about the endpoints 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 HTTP messaging is independent of the underlying transport- or
skipping to change at page 51, line 51 skipping to change at page 50, line 51
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 [CACHING]).
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
that is received without a corresponding connection option usually that is received without a corresponding connection option usually
indicates that the field has been improperly forwarded by an indicates that the field has been improperly forwarded by an
intermediary and ought to be ignored by the recipient. intermediary and ought to be ignored by the recipient.
When defining new connection options, specification authors ought to When defining new connection options, specification authors ought to
skipping to change at page 54, line 7 skipping to change at page 52, line 51
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
requests if all of those requests have idempotent methods (Section requests if all of those requests have idempotent methods
4.2.2 of [RFC7231]). A proxy MUST NOT automatically retry (Section 4.2.2 of [SEMNTCS]). A proxy MUST NOT automatically retry
non-idempotent requests. non-idempotent requests.
A user agent MUST NOT automatically retry a request with a non- A user agent MUST NOT automatically retry a request with a non-
idempotent method unless it has some means to know that the request idempotent method unless it has some means to know that the request
semantics are actually idempotent, regardless of the method, or some semantics are actually idempotent, regardless of the method, or some
means to detect that the original request was never applied. For means to detect that the original request was never applied. For
example, a user agent that knows (through design or configuration) example, a user agent that knows (through design or configuration)
that a POST request to a given resource is safe can repeat that that a POST request to a given resource is safe can repeat that
request automatically. Likewise, a user agent designed specifically request automatically. Likewise, a user agent designed specifically
to operate on a version control repository might be able to recover to operate on a version control repository might be able to recover
skipping to change at page 54, line 31 skipping to change at page 53, line 27
changes that were partially applied, and then automatically retrying changes that were partially applied, and then automatically retrying
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 [SEMNTCS]),
but it MUST send the corresponding responses in the same order that but it MUST send the corresponding responses in the same order that
the 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).
Idempotent methods (Section 4.2.2 of [RFC7231]) are significant to Idempotent methods (Section 4.2.2 of [SEMNTCS]) are significant to
pipelining because they can be automatically retried after a pipelining because they can be automatically retried after a
connection failure. A user agent SHOULD NOT pipeline requests after connection failure. A user agent SHOULD NOT pipeline requests after
a non-idempotent method, until the final response status code for a non-idempotent method, until the final response status code for
that method has been received, unless the user agent has a means to that method has been received, unless the user agent has a means to
detect and recover from partial failure conditions involving the detect and recover from partial failure conditions involving the
pipelined sequence. pipelined sequence.
An intermediary that receives pipelined requests MAY pipeline those An intermediary that receives pipelined requests MAY pipeline those
requests when forwarding them inbound, since it can rely on the requests when forwarding them inbound, since it can rely on the
outbound user agent(s) to determine what requests can be safely outbound user agent(s) to determine what requests can be safely
skipping to change at page 55, line 28 skipping to change at page 54, line 24
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 blocking" problem, wherein a request that takes significant server-
server-side processing and/or has a large payload blocks subsequent side processing and/or has a large payload blocks subsequent requests
requests on the same connection. However, each connection consumes on the same connection. However, each connection consumes server
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 Timeouts 6.5. Failures and Timeouts
Servers will usually have some timeout 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
skipping to change at page 59, line 26 skipping to change at page 58, line 16
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 an Upgrade and an Expect header field with If a server receives both an Upgrade and an Expect header field with
the "100-continue" expectation (Section 5.1.1 of [RFC7231]), the the "100-continue" expectation (Section 5.1.1 of [SEMNTCS]), the
server MUST send a 100 (Continue) response before sending a 101 server MUST send a 100 (Continue) response before sending a 101
(Switching 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 [SEMNTCS]).
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 A construct "#" is defined, similar to "*", for defining comma-
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
generate empty list elements. In other words, a sender MUST generate generate empty list elements. In other words, a sender MUST generate
lists that satisfy the following syntax: lists that satisfy the following syntax:
1#element => element *( OWS "," OWS element ) 1#element => element *( OWS "," OWS element )
and: and:
skipping to change at page 61, line 10 skipping to change at page 59, line 47
", ," ", ,"
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 Headers" HTTP header fields are registered within the "Message Headers"
registry maintained at registry maintained at <http://www.iana.org/assignments/message-
<http://www.iana.org/assignments/message-headers/>. headers/>.
This document defines the following HTTP header fields, so the This document defines the following HTTP header fields, so the
"Permanent Message Header Field Names" registry has been updated "Permanent Message Header Field Names" registry has been updated
accordingly (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" has been 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 header conflict with the "close" connection option of the Connection header
field (Section 6.1). 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 the "Permanent This document defines the following URI schemes, so the "Permanent
skipping to change at page 65, line 16 skipping to change at page 63, line 41
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 [SEMNTCS]) 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 namespace require IETF Review (see Section Values to be added to this namespace require IETF Review (see
4.1 of [RFC5226]), and MUST conform to the purpose of transfer coding Section 4.1 of [RFC5226]), and MUST conform to the purpose of
defined in this specification. transfer coding 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" has been 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 |
| compress | UNIX "compress" data format [Welch] | Section 4.2.1 | | | | .1 |
| deflate | "deflate" compressed data | Section 4.2.2 | | compress | UNIX "compress" data format [Welch] | Section 4 |
| | ([RFC1951]) inside the "zlib" data | | | | | .2.1 |
| | format ([RFC1950]) | | | deflate | "deflate" compressed data ([RFC1951]) | Section 4 |
| gzip | GZIP file format [RFC1952] | Section 4.2.3 | | | inside the "zlib" data format | .2.2 |
| x-compress | Deprecated (alias for compress) | Section 4.2.1 | | | ([RFC1950]) | |
| x-gzip | Deprecated (alias for gzip) | Section 4.2.3 | | gzip | GZIP file format [RFC1952] | Section 4 |
+------------+--------------------------------------+---------------+ | | | .2.3 |
| x-compress | Deprecated (alias for compress) | Section 4 |
| | | .2.1 |
| x-gzip | Deprecated (alias for gzip) | Section 4 |
| | | .2.3 |
+------------+------------------------------------------+-----------+
8.5. Content Coding Registration 8.5. Content Coding Registration
IANA maintains the "HTTP Content Coding Registry" 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 Coding Registry" has been updated with the The "HTTP Content Coding 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 |
| deflate | "deflate" compressed data | Section 4.2.2 | | | | .2.1 |
| | ([RFC1951]) inside the "zlib" data | | | deflate | "deflate" compressed data ([RFC1951]) | Section 4 |
| | format ([RFC1950]) | | | | inside the "zlib" data format | .2.2 |
| gzip | GZIP file format [RFC1952] | Section 4.2.3 | | | ([RFC1950]) | |
| x-compress | Deprecated (alias for compress) | Section 4.2.1 | | gzip | GZIP file format [RFC1952] | Section 4 |
| x-gzip | Deprecated (alias for gzip) | Section 4.2.3 | | | | .2.3 |
+------------+--------------------------------------+---------------+ | x-compress | Deprecated (alias for compress) | Section 4 |
| | | .2.1 |
| x-gzip | Deprecated (alias for gzip) | Section 4 |
| | | .2.3 |
+------------+------------------------------------------+-----------+
8.6. Upgrade Token Registry 8.6. Upgrade Token Registry
The "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry" The "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry"
defines the namespace for protocol-name tokens used to identify defines the namespace for protocol-name tokens used to identify
protocols in the Upgrade header field. 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
skipping to change at page 67, line 13 skipping to change at page 65, line 42
tokens associated with that token at the time of registration. tokens associated with that token at the time of registration.
6. The responsible party MAY change the registration at any time. 6. The responsible party MAY change the registration at any time.
The IANA will keep a record of all such changes, and make them The IANA will keep a record of all such changes, and make them
available upon request. available upon request.
7. The IESG MAY reassign responsibility for a protocol token. This 7. The IESG MAY reassign responsibility for a protocol token. This
will normally only be used in the case when a responsible party will normally only be used in the case when a responsible party
cannot be contacted. cannot be contacted.
This registration procedure for HTTP Upgrade Tokens replaces that
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 upgrade token registry has been updated with The "HTTP" entry in the upgrade token registry has been updated with
the registration below: 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 (e.g, | Section 2 |
| | Protocol | (e.g, "2.0") | | | | Protocol | "2.0") | .6 |
+-------+----------------------+----------------------+-------------+ +-------+----------------------+------------------------+-----------+
The responsible party is: "IETF (iesg@ietf.org) - Internet The responsible party is: "IETF (iesg@ietf.org) - Internet
Engineering Task Force". Engineering Task Force".
9. Security Considerations 9. Security Considerations
This section is meant to inform developers, information providers, This section is meant to inform developers, information providers,
and users of known security considerations relevant to HTTP message and users of known security considerations relevant to HTTP message
syntax, parsing, and routing. Security considerations about HTTP syntax, parsing, and routing. Security considerations about HTTP
semantics and payloads are addressed in [RFC7231]. semantics and payloads are addressed in [SEMNTCS].
9.1. Establishing Authority 9.1. Establishing Authority
HTTP relies on the notion of an authoritative response: a response HTTP relies on the notion of an authoritative response: a response
that has been determined by (or at the direction of) the authority that has been determined by (or at the direction of) the authority
identified within the target URI to be the most appropriate response identified within the target URI to be the most appropriate response
for that request given the state of the target resource at the time for that request given the state of the target resource at the time
of response message origination. Providing a response from a of response message origination. Providing a response from a non-
non-authoritative source, such as a shared cache, is often useful to authoritative source, such as a shared cache, is often useful to
improve performance and availability, but only to the extent that the improve performance and availability, but only to the extent that the
source can be trusted or the distrusted response can be safely used. source can be trusted or the distrusted response can be safely used.
Unfortunately, establishing authority can be difficult. For example, Unfortunately, establishing authority can be difficult. For example,
phishing is an attack on the user's perception of authority, where phishing is an attack on the user's perception of authority, where
that perception can be misled by presenting similar branding in that perception can be misled by presenting similar branding in
hypertext, possibly aided by userinfo obfuscating the authority hypertext, possibly aided by userinfo obfuscating the authority
component (see Section 2.7.1). User agents can reduce the impact of component (see Section 2.7.1). User agents can reduce the impact of
phishing attacks by enabling users to easily inspect a target URI phishing attacks by enabling users to easily inspect a target URI
prior to making an action, by prominently distinguishing (or prior to making an action, by prominently distinguishing (or
skipping to change at page 68, line 49 skipping to change at page 67, line 33
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
to cache poisoning attacks, as described in Section 8 of [RFC7234]. to cache poisoning attacks, as described in Section 8 of [CACHING].
Implementers need to consider the privacy and security implications Implementers need to consider the privacy and security implications
of their design and coding decisions, and of the configuration of their design and coding decisions, and of the configuration
options they provide to operators (especially the default options they provide to operators (especially the default
configuration). configuration).
Users need to be aware that intermediaries are no more trustworthy Users need to be aware that intermediaries are no more trustworthy
than the people who run them; HTTP itself cannot solve this problem. than the people who run them; HTTP itself cannot solve this problem.
9.3. Attacks via Protocol Element Length 9.3. Attacks via Protocol Element Length
skipping to change at page 69, line 28 skipping to change at page 68, line 10
expecting a protocol element with no predefined length. expecting a protocol element with no predefined length.
To promote interoperability, specific recommendations are made for To promote interoperability, specific recommendations are made for
minimum size limits on request-line (Section 3.1.1) and header fields minimum size limits on request-line (Section 3.1.1) and header fields
(Section 3.2). These are minimum recommendations, chosen to be (Section 3.2). These are minimum recommendations, chosen to be
supportable even by implementations with limited resources; it is supportable even by implementations with limited resources; it is
expected that most implementations will choose substantially higher expected that most implementations will choose substantially higher
limits. limits.
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 [SEMNTCS]) or a request payload that is too
large (Section 6.5.11 of [RFC7231]). Additional status codes related large (Section 6.5.11 of [SEMNTCS]). 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
skipping to change at page 70, line 48 skipping to change at page 69, line 32
usage. usage.
This specification has introduced new requirements on request This specification has introduced new requirements on request
parsing, particularly with regard to message framing in parsing, particularly with regard to message framing in
Section 3.3.3, to reduce the effectiveness of request smuggling. Section 3.3.3, to reduce the effectiveness of request smuggling.
9.6. Message Integrity 9.6. Message Integrity
HTTP does not define a specific mechanism for ensuring message HTTP does not define a specific mechanism for ensuring message
integrity, instead relying on the error-detection ability of integrity, instead relying on the error-detection ability of
underlying transport protocols and the use of length or underlying transport protocols and the use of length or chunk-
chunk-delimited framing to detect completeness. Additional integrity delimited framing to detect completeness. Additional integrity
mechanisms, such as hash functions or digital signatures applied to mechanisms, such as hash functions or digital signatures applied to
the content, can be selectively added to messages via extensible the content, can be selectively added to messages via extensible
metadata header fields. Historically, the lack of a single integrity metadata header fields. Historically, the lack of a single integrity
mechanism has been justified by the informal nature of most HTTP mechanism has been justified by the informal nature of most HTTP
communication. However, the prevalence of HTTP as an information communication. However, the prevalence of HTTP as an information
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
skipping to change at page 72, line 7 skipping to change at page 70, line 38
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 it 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 information, including user identifiers, IP addresses, and user-
user-provided query parameters, as soon as that information is no provided query parameters, as soon as that information is no longer
longer necessary to support operational needs for security, auditing, necessary to support operational needs for security, auditing, or
or fraud control. fraud control.
10. Acknowledgments
This edition of HTTP/1.1 builds on the many contributions that went
into RFC 1945, RFC 2068, RFC 2145, and RFC 2616, including
substantial contributions made by the previous authors, editors, and
Working Group Chairs: Tim Berners-Lee, Ari Luotonen, Roy T. Fielding,
Henrik Frystyk Nielsen, Jim Gettys, Jeffrey C. Mogul, Larry Masinter,
and Paul J. Leach. Mark Nottingham oversaw this effort as Working
Group Chair.
Since 1999, the following contributors have helped improve the HTTP
specification by reporting bugs, asking smart questions, drafting or
reviewing text, and evaluating open issues:
Adam Barth, Adam Roach, Addison Phillips, Adrian Chadd, Adrian Cole,
Adrien W. de Croy, Alan Ford, Alan Ruttenberg, Albert Lunde, Alek
Storm, Alex Rousskov, Alexandre Morgaut, Alexey Melnikov, Alisha
Smith, Amichai Rothman, Amit Klein, Amos Jeffries, Andreas Maier,
Andreas Petersson, Andrei Popov, Anil Sharma, Anne van Kesteren,
Anthony Bryan, Asbjorn Ulsberg, Ashok Kumar, Balachander
Krishnamurthy, Barry Leiba, Ben Laurie, Benjamin Carlyle, Benjamin
Niven-Jenkins, Benoit Claise, Bil Corry, Bill Burke, Bjoern
Hoehrmann, Bob Scheifler, Boris Zbarsky, Brett Slatkin, Brian Kell,
Brian McBarron, Brian Pane, Brian Raymor, Brian Smith, Bruce Perens,
Bryce Nesbitt, Cameron Heavon-Jones, Carl Kugler, Carsten Bormann,
Charles Fry, Chris Burdess, Chris Newman, Christian Huitema, Cyrus
Daboo, Dale Robert Anderson, Dan Wing, Dan Winship, Daniel Stenberg,
Darrel Miller, Dave Cridland, Dave Crocker, Dave Kristol, Dave
Thaler, David Booth, David Singer, David W. Morris, Diwakar Shetty,
Dmitry Kurochkin, Drummond Reed, Duane Wessels, Edward Lee, Eitan
Adler, Eliot Lear, Emile Stephan, Eran Hammer-Lahav, Eric D.
Williams, Eric J. Bowman, Eric Lawrence, Eric Rescorla, Erik
Aronesty, EungJun Yi, Evan Prodromou, Felix Geisendoerfer, Florian
Weimer, Frank Ellermann, Fred Akalin, Fred Bohle, Frederic Kayser,
Gabor Molnar, Gabriel Montenegro, Geoffrey Sneddon, Gervase Markham,
Gili Tzabari, Grahame Grieve, Greg Slepak, Greg Wilkins, Grzegorz
Calkowski, Harald Tveit Alvestrand, Harry Halpin, Helge Hess, Henrik
Nordstrom, Henry S. Thompson, Henry Story, Herbert van de Sompel,
Herve Ruellan, Howard Melman, Hugo Haas, Ian Fette, Ian Hickson, Ido
Safruti, Ilari Liusvaara, Ilya Grigorik, Ingo Struck, J. Ross Nicoll,
James Cloos, James H. Manger, James Lacey, James M. Snell, Jamie
Lokier, Jan Algermissen, Jari Arkko, Jeff Hodges (who came up with
the term 'effective Request-URI'), Jeff Pinner, Jeff Walden, Jim
Luther, Jitu Padhye, Joe D. Williams, Joe Gregorio, Joe Orton, Joel
Jaeggli, John C. Klensin, John C. Mallery, John Cowan, John Kemp,
John Panzer, John Schneider, John Stracke, John Sullivan, Jonas
Sicking, Jonathan A. Rees, Jonathan Billington, Jonathan Moore,
Jonathan Silvera, Jordi Ros, Joris Dobbelsteen, Josh Cohen, Julien
Pierre, Jungshik Shin, Justin Chapweske, Justin Erenkrantz, Justin
James, Kalvinder Singh, Karl Dubost, Kathleen Moriarty, Keith
Hoffman, Keith Moore, Ken Murchison, Koen Holtman, Konstantin
Voronkov, Kris Zyp, Leif Hedstrom, Lionel Morand, Lisa Dusseault,
Maciej Stachowiak, Manu Sporny, Marc Schneider, Marc Slemko, Mark
Baker, Mark Pauley, Mark Watson, Markus Isomaki, Markus Lanthaler,
Martin J. Duerst, Martin Musatov, Martin Nilsson, Martin Thomson,
Matt Lynch, Matthew Cox, Matthew Kerwin, Max Clark, Menachem Dodge,
Meral Shirazipour, Michael Burrows, Michael Hausenblas, Michael
Scharf, Michael Sweet, Michael Tuexen, Michael Welzl, Mike Amundsen,
Mike Belshe, Mike Bishop, Mike Kelly, Mike Schinkel, Miles Sabin,
Murray S. Kucherawy, Mykyta Yevstifeyev, Nathan Rixham, Nicholas
Shanks, Nico Williams, Nicolas Alvarez, Nicolas Mailhot, Noah Slater,
Osama Mazahir, Pablo Castro, Pat Hayes, Patrick R. McManus, Paul E.
Jones, Paul Hoffman, Paul Marquess, Pete Resnick, Peter Lepeska,
Peter Occil, Peter Saint-Andre, Peter Watkins, Phil Archer, Phil
Hunt, Philippe Mougin, Phillip Hallam-Baker, Piotr Dobrogost, Poul-
Henning Kamp, Preethi Natarajan, Rajeev Bector, Ray Polk, Reto
Bachmann-Gmuer, Richard Barnes, Richard Cyganiak, Rob Trace, Robby
Simpson, Robert Brewer, Robert Collins, Robert Mattson, Robert
O'Callahan, Robert Olofsson, Robert Sayre, Robert Siemer, Robert de
Wilde, Roberto Javier Godoy, Roberto Peon, Roland Zink, Ronny
Widjaja, Ryan Hamilton, S. Mike Dierken, Salvatore Loreto, Sam
Johnston, Sam Pullara, Sam Ruby, Saurabh Kulkarni, Scott Lawrence
(who maintained the original issues list), Sean B. Palmer, Sean
Turner, Sebastien Barnoud, Shane McCarron, Shigeki Ohtsu, Simon
Yarde, Stefan Eissing, Stefan Tilkov, Stefanos Harhalakis, Stephane
Bortzmeyer, Stephen Farrell, Stephen Kent, Stephen Ludin, Stuart
Williams, Subbu Allamaraju, Subramanian Moonesamy, Susan Hares,
Sylvain Hellegouarch, Tapan Divekar, Tatsuhiro Tsujikawa, Tatsuya
Hayashi, Ted Hardie, Ted Lemon, Thomas Broyer, Thomas Fossati, Thomas
Maslen, Thomas Nadeau, Thomas Nordin, Thomas Roessler, Tim Bray, Tim
Morgan, Tim Olsen, Tom Zhou, Travis Snoozy, Tyler Close, Vincent
Murphy, Wenbo Zhu, Werner Baumann, Wilbur Streett, Wilfredo Sanchez
Vega, William A. Rowe Jr., William Chan, Willy Tarreau, Xiaoshu Wang,
Yaron Goland, Yngve Nysaeter Pettersen, Yoav Nir, Yogesh Bang,
Yuchung Cheng, Yutaka Oiwa, Yves Lafon (long-time member of the
editor team), Zed A. Shaw, and Zhong Yu.
See Section 16 of [RFC2616] for additional acknowledgements from
prior revisions.
11. References 10. References
11.1. Normative References 10.1. Normative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [AUTHFRM] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
RFC 793, September 1981. Ed., "Hypertext Transfer Protocol (HTTP): Authentication",
draft-ietf-httpbis-auth-00 (work in progress), April 2018.
[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data [CACHING] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Format Specification version 3.3", RFC 1950, May 1996. Ed., "Hypertext Transfer Protocol (HTTP): Caching", draft-
ietf-httpbis-cache-00 (work in progress), April 2018.
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format [CONDTNL] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Specification version 1.3", RFC 1951, May 1996. Ed., "Hypertext Transfer Protocol (HTTP): Conditional
Requests", draft-ietf-httpbis-conditional-00 (work in
progress), April 2018.
[RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and [RANGERQ] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
G. Randers-Pehrson, "GZIP file format specification Ed., "Hypertext Transfer Protocol (HTTP): Range Requests",
version 4.3", RFC 1952, May 1996. draft-ietf-httpbis-range-00 (work in progress), April
2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
Requirement Levels", BCP 14, RFC 2119, March 1997. RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format
"Uniform Resource Identifier (URI): Generic Syntax", Specification version 3.3", RFC 1950,
STD 66, RFC 3986, January 2005. DOI 10.17487/RFC1950, May 1996,
<https://www.rfc-editor.org/info/rfc1950>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification
Syntax Specifications: ABNF", STD 68, RFC 5234, version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996,
January 2008. <https://www.rfc-editor.org/info/rfc1951>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G.
Transfer Protocol (HTTP/1.1): Semantics and Content", Randers-Pehrson, "GZIP file format specification version
RFC 7231, June 2014. 4.3", RFC 1952, DOI 10.17487/RFC1952, May 1996,
<https://www.rfc-editor.org/info/rfc1952>.
[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Transfer Protocol (HTTP/1.1): Conditional Requests", Requirement Levels", BCP 14, RFC 2119,
RFC 7232, June 2014. DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
"Hypertext Transfer Protocol (HTTP/1.1): Range Resource Identifier (URI): Generic Syntax", STD 66,
Requests", RFC 7233, June 2014. RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", Specifications: ABNF", STD 68, RFC 5234,
RFC 7234, June 2014. DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext [SEMNTCS] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Transfer Protocol (HTTP/1.1): Authentication", Ed., "Hypertext Transfer Protocol (HTTP): Semantics and
RFC 7235, June 2014. Content", draft-ietf-httpbis-semantics-00 (work in
progress), April 2018.
[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 10.2. Informative References
[BCP115] Hansen, T., Hardie, T., and L. Masinter, "Guidelines [BCP115] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
and Registration Procedures for New URI Schemes", Registration Procedures for New URI Schemes", BCP 115,
BCP 115, RFC 4395, February 2006. RFC 4395, February 2006,
<https://www.rfc-editor.org/info/bcp115>.
[BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type [BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, Specifications and Registration Procedures", BCP 13,
RFC 6838, January 2013. RFC 6838, January 2013,
<https://www.rfc-editor.org/info/bcp13>.
[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, Procedures for Message Header Fields", BCP 90, RFC 3864,
RFC 3864, September 2004. September 2004, <https://www.rfc-editor.org/info/bcp90>.
[Georgiev] Georgiev, M., Iyengar, S., Jana, S., Anubhai, R., [Georgiev]
Boneh, D., and V. Shmatikov, "The Most Dangerous Code Georgiev, M., Iyengar, S., Jana, S., Anubhai, R., Boneh,
in the World: Validating SSL Certificates in Non- D., and V. Shmatikov, "The Most Dangerous Code in the
browser Software", In Proceedings of the 2012 ACM World: Validating SSL Certificates in Non-browser
Conference on Computer and Communications Security (CCS Software", In Proceedings of the 2012 ACM Conference on
'12), pp. 38-49, October 2012, Computer and Communications Security (CCS '12), pp. 38-49,
<http://doi.acm.org/10.1145/2382196.2382204>. October 2012,
<http://doi.acm.org/10.1145/2382196.2382204>.
[ISO-8859-1] International Organization for Standardization, [ISO-8859-1]
"Information technology -- 8-bit single-byte coded International Organization for Standardization,
graphic character sets -- Part 1: Latin alphabet No. "Information technology -- 8-bit single-byte coded graphic
1", ISO/IEC 8859-1:1998, 1998. character sets -- Part 1: Latin alphabet No. 1", ISO/
IEC 8859-1:1998, 1998.
[Klein] Klein, A., "Divide and Conquer - HTTP Response [Klein] Klein, A., "Divide and Conquer - HTTP Response Splitting,
Splitting, Web Cache Poisoning Attacks, and Related Web Cache Poisoning Attacks, and Related Topics", March
Topics", March 2004, <http://packetstormsecurity.com/ 2004, <http://packetstormsecurity.com/papers/general/
papers/general/whitepaper_httpresponse.pdf>. whitepaper_httpresponse.pdf>.
[Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and [Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and
Politics", ACM Transactions on Internet Politics", ACM Transactions on Internet Technology 1(2),
Technology 1(2), November 2001, November 2001, <http://arxiv.org/abs/cs.SE/0105018>.
<http://arxiv.org/abs/cs.SE/0105018>.
[Linhart] Linhart, C., Klein, A., Heled, R., and S. Orrin, "HTTP [Linhart] Linhart, C., Klein, A., Heled, R., and S. Orrin, "HTTP
Request Smuggling", June 2005, Request Smuggling", June 2005,
<http://www.watchfire.com/news/whitepapers.aspx>. <http://www.watchfire.com/news/whitepapers.aspx>.
[RFC1919] Chatel, M., "Classical versus Transparent IP Proxies", [RFC1919] Chatel, M., "Classical versus Transparent IP Proxies",
RFC 1919, March 1996. RFC 1919, DOI 10.17487/RFC1919, March 1996,
<https://www.rfc-editor.org/info/rfc1919>.
[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext
"Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, Transfer Protocol -- HTTP/1.0", RFC 1945,
May 1996. DOI 10.17487/RFC1945, May 1996,
<https://www.rfc-editor.org/info/rfc1945>.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Mail Extensions (MIME) Part One: Format of Internet Extensions (MIME) Part One: Format of Internet Message
Message Bodies", RFC 2045, November 1996. Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
<https://www.rfc-editor.org/info/rfc2045>.
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
Extensions) Part Three: Message Header Extensions for Part Three: Message Header Extensions for Non-ASCII Text",
Non-ASCII Text", RFC 2047, November 1996. RFC 2047, DOI 10.17487/RFC2047, November 1996,
<https://www.rfc-editor.org/info/rfc2047>.
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
T. Berners-Lee, "Hypertext Transfer Protocol -- Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
HTTP/1.1", RFC 2068, January 1997. RFC 2068, DOI 10.17487/RFC2068, January 1997,
<https://www.rfc-editor.org/info/rfc2068>.
[RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, [RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use
"Use and Interpretation of HTTP Version Numbers", and Interpretation of HTTP Version Numbers", RFC 2145,
RFC 2145, May 1997. DOI 10.17487/RFC2145, May 1997,
<https://www.rfc-editor.org/info/rfc2145>.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616,
DOI 10.17487/RFC2616, June 1999,
<https://www.rfc-editor.org/info/rfc2616>.
[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
HTTP/1.1", RFC 2817, May 2000. DOI 10.17487/RFC2818, May 2000,
<https://www.rfc-editor.org/info/rfc2818>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web
Replication and Caching Taxonomy", RFC 3040,
DOI 10.17487/RFC3040, January 2001,
<https://www.rfc-editor.org/info/rfc3040>.
[RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Replication and Caching Taxonomy", RFC 3040, Rose, "DNS Security Introduction and Requirements",
January 2001. RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/info/rfc4033>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based
Rose, "DNS Security Introduction and Requirements", Kerberos and NTLM HTTP Authentication in Microsoft
RFC 4033, March 2005. Windows", RFC 4559, DOI 10.17487/RFC4559, June 2006,
<https://www.rfc-editor.org/info/rfc4559>.
[RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
Kerberos and NTLM HTTP Authentication in Microsoft IANA Considerations Section in RFCs", BCP 26, RFC 5226,
Windows", RFC 4559, June 2006. DOI 10.17487/RFC5226, May 2008,
<https://www.rfc-editor.org/info/rfc5226>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
an IANA Considerations Section in RFCs", BCP 26, (TLS) Protocol Version 1.2", RFC 5246,
RFC 5226, May 2008. DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer [RFC5322] Resnick, P., "Internet Message Format", RFC 5322,
Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5322, October 2008,
August 2008. <https://www.rfc-editor.org/info/rfc5322>.
[RFC5322] Resnick, P., "Internet Message Format", RFC 5322, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
October 2008. DOI 10.17487/RFC6265, April 2011,
<https://www.rfc-editor.org/info/rfc6265>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status
April 2011. Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012,
<https://www.rfc-editor.org/info/rfc6585>.
[RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Codes", RFC 6585, April 2012. Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>.
Appendix A. HTTP Version History Appendix A. HTTP Version History
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
skipping to change at page 79, line 21 skipping to change at page 76, line 21
requirements were placed on all HTTP/1.1 requests in order to ensure requirements were placed on all HTTP/1.1 requests in order to ensure
complete adoption. At the time of this writing, most HTTP-based complete adoption. At the time of this writing, most HTTP-based
services are dependent upon the Host header field for targeting services are dependent upon the Host header field for targeting
requests. requests.
A.1.2. Keep-Alive Connections A.1.2. Keep-Alive Connections
In HTTP/1.0, each connection is established by the client prior to In HTTP/1.0, each connection is established by the client prior to
the request and closed by the server after sending the response. the request and closed by the server after sending the response.
However, some implementations implement the explicitly negotiated However, some implementations implement the explicitly negotiated
("Keep-Alive") version of persistent connections described in Section ("Keep-Alive") version of persistent connections described in
19.7.1 of [RFC2068]. Section 19.7.1 of [RFC2068].
Some clients and servers might wish to be compatible with these Some clients and servers might wish to be compatible with these
previous approaches to persistent connections, by explicitly previous approaches to persistent connections, by explicitly
negotiating for them with a "Connection: keep-alive" request header negotiating for them with a "Connection: keep-alive" request header
field. However, some experimental implementations of HTTP/1.0 field. However, some experimental implementations of HTTP/1.0
persistent connections are faulty; for example, if an HTTP/1.0 proxy persistent connections are faulty; for example, if an HTTP/1.0 proxy
server doesn't understand Connection, it will erroneously forward server doesn't understand Connection, it will erroneously forward
that header field to the next inbound server, which would result in a that header field to the next inbound server, which would result in a
hung connection. hung connection.
One attempted solution was the introduction of a Proxy-Connection One attempted solution was the introduction of a Proxy-Connection
header field, targeted specifically at proxies. In practice, this header field, targeted specifically at proxies. In practice, this
was also unworkable, because proxies are often deployed in multiple was also unworkable, because proxies are often deployed in multiple
layers, bringing about the same problem discussed above. layers, bringing about the same problem discussed above.
As a result, clients are encouraged not to send the Proxy-Connection As a result, clients are encouraged not to send the Proxy-Connection
header field in any requests. header field in any requests.
Clients are also encouraged to consider the use of Connection: Clients are also encouraged to consider the use of Connection: keep-
keep-alive in requests carefully; while they can enable persistent alive in requests carefully; while they can enable persistent
connections with HTTP/1.0 servers, clients using them will need to connections with HTTP/1.0 servers, clients using them will need to
monitor the connection for "hung" requests (which indicate that the monitor the connection for "hung" requests (which indicate that the
client ought stop sending the header field), and this mechanism ought client ought stop sending the header field), and this mechanism ought
not be used by clients at all when a proxy is being used. not be used by clients at all when a proxy is being used.
A.1.3. Introduction of Transfer-Encoding A.1.3. Introduction of Transfer-Encoding
HTTP/1.1 introduces the Transfer-Encoding header field HTTP/1.1 introduces the Transfer-Encoding header field
(Section 3.3.1). Transfer codings need to be decoded prior to (Section 3.3.1). Transfer codings need to be decoded prior to
forwarding an HTTP message over a MIME-compliant protocol. forwarding an HTTP message over a MIME-compliant protocol.
A.2. Changes from RFC 2616 A.2. Changes from RFC 7230
HTTP's approach to error handling has been explained. (Section 2.5)
The HTTP-version ABNF production has been clarified to be case-
sensitive. Additionally, version numbers have been restricted to
single digits, due to the fact that implementations are known to
handle multi-digit version numbers incorrectly. (Section 2.6)
Userinfo (i.e., username and password) are now disallowed in HTTP and
HTTPS URIs, because of security issues related to their transmission
on the wire. (Section 2.7.1)
The HTTPS URI scheme is now defined by this specification;
previously, it was done in Section 2.4 of [RFC2818]. Furthermore, it
implies end-to-end security. (Section 2.7.2)
HTTP messages can be (and often are) buffered by implementations;
despite it sometimes being available as a stream, HTTP is
fundamentally a message-oriented protocol. Minimum supported sizes
for various protocol elements have been suggested, to improve
interoperability. (Section 3)
Invalid whitespace around field-names is now required to be rejected,
because accepting it represents a security vulnerability. The ABNF
productions defining header fields now only list the field value.
(Section 3.2)
Rules about implicit linear whitespace between certain grammar
productions have been removed; now whitespace is only allowed where
specifically defined in the ABNF. (Section 3.2.3)
Header fields that span multiple lines ("line folding") are
deprecated. (Section 3.2.4)
The NUL octet is no longer allowed in comment and quoted-string text,
and handling of backslash-escaping in them has been clarified. The
quoted-pair rule no longer allows escaping control characters other
than HTAB. Non-US-ASCII content in header fields and the reason
phrase has been obsoleted and made opaque (the TEXT rule was
removed). (Section 3.2.6)
Bogus Content-Length header fields are now required to be handled as
errors by recipients. (Section 3.3.2)
The algorithm for determining the message body length has been
clarified to indicate all of the special cases (e.g., driven by
methods or status codes) that affect it, and that new protocol
elements cannot define such special cases. CONNECT is a new, special
case in determining message body length. "multipart/byteranges" is no
longer a way of determining message body length detection.
(Section 3.3.3)
The "identity" transfer coding token has been removed. (Sections 3.3
and 4)
Chunk length does not include the count of the octets in the chunk
header and trailer. Line folding in chunk extensions is disallowed.
(Section 4.1)
The meaning of the "deflate" content coding has been clarified.
(Section 4.2.2)
The segment + query components of RFC 3986 have been used to define
the request-target, instead of abs_path from RFC 1808. The
asterisk-form of the request-target is only allowed with the OPTIONS
method. (Section 5.3)
The term "Effective Request URI" has been introduced. (Section 5.5)
Gateways do not need to generate Via header fields anymore.
(Section 5.7.1)
Exactly when "close" connection options have to be sent has been
clarified. Also, "hop-by-hop" header fields are required to appear
in the Connection header field; just because they're defined as hop-
by-hop in this specification doesn't exempt them. (Section 6.1)
The limit of two connections per server has been removed. An
idempotent sequence of requests is no longer required to be retried.
The requirement to retry requests under certain circumstances when
the server prematurely closes the connection has been removed. Also,
some extraneous requirements about when servers are allowed to close
connections prematurely have been removed. (Section 6.3)
The semantics of the Upgrade header field is now defined in responses
other than 101 (this was incorporated from [RFC2817]). Furthermore,
the ordering in the field value is now significant. (Section 6.7)
Empty list elements in list productions (e.g., a list header field
containing ", ,") have been deprecated. (Section 7)
Registration of Transfer Codings now requires IETF Review
(Section 8.4)
This specification now defines the Upgrade Token Registry, previously
defined in Section 7.2 of [RFC2817]. (Section 8.6)
The expectation to support HTTP/0.9 requests has been removed.
(Appendix A)
Issues with the Keep-Alive and Proxy-Connection header fields in None yet.
requests are pointed out, with use of the latter being discouraged
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
] ]
HTTP-name = %x48.54.54.50 ; HTTP HTTP-name = %x48.54.54.50 ; HTTP
HTTP-version = HTTP-name "/" DIGIT "." DIGIT HTTP-version = HTTP-name "/" DIGIT "." DIGIT
Host = uri-host [ ":" port ] Host = uri-host [ ":" port ]
OWS = *( SP / HTAB ) OWS = *( SP / HTAB )
skipping to change at page 85, line 5 skipping to change at page 79, line 27
"^" / "_" / "`" / "|" / "~" / 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, see [RFC3986], Section 3.2.2> uri-host = <host, see [RFC3986], Section 3.2.2>
Appendix C. Change Log
This section is to be removed before publishing as an RFC.
C.1. Since RFC 7230
The changes in this draft are purely editorial:
o Change boilerplate and abstract to indicate the "draft" status,
and update references to ancestor specifications.
o Adjust historical notes.
o Update links to sibling specifications.
o Replace sections listing changes from RFC 2616 by new empty
sections referring to RFC 723x.
o Remove acknowledgements specific to RFC 723x.
o Move "Acknowledgements" to the very end and make them unnumbered.
Index Index
A A
absolute-form (of request-target) 42 absolute-form (of request-target) 41
accelerator 10 accelerator 10
application/http Media Type 63 application/http Media Type 62
asterisk-form (of request-target) 43 asterisk-form (of request-target) 42
authoritative response 67 authoritative response 66
authority-form (of request-target) 42-43 authority-form (of request-target) 42
B B
browser 7 browser 7
C C
Connection header field 50, 55
Content-Length header field 29
cache 11 cache 11
cacheable 12 cacheable 11
captive portal 11 captive portal 11
chunked (Coding Format) 28, 32, 36 chunked (Coding Format) 28, 31, 35
client 7 client 7
close 51, 56 close 50, 55
compress (Coding Format) 38 compress (Coding Format) 38
connection 7 connection 7
Connection header field 51, 56
Content-Length header field 30
D D
Delimiters 26
deflate (Coding Format) 38 deflate (Coding Format) 38
Delimiters 27
downstream 10 downstream 10
E E
effective request URI 45 effective request URI 44
G G
gateway 10
Grammar Grammar
absolute-form 42 absolute-form 41
absolute-path 16 absolute-path 16
absolute-URI 16 absolute-URI 16
ALPHA 6 ALPHA 6
asterisk-form 41, 43 asterisk-form 41-42
authority 16 authority 16
authority-form 42-43 authority-form 41-42
BWS 25 BWS 24
chunk 36 chunk 35
chunk-data 36 chunk-data 35
chunk-ext 36 chunk-ext 35-36
chunk-ext-name 36 chunk-ext-name 36
chunk-ext-val 36 chunk-ext-val 36
chunk-size 36 chunk-size 35
chunked-body 36 chunked-body 35-36
comment 27 comment 27
Connection 51 Connection 50
connection-option 51 connection-option 50
Content-Length 30 Content-Length 30
CR 6 CR 6
CRLF 6 CRLF 6
ctext 27 ctext 27
CTL 6 CTL 6
DIGIT 6 DIGIT 6
DQUOTE 6 DQUOTE 6
field-content 23 field-content 22
field-name 23, 40 field-name 22, 39
field-value 23 field-value 22
field-vchar 23 field-vchar 22
fragment 16 fragment 16
header-field 23, 37 header-field 22, 36
HEXDIG 6 HEXDIG 6
Host 44 Host 43
HTAB 6 HTAB 6
HTTP-message 19 HTTP-message 19
HTTP-name 14 HTTP-name 14
http-URI 17 http-URI 17
HTTP-version 14 HTTP-version 14
https-URI 18 https-URI 18
last-chunk 36 last-chunk 35
LF 6 LF 6
message-body 28 message-body 27
method 21 method 21
obs-fold 23 obs-fold 22
obs-text 27 obs-text 27
OCTET 6 OCTET 6
origin-form 42 origin-form 41
OWS 25 OWS 24
partial-URI 16 partial-URI 16
port 16 port 16
protocol-name 47 protocol-name 47
protocol-version 47 protocol-version 47
pseudonym 47 pseudonym 47
qdtext 27 qdtext 27
query 16 query 16
quoted-pair 27 quoted-pair 27
quoted-string 27 quoted-string 27
rank 39 rank 38
reason-phrase 22 reason-phrase 22
received-by 47 received-by 47
received-protocol 47 received-protocol 47
request-line 21 request-line 21
request-target 41 request-target 41
RWS 25 RWS 24
scheme 16 scheme 16
segment 16 segment 16
SP 6 SP 6
start-line 21 start-line 20
status-code 22 status-code 22
status-line 22 status-line 22
t-codings 39 t-codings 38
t-ranking 39 t-ranking 38
tchar 27 tchar 26
TE 39 TE 38
token 27 token 26
Trailer 40 Trailer 39
trailer-part 37 trailer-part 35-36
transfer-coding 35 transfer-coding 35
Transfer-Encoding 28 Transfer-Encoding 28
transfer-extension 35 transfer-extension 35
transfer-parameter 35 transfer-parameter 35
Upgrade 57 Upgrade 56
uri-host 16 uri-host 16
URI-reference 16 URI-reference 16
VCHAR 6 VCHAR 6
Via 47 Via 47
gzip (Coding Format) 39 gateway 10
gzip (Coding Format) 38
H H
Host header field 43
header field 19 header field 19
header section 19 header section 19
headers 19 headers 19
Host header field 44 http URI scheme 16
http URI scheme 17 https URI scheme 18
https URI scheme 17
I I
inbound 9 inbound 10
interception proxy 11 interception proxy 11
intermediary 9 intermediary 9
M M
Media Type Media Type
application/http 63 application/http 62
message/http 62 message/http 61
message 7 message 7
message/http Media Type 62 message/http Media Type 61
method 21 method 21
N N
non-transforming proxy 49 non-transforming proxy 48
O O
origin server 7 origin server 7
origin-form (of request-target) 42 origin-form (of request-target) 41
outbound 10 outbound 10
P P
phishing 67 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
response 7 response 7
reverse proxy 10 reverse proxy 10
S S
sender 7 sender 7
server 7 server 7
spider 7 spider 7
T T
target resource 40 TE header field 38
target URI 40 Trailer header field 39
TE header field 39
Trailer header field 40
Transfer-Encoding header field 28 Transfer-Encoding header field 28
transforming proxy 49 target URI 40
target resource 40
transforming proxy 48
transparent proxy 11 transparent proxy 11
tunnel 10 tunnel 10
U U
Upgrade header field 57
upstream 9
URI scheme URI scheme
http 17 http 16
https 17 https 18
Upgrade header field 56
upstream 10
user agent 7 user agent 7
V V
Via header field 47 Via header field 46
Acknowledgments
This edition of the HTTP specification builds on the many
contributions that went into RFC 1945, RFC 2068, RFC 2145, and RFC
2616, including substantial contributions made by the previous
authors, editors, and Working Group Chairs: Tim Berners-Lee, Ari
Luotonen, Roy T. Fielding, Henrik Frystyk Nielsen, Jim Gettys,
Jeffrey C. Mogul, Larry Masinter, Paul J. Leach, and Yves Lafon.
See Section 10 of [RFC7230] for additional acknowledgements from
prior revisions.
[[newacks: New acks to be added here.]]
Authors' Addresses Authors' Addresses
Roy T. Fielding (editor) Roy T. Fielding (editor)
Adobe Systems Incorporated Adobe
345 Park Ave 345 Park Ave
San Jose, CA 95110 San Jose, CA 95110
USA USA
EMail: fielding@gbiv.com EMail: fielding@gbiv.com
URI: http://roy.gbiv.com/ URI: http://roy.gbiv.com/
Mark Nottingham (editor)
Fastly
EMail: mnot@mnot.net
URI: https://www.mnot.net/
Julian F. Reschke (editor) Julian F. Reschke (editor)
greenbytes GmbH greenbytes GmbH
Hafenweg 16 Hafenweg 16
Muenster, NW 48155 Muenster, NW 48155
Germany Germany
EMail: julian.reschke@greenbytes.de EMail: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/ URI: http://greenbytes.de/tech/webdav/
 End of changes. 179 change blocks. 
695 lines changed or deleted 607 lines changed or added

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