draft-ietf-httpbis-messaging-00.txt   draft-ietf-httpbis-messaging-01.txt 
HTTP Working Group R. Fielding, Ed. HTTP Working Group R. Fielding, Ed.
Internet-Draft Adobe Internet-Draft Adobe
Obsoletes: 7230 (if approved) M. Nottingham, Ed. Obsoletes: 7230 (if approved) M. Nottingham, Ed.
Intended status: Standards Track Fastly Intended status: Standards Track Fastly
Expires: October 5, 2018 J. Reschke, Ed. Expires: December 2, 2018 J. Reschke, Ed.
greenbytes greenbytes
April 3, 2018 May 31, 2018
Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing HTTP/1.1 Messaging
draft-ietf-httpbis-messaging-00 draft-ietf-httpbis-messaging-01
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 specifies the HTTP/1.1 message syntax,
its associated terminology, defines the "http" and "https" Uniform message parsing, connection management, and related security
Resource Identifier (URI) schemes, defines the HTTP/1.1 message concerns.
syntax and parsing requirements, and describes related security
concerns for implementations.
This document obsoletes RFC 7230. This document obsoletes portions of RFC 7230.
Editorial Note Editorial Note
This note is to be removed before publishing as an RFC. This note is to be removed before publishing as an RFC.
Discussion of this draft takes place on the HTTP working group Discussion of this draft takes place on the HTTP working group
mailing list (ietf-http-wg@w3.org), which is archived at mailing list (ietf-http-wg@w3.org), which is archived at
<http://lists.w3.org/Archives/Public/ietf-http-wg/>. <https://lists.w3.org/Archives/Public/ietf-http-wg/>.
Working Group information can be found at <http://httpwg.github.io/>; Working Group information can be found at <https://httpwg.org/>;
source code and issues list for this draft can be found at source code and issues list for this draft can be found at
<https://github.com/httpwg/http-core>. <https://github.com/httpwg/http-core>.
The changes in this draft are summarized in Appendix C.1. The changes in this draft are summarized in Appendix D.2.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 5, 2018. This Internet-Draft will expire on December 2, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
(https://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
skipping to change at page 2, line 41 skipping to change at page 2, line 38
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 . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 6 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5
2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Message . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 7 2.1. Message Format . . . . . . . . . . . . . . . . . . . . . 6
2.2. Implementation Diversity . . . . . . . . . . . . . . . . 8 2.2. HTTP Version . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Intermediaries . . . . . . . . . . . . . . . . . . . . . 9 2.3. Message Parsing . . . . . . . . . . . . . . . . . . . . . 7
2.4. Caches . . . . . . . . . . . . . . . . . . . . . . . . . 11 3. Request Line . . . . . . . . . . . . . . . . . . . . . . . . 8
2.5. Conformance and Error Handling . . . . . . . . . . . . . 12 3.1. Method . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.6. Protocol Versioning . . . . . . . . . . . . . . . . . . . 13 3.2. Request Target . . . . . . . . . . . . . . . . . . . . . 9
2.7. Uniform Resource Identifiers . . . . . . . . . . . . . . 16 3.2.1. origin-form . . . . . . . . . . . . . . . . . . . . . 10
2.7.1. http URI Scheme . . . . . . . . . . . . . . . . . . . 16 3.2.2. absolute-form . . . . . . . . . . . . . . . . . . . . 10
2.7.2. https URI Scheme . . . . . . . . . . . . . . . . . . 18 3.2.3. authority-form . . . . . . . . . . . . . . . . . . . 11
2.7.3. http and https URI Normalization and Comparison . . . 19 3.2.4. asterisk-form . . . . . . . . . . . . . . . . . . . . 11
3. Message Format . . . . . . . . . . . . . . . . . . . . . . . 19
3.1. Start Line . . . . . . . . . . . . . . . . . . . . . . . 20 3.3. Effective Request URI . . . . . . . . . . . . . . . . . . 12
3.1.1. Request Line . . . . . . . . . . . . . . . . . . . . 21 4. Status Line . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.2. Status Line . . . . . . . . . . . . . . . . . . . . . 22 5. Header Fields . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 22 5.1. Field Parsing . . . . . . . . . . . . . . . . . . . . . . 15
3.2.1. Field Extensibility . . . . . . . . . . . . . . . . . 23 5.2. Obsolete Line Folding . . . . . . . . . . . . . . . . . . 15
3.2.2. Field Order . . . . . . . . . . . . . . . . . . . . . 23 6. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.3. Whitespace . . . . . . . . . . . . . . . . . . . . . 24 6.1. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 17
3.2.4. Field Parsing . . . . . . . . . . . . . . . . . . . . 24 6.2. Content-Length . . . . . . . . . . . . . . . . . . . . . 18
3.2.5. Field Limits . . . . . . . . . . . . . . . . . . . . 26 6.3. Message Body Length . . . . . . . . . . . . . . . . . . . 19
3.2.6. Field Value Components . . . . . . . . . . . . . . . 26 7. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . 21
3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . 27 7.1. Chunked Transfer Coding . . . . . . . . . . . . . . . . . 22
3.3.1. Transfer-Encoding . . . . . . . . . . . . . . . . . . 28 7.1.1. Chunk Extensions . . . . . . . . . . . . . . . . . . 22
3.3.2. Content-Length . . . . . . . . . . . . . . . . . . . 29 7.1.2. Chunked Trailer Part . . . . . . . . . . . . . . . . 23
3.3.3. Message Body Length . . . . . . . . . . . . . . . . . 31 7.1.3. Decoding Chunked . . . . . . . . . . . . . . . . . . 24
3.4. Handling Incomplete Messages . . . . . . . . . . . . . . 33 7.2. Transfer Codings for Compression . . . . . . . . . . . . 24
3.5. Message Parsing Robustness . . . . . . . . . . . . . . . 34 7.3. Transfer Coding Registry . . . . . . . . . . . . . . . . 25
4. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . 34 7.4. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.1. Chunked Transfer Coding . . . . . . . . . . . . . . . . . 35 8. Handling Incomplete Messages . . . . . . . . . . . . . . . . 26
4.1.1. Chunk Extensions . . . . . . . . . . . . . . . . . . 36 9. Connection Management . . . . . . . . . . . . . . . . . . . . 27
4.1.2. Chunked Trailer Part . . . . . . . . . . . . . . . . 36 9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . 27
4.1.3. Decoding Chunked . . . . . . . . . . . . . . . . . . 37 9.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 29
4.2. Compression Codings . . . . . . . . . . . . . . . . . . . 37 9.3. Persistence . . . . . . . . . . . . . . . . . . . . . . . 29
4.2.1. Compress Coding . . . . . . . . . . . . . . . . . . . 38 9.3.1. Retrying Requests . . . . . . . . . . . . . . . . . . 30
4.2.2. Deflate Coding . . . . . . . . . . . . . . . . . . . 38 9.3.2. Pipelining . . . . . . . . . . . . . . . . . . . . . 31
4.2.3. Gzip Coding . . . . . . . . . . . . . . . . . . . . . 38 9.4. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 31
4.3. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 9.5. Failures and Timeouts . . . . . . . . . . . . . . . . . . 32
4.4. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 39 9.6. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 33
5. Message Routing . . . . . . . . . . . . . . . . . . . . . . . 39 9.7. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.1. Identifying a Target Resource . . . . . . . . . . . . . . 40 9.7.1. Upgrade Protocol Names . . . . . . . . . . . . . . . 36
5.2. Connecting Inbound . . . . . . . . . . . . . . . . . . . 40 9.7.2. Upgrade Token Registry . . . . . . . . . . . . . . . 36
5.3. Request Target . . . . . . . . . . . . . . . . . . . . . 41 10. Enclosing Messages as Data . . . . . . . . . . . . . . . . . 37
5.3.1. origin-form . . . . . . . . . . . . . . . . . . . . . 41 10.1. Media Type message/http . . . . . . . . . . . . . . . . 37
5.3.2. absolute-form . . . . . . . . . . . . . . . . . . . . 41 10.2. Media Type application/http . . . . . . . . . . . . . . 38
5.3.3. authority-form . . . . . . . . . . . . . . . . . . . 42 11. Security Considerations . . . . . . . . . . . . . . . . . . . 39
5.3.4. asterisk-form . . . . . . . . . . . . . . . . . . . . 42 11.1. Response Splitting . . . . . . . . . . . . . . . . . . . 39
5.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . 43 11.2. Request Smuggling . . . . . . . . . . . . . . . . . . . 40
5.5. Effective Request URI . . . . . . . . . . . . . . . . . . 44 11.3. Message Integrity . . . . . . . . . . . . . . . . . . . 40
5.6. Associating a Response to a Request . . . . . . . . . . . 46 11.4. Message Confidentiality . . . . . . . . . . . . . . . . 41
5.7. Message Forwarding . . . . . . . . . . . . . . . . . . . 46 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
5.7.1. Via . . . . . . . . . . . . . . . . . . . . . . . . . 46 12.1. Header Field Registration . . . . . . . . . . . . . . . 41
5.7.2. Transformations . . . . . . . . . . . . . . . . . . . 48 12.2. Media Type Registration . . . . . . . . . . . . . . . . 42
6. Connection Management . . . . . . . . . . . . . . . . . . . . 49 12.3. Transfer Coding Registration . . . . . . . . . . . . . . 42
6.1. Connection . . . . . . . . . . . . . . . . . . . . . . . 50 12.4. Upgrade Token Registration . . . . . . . . . . . . . . . 42
6.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 51 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.3. Persistence . . . . . . . . . . . . . . . . . . . . . . . 51 13.1. Normative References . . . . . . . . . . . . . . . . . . 42
6.3.1. Retrying Requests . . . . . . . . . . . . . . . . . . 52 13.2. Informative References . . . . . . . . . . . . . . . . . 43
6.3.2. Pipelining . . . . . . . . . . . . . . . . . . . . . 53 Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 45
6.4. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 54 Appendix B. Differences between HTTP and MIME . . . . . . . . . 46
6.5. Failures and Timeouts . . . . . . . . . . . . . . . . . . 54 B.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . 47
6.6. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 55 B.2. Conversion to Canonical Form . . . . . . . . . . . . . . 47
6.7. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 56 B.3. Conversion of Date Formats . . . . . . . . . . . . . . . 47
7. ABNF List Extension: #rule . . . . . . . . . . . . . . . . . 58 B.4. Conversion of Content-Encoding . . . . . . . . . . . . . 48
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59 B.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 48
8.1. Header Field Registration . . . . . . . . . . . . . . . . 59 B.6. MHTML and Line Length Limitations . . . . . . . . . . . . 48
8.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 60 Appendix C. HTTP Version History . . . . . . . . . . . . . . . . 48
8.3. Internet Media Type Registration . . . . . . . . . . . . 60 C.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 49
8.3.1. Internet Media Type message/http . . . . . . . . . . 61 C.1.1. Multihomed Web Servers . . . . . . . . . . . . . . . 49
8.3.2. Internet Media Type application/http . . . . . . . . 62 C.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . 50
8.4. Transfer Coding Registry . . . . . . . . . . . . . . . . 63 C.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 50
8.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 63 C.2. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 50
8.4.2. Registration . . . . . . . . . . . . . . . . . . . . 64 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 51
8.5. Content Coding Registration . . . . . . . . . . . . . . . 64 D.1. Between RFC7230 and draft 00 . . . . . . . . . . . . . . 51
8.6. Upgrade Token Registry . . . . . . . . . . . . . . . . . 65 D.2. Since draft-ietf-httpbis-messaging-00 . . . . . . . . . . 51
8.6.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 65 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
8.6.2. Upgrade Token Registration . . . . . . . . . . . . . 65 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 54
9. Security Considerations . . . . . . . . . . . . . . . . . . . 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54
9.1. Establishing Authority . . . . . . . . . . . . . . . . . 66
9.2. Risks of Intermediaries . . . . . . . . . . . . . . . . . 67
9.3. Attacks via Protocol Element Length . . . . . . . . . . . 67
9.4. Response Splitting . . . . . . . . . . . . . . . . . . . 68
9.5. Request Smuggling . . . . . . . . . . . . . . . . . . . . 69
9.6. Message Integrity . . . . . . . . . . . . . . . . . . . . 69
9.7. Message Confidentiality . . . . . . . . . . . . . . . . . 70
9.8. Privacy of Server Log Information . . . . . . . . . . . . 70
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 70
10.1. Normative References . . . . . . . . . . . . . . . . . . 70
10.2. Informative References . . . . . . . . . . . . . . . . . 72
Appendix A. HTTP Version History . . . . . . . . . . . . . . . . 75
A.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 75
A.1.1. Multihomed Web Servers . . . . . . . . . . . . . . . 75
A.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . 76
A.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 76
A.2. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 77
Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 77
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 79
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 messages for flexible interaction with network-based
network-based hypertext information systems. This document is the hypertext information systems. HTTP is defined by a series of
first in a series of documents that collectively form the HTTP/1.1 documents that collectively form the HTTP/1.1 specification:
specification:
1. "Message Syntax and Routing" (this document)
2. "Semantics and Content" [SEMNTCS]
3. "Conditional Requests" [CONDTNL]
4. "Range Requests" [RANGERQ]
5. "Caching" [CACHING]
6. "Authentication" [AUTHFRM]
This specification obsoletes RFC 7230, with the changes being
summarized in Appendix A.2.
HTTP is a generic interface protocol for information systems. It is o "HTTP Semantics" [Semantics]
designed to hide the details of how a service is implemented by
presenting a uniform interface to clients that is independent of the
types of resources provided. Likewise, servers do not need to be
aware of each client's purpose: an HTTP request can be considered in
isolation rather than being associated with a specific type of client
or a predetermined sequence of application steps. The result is a
protocol that can be used effectively in many different contexts and
for which implementations can evolve independently over time.
HTTP is also designed for use as an intermediation protocol for o "HTTP Caching" [Caching]
translating communication to and from non-HTTP information systems.
HTTP proxies and gateways can provide access to alternative
information services by translating their diverse protocols into a
hypertext format that can be viewed and manipulated by clients in the
same way as HTTP services.
One consequence of this flexibility is that the protocol cannot be o "HTTP/1.1 Messaging" (this document)
defined in terms of what occurs behind the interface. Instead, we
are limited to defining the syntax of communication, the intent of
received communication, and the expected behavior of recipients. If
the communication is considered in isolation, then successful actions
ought to be reflected in corresponding changes to the observable
interface provided by servers. However, since multiple clients might
act in parallel and perhaps at cross-purposes, we cannot require that
such changes be observable beyond the scope of a single response.
This document describes the architectural elements that are used or This document defines HTTP/1.1 message syntax and framing
referred to in HTTP, defines the "http" and "https" URI schemes, requirements and their associated connection management. Our goal is
describes overall network operation and connection management, and to define all of the mechanisms necessary for HTTP/1.1 message
defines HTTP message framing and forwarding requirements. Our goal
is to define all of the mechanisms necessary for HTTP message
handling that are independent of message semantics, thereby defining handling that are independent of message semantics, thereby defining
the complete set of requirements for message parsers and message- the complete set of requirements for message parsers and message-
forwarding intermediaries. forwarding intermediaries.
This document obsoletes the portions of RFC 7230 related to HTTP/1.1
messaging and connection management, with the changes being
summarized in Appendix C.2. The other parts of RFC 7230 are
obsoleted by "HTTP Semantics" [Semantics].
1.1. Requirements Notation 1.1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Conformance criteria and considerations regarding error handling are Conformance criteria and considerations regarding error handling are
defined in Section 2.5. defined in Section 3 of [Semantics].
1.2. Syntax Notation 1.2. Syntax Notation
This specification uses the Augmented Backus-Naur Form (ABNF) This specification uses the Augmented Backus-Naur Form (ABNF)
notation of [RFC5234] with a list extension, defined in Section 7, notation of [RFC5234] with a list extension, defined in Section 11 of
that allows for compact definition of comma-separated lists using a [Semantics], that allows for compact definition of comma-separated
'#' operator (similar to how the '*' operator indicates repetition). lists using a '#' operator (similar to how the '*' operator indicates
Appendix B shows the collected grammar with all list operators repetition). Appendix A shows the collected grammar with all list
expanded to standard ABNF notation. operators expanded to standard ABNF notation.
As a convention, ABNF rule names prefixed with "obs-" denote
"obsolete" grammar rules that appear for historical reasons.
The following core rules are included by reference, as defined in The following core rules are included by reference, as defined in
[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
(CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line
feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any
visible [USASCII] character). visible [USASCII] character).
As a convention, ABNF rule names prefixed with "obs-" denote The rules below are defined in [Semantics]:
"obsolete" grammar rules that appear for historical reasons.
2. Architecture
HTTP was created for the World Wide Web (WWW) architecture and has
evolved over time to support the scalability needs of a worldwide
hypertext system. Much of that architecture is reflected in the
terminology and syntax productions used to define HTTP.
2.1. Client/Server Messaging
HTTP is a stateless request/response protocol that operates by
exchanging messages (Section 3) across a reliable transport- or
session-layer "connection" (Section 6). An HTTP "client" is a
program that establishes a connection to a server for the purpose of
sending one or more HTTP requests. An HTTP "server" is a program
that accepts connections in order to service HTTP requests by sending
HTTP responses.
The terms "client" and "server" refer only to the roles that these
programs perform for a particular connection. The same program might
act as a client on some connections and a server on others. The term
"user agent" refers to any of the various client programs that
initiate a request, including (but not limited to) browsers, spiders
(web-based robots), command-line tools, custom applications, and
mobile apps. The term "origin server" refers to the program that can
originate authoritative responses for a given target resource. The
terms "sender" and "recipient" refer to any implementation that sends
or receives a given message, respectively.
HTTP relies upon the Uniform Resource Identifier (URI) standard
[RFC3986] to indicate the target resource (Section 5.1) and
relationships between resources. Messages are passed in a format
similar to that used by Internet mail [RFC5322] and the Multipurpose
Internet Mail Extensions (MIME) [RFC2045] (see Appendix A of
[SEMNTCS] for the differences between HTTP and MIME messages).
Most HTTP communication consists of a retrieval request (GET) for a
representation of some resource identified by a URI. In the simplest
case, this might be accomplished via a single bidirectional
connection (===) between the user agent (UA) and the origin server
(O).
request >
UA ======================================= O
< response
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,
and protocol version (Section 3.1.1), followed by header fields
containing request modifiers, client information, and representation
metadata (Section 3.2), an empty line to indicate the end of the
header section, and finally a message body containing the payload
body (if any, Section 3.3).
A server responds to a client's request by sending one or more HTTP
response messages, each beginning with a status line that includes
the protocol version, a success or error code, and textual reason
phrase (Section 3.1.2), possibly followed by header fields containing
server information, resource metadata, and representation metadata
(Section 3.2), an empty line to indicate the end of the header
section, and finally a message body containing the payload body (if
any, Section 3.3).
A connection might be used for multiple request/response exchanges,
as defined in Section 6.3.
The following example illustrates a typical message exchange for a
GET request (Section 4.3.1 of [SEMNTCS]) on the URI
"http://www.example.com/hello.txt":
Client request:
GET /hello.txt HTTP/1.1
User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
Host: www.example.com
Accept-Language: en, mi
Server response:
HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Accept-Ranges: bytes
Content-Length: 51
Vary: Accept-Encoding
Content-Type: text/plain
Hello World! My payload includes a trailing CRLF.
2.2. Implementation Diversity
When considering the design of HTTP, it is easy to fall into a trap
of thinking that all user agents are general-purpose browsers and all
origin servers are large public websites. That is not the case in
practice. Common HTTP user agents include household appliances,
stereos, scales, firmware update scripts, command-line programs,
mobile apps, and communication devices in a multitude of shapes and
sizes. Likewise, common HTTP origin servers include home automation
units, configurable networking components, office machines,
autonomous robots, news feeds, traffic cameras, ad selectors, and
video-delivery platforms.
The term "user agent" does not imply that there is a human user
directly interacting with the software agent at the time of a
request. In many cases, a user agent is installed or configured to
run in the background and save its results for later inspection (or
save only a subset of those results that might be interesting or
erroneous). Spiders, for example, are typically given a start URI
and configured to follow certain behavior while crawling the Web as a
hypertext graph.
The implementation diversity of HTTP means that not all user agents
can make interactive suggestions to their user or provide adequate
warning for security or privacy concerns. In the few cases where
this specification requires reporting of errors to the user, it is
acceptable for such reporting to only be observable in an error
console or log file. Likewise, requirements that an automated action
be confirmed by the user before proceeding might be met via advance
configuration choices, run-time options, or simple avoidance of the
unsafe action; confirmation does not imply any specific user
interface or interruption of normal processing if the user has
already made that choice.
2.3. Intermediaries
HTTP enables the use of intermediaries to satisfy requests through a
chain of connections. There are three common forms of HTTP
intermediary: proxy, gateway, and tunnel. In some cases, a single
intermediary might act as an origin server, proxy, gateway, or
tunnel, switching behavior based on the nature of each request.
> > > >
UA =========== A =========== B =========== C =========== O
< < < <
The figure above shows three intermediaries (A, B, and C) between the
user agent and origin server. A request or response message that
travels the whole chain will pass through four separate connections.
Some HTTP communication options might apply only to the connection
with the nearest, non-tunnel neighbor, only to the endpoints of the
chain, or to all connections along the chain. Although the diagram
is linear, each participant might be engaged in multiple,
simultaneous communications. For example, B might be receiving
requests from many clients other than A, and/or forwarding requests
to servers other than C, at the same time that it is handling A's
request. Likewise, later requests might be sent through a different
path of connections, often based on dynamic configuration for load
balancing.
The terms "upstream" and "downstream" are used to describe
directional requirements in relation to the message flow: all
messages flow from upstream to downstream. The terms "inbound" and
"outbound" are used to describe directional requirements in relation
to the request route: "inbound" means toward the origin server and
"outbound" means toward the user agent.
A "proxy" is a message-forwarding agent that is selected by the
client, usually via local configuration rules, to receive requests
for some type(s) of absolute URI and attempt to satisfy those
requests via translation through the HTTP interface. Some
translations are minimal, such as for proxy requests for "http" URIs,
whereas other requests might require translation to and from entirely
different application-level protocols. Proxies are often used to
group an organization's HTTP requests through a common intermediary
for the sake of security, annotation services, or shared caching.
Some proxies are designed to apply transformations to selected
messages or payloads while they are being forwarded, as described in
Section 5.7.2.
A "gateway" (a.k.a. "reverse proxy") is an intermediary that acts as
an origin server for the outbound connection but translates received
requests and forwards them inbound to another server or servers.
Gateways are often used to encapsulate legacy or untrusted
information services, to improve server performance through
"accelerator" caching, and to enable partitioning or load balancing
of HTTP services across multiple machines.
All HTTP requirements applicable to an origin server also apply to
the outbound communication of a gateway. A gateway communicates with
inbound servers using any protocol that it desires, including private
extensions to HTTP that are outside the scope of this specification.
However, an HTTP-to-HTTP gateway that wishes to interoperate with
third-party HTTP servers ought to conform to user agent requirements
on the gateway's inbound connection.
A "tunnel" acts as a blind relay between two connections without
changing the messages. Once active, a tunnel is not considered a
party to the HTTP communication, though the tunnel might have been
initiated by an HTTP request. A tunnel ceases to exist when both
ends of the relayed connection are closed. Tunnels are used to
extend a virtual connection through an intermediary, such as when
Transport Layer Security (TLS, [RFC5246]) is used to establish
confidential communication through a shared firewall proxy.
The above categories for intermediary only consider those acting as
participants in the HTTP communication. There are also
intermediaries that can act on lower layers of the network protocol
stack, filtering or redirecting HTTP traffic without the knowledge or
permission of message senders. Network intermediaries are
indistinguishable (at a protocol level) from a man-in-the-middle
attack, often introducing security flaws or interoperability problems
due to mistakenly violating HTTP semantics.
For example, an "interception proxy" [RFC3040] (also commonly known
as a "transparent proxy" [RFC1919] or "captive portal") differs from
an HTTP proxy because it is not selected by the client. Instead, an
interception proxy filters or redirects outgoing TCP port 80 packets
(and occasionally other common port traffic). Interception proxies
are commonly found on public network access points, as a means of
enforcing account subscription prior to allowing use of non-local
Internet services, and within corporate firewalls to enforce network
usage policies.
HTTP is defined as a stateless protocol, meaning that each request
message can be understood in isolation. Many implementations depend
on HTTP's stateless design in order to reuse proxied connections or
dynamically load balance requests across multiple servers. Hence, a
server MUST NOT assume that two requests on the same connection are
from the same user agent unless the connection is secured and
specific to that agent. Some non-standard HTTP extensions (e.g.,
[RFC4559]) have been known to violate this requirement, resulting in
security and interoperability problems.
2.4. Caches
A "cache" is a local store of previous response messages and the
subsystem that controls its message storage, retrieval, and deletion.
A cache stores cacheable responses in order to reduce the response
time and network bandwidth consumption on future, equivalent
requests. Any client or server MAY employ a cache, though a cache
cannot be used by a server while it is acting as a tunnel.
The effect of a cache is that the request/response chain is shortened
if one of the participants along the chain has a cached response
applicable to that request. The following illustrates the resulting
chain if B has a cached copy of an earlier response from O (via C)
for a request that has not been cached by UA or A.
> >
UA =========== A =========== B - - - - - - C - - - - - - O
< <
A response is "cacheable" if a cache is allowed to store a copy of
the response message for use in answering subsequent requests. Even
when a response is cacheable, there might be additional constraints
placed by the client or by the origin server on when that cached
response can be used for a particular request. HTTP requirements for
cache behavior and cacheable responses are defined in Section 2 of
[CACHING].
There is a wide variety of architectures and configurations of caches
deployed across the World Wide Web and inside large organizations.
These include national hierarchies of proxy caches to save
transoceanic bandwidth, collaborative systems that broadcast or
multicast cache entries, archives of pre-fetched cache entries for
use in off-line or high-latency environments, and so on.
2.5. Conformance and Error Handling
This specification targets conformance criteria according to the role BWS = <BWS, see [Semantics], Section 4.3>
of a participant in HTTP communication. Hence, HTTP requirements are OWS = <OWS, see [Semantics], Section 4.3>
placed on senders, recipients, clients, servers, user agents, RWS = <RWS, see [Semantics], Section 4.3>
intermediaries, origin servers, proxies, gateways, or caches, absolute-URI = <absolute-URI, see [RFC3986], Section 4.3>
depending on what behavior is being constrained by the requirement. absolute-path = <absolute-path, see [Semantics], Section 2.4>
Additional (social) requirements are placed on implementations, authority = <authority, see [RFC3986], Section 3.2>
resource owners, and protocol element registrations when they apply comment = <comment, see [Semantics], Section 4.2.3>
beyond the scope of a single communication. field-name = <field-name, see [Semantics], Section 4.2>
field-value = <field-value, see [Semantics], Section 4.2>
obs-text = <obs-text, see [Semantics], Section 4.2.3>
port = <port, see [RFC3986], Section 3.2.3>
query = <query, see [RFC3986], Section 3.4>
quoted-string = <quoted-string, see [Semantics], Section 4.2.3>
token = <token, see [Semantics], Section 4.2.3>
uri-host = <host, see [RFC3986], Section 3.2.2>
The verb "generate" is used instead of "send" where a requirement 2. Message
differentiates between creating a protocol element and merely
forwarding a received element downstream.
An implementation is considered conformant if it complies with all of 2.1. Message Format
the requirements associated with the roles it partakes in HTTP.
Conformance includes both the syntax and semantics of protocol All HTTP/1.1 messages consist of a start-line followed by a sequence
elements. A sender MUST NOT generate protocol elements that convey a of octets in a format similar to the Internet Message Format
meaning that is known by that sender to be false. A sender MUST NOT [RFC5322]: zero or more header fields (collectively referred to as
generate protocol elements that do not match the grammar defined by the "headers" or the "header section"), an empty line indicating the
the corresponding ABNF rules. Within a given message, a sender MUST end of the header section, and an optional message body.
NOT generate protocol elements or syntax alternatives that are only
allowed to be generated by participants in other roles (i.e., a role
that the sender does not have for that message).
When a received protocol element is parsed, the recipient MUST be HTTP-message = start-line
able to parse any value of reasonable length that is applicable to *( header-field CRLF )
the recipient's role and that matches the grammar defined by the CRLF
corresponding ABNF rules. Note, however, that some received protocol [ message-body ]
elements might not be parsed. For example, an intermediary
forwarding a message might parse a header-field into generic field-
name and field-value components, but then forward the header field
without further parsing inside the field-value.
HTTP does not have specific length limitations for many of its An HTTP message can be either a request from client to server or a
protocol elements because the lengths that might be appropriate will response from server to client. Syntactically, the two types of
vary widely, depending on the deployment context and purpose of the message differ only in the start-line, which is either a request-line
implementation. Hence, interoperability between senders and (for requests) or a status-line (for responses), and in the algorithm
recipients depends on shared expectations regarding what is a for determining the length of the message body (Section 6).
reasonable length for each protocol element. Furthermore, what is
commonly understood to be a reasonable length for some protocol
elements has changed over the course of the past two decades of HTTP
use and is expected to continue changing in the future.
At a minimum, a recipient MUST be able to parse and process protocol start-line = request-line / status-line
element lengths that are at least as long as the values that it
generates for those same protocol elements in other messages. For
example, an origin server that publishes very long URI references to
its own resources needs to be able to parse and process those same
references when received as a request target.
A recipient MUST interpret a received protocol element according to In theory, a client could receive requests and a server could receive
the semantics defined for it by this specification, including responses, distinguishing them by their different start-line formats.
extensions to this specification, unless the recipient has determined In practice, servers are implemented to only expect a request (a
(through experience or configuration) that the sender incorrectly response is interpreted as an unknown or invalid request method) and
implements what is implied by those semantics. For example, an clients are implemented to only expect a response.
origin server might disregard the contents of a received Accept-
Encoding header field if inspection of the User-Agent header field
indicates a specific implementation version that is known to fail on
receipt of certain content codings.
Unless noted otherwise, a recipient MAY attempt to recover a usable [[CREF1: Although HTTP makes use of some protocol elements similar to
protocol element from an invalid construct. HTTP does not define the Multipurpose Internet Mail Extensions (MIME) [RFC2045], see
specific error handling mechanisms except when they have a direct Appendix B for the differences between HTTP and MIME messages.]]
impact on security, since different applications of the protocol
require different error handling strategies. For example, a Web
browser might wish to transparently recover from a response where the
Location header field doesn't parse according to the ABNF, whereas a
systems control client might consider any form of error recovery to
be dangerous.
2.6. Protocol Versioning 2.2. HTTP Version
HTTP uses a "<major>.<minor>" numbering scheme to indicate versions HTTP uses a "<major>.<minor>" numbering scheme to indicate versions
of the protocol. This specification defines version "1.1". The of the protocol. This specification defines version "1.1".
protocol version as a whole indicates the sender's conformance with Section 3.5 of [Semantics] specifies the semantics of HTTP version
the set of requirements laid out in that version's corresponding numbers.
specification of HTTP.
The version of an HTTP message is indicated by an HTTP-version field The version of an HTTP/1.x message is indicated by an HTTP-version
in the first line of the message. HTTP-version is case-sensitive. field in the start-line. HTTP-version is case-sensitive.
HTTP-version = HTTP-name "/" DIGIT "." DIGIT HTTP-version = HTTP-name "/" DIGIT "." DIGIT
HTTP-name = %x48.54.54.50 ; "HTTP", case-sensitive HTTP-name = %x48.54.54.50 ; "HTTP", case-sensitive
The HTTP version number consists of two decimal digits separated by a
"." (period or decimal point). The first digit ("major version")
indicates the HTTP messaging syntax, whereas the second digit ("minor
version") indicates the highest minor version within that major
version to which the sender is conformant and able to understand for
future communication. The minor version advertises the sender's
communication capabilities even when the sender is only using a
backwards-compatible subset of the protocol, thereby letting the
recipient know that more advanced features can be used in response
(by servers) or in future requests (by clients).
When an HTTP/1.1 message is sent to an HTTP/1.0 recipient [RFC1945] When an HTTP/1.1 message is sent to an HTTP/1.0 recipient [RFC1945]
or a recipient whose version is unknown, the HTTP/1.1 message is or a recipient whose version is unknown, the HTTP/1.1 message is
constructed such that it can be interpreted as a valid HTTP/1.0 constructed such that it can be interpreted as a valid HTTP/1.0
message if all of the newer features are ignored. This specification message if all of the newer features are ignored. This specification
places recipient-version requirements on some new features so that a places recipient-version requirements on some new features so that a
conformant sender will only use compatible features until it has conformant sender will only use compatible features until it has
determined, through configuration or the receipt of a message, that determined, through configuration or the receipt of a message, that
the recipient supports HTTP/1.1. the recipient supports HTTP/1.1.
The interpretation of a header field does not change between minor
versions of the same major HTTP version, though the default behavior
of a recipient in the absence of such a field can change. Unless
specified otherwise, header fields defined in HTTP/1.1 are defined
for all versions of HTTP/1.x. In particular, the Host and Connection
header fields ought to be implemented by all HTTP/1.x implementations
whether or not they advertise conformance with HTTP/1.1.
New header fields can be introduced without changing the protocol
version if their defined semantics allow them to be safely ignored by
recipients that do not recognize them. Header field extensibility is
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 start-line without ensuring that the protocol
that the protocol version in that message matches a version to which version in that message matches a version to which that intermediary
that intermediary is conformant for both the receiving and sending of is conformant for both the receiving and sending of messages.
messages. Forwarding an HTTP message without rewriting the HTTP- Forwarding an HTTP message without rewriting the HTTP-version might
version might result in communication errors when downstream result in communication errors when downstream recipients use the
recipients use the message sender's version to determine what message sender's version to determine what features are safe to use
features are safe to use for later communication with that sender. for later communication with that sender.
A client SHOULD send a request version equal to the highest version
to which the client is conformant and whose major version is no
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
conformant.
A client MAY send a lower request version if it is known that the
server incorrectly implements the HTTP specification, but only after
the client has attempted at least one normal request and determined
from the response status code or header fields (e.g., Server) that
the server improperly handles higher request versions.
A server SHOULD send a response version equal to the highest version
to which the server is conformant that has a major version less than
or equal to the one received in the request. A server MUST NOT send
a version to which it is not conformant. A server can send a 505
(HTTP Version Not Supported) response if it wishes, for any reason,
to refuse service of the client's major protocol version.
A server MAY send an HTTP/1.0 response to a request if it is known or A server MAY send an HTTP/1.0 response to an HTTP/1.1 request if it
suspected that the client incorrectly implements the HTTP is known or suspected that the client incorrectly implements the HTTP
specification and is incapable of correctly processing later version specification and is incapable of correctly processing later version
responses, such as when a client fails to parse the version number responses, such as when a client fails to parse the version number
correctly or when an intermediary is known to blindly forward the correctly or when an intermediary is known to blindly forward the
HTTP-version even when it doesn't conform to the given minor version HTTP-version even when it doesn't conform to the given minor version
of the protocol. Such protocol downgrades SHOULD NOT be performed of the protocol. Such protocol downgrades SHOULD NOT be performed
unless triggered by specific client attributes, such as when one or unless triggered by specific client attributes, such as when one or
more of the request header fields (e.g., User-Agent) uniquely match more of the request header fields (e.g., User-Agent) uniquely match
the values sent by a client known to be in error. the values sent by a client known to be in error.
The intention of HTTP's versioning design is that the major number 2.3. Message Parsing
will only be incremented if an incompatible message syntax is
introduced, and that the minor number will only be incremented when
changes made to the protocol have the effect of adding to the message
semantics or implying additional capabilities of the sender.
However, the minor version was not incremented for the changes
introduced between [RFC2068] and [RFC2616], and this revision has
specifically avoided any such changes to the protocol.
When an HTTP message is received with a major version number that the
recipient implements, but a higher minor version number than what the
recipient implements, the recipient SHOULD process the message as if
it were in the highest minor version within that major version to
which the recipient is conformant. A recipient can assume that a
message with a higher minor version, when sent to a recipient that
has not yet indicated support for that higher version, is
sufficiently backwards-compatible to be safely processed by any
implementation of the same major version.
2.7. Uniform Resource Identifiers
Uniform Resource Identifiers (URIs) [RFC3986] are used throughout
HTTP as the means for identifying resources (Section 2 of [SEMNTCS]).
URI references are used to target requests, indicate redirects, and
define relationships.
The definitions of "URI-reference", "absolute-URI", "relative-part",
"scheme", "authority", "port", "host", "path-abempty", "segment",
"query", and "fragment" are adopted from the URI generic syntax. An
"absolute-path" rule is defined for protocol elements that can
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
be used in references, and path-absolute rule, which does not allow
paths that begin with "//".) A "partial-URI" rule is defined for
protocol elements that can contain a relative URI but not a fragment
component.
URI-reference = <URI-reference, see [RFC3986], Section 4.1>
absolute-URI = <absolute-URI, see [RFC3986], Section 4.3>
relative-part = <relative-part, see [RFC3986], Section 4.2>
scheme = <scheme, see [RFC3986], Section 3.1>
authority = <authority, see [RFC3986], Section 3.2>
uri-host = <host, see [RFC3986], Section 3.2.2>
port = <port, see [RFC3986], Section 3.2.3>
path-abempty = <path-abempty, see [RFC3986], Section 3.3>
segment = <segment, see [RFC3986], Section 3.3>
query = <query, see [RFC3986], Section 3.4>
fragment = <fragment, see [RFC3986], Section 3.5>
absolute-path = 1*( "/" segment )
partial-URI = relative-part [ "?" query ]
Each protocol element in HTTP that allows a URI reference will
indicate in its ABNF production whether the element allows any form
of reference (URI-reference), only a URI in absolute form (absolute-
URI), only the path and optional query components, or some
combination of the above. Unless otherwise indicated, URI references
are parsed relative to the effective request URI (Section 5.5).
2.7.1. http URI Scheme
The "http" URI scheme is hereby defined for the purpose of minting
identifiers according to their association with the hierarchical
namespace governed by a potential HTTP origin server listening for
TCP ([RFC0793]) connections on a given port.
http-URI = "http:" "//" authority path-abempty [ "?" query ]
[ "#" fragment ]
The origin server for an "http" URI is identified by the authority
component, which includes a host identifier and optional TCP port
([RFC3986], Section 3.2.2). The hierarchical path component and
optional query component serve as an identifier for a potential
target resource within that origin server's name space. The optional
fragment component allows for indirect identification of a secondary
resource, independent of the URI scheme, as defined in Section 3.5 of
[RFC3986].
A sender MUST NOT generate an "http" URI with an empty host
identifier. A recipient that processes such a URI reference MUST
reject it as invalid.
If the host identifier is provided as an IP address, the origin
server is the listener (if any) on the indicated TCP port at that IP
address. If host is a registered name, the registered name is an
indirect identifier for use with a name resolution service, such as
DNS, to find an address for that origin server. If the port
subcomponent is empty or not given, TCP port 80 (the reserved port
for WWW services) is the default.
Note that the presence of a URI with a given authority component does
not imply that there is always an HTTP server listening for
connections on that host and port. Anyone can mint a URI. What the
authority component determines is who has the right to respond
authoritatively to requests that target the identified resource. The
delegated nature of registered names and IP addresses creates a
federated namespace, based on control over the indicated host and
port, whether or not an HTTP server is present. See Section 9.1 for
security considerations related to establishing authority.
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
host to an IP address, establishing a TCP connection to that address
on the indicated port, and sending an HTTP request message
(Section 3) containing the URI's identifying data (Section 5) to the
server. If the server responds to that request with a non-interim
HTTP response message, as described in Section 6 of [SEMNTCS], then
that response is considered an authoritative answer to the client's
request.
Although HTTP is independent of the transport protocol, the "http"
scheme is specific to TCP-based services because the name delegation
process depends on TCP for establishing authority. An HTTP service
based on some other underlying connection protocol would presumably
be identified using a different URI scheme, just as the "https"
scheme (below) is used for resources that require an end-to-end
secured connection. Other protocols might also be used to provide
access to "http" identified resources -- it is only the authoritative
interface that is specific to TCP.
The URI generic syntax for authority also includes a deprecated
userinfo subcomponent ([RFC3986], Section 3.2.1) for including user
authentication information in the URI. Some implementations make use
of the userinfo component for internal configuration of
authentication information, such as within command invocation
options, configuration files, or bookmark lists, even though such
usage might expose a user identifier or password. A sender MUST NOT
generate the userinfo subcomponent (and its "@" delimiter) when an
"http" URI reference is generated within a message as a request
target or header field value. Before making use of an "http" URI
reference received from an untrusted source, a recipient SHOULD parse
for userinfo and treat its presence as an error; it is likely being
used to obscure the authority for the sake of phishing attacks.
2.7.2. https URI Scheme
The "https" URI scheme is hereby defined for the purpose of minting
identifiers according to their association with the hierarchical
namespace governed by a potential HTTP origin server listening to a
given TCP port for TLS-secured connections ([RFC5246]).
All of the requirements listed above for the "http" scheme are also
requirements for the "https" scheme, except that TCP port 443 is the
default if the port subcomponent is empty or not given, and the user
agent MUST ensure that its connection to the origin server is secured
through the use of strong encryption, end-to-end, prior to sending
the first HTTP request.
https-URI = "https:" "//" authority path-abempty [ "?" query ]
[ "#" fragment ]
Note that the "https" URI scheme depends on both TLS and TCP for
establishing authority. Resources made available via the "https"
scheme have no shared identity with the "http" scheme even if their
resource identifiers indicate the same authority (the same host
listening to the same TCP port). They are distinct namespaces and
are considered to be distinct origin servers. However, an extension
to HTTP that is defined to apply to entire host domains, such as the
Cookie protocol [RFC6265], can allow information set by one service
to impact communication with other services within a matching group
of host domains.
The process for authoritative access to an "https" identified
resource is defined in [RFC2818].
2.7.3. http and https URI Normalization and Comparison
Since the "http" and "https" schemes conform to the URI generic
syntax, such URIs are normalized and compared according to the
algorithm defined in Section 6 of [RFC3986], using the defaults
described above for each scheme.
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
absolute form as the request target of an OPTIONS request, an empty
path component is equivalent to an absolute path of "/", so the
normal form is to provide a path of "/" instead. The scheme and host
are case-insensitive and normally provided in lowercase; all other
components are compared in a case-sensitive manner. Characters other
than those in the "reserved" set are equivalent to their percent-
encoded octets: the normal form is to not encode them (see Sections
2.1 and 2.2 of [RFC3986]).
For example, the following three URIs are equivalent:
http://example.com:80/~smith/home.html
http://EXAMPLE.com/%7Esmith/home.html
http://EXAMPLE.com:/%7esmith/home.html
3. Message Format
All HTTP/1.1 messages consist of a start-line followed by a sequence
of octets in a format similar to the Internet Message Format
[RFC5322]: zero or more header fields (collectively referred to as
the "headers" or the "header section"), an empty line indicating the
end of the header section, and an optional message body.
HTTP-message = start-line
*( header-field CRLF )
CRLF
[ message-body ]
The normal procedure for parsing an HTTP message is to read the The normal procedure for parsing an HTTP message is to read the
start-line into a structure, read each header field into a hash table start-line into a structure, read each header field into a hash table
by field name until the empty line, and then use the parsed data to by field name until the empty line, and then use the parsed data to
determine if a message body is expected. If a message body has been determine if a message body is expected. If a message body has been
indicated, then it is read as a stream until an amount of octets indicated, then it is read as a stream until an amount of octets
equal to the message body length is read or the connection is closed. equal to the message body length is read or the connection is closed.
A recipient MUST parse an HTTP message as a sequence of octets in an A recipient MUST parse an HTTP message as a sequence of octets in an
encoding that is a superset of US-ASCII [USASCII]. Parsing an HTTP encoding that is a superset of US-ASCII [USASCII]. Parsing an HTTP
message as a stream of Unicode characters, without regard for the message as a stream of Unicode characters, without regard for the
specific encoding, creates security vulnerabilities due to the specific encoding, creates security vulnerabilities due to the
varying ways that string processing libraries handle invalid varying ways that string processing libraries handle invalid
multibyte character sequences that contain the octet LF (%x0A). multibyte character sequences that contain the octet LF (%x0A).
String-based parsers can only be safely used within protocol elements String-based parsers can only be safely used within protocol elements
after the element has been extracted from the message, such as within after the element has been extracted from the message, such as within
a header field-value after message parsing has delineated the a header field-value after message parsing has delineated the
individual fields. individual fields.
An HTTP message can be parsed as a stream for incremental processing Although the line terminator for the start-line and header fields is
or forwarding downstream. However, recipients cannot rely on the sequence CRLF, a recipient MAY recognize a single LF as a line
incremental delivery of partial messages, since some implementations terminator and ignore any preceding CR.
will buffer or delay message forwarding for the sake of network
efficiency, security checks, or payload transformations. Older HTTP/1.0 user agent implementations might send an extra CRLF
after a POST request as a workaround for some early server
applications that failed to read message body content that was not
terminated by a line-ending. An HTTP/1.1 user agent MUST NOT preface
or follow a request with an extra CRLF. If terminating the request
message body with a line-ending is desired, then the user agent MUST
count the terminating CRLF octets as part of the message body length.
In the interest of robustness, a server that is expecting to receive
and parse a request-line SHOULD ignore at least one empty line (CRLF)
received prior to the request-line.
A sender MUST NOT send whitespace between the start-line and the A sender MUST NOT send whitespace between the start-line and the
first header field. A recipient that receives whitespace between the first header field. A recipient that receives whitespace between the
start-line and the first header field MUST either reject the message start-line and the first header field MUST either reject the message
as invalid or consume each whitespace-preceded line without further as invalid or consume each whitespace-preceded line without further
processing of it (i.e., ignore the entire line, along with any processing of it (i.e., ignore the entire line, along with any
subsequent lines preceded by whitespace, until a properly formed subsequent lines preceded by whitespace, until a properly formed
header field is received or the header section is terminated). header field is received or the header section is terminated).
The presence of such whitespace in a request might be an attempt to The presence of such whitespace in a request might be an attempt to
trick a server into ignoring that field or processing the line after trick a server into ignoring that field or processing the line after
it as a new request, either of which might result in a security it as a new request, either of which might result in a security
vulnerability if other implementations within the request chain vulnerability if other implementations within the request chain
interpret the same message differently. Likewise, the presence of interpret the same message differently. Likewise, the presence of
such whitespace in a response might be ignored by some clients or such whitespace in a response might be ignored by some clients or
cause others to cease parsing. cause others to cease parsing.
3.1. Start Line When a server listening only for HTTP request messages, or processing
what appears from the start-line to be an HTTP request message,
An HTTP message can be either a request from client to server or a receives a sequence of octets that does not match the HTTP-message
response from server to client. Syntactically, the two types of grammar aside from the robustness exceptions listed above, the server
message differ only in the start-line, which is either a request-line SHOULD respond with a 400 (Bad Request) response.
(for requests) or a status-line (for responses), and in the algorithm
for determining the length of the message body (Section 3.3).
In theory, a client could receive requests and a server could receive
responses, distinguishing them by their different start-line formats,
but, in practice, servers are implemented to only expect a request (a
response is interpreted as an unknown or invalid request method) and
clients are implemented to only expect a response.
start-line = request-line / status-line
3.1.1. Request Line 3. Request Line
A request-line begins with a method token, followed by a single space A request-line begins with a method token, followed by a single space
(SP), the request-target, another single space (SP), the protocol (SP), the request-target, another single space (SP), the protocol
version, and 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
Although the request-line grammar rule requires that each of the
component elements be separated by a single SP octet, recipients MAY
instead parse on whitespace-delimited word boundaries and, aside from
the CRLF terminator, treat any form of whitespace as the SP separator
while ignoring preceding or trailing whitespace; such whitespace
includes one or more of the following octets: SP, HTAB, VT (%x0B), FF
(%x0C), or bare CR. However, lenient parsing can result in request
smuggling security vulnerabilities if there are multiple recipients
of the message and each has its own unique interpretation of
robustness (see Section 11.2).
HTTP does not place a predefined limit on the length of a request-
line, as described in Section 3 of [Semantics]. A server that
receives a method longer than any that it implements SHOULD respond
with a 501 (Not Implemented) status code. A server that receives a
request-target longer than any URI it wishes to parse MUST respond
with a 414 (URI Too Long) status code (see Section 9.5.15 of
[Semantics]).
Various ad hoc limitations on request-line length are found in
practice. It is RECOMMENDED that all HTTP senders and recipients
support, at a minimum, request-line lengths of 8000 octets.
3.1. Method
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 [SEMNTCS], along with information regarding the HTTP Section 7 of [Semantics], along with information regarding the HTTP
method registry and considerations for defining new methods. method registry and considerations for defining new methods.
3.2. Request Target
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. The client derives a request-target from its desired
target URI. There are four distinct formats for the request-target,
depending on both the method being requested and whether the request
is to a proxy.
Recipients typically parse the request-line into its component parts request-target = origin-form
by splitting on whitespace (see Section 3.5), since no whitespace is / absolute-form
allowed in the three components. Unfortunately, some user agents / authority-form
fail to properly encode or exclude whitespace found in hypertext / asterisk-form
references, resulting in those disallowed characters being sent in a
request-target. No whitespace is allowed in the request-target. Unfortunately, some
user agents fail to properly encode or exclude whitespace found in
hypertext references, resulting in those disallowed characters being
sent as the request-target in a malformed request-line.
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 request- 3.2.1. origin-form
line, as described in Section 2.5. A server that receives a method
longer than any that it implements SHOULD respond with a 501 (Not
Implemented) status code. A server that receives a request-target
longer than any URI it wishes to parse MUST respond with a 414 (URI
Too Long) status code (see Section 6.5.12 of [SEMNTCS]).
Various ad hoc limitations on request-line length are found in The most common form of request-target is the origin-form.
practice. It is RECOMMENDED that all HTTP senders and recipients
support, at a minimum, request-line lengths of 8000 octets.
3.1.2. Status Line origin-form = absolute-path [ "?" query ]
When making a request directly to an origin server, other than a
CONNECT or server-wide OPTIONS request (as detailed below), a client
MUST send only the absolute path and query components of the target
URI as the request-target. If the target URI's path component is
empty, the client MUST send "/" as the path within the origin-form of
request-target. A Host header field is also sent, as defined in
Section 5.4 of [Semantics].
For example, a client wishing to retrieve a representation of the
resource identified as
http://www.example.org/where?q=now
directly from the origin server would open (or reuse) a TCP
connection to port 80 of the host "www.example.org" and send the
lines:
GET /where?q=now HTTP/1.1
Host: www.example.org
followed by the remainder of the request message.
3.2.2. absolute-form
When making a request to a proxy, other than a CONNECT or server-wide
OPTIONS request (as detailed below), a client MUST send the target
URI in absolute-form as the request-target.
absolute-form = absolute-URI
The proxy is requested to either service that request from a valid
cache, if possible, or make the same request on the client's behalf
to either the next inbound proxy server or directly to the origin
server indicated by the request-target. Requirements on such
"forwarding" of messages are defined in Section 5.6 of [Semantics].
An example absolute-form of request-line would be:
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
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 to proxies.
3.2.3. authority-form
The authority-form of request-target is only used for CONNECT
requests (Section 7.3.6 of [Semantics]).
authority-form = authority
When making a CONNECT request to establish a tunnel through one or
more proxies, a client MUST send only the target URI's authority
component (excluding any userinfo and its "@" delimiter) as the
request-target. For example,
CONNECT www.example.com:80 HTTP/1.1
3.2.4. asterisk-form
The asterisk-form of request-target is only used for a server-wide
OPTIONS request (Section 7.3.7 of [Semantics]).
asterisk-form = "*"
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
send only "*" (%x2A) as the request-target. For example,
OPTIONS * HTTP/1.1
If a proxy receives an OPTIONS request with an absolute-form of
request-target in which the URI has an empty path and no query
component, then the last proxy on the request chain MUST send a
request-target of "*" when it forwards the request to the indicated
origin server.
For example, the request
OPTIONS http://www.example.org:8001 HTTP/1.1
would be forwarded by the final proxy as
OPTIONS * HTTP/1.1
Host: www.example.org:8001
after connecting to port 8001 of host "www.example.org".
3.3. Effective Request URI
Since the request-target often contains only part of the user agent's
target URI, a server reconstructs the intended target as an effective
request URI to properly service the request (Section 5.3 of
[Semantics]).
If the request-target is in absolute-form, the effective request URI
is the same as the request-target. Otherwise, the effective request
URI is constructed as follows:
If the server's configuration (or outbound gateway) provides a
fixed URI scheme, that scheme is used for the effective request
URI. Otherwise, if the request is received over a TLS-secured TCP
connection, the effective request URI's scheme is "https"; if not,
the scheme is "http".
If the server's configuration (or outbound gateway) provides a
fixed URI authority component, that authority is used for the
effective request URI. If not, then if the request-target is in
authority-form, the effective request URI's authority component is
the same as the request-target. If not, then if a Host header
field is supplied with a non-empty field-value, the authority
component is the same as the Host field-value. Otherwise, the
authority component is assigned the default name configured for
the server and, if the connection's incoming TCP port number
differs from the default port for the effective request URI's
scheme, then a colon (":") and the incoming port number (in
decimal form) are appended to the authority component.
If the request-target is in authority-form or asterisk-form, the
effective request URI's combined path and query component is
empty. Otherwise, the combined path and query component is the
same as the request-target.
The components of the effective request URI, once determined as
above, can be combined into absolute-URI form by concatenating the
scheme, "://", authority, and combined path and query component.
Example 1: the following message received over an insecure TCP
connection
GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.example.org:8080
has an effective request URI of
http://www.example.org:8080/pub/WWW/TheProject.html
Example 2: the following message received over a TLS-secured TCP
connection
OPTIONS * HTTP/1.1
Host: www.example.org
has an effective request URI of
https://www.example.org
Recipients of an HTTP/1.0 request that lacks a Host header field
might need to use heuristics (e.g., examination of the URI path for
something unique to a particular host) in order to guess the
effective request URI's authority component.
4. 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
Although the status-line grammar rule requires that each of the
component elements be separated by a single SP octet, recipients MAY
instead parse on whitespace-delimited word boundaries and, aside from
the line terminator, treat any form of whitespace as the SP separator
while ignoring preceding or trailing whitespace; such whitespace
includes one or more of the following octets: SP, HTAB, VT (%x0B), FF
(%x0C), or bare CR. However, lenient parsing can result in response
splitting security vulnerabilities if there are multiple recipients
of the message and each has its own unique interpretation of
robustness (see Section 11.1).
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 [SEMNTCS] for information about the semantics of See Section 9 of [Semantics] 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
more frequently used with interactive text clients. A client SHOULD more frequently used with interactive text clients. A client SHOULD
ignore the reason-phrase content. ignore the reason-phrase content.
reason-phrase = *( HTAB / SP / VCHAR / obs-text ) reason-phrase = *( HTAB / SP / VCHAR / obs-text )
3.2. Header Fields 5. Header Fields
Each header field consists of a case-insensitive field name followed Each header field consists of a case-insensitive field name followed
by a colon (":"), optional leading whitespace, the field value, and by a colon (":"), optional leading whitespace, the field value, and
optional trailing whitespace. optional trailing whitespace.
header-field = field-name ":" OWS field-value OWS header-field = field-name ":" OWS field-value OWS
field-name = token [[CREF2: Most HTTP field names and the rules for parsing within field
field-value = *( field-content / obs-fold ) values are defined in Section 4 of [Semantics]. This section covers
field-content = field-vchar [ 1*( SP / HTAB ) field-vchar ] the generic syntax for header field inclusion within, and extraction
field-vchar = VCHAR / obs-text from, HTTP/1.1 messages. In addition, the following header fields
are defined by this document because they are specific to HTTP/1.1
obs-fold = CRLF 1*( SP / HTAB ) message processing: ]]
; obsolete line folding
; see Section 3.2.4
The field-name token labels the corresponding field-value as having
the semantics defined by that header field. For example, the Date
header field is defined in Section 7.1.1.2 of [SEMNTCS] as containing
the origination timestamp for the message in which it appears.
3.2.1. Field Extensibility
Header fields are fully extensible: there is no limit on the
introduction of new field names, each presumably defining new
semantics, nor on the number of header fields used in a given
message. Existing fields are defined in each part of this
specification and in many other specifications outside this document
set.
New header fields can be defined such that, when they are understood
by a recipient, they might override or enhance the interpretation of
previously defined header fields, define preconditions on request
evaluation, or refine the meaning of responses.
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 specifically configured to block, or otherwise transform, such
fields. Other recipients SHOULD ignore unrecognized header fields.
These requirements allow HTTP's functionality to be enhanced without
requiring prior update of deployed intermediaries.
All defined header fields ought to be registered with IANA in the
"Message Headers" registry, as described in Section 8.3 of [SEMNTCS].
3.2.2. Field Order
The order in which header fields with differing field names are
received is not significant. However, it is good practice to send
header fields that contain control data first, such as Host on
requests and Date on responses, so that implementations can decide
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
header section is received, since later header fields might include
conditionals, authentication credentials, or deliberately misleading
duplicate header fields that would impact request processing.
A sender MUST NOT generate multiple header fields with the same field
name in a message unless either the entire field value for that
header field is defined as a comma-separated list [i.e., #(values)]
or the header field is a well-known exception (as noted below).
A recipient MAY combine multiple header fields with the same field
name into one "field-name: field-value" pair, without changing the
semantics of the message, by appending each subsequent field value to
the combined field value in order, separated by a comma. The order
in which header fields with the same field name are received is
therefore significant to the interpretation of the combined field
value; a proxy MUST NOT change the order of these field values when
forwarding a message.
Note: In practice, the "Set-Cookie" header field ([RFC6265]) often
appears multiple times in a response message and does not use the
list syntax, violating the above requirements on multiple header
fields with the same name. Since it cannot be combined into a
single field-value, recipients ought to handle "Set-Cookie" as a
special case while processing header fields. (See Appendix A.2.3
of [Kri2001] for details.)
3.2.3. Whitespace
This specification uses three rules to denote the use of linear
whitespace: OWS (optional whitespace), RWS (required whitespace), and
BWS ("bad" whitespace).
The OWS rule is used where zero or more linear whitespace octets
might appear. For protocol elements where optional whitespace is
preferred to improve readability, a sender SHOULD generate the
optional whitespace as a single SP; otherwise, a sender SHOULD NOT
generate optional whitespace except as needed to white out invalid or
unwanted protocol elements during in-place message filtering.
The RWS rule is used when at least one linear whitespace octet is +-------------------+----------+----------+---------------+
required to separate field tokens. A sender SHOULD generate RWS as a | Header Field Name | Protocol | Status | Reference |
single SP. +-------------------+----------+----------+---------------+
| Connection | http | standard | Section 9.1 |
| MIME-Version | http | standard | Appendix B.1 |
| TE | http | standard | Section 7.4 |
| Transfer-Encoding | http | standard | Section 6.1 |
| Upgrade | http | standard | Section 9.7 |
+-------------------+----------+----------+---------------+
The BWS rule is used where the grammar allows optional whitespace Furthermore, the field name "Close" is reserved, since using that
only for historical reasons. A sender MUST NOT generate BWS in name as an HTTP header field might conflict with the "close"
messages. A recipient MUST parse for such bad whitespace and remove connection option of the Connection header field (Section 9.1).
it before interpreting the protocol element.
OWS = *( SP / HTAB ) +-------------------+----------+----------+------------+
; optional whitespace | Header Field Name | Protocol | Status | Reference |
RWS = 1*( SP / HTAB ) +-------------------+----------+----------+------------+
; required whitespace | Close | http | reserved | Section 5 |
BWS = OWS +-------------------+----------+----------+------------+
; "bad" whitespace
3.2.4. Field Parsing 5.1. Field Parsing
Messages are parsed using a generic algorithm, independent of the Messages are parsed using a generic algorithm, independent of the
individual header field names. The contents within a given field individual header field names. The contents within a given field
value are not parsed until a later stage of message interpretation value are not parsed until a later stage of message interpretation
(usually after the message's entire header section has been (usually after the message's entire header section has been
processed). Consequently, this specification does not use ABNF rules processed).
to define each "Field-Name: Field Value" pair, as was done in
previous editions. Instead, this specification uses ABNF rules that
are named according to each registered field name, wherein the rule
defines the valid grammar for that field's corresponding field values
(i.e., after the field-value has been extracted from the header
section by a generic field parser).
No whitespace is allowed between the header field-name and colon. In No whitespace is allowed between the header field-name and colon. In
the past, differences in the handling of such whitespace have led to the past, differences in the handling of such whitespace have led to
security vulnerabilities in request routing and response handling. A security vulnerabilities in request routing and response handling. A
server MUST reject any received request message that contains server MUST reject any received request message that contains
whitespace between a header field-name and colon with a response code whitespace between a header field-name and colon with a response code
of 400 (Bad Request). A proxy MUST remove any such whitespace from a of 400 (Bad Request). A proxy MUST remove any such whitespace from a
response message before forwarding the message downstream. response message before forwarding the message downstream.
A field value might be preceded and/or followed by optional A field value might be preceded and/or followed by optional
whitespace (OWS); a single SP preceding the field-value is preferred whitespace (OWS); a single SP preceding the field-value is preferred
for consistent readability by humans. The field value does not for consistent readability by humans. The field value does not
include any leading or trailing 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 non- first non-whitespace octet of the field value or after the last non-
whitespace octet of the field value ought to be excluded by parsers whitespace octet of the field value ought to be excluded by parsers
when extracting the field value from a header field. when extracting the field value from a header field.
5.2. Obsolete Line Folding
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 10.1).
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 obs-fold = CRLF 1*( SP / HTAB )
within the message/http media type. ; obsolete line folding
A sender MUST NOT generate a message that includes 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 within the
message/http media type.
A server that receives an obs-fold in a request message that is not A server that receives an obs-fold in a request message that is not
within a message/http container MUST either reject the message by within a message/http container MUST either reject the message by
sending a 400 (Bad Request), preferably with a representation sending a 400 (Bad Request), preferably with a representation
explaining that obsolete line folding is unacceptable, or replace explaining that obsolete line folding is unacceptable, or replace
each received obs-fold with one or more SP octets prior to each received obs-fold with one or more SP octets prior to
interpreting the field value or forwarding the message downstream. interpreting the field value or forwarding the message downstream.
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
skipping to change at page 26, line 10 skipping to change at page 16, line 22
with a representation explaining that unacceptable line folding was with a representation explaining that unacceptable line folding was
received, or replace each received obs-fold with one or more SP received, or replace each received obs-fold with one or more SP
octets prior to interpreting the field value or forwarding the octets prior to interpreting the field value or forwarding the
message downstream. message downstream.
A user agent that receives an obs-fold in a response message that is A user agent that receives an obs-fold in a response message that is
not within a message/http container MUST replace each received obs- not within a message/http container MUST replace each received obs-
fold with one or more SP octets prior to interpreting the field fold with one or more SP octets prior to interpreting the field
value. value.
Historically, HTTP has allowed field content with text in the 6. Message Body
ISO-8859-1 charset [ISO-8859-1], supporting other charsets only
through use of [RFC2047] encoding. In practice, most HTTP header
field values use only a subset of the US-ASCII charset [USASCII].
Newly defined header fields SHOULD limit their field values to
US-ASCII octets. A recipient SHOULD treat other octets in field
content (obs-text) as opaque data.
3.2.5. Field Limits
HTTP does not place a predefined limit on the length of each header
field or on the length of the header section as a whole, as described
in Section 2.5. Various ad hoc limitations on individual header
field length are found in practice, often depending on the specific
field semantics.
A server that receives a request header field, or set of fields,
larger than it wishes to process MUST respond with an appropriate 4xx
(Client Error) status code. Ignoring such header fields would
increase the server's vulnerability to request smuggling attacks
(Section 9.5).
A client MAY discard or truncate received header fields that are
larger than the client wishes to process if the field semantics are
such that the dropped value(s) can be safely ignored without changing
the message framing or response semantics.
3.2.6. Field Value Components
Most HTTP header field values are defined using common syntax
components (token, quoted-string, and comment) separated by
whitespace or specific delimiting characters. Delimiters are chosen
from the set of US-ASCII visual characters not allowed in a token
(DQUOTE and "(),/:;<=>?@[\]{}").
token = 1*tchar
tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*"
/ "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
/ DIGIT / ALPHA
; any VCHAR, except delimiters
A string of text is parsed as a single value if it is quoted using
double-quote marks.
quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
qdtext = HTAB / SP /%x21 / %x23-5B / %x5D-7E / obs-text
obs-text = %x80-FF
Comments can be included in some HTTP header fields by surrounding
the comment text with parentheses. Comments are only allowed in
fields containing "comment" as part of their field value definition.
comment = "(" *( ctext / quoted-pair / comment ) ")"
ctext = HTAB / SP / %x21-27 / %x2A-5B / %x5D-7E / obs-text
The backslash octet ("\") can be used as a single-octet quoting
mechanism within quoted-string and comment constructs. Recipients
that process the value of a quoted-string MUST handle a quoted-pair
as if it were replaced by the octet following the backslash.
quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
A sender SHOULD NOT generate a quoted-pair in a quoted-string except
where necessary to quote DQUOTE and backslash octets occurring within
that string. A sender SHOULD NOT generate a quoted-pair in a comment
except where necessary to quote parentheses ["(" and ")"] and
backslash octets occurring within that comment.
3.3. Message Body
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 6.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 Content- The presence of a message body in a request is signaled by a Content-
Length or Transfer-Encoding header field. Request message framing is Length or Transfer-Encoding header field. Request message framing is
independent of method semantics, even if the method does not define independent of method semantics, even if the method does 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 4). Responses to the HEAD request method (Section 7.3.2 of
of [SEMNTCS]) never include a message body because the associated [Semantics]) 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 [SEMNTCS]). 2xx the request method had been GET (Section 7.3.1 of [Semantics]). 2xx
(Successful) responses to a CONNECT request method (Section 4.3.6 of (Successful) responses to a CONNECT request method (Section 7.3.6 of
[SEMNTCS]) switch to tunnel mode instead of having a message body. [Semantics]) 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 6.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 7.
Transfer-Encoding = 1#transfer-coding Transfer-Encoding = 1#transfer-coding
Transfer-Encoding is analogous to the Content-Transfer-Encoding field Transfer-Encoding is analogous to the Content-Transfer-Encoding field
of MIME, which was designed to enable safe transport of binary data of MIME, which was designed to enable safe transport of binary data
over a 7-bit transport service ([RFC2045], Section 6). However, safe over a 7-bit transport service ([RFC2045], Section 6). However, safe
transport has a different focus for an 8bit-clean transfer protocol. transport has a different focus for an 8bit-clean transfer protocol.
In HTTP's case, Transfer-Encoding is primarily intended to accurately In HTTP's case, Transfer-Encoding is primarily intended to accurately
delimit a dynamically generated payload and to distinguish payload delimit a dynamically generated payload and to distinguish payload
encodings that are only applied for transport efficiency or security encodings that are only applied for transport efficiency or security
from those that are characteristics of the selected resource. from those that are characteristics of the selected resource.
A recipient MUST be able to parse the chunked transfer coding A recipient MUST be able to parse the chunked transfer coding
(Section 4.1) because it plays a crucial role in framing messages (Section 7.1) because it plays a crucial role in framing messages
when the payload body size is not known in advance. A sender MUST when the payload body size is not known in advance. A sender MUST
NOT apply chunked more than once to a message body (i.e., chunking an NOT apply chunked more than once to a message body (i.e., chunking an
already chunked message is not allowed). If any transfer coding already chunked message is not allowed). If any transfer coding
other than chunked is applied to a request payload body, the sender other than chunked is applied to a request payload body, the sender
MUST apply chunked as the final transfer coding to ensure that the MUST apply chunked as the final transfer coding to ensure that the
message is properly framed. If any transfer coding other than message is properly framed. If any transfer coding other than
chunked is applied to a response payload body, the sender MUST either chunked is applied to a response payload body, the sender MUST either
apply chunked as the final transfer coding or terminate the message apply chunked as the final transfer coding or terminate the message
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 [SEMNTCS]), Transfer- Unlike Content-Encoding (Section 6.1.2 of [Semantics]), Transfer-
Encoding is a property of the message, not of the representation, and Encoding is a property of the message, not of the representation, and
any recipient along the request/response chain MAY decode the any recipient along the request/response chain MAY decode the
received transfer coding(s) or apply additional transfer coding(s) to received transfer coding(s) or apply additional transfer coding(s) to
the message body, assuming that corresponding changes are made to the the message body, assuming that corresponding changes are made to the
Transfer-Encoding field-value. Additional information about the Transfer-Encoding field-value. Additional information about the
encoding parameters can be provided by other header fields not encoding parameters can be provided by other 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 [CONDTNL]) to a GET 304 (Not Modified) response (Section 9.4.5 of [Semantics]) 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 7.3.6 of
[SEMNTCS]). [Semantics]).
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).
A server that receives a request message with a transfer coding it A server that receives a request message with a transfer coding it
does not understand SHOULD respond with 501 (Not Implemented). does not understand SHOULD respond with 501 (Not Implemented).
3.3.2. Content-Length 6.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 [SEMNTCS]). representation (Section 6.2.4 of [Semantics]).
Content-Length = 1*DIGIT
An example is
Content-Length: 3495
A sender MUST NOT send a Content-Length header field in any message
that contains a Transfer-Encoding header field.
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
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
(indicating an empty payload body). A user agent SHOULD NOT send a
Content-Length header field when the request message does not contain
a payload body and the method semantics do not anticipate such a
body.
A server MAY send a Content-Length header field in a response to a
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
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.
A server MAY send a Content-Length header field in a 304 (Not
Modified) response to a conditional GET request (Section 4.1 of
[CONDTNL]); a server MUST NOT send Content-Length in such a response
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
request.
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
server MUST NOT send a Content-Length header field in any 2xx
(Successful) response to a CONNECT request (Section 4.3.6 of
[SEMNTCS]).
Aside from the cases defined above, in the absence of Transfer-
Encoding, an origin server SHOULD send a Content-Length header field
when the payload body size is known prior to sending the complete
header section. This will allow downstream recipients to measure
transfer progress, know when a received message is complete, and
potentially reuse the connection for additional requests.
Any Content-Length field value greater than or equal to zero is
valid. Since there is no predefined limit to the length of a
payload, a recipient MUST anticipate potentially large decimal
numerals and prevent parsing errors due to integer conversion
overflows (Section 9.3).
If a message is received that has multiple Content-Length header
fields with field-values consisting of the same decimal value, or a
single Content-Length header field with a field value containing a
list of identical decimal values (e.g., "Content-Length: 42, 42"),
indicating that duplicate Content-Length header fields have been
generated or combined by an upstream message processor, then the
recipient MUST either reject the message as invalid or replace the
duplicated field-values with a single valid Content-Length field
containing that decimal value prior to determining the message body
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" media- optional field used only within the "message/external-body" media-
type. type.
3.3.3. Message Body Length 6.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
message, and thus cannot contain a message body. message, and thus cannot contain a message body.
2. Any 2xx (Successful) response to a CONNECT request implies that 2. Any 2xx (Successful) response to a CONNECT request implies that
the connection will become a tunnel immediately after the empty the connection will become a tunnel immediately after the empty
line that concludes the header fields. A client MUST ignore any line that concludes the header fields. A client MUST ignore any
Content-Length or Transfer-Encoding header fields received in Content-Length or Transfer-Encoding header fields received in
such a message. such a message.
3. If a Transfer-Encoding header field is present and the chunked 3. If a Transfer-Encoding header field is present and the chunked
transfer coding (Section 4.1) is the final encoding, the message transfer coding (Section 7.1) is the final encoding, the message
body length is determined by reading and decoding the chunked body length is determined by reading and decoding the chunked
data until the transfer coding indicates the data is complete. data until the transfer coding indicates the data is complete.
If a Transfer-Encoding header field is present in a response and If a Transfer-Encoding header field is present in a response and
the chunked transfer coding is not the final encoding, the the chunked transfer coding is not the final encoding, the
message body length is determined by reading the connection until message body length is determined by reading the connection until
it is closed by the server. If a Transfer-Encoding header field it is closed by the server. If a Transfer-Encoding header field
is present in a request and the chunked transfer coding is not is present in a request and the chunked transfer coding is not
the final encoding, the message body length cannot be determined the final encoding, the message body length cannot be determined
reliably; the server MUST respond with the 400 (Bad Request) reliably; the server MUST respond with the 400 (Bad Request)
status code and then close the connection. status code and then close the connection.
If a message is received with both a Transfer-Encoding and a If a message is received with both a Transfer-Encoding and a
Content-Length header field, the Transfer-Encoding overrides the Content-Length header field, the Transfer-Encoding overrides the
Content-Length. Such a message might indicate an attempt to Content-Length. Such a message might indicate an attempt to
perform request smuggling (Section 9.5) or response splitting perform request smuggling (Section 11.2) or response splitting
(Section 9.4) and ought to be handled as an error. A sender MUST (Section 11.1) and ought to be handled as an error. A sender
remove the received Content-Length field prior to forwarding such MUST remove the received Content-Length field prior to forwarding
a message downstream. such a message downstream.
4. If a message is received without Transfer-Encoding and with 4. If a message is received without Transfer-Encoding and with
either multiple Content-Length header fields having differing either multiple Content-Length header fields having differing
field-values or a single Content-Length header field having an field-values or a single Content-Length header field having an
invalid value, then the message framing is invalid and the invalid value, then the message framing is invalid and the
recipient MUST treat it as an unrecoverable error. If this is a recipient MUST treat it as an unrecoverable error. If this is a
request message, the server MUST respond with a 400 (Bad Request) request message, the server MUST respond with a 400 (Bad Request)
status code and then close the connection. If this is a response status code and then close the connection. If this is a response
message received by a proxy, the proxy MUST close the connection message received by a proxy, the proxy MUST close the connection
to the server, discard the received response, and send a 502 (Bad to the server, discard the received response, and send a 502 (Bad
skipping to change at page 33, line 31 skipping to change at page 21, line 10
If the final response to the last request on a connection has been If the final response to the last request on a connection has been
completely received and there remains additional data to read, a user completely received and there remains additional data to read, a user
agent MAY discard the remaining data or attempt to determine if that agent MAY discard the remaining data or attempt to determine if that
data belongs as part of the prior response body, which might be the data belongs as part of the prior response body, which might be the
case if the prior message's Content-Length value is incorrect. A case if the prior message's Content-Length value is incorrect. A
client MUST NOT process, cache, or forward such extra data as a client MUST NOT process, cache, or forward such extra data as a
separate response, since such behavior would be vulnerable to cache separate response, since such behavior would be vulnerable to cache
poisoning. poisoning.
3.4. Handling Incomplete Messages 7. Transfer Codings
A server that receives an incomplete request message, usually due to
a canceled request or a triggered timeout exception, MAY send an
error response prior to closing the connection.
A client that receives an incomplete response message, which can
occur when a connection is closed prematurely or when decoding a
supposedly chunked transfer coding fails, MUST record the message as
incomplete. Cache requirements for incomplete responses are defined
in Section 3 of [CACHING].
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
fields to convey the full meaning of the response, then the client
cannot assume that meaning has been conveyed; the client might need
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
the zero-sized chunk that terminates the encoding has not been
received. A message that uses a valid Content-Length is incomplete
if the size of the message body received (in octets) is less than the
value given by Content-Length. A response that has neither chunked
transfer coding nor Content-Length is terminated by closure of the
connection and, thus, is considered complete regardless of the number
of message body octets received, provided that the header section was
received intact.
3.5. Message Parsing Robustness
Older HTTP/1.0 user agent implementations might send an extra CRLF
after a POST request as a workaround for some early server
applications that failed to read message body content that was not
terminated by a line-ending. An HTTP/1.1 user agent MUST NOT preface
or follow a request with an extra CRLF. If terminating the request
message body with a line-ending is desired, then the user agent MUST
count the terminating CRLF octets as part of the message body length.
In the interest of robustness, a server that is expecting to receive
and parse a request-line SHOULD ignore at least one empty line (CRLF)
received prior to the request-line.
Although the line terminator for the start-line and header fields is
the sequence CRLF, a recipient MAY recognize a single LF as a line
terminator and ignore any preceding CR.
Although the request-line and status-line grammar rules require that
each of the component elements be separated by a single SP octet,
recipients MAY instead parse on whitespace-delimited word boundaries
and, aside from the CRLF terminator, treat any form of whitespace as
the SP separator while ignoring preceding or trailing whitespace;
such whitespace includes one or more of the following octets: SP,
HTAB, VT (%x0B), FF (%x0C), or bare CR. However, lenient parsing can
result in security vulnerabilities if there are multiple recipients
of the message and each has its own unique interpretation of
robustness (see Section 9.5).
When a server listening only for HTTP request messages, or processing
what appears from the start-line to be an HTTP request message,
receives a sequence of octets that does not match the HTTP-message
grammar aside from the robustness exceptions listed above, the server
SHOULD respond with a 400 (Bad Request) response.
4. Transfer Codings
Transfer coding names are used to indicate an encoding transformation Transfer coding names are used to indicate an encoding transformation
that has been, can be, or might need to be applied to a payload body that has been, can be, or might need to be applied to a payload body
in order to ensure "safe transport" through the network. This in order to ensure "safe transport" through the network. This
differs from a content coding in that the transfer coding is a differs from a content coding in that the transfer coding is a
property of the message rather than a property of the representation property of the message rather than a property of the representation
that is being transferred. that is being transferred.
transfer-coding = "chunked" ; Section 4.1 transfer-coding = "chunked" ; Section 7.1
/ "compress" ; Section 4.2.1 / "compress" ; [Semantics], Section 6.1.2.1
/ "deflate" ; Section 4.2.2 / "deflate" ; [Semantics], Section 6.1.2.2
/ "gzip" ; Section 4.2.3 / "gzip" ; [Semantics], Section 6.1.2.3
/ transfer-extension / transfer-extension
transfer-extension = token *( OWS ";" OWS transfer-parameter ) transfer-extension = token *( OWS ";" OWS transfer-parameter )
Parameters are in the form of a name or name=value pair. Parameters are in the form of a name or name=value pair.
transfer-parameter = token BWS "=" BWS ( token / quoted-string ) transfer-parameter = token BWS "=" BWS ( token / quoted-string )
All transfer-coding names are case-insensitive and ought to be All transfer-coding names are case-insensitive and ought to be
registered within the HTTP Transfer Coding registry, as defined in registered within the HTTP Transfer Coding registry, as defined in
Section 8.4. They are used in the TE (Section 4.3) and Transfer- Section 7.3. They are used in the TE (Section 7.4) and Transfer-
Encoding (Section 3.3.1) header fields. Encoding (Section 6.1) header fields.
4.1. Chunked Transfer Coding +------------+------------------------------------------+-----------+
| Name | Description | Reference |
+------------+------------------------------------------+-----------+
| chunked | Transfer in a series of chunks | Section 7 |
| | | .1 |
| compress | UNIX "compress" data format [Welch] | Section 7 |
| | | .2 |
| deflate | "deflate" compressed data ([RFC1951]) | Section 7 |
| | inside the "zlib" data format | .2 |
| | ([RFC1950]) | |
| gzip | GZIP file format [RFC1952] | Section 7 |
| | | .2 |
| x-compress | Deprecated (alias for compress) | Section 7 |
| | | .2 |
| x-gzip | Deprecated (alias for gzip) | Section 7 |
| | | .2 |
+------------+------------------------------------------+-----------+
7.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.
chunked-body = *chunk chunked-body = *chunk
skipping to change at page 36, line 5 skipping to change at page 22, line 35
chunk-data = 1*OCTET ; a sequence of chunk-size octets chunk-data = 1*OCTET ; a sequence of chunk-size octets
The chunk-size field is a string of hex digits indicating the size of The chunk-size field is a string of hex digits indicating the size of
the chunk-data in octets. The chunked transfer coding is complete the chunk-data in octets. The chunked transfer coding is complete
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 7.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), mid- supplying per-chunk metadata (such as a signature or hash), mid-
message control information, or randomization of message body size. message control information, or randomization of message body 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
skipping to change at page 36, line 32 skipping to change at page 23, line 14
server can have shared expectations regarding the use of chunk server can have shared expectations regarding the use of chunk
extensions) or for padding within an end-to-end secured connection. extensions) or for padding within an end-to-end secured connection.
A recipient MUST ignore unrecognized chunk extensions. A server A recipient MUST ignore unrecognized chunk extensions. A server
ought to limit the total length of chunk extensions received in a ought to limit the total length of chunk extensions received in a
request to an amount reasonable for the services provided, in the request to an amount reasonable for the services provided, in the
same way that it applies length limitations and timeouts for other same way that it applies length limitations and timeouts for other
parts of a message, and generate an appropriate 4xx (Client Error) parts of a message, and generate an appropriate 4xx (Client Error)
response if that amount is exceeded. response if that amount is exceeded.
4.1.2. Chunked Trailer Part 7.1.2. Chunked Trailer Part
A trailer allows the sender to include additional fields at the end A trailer allows the sender to include additional fields at the end
of a chunked message in order to supply metadata that might be of a chunked message in order to supply metadata that might be
dynamically generated while the message body is sent, such as a dynamically generated while the message body is sent, such as a
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 [SEMNTCS]), authentication (e.g., see conditionals in Section 8 of [Semantics]), authentication (e.g., see
[AUTHFRM] and [RFC6265]), response control data (e.g., see Section 8.5 of [Semantics] and [RFC6265]), response control data
Section 7.1 of [SEMNTCS]), or determining how to process the payload (e.g., see Section 10.1 of [Semantics]), or determining how to
(e.g., Content-Encoding, Content-Type, Content-Range, and Trailer). process the payload (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"
is acceptable, as described in Section 4.3, a server SHOULD NOT is acceptable, as described in Section 7.4, a server SHOULD NOT
generate trailer fields that it believes are necessary for the user generate trailer fields that it believes are necessary for the user
agent to receive. Without a TE containing "trailers", the server agent to receive. Without a TE containing "trailers", the server
ought to assume that the trailer fields might be silently discarded ought to assume that the trailer fields might be silently discarded
along the path to the user agent. This requirement allows along the path to the user agent. This requirement allows
intermediaries to forward a de-chunked message to an HTTP/1.0 intermediaries to forward a de-chunked message to an HTTP/1.0
recipient without buffering the entire response. recipient without buffering the entire response.
4.1.3. Decoding Chunked When a message includes a message body encoded with the chunked
transfer coding and the sender desires to send metadata in the form
of trailer fields at the end of the message, the sender SHOULD
generate a Trailer header field before the message body to indicate
which fields will be present in the trailers. This allows the
recipient to prepare for receipt of that metadata before it starts
processing the body, which is useful if the message is being streamed
and the recipient wishes to confirm an integrity check on the fly.
7.1.3. Decoding Chunked
A process for decoding the chunked transfer coding can be represented A process for decoding the chunked transfer coding can be represented
in pseudo-code as: in pseudo-code as:
length := 0 length := 0
read chunk-size, chunk-ext (if any), and CRLF read chunk-size, chunk-ext (if any), and CRLF
while (chunk-size > 0) { while (chunk-size > 0) {
read chunk-data and CRLF read chunk-data and CRLF
append chunk-data to decoded-body append chunk-data to decoded-body
length := length + chunk-size length := length + chunk-size
skipping to change at page 37, line 46 skipping to change at page 24, line 38
while (trailer field is not empty) { while (trailer field is not empty) {
if (trailer field is allowed to be sent in a trailer) { if (trailer field is allowed to be sent in a trailer) {
append trailer field to existing header fields append trailer field to existing header fields
} }
read trailer-field read trailer-field
} }
Content-Length := length Content-Length := length
Remove "chunked" from Transfer-Encoding Remove "chunked" from Transfer-Encoding
Remove Trailer from existing header fields Remove Trailer from existing header fields
4.2. Compression Codings 7.2. Transfer Codings for Compression
The codings defined below can be used to compress the payload of a The following transfer coding names for compression are defined by
message. the same algorithm as their corresponding content coding:
4.2.1. Compress Coding compress (and x-compress)
See Section 6.1.2.1 of [Semantics].
The "compress" coding is an adaptive Lempel-Ziv-Welch (LZW) coding deflate
[Welch] that is commonly produced by the UNIX file compression See Section 6.1.2.2 of [Semantics].
program "compress". A recipient SHOULD consider "x-compress" to be
equivalent to "compress".
4.2.2. Deflate Coding gzip (and x-gzip)
See Section 6.1.2.3 of [Semantics].
The "deflate" coding is a "zlib" data format [RFC1950] containing a 7.3. Transfer Coding Registry
"deflate" compressed data stream [RFC1951] that uses a combination of
the Lempel-Ziv (LZ77) compression algorithm and Huffman coding.
Note: Some non-conformant implementations send the "deflate" The "HTTP Transfer Coding Registry" defines the namespace for
compressed data without the zlib wrapper. transfer coding names. It is maintained at
<https://www.iana.org/assignments/http-parameters>.
4.2.3. Gzip Coding Registrations MUST include the following fields:
The "gzip" coding is an LZ77 coding with a 32-bit Cyclic Redundancy o Name
Check (CRC) that is commonly produced by the gzip file compression
program [RFC1952]. A recipient SHOULD consider "x-gzip" to be
equivalent to "gzip".
4.3. TE o Description
o Pointer to specification text
Names of transfer codings MUST NOT overlap with names of content
codings (Section 6.1.2 of [Semantics]) unless the encoding
transformation is identical, as is the case for the compression
codings defined in Section 7.2.
Values to be added to this namespace require IETF Review (see
Section 4.1 of [RFC5226]), and MUST conform to the purpose of
transfer coding defined in this specification.
Use of program names for the identification of encoding formats is
not desirable and is discouraged for future encodings.
7.4. TE
The "TE" header field in a request indicates what transfer codings, The "TE" header field in a request indicates what transfer codings,
besides chunked, the client is willing to accept in response, and besides chunked, the client is willing to accept in response, and
whether or not the client is willing to accept trailer fields in a whether or not the client is willing to accept trailer fields in a
chunked transfer coding. chunked transfer coding.
The TE field-value consists of a comma-separated list of transfer The TE field-value consists of a comma-separated list of transfer
coding names, each allowing for optional parameters (as described in coding names, each allowing for optional parameters (as described in
Section 4), and/or the keyword "trailers". A client MUST NOT send Section 7), and/or the keyword "trailers". A client MUST NOT send
the chunked transfer coding name in TE; chunked is always acceptable the chunked transfer coding name in TE; chunked is always acceptable
for HTTP/1.1 recipients. for HTTP/1.1 recipients.
TE = #t-codings TE = #t-codings
t-codings = "trailers" / ( transfer-coding [ t-ranking ] ) t-codings = "trailers" / ( transfer-coding [ t-ranking ] )
t-ranking = OWS ";" OWS "q=" rank t-ranking = OWS ";" OWS "q=" rank
rank = ( "0" [ "." 0*3DIGIT ] ) rank = ( "0" [ "." 0*3DIGIT ] )
/ ( "1" [ "." 0*3("0") ] ) / ( "1" [ "." 0*3("0") ] )
Three examples of TE use are below. Three examples of TE use are below.
TE: deflate TE: deflate
TE: TE:
TE: trailers, deflate;q=0.5 TE: trailers, deflate;q=0.5
The presence of the keyword "trailers" indicates that the client is The presence of the keyword "trailers" indicates that the client is
willing to accept trailer fields in a chunked transfer coding, as willing to accept trailer fields in a chunked transfer coding, as
defined in Section 4.1.2, on behalf of itself and any downstream defined in Section 7.1.2, on behalf of itself and any downstream
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, (similar to the qvalues used in content negotiation fields,
Section 5.3.1 of [SEMNTCS]). The rank value is a real number in the Section 8.4.1 of [Semantics]). The rank value is a real number in
range 0 through 1, where 0.001 is the least preferred and 1 is the the range 0 through 1, where 0.001 is the least preferred and 1 is
most preferred; a value of 0 means "not acceptable". the 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 9.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.
4.4. Trailer 8. Handling Incomplete Messages
When a message includes a message body encoded with the chunked
transfer coding and the sender desires to send metadata in the form
of trailer fields at the end of the message, the sender SHOULD
generate a Trailer header field before the message body to indicate
which fields will be present in the trailers. This allows the
recipient to prepare for receipt of that metadata before it starts
processing the body, which is useful if the message is being streamed
and the recipient wishes to confirm an integrity check on the fly.
Trailer = 1#field-name
5. Message Routing
HTTP request message routing is determined by each client based on
the target resource, the client's proxy configuration, and
establishment or reuse of an inbound connection. The corresponding
response routing follows the same connection chain back to the
client.
5.1. Identifying a Target Resource
HTTP is used in a wide variety of applications, ranging from general-
purpose computers to home appliances. In some cases, communication
options are hard-coded in a client's configuration. However, most
HTTP clients rely on the same resource identification mechanism and
configuration techniques as general-purpose Web browsers.
HTTP communication is initiated by a user agent for some purpose.
The purpose is a combination of request semantics, which are defined
in [SEMNTCS], and a target resource upon which to apply those
semantics. A URI reference (Section 2.7) is typically used as an
identifier for the "target resource", which a user agent would
resolve to its absolute form in order to obtain the "target URI".
The target URI excludes the reference's fragment component, if any,
since fragment identifiers are reserved for client-side processing
([RFC3986], Section 3.5).
5.2. Connecting Inbound
Once the target URI is determined, a client needs to decide whether a
network request is necessary to accomplish the desired semantics and,
if so, where that request is to be directed.
If the client has a cache [CACHING] and the request can be satisfied
by it, then the request is usually directed there first.
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
used to satisfy the request. Proxy configuration is implementation-
dependent, but is often based on URI prefix matching, selective
authority matching, or both, and the proxy itself is usually
identified by an "http" or "https" URI. If a proxy is applicable,
the client connects inbound by establishing (or reusing) a connection
to that proxy.
If no proxy is applicable, a typical client will invoke a handler
routine, usually specific to the target URI's scheme, to connect
directly to an authority for the target resource. How that is
accomplished is dependent on the target URI scheme and defined by its
associated specification, similar to how this specification defines
origin server access for resolution of the "http" (Section 2.7.1) and
"https" (Section 2.7.2) schemes.
HTTP requirements regarding connection management are defined in
Section 6.
5.3. Request Target
Once an inbound connection is obtained, the client sends an HTTP
request message (Section 3) with a request-target derived from the
target URI. There are four distinct formats for the request-target,
depending on both the method being requested and whether the request
is to a proxy.
request-target = origin-form
/ absolute-form
/ authority-form
/ asterisk-form
5.3.1. origin-form
The most common form of request-target is the origin-form.
origin-form = absolute-path [ "?" query ]
When making a request directly to an origin server, other than a
CONNECT or server-wide OPTIONS request (as detailed below), a client
MUST send only the absolute path and query components of the target
URI as the request-target. If the target URI's path component is
empty, the client MUST send "/" as the path within the origin-form of
request-target. A Host header field is also sent, as defined in
Section 5.4.
For example, a client wishing to retrieve a representation of the
resource identified as
http://www.example.org/where?q=now
directly from the origin server would open (or reuse) a TCP
connection to port 80 of the host "www.example.org" and send the
lines:
GET /where?q=now HTTP/1.1
Host: www.example.org
followed by the remainder of the request message.
5.3.2. absolute-form
When making a request to a proxy, other than a CONNECT or server-wide
OPTIONS request (as detailed below), a client MUST send the target
URI in absolute-form as the request-target.
absolute-form = absolute-URI
The proxy is requested to either service that request from a valid
cache, if possible, or make the same request on the client's behalf
to either the next inbound proxy server or directly to the origin
server indicated by the request-target. Requirements on such
"forwarding" of messages are defined in Section 5.7.
An example absolute-form of request-line would be:
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
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 to proxies.
5.3.3. authority-form
The authority-form of request-target is only used for CONNECT
requests (Section 4.3.6 of [SEMNTCS]).
authority-form = authority
When making a CONNECT request to establish a tunnel through one or
more proxies, a client MUST send only the target URI's authority
component (excluding any userinfo and its "@" delimiter) as the
request-target. For example,
CONNECT www.example.com:80 HTTP/1.1
5.3.4. asterisk-form
The asterisk-form of request-target is only used for a server-wide
OPTIONS request (Section 4.3.7 of [SEMNTCS]).
asterisk-form = "*"
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
send only "*" (%x2A) as the request-target. For example,
OPTIONS * HTTP/1.1
If a proxy receives an OPTIONS request with an absolute-form of
request-target in which the URI has an empty path and no query
component, then the last proxy on the request chain MUST send a
request-target of "*" when it forwards the request to the indicated
origin server.
For example, the request
OPTIONS http://www.example.org:8001 HTTP/1.1
would be forwarded by the final proxy as
OPTIONS * HTTP/1.1
Host: www.example.org:8001
after connecting to port 8001 of host "www.example.org".
5.4. Host
The "Host" header field in a request provides the host and port
information from the target URI, enabling the origin server to
distinguish among resources while servicing requests for multiple
host names on a single IP address.
Host = uri-host [ ":" port ] ; Section 2.7.1
A client MUST send a Host header field in all HTTP/1.1 request
messages. If the target URI includes an authority component, then a
client MUST send a field-value for Host that is identical to that
authority component, excluding any userinfo subcomponent and its "@"
delimiter (Section 2.7.1). If the authority component is missing or
undefined for the target URI, then a client MUST send a Host header
field with an empty field-value.
Since the Host field-value is critical information for handling a
request, a user agent SHOULD generate Host as the first header field
following the request-line.
For example, a GET request to the origin server for
<http://www.example.org/pub/WWW/> would begin with:
GET /pub/WWW/ HTTP/1.1
Host: www.example.org
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
Host information to be forwarded through ancient HTTP/1.0 proxies
that might not have implemented Host.
When a proxy receives a request with an absolute-form of request-
target, the proxy MUST ignore the received Host header field (if any)
and instead replace it with the host information of the request-
target. A proxy that forwards such a request MUST generate a new
Host field-value based on the received request-target rather than
forward the received Host field-value.
Since the Host header field acts as an application-level routing
mechanism, it is a frequent target for malware seeking to poison a
shared cache or redirect a request to an unintended server. An
interception proxy is particularly vulnerable if it relies on the
Host field-value for redirecting requests to internal servers, or for
use as a cache key in a shared cache, without first verifying that
the intercepted connection is targeting a valid IP address for that
host.
A server MUST respond with a 400 (Bad Request) status code to any
HTTP/1.1 request message that lacks a Host header field and to any
request message that contains more than one Host header field or a
Host header field with an invalid field-value.
5.5. Effective Request URI
Since the request-target often contains only part of the user agent's
target URI, a server reconstructs the intended target as an
"effective request URI" to properly service the request. This
reconstruction involves both the server's local configuration and
information communicated in the request-target, Host header field,
and connection context.
For a user agent, the effective request URI is the target URI.
If the request-target is in absolute-form, the effective request URI
is the same as the request-target. Otherwise, the effective request
URI is constructed as follows:
If the server's configuration (or outbound gateway) provides a
fixed URI scheme, that scheme is used for the effective request
URI. Otherwise, if the request is received over a TLS-secured TCP
connection, the effective request URI's scheme is "https"; if not,
the scheme is "http".
If the server's configuration (or outbound gateway) provides a
fixed URI authority component, that authority is used for the
effective request URI. If not, then if the request-target is in
authority-form, the effective request URI's authority component is
the same as the request-target. If not, then if a Host header
field is supplied with a non-empty field-value, the authority
component is the same as the Host field-value. Otherwise, the
authority component is assigned the default name configured for
the server and, if the connection's incoming TCP port number
differs from the default port for the effective request URI's
scheme, then a colon (":") and the incoming port number (in
decimal form) are appended to the authority component.
If the request-target is in authority-form or asterisk-form, the
effective request URI's combined path and query component is
empty. Otherwise, the combined path and query component is the
same as the request-target.
The components of the effective request URI, once determined as
above, can be combined into absolute-URI form by concatenating the
scheme, "://", authority, and combined path and query component.
Example 1: the following message received over an insecure TCP
connection
GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.example.org:8080
has an effective request URI of
http://www.example.org:8080/pub/WWW/TheProject.html
Example 2: the following message received over a TLS-secured TCP
connection
OPTIONS * HTTP/1.1
Host: www.example.org
has an effective request URI of
https://www.example.org
Recipients of an HTTP/1.0 request that lacks a Host header field
might need to use heuristics (e.g., examination of the URI path for
something unique to a particular host) in order to guess the
effective request URI's authority component.
Once the effective request URI has been constructed, an origin server
needs to decide whether or not to provide service for that URI via
the connection in which the request was received. For example, the
request might have been misdirected, deliberately or accidentally,
such that the information within a received request-target or Host
header field differs from the host or port upon which the connection
has been made. If the connection is from a trusted gateway, that
inconsistency might be expected; otherwise, it might indicate an
attempt to bypass security filters, trick the server into delivering
non-public content, or poison a cache. See Section 9 for security
considerations regarding message routing.
5.6. Associating a Response to a Request
HTTP does not include a request identifier for associating a given
request message with its corresponding one or more response messages.
Hence, it relies on the order of response arrival to correspond
exactly to the order in which requests are made on the same
connection. More than one response message per request only occurs
when one or more informational responses (1xx, see Section 6.2 of
[SEMNTCS]) precede a final response to the same request.
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 associate each received response message on that connection to
the highest ordered request that has not yet received a final (non-
1xx) response.
5.7. Message Forwarding
As described in Section 2.3, intermediaries can serve a variety of
roles in the processing of HTTP requests and responses. Some
intermediaries are used to improve performance or availability.
Others are used for access control or to filter content. Since an
HTTP stream has characteristics similar to a pipe-and-filter
architecture, there are no inherent limits to the extent an
intermediary can enhance (or interfere) with either direction of the
stream.
An intermediary not acting as a tunnel MUST implement the Connection
header field, as specified in Section 6.1, and exclude fields from
being forwarded that are only intended for the incoming connection.
An intermediary MUST NOT forward a message to itself unless it is
protected from an infinite request loop. In general, an intermediary
ought to recognize its own server names, including any aliases, local
variations, or literal IP addresses, and respond to such requests
directly.
5.7.1. Via
The "Via" header field indicates the presence of intermediate
protocols and recipients between the user agent and the server (on
requests) or between the origin server and the client (on responses),
similar to the "Received" header field in email (Section 3.6.7 of
[RFC5322]). Via can be used for tracking message forwards, avoiding
request loops, and identifying the protocol capabilities of senders
along the request/response chain.
Via = 1#( received-protocol RWS received-by [ RWS comment ] )
received-protocol = [ protocol-name "/" ] protocol-version
; see Section 6.7
received-by = ( uri-host [ ":" port ] ) / pseudonym
pseudonym = token
Multiple Via field values represent each proxy or gateway that has
forwarded the message. Each intermediary appends its own information
about how the message was received, such that the end result is
ordered according to the sequence of forwarding recipients.
A proxy MUST send an appropriate Via header field, as described
below, in each message that it forwards. An HTTP-to-HTTP gateway
MUST send an appropriate Via header field in each inbound request
message and MAY send a Via header field in forwarded response
messages.
For each intermediary, the received-protocol indicates the protocol
and protocol version used by the upstream sender of the message.
Hence, the Via field value records the advertised protocol
capabilities of the request/response chain such that they remain
visible to downstream recipients; this can be useful for determining
what backwards-incompatible features might be safe to use in
response, or within a later request, as described in Section 2.6.
For brevity, the protocol-name is omitted when the received protocol
is HTTP.
The received-by portion of the field value is normally the host and
optional port number of a recipient server or client that
subsequently forwarded the message. However, if the real host is
considered to be sensitive information, a sender MAY replace it with
a pseudonym. If a port is not provided, a recipient MAY interpret
that as meaning it was received on the default TCP port, if any, for
the received-protocol.
A sender MAY generate comments in the Via header field to identify
the software of each recipient, analogous to the User-Agent and
Server header fields. However, all comments in the Via field are
optional, and a recipient MAY remove them prior to forwarding the
message.
For example, a request message could be sent from an HTTP/1.0 user
agent to an internal proxy code-named "fred", which uses HTTP/1.1 to
forward the request to a public proxy at p.example.net, which
completes the request by forwarding it to the origin server at
www.example.com. The request received by www.example.com would then
have the following Via header field:
Via: 1.0 fred, 1.1 p.example.net
An intermediary used as a portal through a network firewall SHOULD
NOT forward the names and ports of hosts within the firewall region
unless it is explicitly enabled to do so. If not enabled, such an
intermediary SHOULD replace each received-by host of any host behind
the firewall by an appropriate pseudonym for that host.
An intermediary MAY combine an ordered subsequence of Via header
field entries into a single such entry if the entries have identical
received-protocol values. For example,
Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
could be collapsed to
Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
A sender SHOULD NOT combine multiple entries unless they are all
under the same organizational control and the hosts have already been
replaced by pseudonyms. A sender MUST NOT combine entries that have
different received-protocol values.
5.7.2. Transformations
Some intermediaries include features for transforming messages and
their payloads. A proxy might, for example, convert between image
formats in order to save cache space or to reduce the amount of
traffic on a slow link. However, operational problems might occur
when these transformations are applied to payloads intended for
critical applications, such as medical imaging or scientific data
analysis, particularly when integrity checks or digital signatures
are used to ensure that the payload received is identical to the
original.
An HTTP-to-HTTP proxy is called a "transforming proxy" if it is
designed or configured to modify messages in a semantically
meaningful way (i.e., modifications, beyond those required by normal
HTTP processing, that change the message in a way that would be
significant to the original sender or potentially significant to
downstream recipients). For example, a transforming proxy might be
acting as a shared annotation server (modifying responses to include
references to a local annotation database), a malware filter, a
format transcoder, or a privacy filter. Such transformations are
presumed to be desired by whichever client (or client organization)
selected the proxy.
If a proxy receives a request-target with a host name that is not a
fully qualified domain name, it MAY add its own domain to the host
name it received when forwarding the request. A proxy MUST NOT
change the host name if the request-target contains a fully qualified
domain name.
A proxy MUST NOT modify the "absolute-path" and "query" parts of the
received request-target when forwarding it to the next inbound
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 server that receives an incomplete request message, usually due to
a transfer coding (Section 4). a canceled request or a triggered timeout exception, MAY send an
error response prior to closing the connection.
A proxy MUST NOT transform the payload (Section 3.3 of [SEMNTCS]) of A client that receives an incomplete response message, which can
a message that contains a no-transform cache-control directive occur when a connection is closed prematurely or when decoding a
(Section 5.2 of [CACHING]). supposedly chunked transfer coding fails, MUST record the message as
incomplete. Cache requirements for incomplete responses are defined
in Section 3 of [Caching].
A proxy MAY transform the payload of a message that does not contain If a response terminates in the middle of the header section (before
a no-transform cache-control directive. A proxy that transforms a the empty line is received) and the status code might rely on header
payload MUST add a Warning header field with the warn-code of 214 fields to convey the full meaning of the response, then the client
("Transformation Applied") if one is not already in the message (see cannot assume that meaning has been conveyed; the client might need
Section 5.5 of [CACHING]). A proxy that transforms the payload of a to repeat the request in order to determine what action to take next.
200 (OK) response can further inform downstream recipients that a
transformation has been applied by changing the response status code
to 203 (Non-Authoritative Information) (Section 6.3.4 of [SEMNTCS]).
A proxy SHOULD NOT modify header fields that provide information A message body that uses the chunked transfer coding is incomplete if
about the endpoints of the communication chain, the resource state, the zero-sized chunk that terminates the encoding has not been
or the selected representation (other than the payload) unless the received. A message that uses a valid Content-Length is incomplete
field's definition specifically allows such modification or the if the size of the message body received (in octets) is less than the
modification is deemed necessary for privacy or security. value given by Content-Length. A response that has neither chunked
transfer coding nor Content-Length is terminated by closure of the
connection and, thus, is considered complete regardless of the number
of message body octets received, provided that the header section was
received intact.
6. Connection Management 9. Connection Management
HTTP messaging is independent of the underlying transport- or HTTP messaging is independent of the underlying transport- or
session-layer connection protocol(s). HTTP only presumes a reliable session-layer connection protocol(s). HTTP only presumes a reliable
transport with in-order delivery of requests and the corresponding transport with in-order delivery of requests and the corresponding
in-order delivery of responses. The mapping of HTTP request and in-order delivery of responses. The mapping of HTTP request and
response structures onto the data units of an underlying transport response structures onto the data units of an underlying transport
protocol is outside the scope of this specification. protocol is outside the scope of this specification.
As described in Section 5.2, the specific connection protocols to be As described in Section 5.2 of [Semantics], the specific connection
used for an HTTP interaction are determined by client configuration protocols to be used for an HTTP interaction are determined by client
and the target URI. For example, the "http" URI scheme configuration and the target URI. For example, the "http" URI scheme
(Section 2.7.1) indicates a default connection of TCP over IP, with a (Section 2.5.1 of [Semantics]) indicates a default connection of TCP
default TCP port of 80, but the client might be configured to use a over IP, with a default TCP port of 80, but the client might be
proxy via some other connection, port, or protocol. configured to use a proxy via some other connection, port, or
protocol.
HTTP implementations are expected to engage in connection management, HTTP implementations are expected to engage in connection management,
which includes maintaining the state of current connections, which includes maintaining the state of current connections,
establishing a new connection or reusing an existing connection, establishing a new connection or reusing an existing connection,
processing messages received on a connection, detecting connection processing messages received on a connection, detecting connection
failures, and closing each connection. Most clients maintain failures, and closing each connection. Most clients maintain
multiple connections in parallel, including more than one connection multiple connections in parallel, including more than one connection
per server endpoint. Most servers are designed to maintain thousands per server endpoint. Most servers are designed to maintain thousands
of concurrent connections, while controlling request queues to enable of concurrent connections, while controlling request queues to enable
fair use and detect denial-of-service attacks. fair use and detect denial-of-service attacks.
6.1. Connection 9.1. Connection
The "Connection" header field allows the sender to indicate desired The "Connection" header field allows the sender to indicate desired
control options for the current connection. In order to avoid control options for the current connection. In order to avoid
confusing downstream recipients, a proxy or gateway MUST remove or confusing downstream recipients, a proxy or gateway MUST remove or
replace any received connection options before forwarding the replace any received connection options before forwarding the
message. message.
When a header field aside from Connection is used to supply control When a header field aside from Connection is used to supply control
information for or about the current connection, the sender MUST list information for or about the current connection, the sender MUST list
the corresponding field-name within the Connection header field. A the corresponding field-name within the Connection header field. A
skipping to change at page 50, line 51 skipping to change at page 28, line 33
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 [CACHING]). (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 51, line 29 skipping to change at page 29, line 13
that field-name for anything else. that field-name for anything else.
The "close" connection option is defined for a sender to signal that The "close" connection option is defined for a sender to signal that
this connection will be closed after completion of the response. For this connection will be closed after completion of the response. For
example, example,
Connection: close Connection: close
in either the request or the response header fields indicates that in either the request or the response header fields indicates that
the sender is going to close the connection after the current the sender is going to close the connection after the current
request/response is complete (Section 6.6). request/response is complete (Section 9.6).
A client that does not support persistent connections MUST send the A client that does not support persistent connections MUST send the
"close" connection option in every request message. "close" connection option in every request message.
A server that does not support persistent connections MUST send the A server that does not support persistent connections MUST send the
"close" connection option in every response message that does not "close" connection option in every response message that does not
have a 1xx (Informational) status code. have a 1xx (Informational) status code.
6.2. Establishment 9.2. Establishment
It is beyond the scope of this specification to describe how It is beyond the scope of this specification to describe how
connections are established via various transport- or session-layer connections are established via various transport- or session-layer
protocols. Each connection applies to only one transport link. protocols. Each connection applies to only one transport link.
6.3. Persistence 9.3. Persistence
HTTP/1.1 defaults to the use of "persistent connections", allowing HTTP/1.1 defaults to the use of "persistent connections", allowing
multiple requests and responses to be carried over a single multiple requests and responses to be carried over a single
connection. The "close" connection option is used to signal that a connection. The "close" connection option is used to signal that a
connection will not persist after the current request/response. HTTP connection will not persist after the current request/response. HTTP
implementations SHOULD support persistent connections. implementations SHOULD support persistent connections.
A recipient determines whether a connection is persistent or not A recipient determines whether a connection is persistent or not
based on the most recently received message's protocol version and based on the most recently received message's protocol version and
Connection header field (if any): Connection header field (if any):
skipping to change at page 52, line 28 skipping to change at page 30, line 11
connection will persist after the current response; otherwise, connection will persist after the current response; otherwise,
o The connection will close after the current response. o The connection will close after the current response.
A client MAY send additional requests on a persistent connection A client MAY send additional requests on a persistent connection
until it sends or receives a "close" connection option or receives an until it sends or receives a "close" connection option or receives an
HTTP/1.0 response without a "keep-alive" connection option. HTTP/1.0 response without a "keep-alive" connection option.
In order to remain persistent, all messages on a connection need to In order to remain persistent, all messages on a connection need to
have a self-defined message length (i.e., one not defined by closure have a self-defined message length (i.e., one not defined by closure
of the connection), as described in Section 3.3. A server MUST read of the connection), as described in Section 6. A server MUST read
the entire request message body or close the connection after sending the entire request message body or close the connection after sending
its response, since otherwise the remaining data on a persistent its response, since otherwise the remaining data on a persistent
connection would be misinterpreted as the next request. Likewise, a connection would be misinterpreted as the next request. Likewise, a
client MUST read the entire response message body if it intends to client MUST read the entire response message body if it intends to
reuse the same connection for a subsequent request. reuse the same connection for a subsequent request.
A proxy server MUST NOT maintain a persistent connection with an A proxy server MUST NOT maintain a persistent connection with an
HTTP/1.0 client (see Section 19.7.1 of [RFC2068] for information and HTTP/1.0 client (see Section 19.7.1 of [RFC2068] for information and
discussion of the problems with the Keep-Alive header field discussion of the problems with the Keep-Alive header field
implemented by many HTTP/1.0 clients). implemented by many HTTP/1.0 clients).
See Appendix A.1.2 for more information on backwards compatibility See Appendix C.1.2 for more information on backwards compatibility
with HTTP/1.0 clients. with HTTP/1.0 clients.
6.3.1. Retrying Requests 9.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 requests if all of those requests have idempotent methods
(Section 4.2.2 of [SEMNTCS]). A proxy MUST NOT automatically retry (Section 7.2.2 of [Semantics]). 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
from partial failure conditions by checking the target resource from partial failure conditions by checking the target resource
revision(s) after a failed connection, reverting or fixing any revision(s) after a failed connection, reverting or fixing any
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 9.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 [SEMNTCS]), parallel if they all have safe methods (Section 7.2.1 of
but it MUST send the corresponding responses in the same order that [Semantics]), but it MUST send the corresponding responses in the
the requests were received. same order that 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 9.6).
Idempotent methods (Section 4.2.2 of [SEMNTCS]) are significant to Idempotent methods (Section 7.2.2 of [Semantics]) 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
pipelined. If the inbound connection fails before receiving a pipelined. If the inbound connection fails before receiving a
response, the pipelining intermediary MAY attempt to retry a sequence response, the pipelining intermediary MAY attempt to retry a sequence
of requests that have yet to receive a response if the requests all of requests that have yet to receive a response if the requests all
have idempotent methods; otherwise, the pipelining intermediary have idempotent methods; otherwise, the pipelining intermediary
SHOULD forward any received responses and then close the SHOULD forward any received responses and then close the
corresponding outbound connection(s) so that the outbound user corresponding outbound connection(s) so that the outbound user
agent(s) can recover accordingly. agent(s) can recover accordingly.
6.4. Concurrency 9.4. Concurrency
A client ought to limit the number of simultaneous open connections A client ought to limit the number of simultaneous open connections
that it maintains to a given server. that it maintains to a given server.
Previous revisions of HTTP gave a specific number of connections as a Previous revisions of HTTP gave a specific number of connections as a
ceiling, but this was found to be impractical for many applications. ceiling, but this was found to be impractical for many applications.
As a result, this specification does not mandate a particular maximum As a result, this specification does not mandate a particular maximum
number of connections but, instead, encourages clients to be number of connections but, instead, encourages clients to be
conservative when opening multiple connections. conservative when opening multiple connections.
skipping to change at page 54, line 34 skipping to change at page 32, line 16
blocking" problem, wherein a request that takes significant server- blocking" problem, wherein a request that takes significant server-
side processing and/or has a large payload blocks subsequent requests side processing and/or has a large payload blocks subsequent requests
on the same connection. However, each connection consumes server on the same connection. However, each connection consumes server
resources. Furthermore, using multiple connections can cause resources. Furthermore, using multiple connections can cause
undesirable side effects in congested networks. undesirable side effects in congested networks.
Note that a server might reject traffic that it deems abusive or Note that a server might reject traffic that it deems abusive or
characteristic of a denial-of-service attack, such as an excessive characteristic of a denial-of-service attack, such as an excessive
number of open connections from a single client. number of open connections from a single client.
6.5. Failures and Timeouts 9.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
this a higher value since it is likely that the client will be making this a higher value since it is likely that the client will be making
more connections through the same proxy server. The use of more connections through the same proxy server. The use of
persistent connections places no requirements on the length (or persistent connections places no requirements on the length (or
existence) of this timeout for either the client or the server. existence) of this timeout for either the client or the server.
A client or server that wishes to time out SHOULD issue a graceful A client or server that wishes to time out SHOULD issue a graceful
close on the connection. Implementations SHOULD constantly monitor close on the connection. Implementations SHOULD constantly monitor
skipping to change at page 55, line 21 skipping to change at page 33, line 5
expectation that clients will retry. The latter technique can expectation that clients will retry. The latter technique can
exacerbate network congestion. exacerbate network congestion.
A client sending a message body SHOULD monitor the network connection A client sending a message body SHOULD monitor the network connection
for an error response while it is transmitting the request. If the for an error response while it is transmitting the request. If the
client sees a response that indicates the server does not wish to client sees a response that indicates the server does not wish to
receive the message body and is closing the connection, the client receive the message body and is closing the connection, the client
SHOULD immediately cease transmitting the body and close its side of SHOULD immediately cease transmitting the body and close its side of
the connection. the connection.
6.6. Tear-down 9.6. Tear-down
The Connection header field (Section 6.1) provides a "close" The Connection header field (Section 9.1) provides a "close"
connection option that a sender SHOULD send when it wishes to close connection option that a sender SHOULD send when it wishes to close
the connection after the current request/response pair. the connection after the current request/response pair.
A client that sends a "close" connection option MUST NOT send further A client that sends a "close" connection option MUST NOT send further
requests on that connection (after the one containing "close") and requests on that connection (after the one containing "close") and
MUST close the connection after reading the final response message MUST close the connection after reading the final response message
corresponding to this request. corresponding to this request.
A server that receives a "close" connection option MUST initiate a A server that receives a "close" connection option MUST initiate a
close of the connection (see below) after it sends the final response close of the connection (see below) after it sends the final response
skipping to change at page 56, line 24 skipping to change at page 34, line 8
the write side of the read/write connection. The server then the write side of the read/write connection. The server then
continues to read from the connection until it receives a continues to read from the connection until it receives a
corresponding close by the client, or until the server is reasonably corresponding close by the client, or until the server is reasonably
certain that its own TCP stack has received the client's certain that its own TCP stack has received the client's
acknowledgement of the packet(s) containing the server's last acknowledgement of the packet(s) containing the server's last
response. Finally, the server fully closes the connection. response. Finally, the server fully closes the connection.
It is unknown whether the reset problem is exclusive to TCP or might It is unknown whether the reset problem is exclusive to TCP or might
also be found in other transport connection protocols. also be found in other transport connection protocols.
6.7. Upgrade 9.7. Upgrade
The "Upgrade" header field is intended to provide a simple mechanism The "Upgrade" header field is intended to provide a simple mechanism
for transitioning from HTTP/1.1 to some other protocol on the same for transitioning from HTTP/1.1 to some other protocol on the same
connection. A client MAY send a list of protocols in the Upgrade connection. A client MAY send a list of protocols in the Upgrade
header field of a request to invite the server to switch to one or header field of a request to invite the server to switch to one or
more of those protocols, in order of descending preference, before more of those protocols, in order of descending preference, before
sending the final response. A server MAY ignore a received Upgrade sending the final response. A server MAY ignore a received Upgrade
header field if it wishes to continue using the current protocol on header field if it wishes to continue using the current protocol on
that connection. Upgrade cannot be used to insist on a protocol that connection. Upgrade cannot be used to insist on a protocol
change. change.
skipping to change at page 58, line 6 skipping to change at page 35, line 36
request: request:
HTTP/1.1 101 Switching Protocols HTTP/1.1 101 Switching Protocols
Connection: upgrade Connection: upgrade
Upgrade: HTTP/2.0 Upgrade: HTTP/2.0
[... data stream switches to HTTP/2.0 with an appropriate response [... data stream switches to HTTP/2.0 with an appropriate response
(as defined by new protocol) to the "GET /hello.txt" request ...] (as defined by new protocol) to the "GET /hello.txt" request ...]
When Upgrade is sent, the sender MUST also send a Connection header When Upgrade is sent, the sender MUST also send a Connection header
field (Section 6.1) that contains an "upgrade" connection option, in field (Section 9.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 [SEMNTCS]), the the "100-continue" expectation (Section 8.1.1 of [Semantics]), 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 [SEMNTCS]). (Section 9.4 of [Semantics]).
9.7.1. Upgrade Protocol Names
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 3.5 of [Semantics] and future updates to
specification. Additional tokens ought to be registered with IANA this specification. Additional protocol names ought to be registered
using the registration procedure defined in Section 8.6. using the registration procedure defined in Section 9.7.2.
7. ABNF List Extension: #rule
A #rule extension to the ABNF rules of [RFC5234] is used to improve
readability in the definitions of some header field values.
A construct "#" is defined, similar to "*", for defining comma-
delimited lists of elements. The full form is "<n>#<m>element"
indicating at least <n> and at most <m> elements, each separated by a
single comma (",") and optional whitespace (OWS).
In any production that uses the list construct, a sender MUST NOT
generate empty list elements. In other words, a sender MUST generate
lists that satisfy the following syntax:
1#element => element *( OWS "," OWS element )
and:
#element => [ 1#element ]
and for n >= 1 and m > 1:
<n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element )
For compatibility with legacy list rules, a recipient MUST parse and
ignore a reasonable number of empty list elements: enough to handle
common mistakes by senders that merge values, but not so much that
they could be used as a denial-of-service mechanism. In other words,
a recipient MUST accept lists that satisfy the following syntax:
#element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ]
1#element => *( "," OWS ) element *( OWS "," [ OWS element ] )
Empty elements do not contribute to the count of elements present.
For example, given these ABNF productions:
example-list = 1#example-list-elmt
example-list-elmt = token ; see Section 3.2.6
Then the following are valid values for example-list (not including
the double quotes, which are present for delimitation only):
"foo,bar"
"foo ,bar,"
"foo , ,bar,charlie "
In contrast, the following values would be invalid, since at least
one non-empty element is required by the example-list production:
""
","
", ,"
Appendix B shows the collected ABNF for recipients after the list
constructs have been expanded.
8. IANA Considerations
8.1. Header Field Registration
HTTP header fields are registered within the "Message Headers" +------+-------------------+--------------------+-------------------+
registry maintained at <http://www.iana.org/assignments/message- | Name | Description | Expected Version | Reference |
headers/>. | | | Tokens | |
+------+-------------------+--------------------+-------------------+
| HTTP | Hypertext | any DIGIT.DIGIT | Section 3.5 of |
| | Transfer Protocol | (e.g, "2.0") | [Semantics] |
+------+-------------------+--------------------+-------------------+
This document defines the following HTTP header fields, so the 9.7.2. Upgrade Token Registry
"Permanent Message Header Field Names" registry has been updated
accordingly (see [BCP90]).
+-------------------+----------+----------+----------------+ The "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry"
| Header Field Name | Protocol | Status | Reference | defines the namespace for protocol-name tokens used to identify
+-------------------+----------+----------+----------------+ protocols in the Upgrade header field. The registry is maintained at
| Connection | http | standard | Section 6.1 | <https://www.iana.org/assignments/http-upgrade-tokens>.
| Content-Length | http | standard | Section 3.3.2 |
| Host | http | standard | Section 5.4 |
| TE | http | standard | Section 4.3 |
| Trailer | http | standard | Section 4.4 |
| Transfer-Encoding | http | standard | Section 3.3.1 |
| Upgrade | http | standard | Section 6.7 |
| Via | http | standard | Section 5.7.1 |
+-------------------+----------+----------+----------------+
Furthermore, the header field-name "Close" has been registered as Each registered protocol name is associated with contact information
"reserved", since using that name as an HTTP header field might and an optional set of specifications that details how the connection
conflict with the "close" connection option of the Connection header will be processed after it has been upgraded.
field (Section 6.1).
+-------------------+----------+----------+--------------+ Registrations happen on a "First Come First Served" basis (see
| Header Field Name | Protocol | Status | Reference | Section 4.1 of [RFC5226]) and are subject to the following rules:
+-------------------+----------+----------+--------------+
| Close | http | reserved | Section 8.1 |
+-------------------+----------+----------+--------------+
The change controller is: "IETF (iesg@ietf.org) - Internet 1. A protocol-name token, once registered, stays registered forever.
Engineering Task Force".
8.2. URI Scheme Registration 2. The registration MUST name a responsible party for the
registration.
IANA maintains the registry of URI Schemes [BCP115] at 3. The registration MUST name a point of contact.
<http://www.iana.org/assignments/uri-schemes/>.
This document defines the following URI schemes, so the "Permanent 4. The registration MAY name a set of specifications associated with
URI Schemes" registry has been updated accordingly. that token. Such specifications need not be publicly available.
+------------+------------------------------------+---------------+ 5. The registration SHOULD name a set of expected "protocol-version"
| URI Scheme | Description | Reference | tokens associated with that token at the time of registration.
+------------+------------------------------------+---------------+
| http | Hypertext Transfer Protocol | Section 2.7.1 |
| https | Hypertext Transfer Protocol Secure | Section 2.7.2 |
+------------+------------------------------------+---------------+
8.3. Internet Media Type Registration 6. The responsible party MAY change the registration at any time.
The IANA will keep a record of all such changes, and make them
available upon request.
IANA maintains the registry of Internet media types [BCP13] at 7. The IESG MAY reassign responsibility for a protocol token. This
<http://www.iana.org/assignments/media-types>. will normally only be used in the case when a responsible party
cannot be contacted.
This document serves as the specification for the Internet media 10. Enclosing Messages as Data
types "message/http" and "application/http". The following has been
registered with IANA.
8.3.1. Internet Media Type message/http 10.1. Media Type message/http
The message/http type can be used to enclose a single HTTP request or The message/http media type can be used to enclose a single HTTP
response message, provided that it obeys the MIME restrictions for request or response message, provided that it obeys the MIME
all "message" types regarding line length and encodings. restrictions for all "message" types regarding line length and
encodings.
Type name: message Type name: message
Subtype name: http Subtype name: http
Required parameters: N/A Required parameters: N/A
Optional parameters: version, msgtype Optional parameters: version, msgtype
version: The HTTP-version number of the enclosed message (e.g., version: The HTTP-version number of the enclosed message (e.g.,
"1.1"). If not present, the version can be determined from the "1.1"). If not present, the version can be determined from the
first line of the body. first line of the body.
msgtype: The message type -- "request" or "response". If not msgtype: The message type -- "request" or "response". If not
present, the type can be determined from the first line of the present, the type can be determined from the first line of the
body. body.
Encoding considerations: only "7bit", "8bit", or "binary" are Encoding considerations: only "7bit", "8bit", or "binary" are
permitted permitted
Security considerations: see Section 9 Security considerations: see Section 11
Interoperability considerations: N/A Interoperability considerations: N/A
Published specification: This specification (see Section 8.3.1). Published specification: This specification (see Section 10.1).
Applications that use this media type: N/A Applications that use this media type: N/A
Fragment identifier considerations: N/A Fragment identifier considerations: N/A
Additional information: Additional information:
Magic number(s): N/A Magic number(s): N/A
Deprecated alias names for this type: N/A Deprecated alias names for this type: N/A
skipping to change at page 62, line 16 skipping to change at page 38, line 24
See Authors' Addresses section. See Authors' Addresses section.
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: N/A Restrictions on usage: N/A
Author: See Authors' Addresses section. Author: See Authors' Addresses section.
Change controller: IESG Change controller: IESG
8.3.2. Internet Media Type application/http 10.2. Media Type application/http
The application/http type can be used to enclose a pipeline of one or The application/http media type can be used to enclose a pipeline of
more HTTP request or response messages (not intermixed). one or more HTTP request or response messages (not intermixed).
Type name: application Type name: application
Subtype name: http Subtype name: http
Required parameters: N/A Required parameters: N/A
Optional parameters: version, msgtype Optional parameters: version, msgtype
version: The HTTP-version number of the enclosed messages (e.g., version: The HTTP-version number of the enclosed messages (e.g.,
skipping to change at page 62, line 41 skipping to change at page 38, line 49
first line of the body. first line of the body.
msgtype: The message type -- "request" or "response". If not msgtype: The message type -- "request" or "response". If not
present, the type can be determined from the first line of the present, the type can be determined from the first line of the
body. body.
Encoding considerations: HTTP messages enclosed by this type are in Encoding considerations: HTTP messages enclosed by this type are in
"binary" format; use of an appropriate Content-Transfer-Encoding "binary" format; use of an appropriate Content-Transfer-Encoding
is required when transmitted via email. is required when transmitted via email.
Security considerations: see Section 9 Security considerations: see Section 11
Interoperability considerations: N/A Interoperability considerations: N/A
Published specification: This specification (see Section 10.2).
Published specification: This specification (see Section 8.3.2).
Applications that use this media type: N/A Applications that use this media type: N/A
Fragment identifier considerations: N/A Fragment identifier considerations: N/A
Additional information: Additional information:
Deprecated alias names for this type: N/A Deprecated alias names for this type: N/A
Magic number(s): N/A Magic number(s): N/A
skipping to change at page 63, line 24 skipping to change at page 39, line 31
See Authors' Addresses section. See Authors' Addresses section.
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: N/A Restrictions on usage: N/A
Author: See Authors' Addresses section. Author: See Authors' Addresses section.
Change controller: IESG Change controller: IESG
8.4. Transfer Coding Registry 11. Security Considerations
The "HTTP Transfer Coding Registry" defines the namespace for
transfer coding names. It is maintained at
<http://www.iana.org/assignments/http-parameters>.
8.4.1. Procedure
Registrations MUST include the following fields:
o Name
o Description
o Pointer to specification text
Names of transfer codings MUST NOT overlap with names of content
codings (Section 3.1.2.1 of [SEMNTCS]) unless the encoding
transformation is identical, as is the case for the compression
codings defined in Section 4.2.
Values to be added to this namespace require IETF Review (see
Section 4.1 of [RFC5226]), and MUST conform to the purpose of
transfer coding defined in this specification.
Use of program names for the identification of encoding formats is
not desirable and is discouraged for future encodings.
8.4.2. Registration
The "HTTP Transfer Coding Registry" has been updated with the
registrations below:
+------------+------------------------------------------+-----------+
| Name | Description | Reference |
+------------+------------------------------------------+-----------+
| chunked | Transfer in a series of chunks | Section 4 |
| | | .1 |
| compress | UNIX "compress" data format [Welch] | Section 4 |
| | | .2.1 |
| deflate | "deflate" compressed data ([RFC1951]) | Section 4 |
| | inside the "zlib" data format | .2.2 |
| | ([RFC1950]) | |
| 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
IANA maintains the "HTTP Content Coding Registry" at
<http://www.iana.org/assignments/http-parameters>.
The "HTTP Content Coding Registry" has been updated with the
registrations below:
+------------+------------------------------------------+-----------+
| Name | Description | Reference |
+------------+------------------------------------------+-----------+
| compress | UNIX "compress" data format [Welch] | Section 4 |
| | | .2.1 |
| deflate | "deflate" compressed data ([RFC1951]) | Section 4 |
| | inside the "zlib" data format | .2.2 |
| | ([RFC1950]) | |
| 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.6. Upgrade Token Registry
The "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry"
defines the namespace for protocol-name tokens used to identify
protocols in the Upgrade header field. The registry is maintained at
<http://www.iana.org/assignments/http-upgrade-tokens>.
8.6.1. Procedure
Each registered protocol name is associated with contact information
and an optional set of specifications that details how the connection
will be processed after it has been upgraded.
Registrations happen on a "First Come First Served" basis (see
Section 4.1 of [RFC5226]) and are subject to the following rules:
1. A protocol-name token, once registered, stays registered forever.
2. The registration MUST name a responsible party for the
registration.
3. The registration MUST name a point of contact.
4. The registration MAY name a set of specifications associated with
that token. Such specifications need not be publicly available.
5. The registration SHOULD name a set of expected "protocol-version"
tokens associated with that token at the time of registration.
6. The responsible party MAY change the registration at any time.
The IANA will keep a record of all such changes, and make them
available upon request.
7. The IESG MAY reassign responsibility for a protocol token. This
will normally only be used in the case when a responsible party
cannot be contacted.
8.6.2. Upgrade Token Registration
The "HTTP" entry in the upgrade token registry has been updated with
the registration below:
+-------+----------------------+------------------------+-----------+
| Value | Description | Expected Version | Reference |
| | | Tokens | |
+-------+----------------------+------------------------+-----------+
| HTTP | Hypertext Transfer | any DIGIT.DIGIT (e.g, | Section 2 |
| | Protocol | "2.0") | .6 |
+-------+----------------------+------------------------+-----------+
The responsible party is: "IETF (iesg@ietf.org) - Internet
Engineering Task Force".
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 [SEMNTCS]. semantics and payloads are addressed in [Semantics].
9.1. Establishing Authority
HTTP relies on the notion of an authoritative response: a response
that has been determined by (or at the direction of) the authority
identified within the target URI to be the most appropriate response
for that request given the state of the target resource at the time
of response message origination. Providing a response from a non-
authoritative source, such as a shared cache, is often useful to
improve performance and availability, but only to the extent that the
source can be trusted or the distrusted response can be safely used.
Unfortunately, establishing authority can be difficult. For example,
phishing is an attack on the user's perception of authority, where
that perception can be misled by presenting similar branding in
hypertext, possibly aided by userinfo obfuscating the authority
component (see Section 2.7.1). User agents can reduce the impact of
phishing attacks by enabling users to easily inspect a target URI
prior to making an action, by prominently distinguishing (or
rejecting) userinfo when present, and by not sending stored
credentials and cookies when the referring document is from an
unknown or untrusted source.
When a registered name is used in the authority component, the "http"
URI scheme (Section 2.7.1) relies on the user's local name resolution
service to determine where it can find authoritative responses. This
means that any attack on a user's network host table, cached names,
or name resolution libraries becomes an avenue for attack on
establishing authority. Likewise, the user's choice of server for
Domain Name Service (DNS), and the hierarchy of servers from which it
obtains resolution results, could impact the authenticity of address
mappings; DNS Security Extensions (DNSSEC, [RFC4033]) are one way to
improve authenticity.
Furthermore, after an IP address is obtained, establishing authority
for an "http" URI is vulnerable to attacks on Internet Protocol
routing.
The "https" scheme (Section 2.7.2) is intended to prevent (or at
least reveal) many of these potential attacks on establishing
authority, provided that the negotiated TLS connection is secured and
the client properly verifies that the communicating server's identity
matches the target URI's authority component (see [RFC2818]).
Correctly implementing such verification can be difficult (see
[Georgiev]).
9.2. Risks of Intermediaries
By their very nature, HTTP intermediaries are men-in-the-middle and,
thus, represent an opportunity for man-in-the-middle attacks.
Compromise of the systems on which the intermediaries run can result
in serious security and privacy problems. Intermediaries might have
access to security-related information, personal information about
individual users and organizations, and proprietary information
belonging to users and content providers. A compromised
intermediary, or an intermediary implemented or configured without
regard to security and privacy considerations, might be used in the
commission of a wide range of potential attacks.
Intermediaries that contain a shared cache are especially vulnerable
to cache poisoning attacks, as described in Section 8 of [CACHING].
Implementers need to consider the privacy and security implications
of their design and coding decisions, and of the configuration
options they provide to operators (especially the default
configuration).
Users need to be aware that intermediaries are no more trustworthy
than the people who run them; HTTP itself cannot solve this problem.
9.3. Attacks via Protocol Element Length
Because HTTP uses mostly textual, character-delimited fields, parsers
are often vulnerable to attacks based on sending very long (or very
slow) streams of data, particularly where an implementation is
expecting a protocol element with no predefined length.
To promote interoperability, specific recommendations are made for
minimum size limits on request-line (Section 3.1.1) and header fields
(Section 3.2). These are minimum recommendations, chosen to be
supportable even by implementations with limited resources; it is
expected that most implementations will choose substantially higher
limits.
A server can reject a message that has a request-target that is too
long (Section 6.5.12 of [SEMNTCS]) or a request payload that is too
large (Section 6.5.11 of [SEMNTCS]). Additional status codes related
to capacity limits have been defined by extensions to HTTP [RFC6585].
Recipients ought to carefully limit the extent to which they process
other protocol elements, including (but not limited to) request
methods, response status phrases, header field-names, numeric values,
and body chunks. Failure to limit such processing can result in
buffer overflows, arithmetic overflows, or increased vulnerability to
denial-of-service attacks.
9.4. Response Splitting 11.1. Response Splitting
Response splitting (a.k.a, CRLF injection) is a common technique, Response splitting (a.k.a, CRLF injection) is a common technique,
used in various attacks on Web usage, that exploits the line-based used in various attacks on Web usage, that exploits the line-based
nature of HTTP message framing and the ordered association of nature of HTTP message framing and the ordered association of
requests to responses on persistent connections [Klein]. This requests to responses on persistent connections [Klein]. This
technique can be particularly damaging when the requests pass through technique can be particularly damaging when the requests pass through
a shared cache. a shared cache.
Response splitting exploits a vulnerability in servers (usually Response splitting exploits a vulnerability in servers (usually
within an application server) where an attacker can send encoded data within an application server) where an attacker can send encoded data
skipping to change at page 69, line 4 skipping to change at page 40, line 21
For example, a parameter within the request-target might be read by For example, a parameter within the request-target might be read by
an application server and reused within a redirect, resulting in the an application server and reused within a redirect, resulting in the
same parameter being echoed in the Location header field of the same parameter being echoed in the Location header field of the
response. If the parameter is decoded by the application and not response. If the parameter is decoded by the application and not
properly encoded when placed in the response field, the attacker can properly encoded when placed in the response field, the attacker can
send encoded CRLF octets and other content that will make the send encoded CRLF octets and other content that will make the
application's single response look like two or more responses. application's single response look like two or more responses.
A common defense against response splitting is to filter requests for A common defense against response splitting is to filter requests for
data that looks like encoded CR and LF (e.g., "%0D" and "%0A"). data that looks like encoded CR and LF (e.g., "%0D" and "%0A").
However, that assumes the application server is only performing URI However, that assumes the application server is only performing URI
decoding, rather than more obscure data transformations like charset decoding, rather than more obscure data transformations like charset
transcoding, XML entity translation, base64 decoding, sprintf transcoding, XML entity translation, base64 decoding, sprintf
reformatting, etc. A more effective mitigation is to prevent reformatting, etc. A more effective mitigation is to prevent
anything other than the server's core protocol libraries from sending anything other than the server's core protocol libraries from sending
a CR or LF within the header section, which means restricting the a CR or LF within the header section, which means restricting the
output of header fields to APIs that filter for bad octets and not output of header fields to APIs that filter for bad octets and not
allowing application servers to write directly to the protocol allowing application servers to write directly to the protocol
stream. stream.
9.5. Request Smuggling 11.2. Request Smuggling
Request smuggling ([Linhart]) is a technique that exploits Request smuggling ([Linhart]) is a technique that exploits
differences in protocol parsing among various recipients to hide differences in protocol parsing among various recipients to hide
additional requests (which might otherwise be blocked or disabled by additional requests (which might otherwise be blocked or disabled by
policy) within an apparently harmless request. Like response policy) within an apparently harmless request. Like response
splitting, request smuggling can lead to a variety of attacks on HTTP splitting, request smuggling can lead to a variety of attacks on HTTP
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 6.3,
Section 3.3.3, to reduce the effectiveness of request smuggling. to reduce the effectiveness of request smuggling.
9.6. Message Integrity 11.3. 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 chunk- underlying transport protocols and the use of length or 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
skipping to change at page 70, line 4 skipping to change at page 41, line 20
User agents are encouraged to implement configurable means for User agents are encouraged to implement configurable means for
detecting and reporting failures of message integrity such that those detecting and reporting failures of message integrity such that those
means can be enabled within environments for which integrity is means can be enabled within environments for which integrity is
necessary. For example, a browser being used to view medical history necessary. For example, a browser being used to view medical history
or drug interaction information needs to indicate to the user when or drug interaction information needs to indicate to the user when
such information is detected by the protocol to be incomplete, such information is detected by the protocol to be incomplete,
expired, or corrupted during transfer. Such mechanisms might be expired, or corrupted during transfer. Such mechanisms might be
selectively enabled via user agent extensions or the presence of selectively enabled via user agent extensions or the presence of
message integrity metadata in a response. At a minimum, user agents message integrity metadata in a response. At a minimum, user agents
ought to provide some indication that allows a user to distinguish ought to provide some indication that allows a user to distinguish
between a complete and incomplete response message (Section 3.4) when between a complete and incomplete response message (Section 8) when
such verification is desired. such verification is desired.
9.7. Message Confidentiality 11.4. Message Confidentiality
HTTP relies on underlying transport protocols to provide message HTTP relies on underlying transport protocols to provide message
confidentiality when that is desired. HTTP has been specifically confidentiality when that is desired. HTTP has been specifically
designed to be independent of the transport protocol, such that it designed to be independent of the transport protocol, such that it
can be used over many different forms of encrypted connection, with can be used over many different forms of encrypted connection, with
the selection of such transports being identified by the choice of the selection of such transports being identified by the choice of
URI scheme or within user agent configuration. URI scheme or within user agent configuration.
The "https" scheme can be used to identify resources that require a The "https" scheme can be used to identify resources that require a
confidential connection, as described in Section 2.7.2. confidential connection, as described in Section 2.5.2 of
[Semantics].
9.8. Privacy of Server Log Information 12. IANA Considerations
A server is in the position to save personal data about a user's This section is to be removed before publishing as an RFC.
requests over time, which might identify their reading patterns or
subjects of interest. In particular, log information gathered at an
intermediary often contains a history of user agent interaction,
across a multitude of sites, that can be traced to individual users.
HTTP log information is confidential in nature; its handling is often The change controller for the following registrations is: "IETF
constrained by laws and regulations. Log information needs to be (iesg@ietf.org) - Internet Engineering Task Force".
securely stored and appropriate guidelines followed for its analysis.
Anonymization of personal information within individual entries
helps, but it is generally not sufficient to prevent real log traces
from being re-identified based on correlation with other access
characteristics. As such, access traces that are keyed to a specific
client are unsafe to publish even if the key is pseudonymous.
To minimize the risk of theft or accidental publication, log 12.1. Header Field Registration
information ought to be purged of personally identifiable
information, including user identifiers, IP addresses, and user-
provided query parameters, as soon as that information is no longer
necessary to support operational needs for security, auditing, or
fraud control.
10. References Please update the "Message Headers" registry of "Permanent Message
Header Field Names" at <https://www.iana.org/assignments/message-
headers> with the header field names listed in the two tables of
Section 5.
10.1. Normative References 12.2. Media Type Registration
[AUTHFRM] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Please update the "Media Types" registry at
Ed., "Hypertext Transfer Protocol (HTTP): Authentication", <https://www.iana.org/assignments/media-types> with the registration
draft-ietf-httpbis-auth-00 (work in progress), April 2018. information in Section 10.1 and Section 10.2 for the media types
"message/http" and "application/http", respectively.
[CACHING] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 12.3. Transfer Coding Registration
Ed., "Hypertext Transfer Protocol (HTTP): Caching", draft-
ietf-httpbis-cache-00 (work in progress), April 2018.
[CONDTNL] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Please update the "HTTP Transfer Coding Registry" at
Ed., "Hypertext Transfer Protocol (HTTP): Conditional <https://www.iana.org/assignments/http-parameters/> with the
Requests", draft-ietf-httpbis-conditional-00 (work in registration procedure of Section 7.3 and the content coding names
progress), April 2018. summarized in the table of Section 7.
[RANGERQ] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 12.4. Upgrade Token Registration
Ed., "Hypertext Transfer Protocol (HTTP): Range Requests",
draft-ietf-httpbis-range-00 (work in progress), April
2018.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, Please update the "Hypertext Transfer Protocol (HTTP) Upgrade Token
RFC 793, DOI 10.17487/RFC0793, September 1981, Registry" at <https://www.iana.org/assignments/http-upgrade-tokens>
<https://www.rfc-editor.org/info/rfc793>. with the registration procedure of Section 9.7.2 and the upgrade
token names summarized in the table of Section 9.7.1.
13. References
13.1. Normative References
[Caching] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Caching", draft-ietf-httpbis-cache-01 (work in
progress), May 2018.
[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format
Specification version 3.3", RFC 1950, Specification version 3.3", RFC 1950,
DOI 10.17487/RFC1950, May 1996, DOI 10.17487/RFC1950, May 1996,
<https://www.rfc-editor.org/info/rfc1950>. <https://www.rfc-editor.org/info/rfc1950>.
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification
version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996, version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996,
<https://www.rfc-editor.org/info/rfc1951>. <https://www.rfc-editor.org/info/rfc1951>.
skipping to change at page 72, line 5 skipping to change at page 43, line 15
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[SEMNTCS] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [Semantics]
Ed., "Hypertext Transfer Protocol (HTTP): Semantics and Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Content", draft-ietf-httpbis-semantics-00 (work in Ed., "HTTP Semantics", draft-ietf-httpbis-semantics-01
progress), April 2018. (work in progress), May 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.
10.2. Informative References 13.2. Informative References
[BCP115] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
Registration Procedures for New URI Schemes", BCP 115,
RFC 4395, February 2006,
<https://www.rfc-editor.org/info/bcp115>.
[BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, January 2013,
<https://www.rfc-editor.org/info/bcp13>.
[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004, <https://www.rfc-editor.org/info/bcp90>.
[Georgiev]
Georgiev, M., Iyengar, S., Jana, S., Anubhai, R., Boneh,
D., and V. Shmatikov, "The Most Dangerous Code in the
World: Validating SSL Certificates in Non-browser
Software", In Proceedings of the 2012 ACM Conference on
Computer and Communications Security (CCS '12), pp. 38-49,
October 2012,
<http://doi.acm.org/10.1145/2382196.2382204>.
[ISO-8859-1]
International Organization for Standardization,
"Information technology -- 8-bit single-byte coded graphic
character sets -- Part 1: Latin alphabet No. 1", ISO/
IEC 8859-1:1998, 1998.
[Klein] Klein, A., "Divide and Conquer - HTTP Response Splitting, [Klein] Klein, A., "Divide and Conquer - HTTP Response Splitting,
Web Cache Poisoning Attacks, and Related Topics", March Web Cache Poisoning Attacks, and Related Topics", March
2004, <http://packetstormsecurity.com/papers/general/ 2004, <http://packetstormsecurity.com/papers/general/
whitepaper_httpresponse.pdf>. whitepaper_httpresponse.pdf>.
[Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and
Politics", ACM Transactions on Internet Technology 1(2),
November 2001, <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",
RFC 1919, DOI 10.17487/RFC1919, March 1996,
<https://www.rfc-editor.org/info/rfc1919>.
[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext
Transfer Protocol -- HTTP/1.0", RFC 1945, Transfer Protocol -- HTTP/1.0", RFC 1945,
DOI 10.17487/RFC1945, May 1996, DOI 10.17487/RFC1945, May 1996,
<https://www.rfc-editor.org/info/rfc1945>. <https://www.rfc-editor.org/info/rfc1945>.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
<https://www.rfc-editor.org/info/rfc2045>. <https://www.rfc-editor.org/info/rfc2045>.
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Part Three: Message Header Extensions for Non-ASCII Text", Extensions (MIME) Part Two: Media Types", RFC 2046,
RFC 2047, DOI 10.17487/RFC2047, November 1996, DOI 10.17487/RFC2046, November 1996,
<https://www.rfc-editor.org/info/rfc2047>. <https://www.rfc-editor.org/info/rfc2046>.
[RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Five: Conformance Criteria and
Examples", RFC 2049, DOI 10.17487/RFC2049, November 1996,
<https://www.rfc-editor.org/info/rfc2049>.
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
RFC 2068, DOI 10.17487/RFC2068, January 1997, RFC 2068, DOI 10.17487/RFC2068, January 1997,
<https://www.rfc-editor.org/info/rfc2068>. <https://www.rfc-editor.org/info/rfc2068>.
[RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use [RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud,
and Interpretation of HTTP Version Numbers", RFC 2145, "MIME Encapsulation of Aggregate Documents, such as HTML
DOI 10.17487/RFC2145, May 1997, (MHTML)", RFC 2557, DOI 10.17487/RFC2557, March 1999,
<https://www.rfc-editor.org/info/rfc2145>. <https://www.rfc-editor.org/info/rfc2557>.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616,
DOI 10.17487/RFC2616, June 1999,
<https://www.rfc-editor.org/info/rfc2616>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000,
<https://www.rfc-editor.org/info/rfc2818>.
[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>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/info/rfc4033>.
[RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based
Kerberos and NTLM HTTP Authentication in Microsoft
Windows", RFC 4559, DOI 10.17487/RFC4559, June 2006,
<https://www.rfc-editor.org/info/rfc4559>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<https://www.rfc-editor.org/info/rfc5226>. <https://www.rfc-editor.org/info/rfc5226>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>.
[RFC5322] Resnick, P., "Internet Message Format", RFC 5322, [RFC5322] Resnick, P., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008, DOI 10.17487/RFC5322, October 2008,
<https://www.rfc-editor.org/info/rfc5322>. <https://www.rfc-editor.org/info/rfc5322>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011, DOI 10.17487/RFC6265, April 2011,
<https://www.rfc-editor.org/info/rfc6265>. <https://www.rfc-editor.org/info/rfc6265>.
[RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status
Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012,
<https://www.rfc-editor.org/info/rfc6585>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014, RFC 7230, DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>. <https://www.rfc-editor.org/info/rfc7230>.
Appendix A. HTTP Version History [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014,
<https://www.rfc-editor.org/info/rfc7231>.
Appendix A. Collected ABNF
In the collected ABNF below, list rules are expanded as per
Section 11 of [Semantics].
BWS = <BWS, see [Semantics], Section 4.3>
Connection = *( "," OWS ) connection-option *( OWS "," [ OWS
connection-option ] )
HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body
]
HTTP-name = %x48.54.54.50 ; HTTP
HTTP-version = HTTP-name "/" DIGIT "." DIGIT
OWS = <OWS, see [Semantics], Section 4.3>
RWS = <RWS, see [Semantics], Section 4.3>
TE = [ ( "," / t-codings ) *( OWS "," [ OWS t-codings ] ) ]
Transfer-Encoding = *( "," OWS ) transfer-coding *( OWS "," [ OWS
transfer-coding ] )
Upgrade = *( "," OWS ) protocol *( OWS "," [ OWS protocol ] )
absolute-URI = <absolute-URI, see [RFC3986], Section 4.3>
absolute-form = absolute-URI
absolute-path = <absolute-path, see [Semantics], Section 2.4>
asterisk-form = "*"
authority = <authority, see [RFC3986], Section 3.2>
authority-form = authority
chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF
chunk-data = 1*OCTET
chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
chunk-ext-name = token
chunk-ext-val = token / quoted-string
chunk-size = 1*HEXDIG
chunked-body = *chunk last-chunk trailer-part CRLF
comment = <comment, see [Semantics], Section 4.2.3>
connection-option = token
field-name = <field-name, see [Semantics], Section 4.2>
field-value = <field-value, see [Semantics], Section 4.2>
header-field = field-name ":" OWS field-value OWS
last-chunk = 1*"0" [ chunk-ext ] CRLF
message-body = *OCTET
method = token
obs-fold = CRLF 1*( SP / HTAB )
obs-text = <obs-text, see [Semantics], Section 4.2.3>
origin-form = absolute-path [ "?" query ]
port = <port, see [RFC3986], Section 3.2.3>
protocol = protocol-name [ "/" protocol-version ]
protocol-name = token
protocol-version = token
query = <query, see [RFC3986], Section 3.4>
quoted-string = <quoted-string, see [Semantics], Section 4.2.3>
rank = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
reason-phrase = *( HTAB / SP / VCHAR / obs-text )
request-line = method SP request-target SP HTTP-version CRLF
request-target = origin-form / absolute-form / authority-form /
asterisk-form
start-line = request-line / status-line
status-code = 3DIGIT
status-line = HTTP-version SP status-code SP reason-phrase CRLF
t-codings = "trailers" / ( transfer-coding [ t-ranking ] )
t-ranking = OWS ";" OWS "q=" rank
token = <token, see [Semantics], Section 4.2.3>
trailer-part = *( header-field CRLF )
transfer-coding = "chunked" / "compress" / "deflate" / "gzip" /
transfer-extension
transfer-extension = token *( OWS ";" OWS transfer-parameter )
transfer-parameter = token BWS "=" BWS ( token / quoted-string )
uri-host = <host, see [RFC3986], Section 3.2.2>
Appendix B. Differences between HTTP and MIME
HTTP/1.1 uses many of the constructs defined for the Internet Message
Format [RFC5322] and the Multipurpose Internet Mail Extensions (MIME)
[RFC2045] to allow a message body to be transmitted in an open
variety of representations and with extensible header fields.
However, RFC 2045 is focused only on email; applications of HTTP have
many characteristics that differ from email; hence, HTTP has features
that differ from MIME. These differences were carefully chosen to
optimize performance over binary connections, to allow greater
freedom in the use of new media types, to make date comparisons
easier, and to acknowledge the practice of some early HTTP servers
and clients.
This appendix describes specific areas where HTTP differs from MIME.
Proxies and gateways to and from strict MIME environments need to be
aware of these differences and provide the appropriate conversions
where necessary.
B.1. MIME-Version
HTTP is not a MIME-compliant protocol. However, messages can include
a single MIME-Version header field to indicate what version of the
MIME protocol was used to construct the message. Use of the MIME-
Version header field indicates that the message is in full
conformance with the MIME protocol (as defined in [RFC2045]).
Senders are responsible for ensuring full conformance (where
possible) when exporting HTTP messages to strict MIME environments.
B.2. Conversion to Canonical Form
MIME requires that an Internet mail body part be converted to
canonical form prior to being transferred, as described in Section 4
of [RFC2049]. Section 6.1.1.2 of [Semantics] describes the forms
allowed for subtypes of the "text" media type when transmitted over
HTTP. [RFC2046] requires that content with a type of "text"
represent line breaks as CRLF and forbids the use of CR or LF outside
of line break sequences. HTTP allows CRLF, bare CR, and bare LF to
indicate a line break within text content.
A proxy or gateway from HTTP to a strict MIME environment ought to
translate all line breaks within text media types to the RFC 2049
canonical form of CRLF. Note, however, this might be complicated by
the presence of a Content-Encoding and by the fact that HTTP allows
the use of some charsets that do not use octets 13 and 10 to
represent CR and LF, respectively.
Conversion will break any cryptographic checksums applied to the
original content unless the original content is already in canonical
form. Therefore, the canonical form is recommended for any content
that uses such checksums in HTTP.
B.3. Conversion of Date Formats
HTTP/1.1 uses a restricted set of date formats (Section 10.1.1.1 of
[Semantics]) to simplify the process of date comparison. Proxies and
gateways from other protocols ought to ensure that any Date header
field present in a message conforms to one of the HTTP/1.1 formats
and rewrite the date if necessary.
B.4. Conversion of Content-Encoding
MIME does not include any concept equivalent to HTTP/1.1's Content-
Encoding header field. Since this acts as a modifier on the media
type, proxies and gateways from HTTP to MIME-compliant protocols
ought to either change the value of the Content-Type header field or
decode the representation before forwarding the message. (Some
experimental applications of Content-Type for Internet mail have used
a media-type parameter of ";conversions=<content-coding>" to perform
a function equivalent to Content-Encoding. However, this parameter
is not part of the MIME standards).
B.5. Conversion of Content-Transfer-Encoding
HTTP does not use the Content-Transfer-Encoding field of MIME.
Proxies and gateways from MIME-compliant protocols to HTTP need to
remove any Content-Transfer-Encoding prior to delivering the response
message to an HTTP client.
Proxies and gateways from HTTP to MIME-compliant protocols are
responsible for ensuring that the message is in the correct format
and encoding for safe transport on that protocol, where "safe
transport" is defined by the limitations of the protocol being used.
Such a proxy or gateway ought to transform and label the data with an
appropriate Content-Transfer-Encoding if doing so will improve the
likelihood of safe transport over the destination protocol.
B.6. MHTML and Line Length Limitations
HTTP implementations that share code with MHTML [RFC2557]
implementations need to be aware of MIME line length limitations.
Since HTTP does not have this limitation, HTTP does not fold long
lines. MHTML messages being transported by HTTP follow all
conventions of MHTML, including line length limitations and folding,
canonicalization, etc., since HTTP transfers message-bodies as
payload and, aside from the "multipart/byteranges" type
(Section 6.3.4 of [Semantics]), does not interpret the content or any
MIME header lines that might be contained therein.
Appendix C. 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
effects of hierarchical proxies, caching, the need for persistent effects of hierarchical proxies, caching, the need for persistent
connections, or name-based virtual hosts. The proliferation of connections, or name-based virtual hosts. The proliferation of
skipping to change at page 75, line 42 skipping to change at page 49, line 32
can be expected to understand any valid HTTP/1.0 response. can be expected to understand any valid HTTP/1.0 response.
Since HTTP/0.9 did not support header fields in a request, there is Since HTTP/0.9 did not support header fields in a request, there is
no mechanism for it to support name-based virtual hosts (selection of no mechanism for it to support name-based virtual hosts (selection of
resource by inspection of the Host header field). Any server that resource by inspection of the Host header field). Any server that
implements name-based virtual hosts ought to disable support for implements name-based virtual hosts ought to disable support for
HTTP/0.9. Most requests that appear to be HTTP/0.9 are, in fact, HTTP/0.9. Most requests that appear to be HTTP/0.9 are, in fact,
badly constructed HTTP/1.x requests caused by a client failing to badly constructed HTTP/1.x requests caused by a client failing to
properly encode the request-target. properly encode the request-target.
A.1. Changes from HTTP/1.0 C.1. Changes from HTTP/1.0
This section summarizes major differences between versions HTTP/1.0 This section summarizes major differences between versions HTTP/1.0
and HTTP/1.1. and HTTP/1.1.
A.1.1. Multihomed Web Servers C.1.1. Multihomed Web Servers
The requirements that clients and servers support the Host header The requirements that clients and servers support the Host header
field (Section 5.4), report an error if it is missing from an field (Section 5.4 of [Semantics]), report an error if it is missing
HTTP/1.1 request, and accept absolute URIs (Section 5.3) are among from an HTTP/1.1 request, and accept absolute URIs (Section 3.2) are
the most important changes defined by HTTP/1.1. among the most important changes defined by HTTP/1.1.
Older HTTP/1.0 clients assumed a one-to-one relationship of IP Older HTTP/1.0 clients assumed a one-to-one relationship of IP
addresses and servers; there was no other established mechanism for addresses and servers; there was no other established mechanism for
distinguishing the intended server of a request than the IP address distinguishing the intended server of a request than the IP address
to which that request was directed. The Host header field was to which that request was directed. The Host header field was
introduced during the development of HTTP/1.1 and, though it was introduced during the development of HTTP/1.1 and, though it was
quickly implemented by most HTTP/1.0 browsers, additional quickly implemented by most HTTP/1.0 browsers, additional
requirements were placed on all HTTP/1.1 requests in order to ensure requirements were placed on all HTTP/1.1 requests in order to ensure
complete adoption. At the time of this writing, most HTTP-based complete adoption. At the time of this writing, most HTTP-based
services are dependent upon the Host header field for targeting services are dependent upon the Host header field for targeting
requests. requests.
A.1.2. Keep-Alive Connections C.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 ("Keep-Alive") version of persistent connections described in
Section 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
skipping to change at page 76, line 48 skipping to change at page 50, line 39
As a result, clients are encouraged not to send the Proxy-Connection As a result, clients are encouraged not to send the Proxy-Connection
header field in any requests. header field in any requests.
Clients are also encouraged to consider the use of Connection: keep- Clients are also encouraged to consider the use of Connection: keep-
alive in requests carefully; while they can enable persistent alive in requests carefully; while they can enable persistent
connections with HTTP/1.0 servers, clients using them 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 C.1.3. Introduction of Transfer-Encoding
HTTP/1.1 introduces the Transfer-Encoding header field
(Section 3.3.1). Transfer codings need to be decoded prior to
forwarding an HTTP message over a MIME-compliant protocol.
A.2. Changes from RFC 7230
None yet.
Appendix B. Collected ABNF
BWS = OWS
Connection = *( "," OWS ) connection-option *( OWS "," [ OWS
connection-option ] )
Content-Length = 1*DIGIT
HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body
]
HTTP-name = %x48.54.54.50 ; HTTP
HTTP-version = HTTP-name "/" DIGIT "." DIGIT
Host = uri-host [ ":" port ]
OWS = *( SP / HTAB )
RWS = 1*( SP / HTAB )
TE = [ ( "," / t-codings ) *( OWS "," [ OWS t-codings ] ) ]
Trailer = *( "," OWS ) field-name *( OWS "," [ OWS field-name ] )
Transfer-Encoding = *( "," OWS ) transfer-coding *( OWS "," [ OWS
transfer-coding ] )
URI-reference = <URI-reference, see [RFC3986], Section 4.1>
Upgrade = *( "," OWS ) protocol *( OWS "," [ OWS protocol ] )
Via = *( "," OWS ) ( received-protocol RWS received-by [ RWS comment
] ) *( OWS "," [ OWS ( received-protocol RWS received-by [ RWS
comment ] ) ] )
absolute-URI = <absolute-URI, see [RFC3986], Section 4.3>
absolute-form = absolute-URI
absolute-path = 1*( "/" segment )
asterisk-form = "*"
authority = <authority, see [RFC3986], Section 3.2>
authority-form = authority
chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF
chunk-data = 1*OCTET
chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
chunk-ext-name = token
chunk-ext-val = token / quoted-string
chunk-size = 1*HEXDIG
chunked-body = *chunk last-chunk trailer-part CRLF
comment = "(" *( ctext / quoted-pair / comment ) ")"
connection-option = token
ctext = HTAB / SP / %x21-27 ; '!'-'''
/ %x2A-5B ; '*'-'['
/ %x5D-7E ; ']'-'~'
/ obs-text
field-content = field-vchar [ 1*( SP / HTAB ) field-vchar ]
field-name = token
field-value = *( field-content / obs-fold )
field-vchar = VCHAR / obs-text
fragment = <fragment, see [RFC3986], Section 3.5>
header-field = field-name ":" OWS field-value OWS
http-URI = "http://" authority path-abempty [ "?" query ] [ "#"
fragment ]
https-URI = "https://" authority path-abempty [ "?" query ] [ "#"
fragment ]
last-chunk = 1*"0" [ chunk-ext ] CRLF
message-body = *OCTET
method = token
obs-fold = CRLF 1*( SP / HTAB )
obs-text = %x80-FF
origin-form = absolute-path [ "?" query ]
partial-URI = relative-part [ "?" query ]
path-abempty = <path-abempty, see [RFC3986], Section 3.3>
port = <port, see [RFC3986], Section 3.2.3>
protocol = protocol-name [ "/" protocol-version ]
protocol-name = token
protocol-version = token
pseudonym = token
qdtext = HTAB / SP / "!" / %x23-5B ; '#'-'['
/ %x5D-7E ; ']'-'~'
/ obs-text
query = <query, see [RFC3986], Section 3.4>
quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
rank = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
reason-phrase = *( HTAB / SP / VCHAR / obs-text )
received-by = ( uri-host [ ":" port ] ) / pseudonym
received-protocol = [ protocol-name "/" ] protocol-version
relative-part = <relative-part, see [RFC3986], Section 4.2>
request-line = method SP request-target SP HTTP-version CRLF
request-target = origin-form / absolute-form / authority-form /
asterisk-form
scheme = <scheme, see [RFC3986], Section 3.1> HTTP/1.1 introduces the Transfer-Encoding header field (Section 6.1).
segment = <segment, see [RFC3986], Section 3.3> Transfer codings need to be decoded prior to forwarding an HTTP
start-line = request-line / status-line message over a MIME-compliant protocol.
status-code = 3DIGIT
status-line = HTTP-version SP status-code SP reason-phrase CRLF
t-codings = "trailers" / ( transfer-coding [ t-ranking ] ) C.2. Changes from RFC 7230
t-ranking = OWS ";" OWS "q=" rank
tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." /
"^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA
token = 1*tchar
trailer-part = *( header-field CRLF )
transfer-coding = "chunked" / "compress" / "deflate" / "gzip" /
transfer-extension
transfer-extension = token *( OWS ";" OWS transfer-parameter )
transfer-parameter = token BWS "=" BWS ( token / quoted-string )
uri-host = <host, see [RFC3986], Section 3.2.2> Most of the sections introducing HTTP's design goals, history,
architecture, conformance criteria, protocol versioning, URIs,
message routing, and header field values have been moved to
[Semantics]. This document has been reduced to just the messaging
syntax and connection management requirements specific to HTTP/1.1.
Appendix C. Change Log Appendix D. Change Log
This section is to be removed before publishing as an RFC. This section is to be removed before publishing as an RFC.
C.1. Since RFC 7230 D.1. Between RFC7230 and draft 00
The changes in this draft are purely editorial: The changes were purely editorial:
o Change boilerplate and abstract to indicate the "draft" status, o Change boilerplate and abstract to indicate the "draft" status,
and update references to ancestor specifications. and update references to ancestor specifications.
o Adjust historical notes. o Adjust historical notes.
o Update links to sibling specifications. o Update links to sibling specifications.
o Replace sections listing changes from RFC 2616 by new empty o Replace sections listing changes from RFC 2616 by new empty
sections referring to RFC 723x. sections referring to RFC 723x.
o Remove acknowledgements specific to RFC 723x. o Remove acknowledgements specific to RFC 723x.
o Move "Acknowledgements" to the very end and make them unnumbered. o Move "Acknowledgements" to the very end and make them unnumbered.
D.2. Since draft-ietf-httpbis-messaging-00
The changes in this draft are editorial, with respect to HTTP as a
whole, to move all core HTTP semantics into [Semantics]:
o Moved introduction, architecture, conformance, and ABNF extensions
from RFC 7230 (Messaging) to semantics [Semantics].
o Moved discussion of MIME differences from RFC 7231 (Semantics) to
Appendix B since they mostly cover transforming 1.1 messages.
o Moved all extensibility tips, registration procedures, and
registry tables from the IANA considerations to normative
sections, reducing the IANA considerations to just instructions
that will be removed prior to publication as an RFC.
Index Index
A A
absolute-form (of request-target) 41 absolute-form (of request-target) 10
accelerator 10 application/http Media Type 38
application/http Media Type 62 asterisk-form (of request-target) 11
asterisk-form (of request-target) 42 authority-form (of request-target) 11
authoritative response 66
authority-form (of request-target) 42
B
browser 7
C C
Connection header field 50, 55 Connection header field 27, 33
Content-Length header field 29 Content-Length header field 18
cache 11 Content-Transfer-Encoding header field 48
cacheable 11 chunked (Coding Format) 17, 19
captive portal 11 chunked (transfer coding) 22
chunked (Coding Format) 28, 31, 35 close 27, 33
client 7 compress (transfer coding) 24
close 50, 55
compress (Coding Format) 38
connection 7
D D
Delimiters 26 deflate (transfer coding) 24
deflate (Coding Format) 38
downstream 10
E E
effective request URI 44 effective request URI 12
G G
Grammar Grammar
absolute-form 41 absolute-form 9-10
absolute-path 16 ALPHA 5
absolute-URI 16 asterisk-form 9, 11
ALPHA 6 authority-form 9, 11
asterisk-form 41-42 chunk 22
authority 16 chunk-data 22
authority-form 41-42 chunk-ext 22
BWS 24 chunk-ext-name 22
chunk 35 chunk-ext-val 22
chunk-data 35 chunk-size 22
chunk-ext 35-36 chunked-body 22
chunk-ext-name 36 Connection 28
chunk-ext-val 36 connection-option 28
chunk-size 35 CR 5
chunked-body 35-36 CRLF 5
comment 27 CTL 5
Connection 50 DIGIT 5
connection-option 50 DQUOTE 5
Content-Length 30 field-name 14
CR 6 field-value 14
CRLF 6 header-field 14, 23
ctext 27 HEXDIG 5
CTL 6 HTAB 5
DIGIT 6 HTTP-message 6
DQUOTE 6 HTTP-name 6
field-content 22 HTTP-version 6
field-name 22, 39 last-chunk 22
field-value 22 LF 5
field-vchar 22 message-body 16
fragment 16 method 9
header-field 22, 36 obs-fold 15
HEXDIG 6 OCTET 5
Host 43 origin-form 9-10
HTAB 6 rank 25
HTTP-message 19 reason-phrase 14
HTTP-name 14 request-line 8
http-URI 17 request-target 9
HTTP-version 14 SP 5
https-URI 18 start-line 6
last-chunk 35 status-code 14
LF 6 status-line 13
message-body 27 t-codings 25
method 21 t-ranking 25
obs-fold 22 TE 25
obs-text 27 trailer-part 22-23
OCTET 6 transfer-coding 21
origin-form 41 Transfer-Encoding 17
OWS 24 transfer-extension 21
partial-URI 16 transfer-parameter 21
port 16 Upgrade 34
protocol-name 47 VCHAR 5
protocol-version 47 gzip (transfer coding) 24
pseudonym 47
qdtext 27
query 16
quoted-pair 27
quoted-string 27
rank 38
reason-phrase 22
received-by 47
received-protocol 47
request-line 21
request-target 41
RWS 24
scheme 16
segment 16
SP 6
start-line 20
status-code 22
status-line 22
t-codings 38
t-ranking 38
tchar 26
TE 38
token 26
Trailer 39
trailer-part 35-36
transfer-coding 35
Transfer-Encoding 28
transfer-extension 35
transfer-parameter 35
Upgrade 56
uri-host 16
URI-reference 16
VCHAR 6
Via 47
gateway 10
gzip (Coding Format) 38
H H
Host header field 43 header field 6
header field 19 header section 6
header section 19 headers 6
headers 19
http URI scheme 16
https URI scheme 18
I
inbound 10
interception proxy 11
intermediary 9
M M
MIME-Version header field 47
Media Type Media Type
application/http 62 application/http 38
message/http 61 message/http 37
message 7 message/http Media Type 37
message/http Media Type 61 method 9
method 21
N
non-transforming proxy 48
O O
origin server 7 origin-form (of request-target) 10
origin-form (of request-target) 41
outbound 10
P
phishing 66
proxy 10
R R
recipient 7 request-target 9
request 7
request-target 21
resource 16
response 7
reverse proxy 10
S
sender 7
server 7
spider 7
T T
TE header field 38 TE header field 25
Trailer header field 39 Transfer-Encoding header field 17
Transfer-Encoding header field 28
target URI 40
target resource 40
transforming proxy 48
transparent proxy 11
tunnel 10
U U
URI scheme Upgrade header field 34
http 16
https 18
Upgrade header field 56
upstream 10
user agent 7
V X
Via header field 46 x-compress (transfer coding) 24
x-gzip (transfer coding) 24
Acknowledgments Acknowledgments
This edition of the HTTP specification builds on the many See Appendix "Acknowledgments" of [Semantics].
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 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: https://roy.gbiv.com/
Mark Nottingham (editor) Mark Nottingham (editor)
Fastly Fastly
EMail: mnot@mnot.net EMail: mnot@mnot.net
URI: https://www.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: https://greenbytes.de/tech/webdav/
 End of changes. 204 change blocks. 
2459 lines changed or deleted 1017 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/