draft-ietf-httpbis-semantics-13.txt   draft-ietf-httpbis-semantics-14.txt 
HTTP Working Group R. Fielding, Ed. HTTP Working Group R. Fielding, Ed.
Internet-Draft Adobe Internet-Draft Adobe
Obsoletes: 2818, 7230, 7231, 7232, 7233, 7235, M. Nottingham, Ed. Obsoletes: 2818, 7230, 7231, 7232, 7233, 7235, M. Nottingham, Ed.
7538, 7615, 7694 (if approved) Fastly 7538, 7615, 7694 (if approved) Fastly
Updates: 3864 (if approved) J. Reschke, Ed. Updates: 3864 (if approved) J. Reschke, Ed.
Intended status: Standards Track greenbytes Intended status: Standards Track greenbytes
Expires: June 17, 2021 December 14, 2020 Expires: July 17, 2021 January 13, 2021
HTTP Semantics HTTP Semantics
draft-ietf-httpbis-semantics-13 draft-ietf-httpbis-semantics-14
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 defines the semantics shared by all versions systems. This document describes the overall architecture of HTTP,
of HTTP, including its architecture, terminology, core protocol establishes common terminology, and defines aspects of the protocol
elements, and extensibility mechanisms, along with the "http" and that are shared by all versions. In this definition are core
protocol elements, extensibility mechanisms, and the "http" and
"https" Uniform Resource Identifier (URI) schemes. "https" Uniform Resource Identifier (URI) schemes.
This document obsoletes RFC 2818, RFC 7231, RFC 7232, RFC 7233, RFC This document obsoletes RFC 2818, RFC 7231, RFC 7232, RFC 7233, RFC
7235, RFC 7538, RFC 7615, RFC 7694, and portions of RFC 7230. 7235, RFC 7538, RFC 7615, RFC 7694, and 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
<https://lists.w3.org/Archives/Public/ietf-http-wg/>. <https://lists.w3.org/Archives/Public/ietf-http-wg/>.
Working Group information can be found at <https://httpwg.org/>; 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.14. The changes in this draft are summarized in Appendix C.15.
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 June 17, 2021. This Internet-Draft will expire on July 17, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
skipping to change at page 2, line 42 skipping to change at page 2, line 42
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 . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 9
1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2. History and Evolution . . . . . . . . . . . . . . . . . . 9 1.2. History and Evolution . . . . . . . . . . . . . . . . . . 10
1.3. Core Semantics . . . . . . . . . . . . . . . . . . . . . 10 1.3. Core Semantics . . . . . . . . . . . . . . . . . . . . . 10
1.4. Specifications Obsoleted by this Document . . . . . . . . 11 1.4. Specifications Obsoleted by this Document . . . . . . . . 11
2. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 11 2. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 11 2.1. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 12
2.2. Requirements Notation . . . . . . . . . . . . . . . . . . 12 2.2. Requirements Notation . . . . . . . . . . . . . . . . . . 12
2.3. Length Requirements . . . . . . . . . . . . . . . . . . . 13 2.3. Length Requirements . . . . . . . . . . . . . . . . . . . 13
2.4. Error Handling . . . . . . . . . . . . . . . . . . . . . 13 2.4. Error Handling . . . . . . . . . . . . . . . . . . . . . 14
2.5. Protocol Version . . . . . . . . . . . . . . . . . . . . 14 2.5. Protocol Version . . . . . . . . . . . . . . . . . . . . 14
3. Terminology and Core Concepts . . . . . . . . . . . . . . . . 15 3. Terminology and Core Concepts . . . . . . . . . . . . . . . . 15
3.1. Resources . . . . . . . . . . . . . . . . . . . . . . . . 15 3.1. Resources . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2. Connections . . . . . . . . . . . . . . . . . . . . . . . 15 3.2. Representations . . . . . . . . . . . . . . . . . . . . . 16
3.3. Messages . . . . . . . . . . . . . . . . . . . . . . . . 16 3.3. Connections, Clients and Servers . . . . . . . . . . . . 16
3.4. User Agent . . . . . . . . . . . . . . . . . . . . . . . 16 3.4. Messages . . . . . . . . . . . . . . . . . . . . . . . . 17
3.5. Origin Server . . . . . . . . . . . . . . . . . . . . . . 17 3.5. User Agents . . . . . . . . . . . . . . . . . . . . . . . 17
3.6. Intermediaries . . . . . . . . . . . . . . . . . . . . . 17 3.6. Origin Server . . . . . . . . . . . . . . . . . . . . . . 18
3.7. Caches . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.7. Intermediaries . . . . . . . . . . . . . . . . . . . . . 18
3.8. Example Message Exchange . . . . . . . . . . . . . . . . 20 3.8. Caches . . . . . . . . . . . . . . . . . . . . . . . . . 20
4. Identifiers in HTTP . . . . . . . . . . . . . . . . . . . . . 21 3.9. Example Message Exchange . . . . . . . . . . . . . . . . 21
4.1. URI References . . . . . . . . . . . . . . . . . . . . . 21 4. Identifiers in HTTP . . . . . . . . . . . . . . . . . . . . . 22
4.2. HTTP-Related URI Schemes . . . . . . . . . . . . . . . . 22 4.1. URI References . . . . . . . . . . . . . . . . . . . . . 22
4.2.1. http URI Scheme . . . . . . . . . . . . . . . . . . . 22 4.2. HTTP-Related URI Schemes . . . . . . . . . . . . . . . . 23
4.2.2. https URI Scheme . . . . . . . . . . . . . . . . . . 23 4.2.1. http URI Scheme . . . . . . . . . . . . . . . . . . . 23
4.2.3. http(s) Normalization and Comparison . . . . . . . . 24 4.2.2. https URI Scheme . . . . . . . . . . . . . . . . . . 24
4.2.4. Deprecation of userinfo in http(s) URIs . . . . . . . 24 4.2.3. http(s) Normalization and Comparison . . . . . . . . 25
4.2.5. http(s) References with Fragment Identifiers . . . . 25 4.2.4. Deprecation of userinfo in http(s) URIs . . . . . . . 25
4.3. Authoritative Access . . . . . . . . . . . . . . . . . . 25 4.2.5. http(s) References with Fragment Identifiers . . . . 26
4.3.1. URI Origin . . . . . . . . . . . . . . . . . . . . . 25 4.3. Authoritative Access . . . . . . . . . . . . . . . . . . 26
4.3.2. http origins . . . . . . . . . . . . . . . . . . . . 26 4.3.1. URI Origin . . . . . . . . . . . . . . . . . . . . . 26
4.3.3. https origins . . . . . . . . . . . . . . . . . . . . 27 4.3.2. http origins . . . . . . . . . . . . . . . . . . . . 27
4.3.4. https certificate verification . . . . . . . . . . . 28 4.3.3. https origins . . . . . . . . . . . . . . . . . . . . 28
5. Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.3.4. https certificate verification . . . . . . . . . . . 29
5.1. Field Names . . . . . . . . . . . . . . . . . . . . . . . 29 5. Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.2. Field Lines and Combined Field Value . . . . . . . . . . 30 5.1. Field Names . . . . . . . . . . . . . . . . . . . . . . . 30
5.3. Field Order . . . . . . . . . . . . . . . . . . . . . . . 30 5.2. Field Lines and Combined Field Value . . . . . . . . . . 31
5.4. Field Limits . . . . . . . . . . . . . . . . . . . . . . 31 5.3. Field Order . . . . . . . . . . . . . . . . . . . . . . . 31
5.5. Field Values . . . . . . . . . . . . . . . . . . . . . . 32 5.4. Field Limits . . . . . . . . . . . . . . . . . . . . . . 32
5.6. Common Rules for Defining Field Values . . . . . . . . . 34 5.5. Field Values . . . . . . . . . . . . . . . . . . . . . . 33
5.6.1. Lists (#rule ABNF Extension) . . . . . . . . . . . . 34 5.6. Common Rules for Defining Field Values . . . . . . . . . 35
5.6.2. Tokens . . . . . . . . . . . . . . . . . . . . . . . 35 5.6.1. Lists (#rule ABNF Extension) . . . . . . . . . . . . 35
5.6.3. Whitespace . . . . . . . . . . . . . . . . . . . . . 35 5.6.2. Tokens . . . . . . . . . . . . . . . . . . . . . . . 36
5.6.4. Quoted Strings . . . . . . . . . . . . . . . . . . . 36 5.6.3. Whitespace . . . . . . . . . . . . . . . . . . . . . 36
5.6.5. Comments . . . . . . . . . . . . . . . . . . . . . . 37 5.6.4. Quoted Strings . . . . . . . . . . . . . . . . . . . 37
5.6.6. Parameters . . . . . . . . . . . . . . . . . . . . . 37 5.6.5. Comments . . . . . . . . . . . . . . . . . . . . . . 38
5.6.7. Date/Time Formats . . . . . . . . . . . . . . . . . . 37 5.6.6. Parameters . . . . . . . . . . . . . . . . . . . . . 38
6. Message Abstraction . . . . . . . . . . . . . . . . . . . . . 39 5.6.7. Date/Time Formats . . . . . . . . . . . . . . . . . . 38
6.1. Framing and Completeness . . . . . . . . . . . . . . . . 40 6. Message Abstraction . . . . . . . . . . . . . . . . . . . . . 40
6.2. Control Data . . . . . . . . . . . . . . . . . . . . . . 41 6.1. Framing and Completeness . . . . . . . . . . . . . . . . 41
6.3. Header Fields . . . . . . . . . . . . . . . . . . . . . . 42 6.2. Control Data . . . . . . . . . . . . . . . . . . . . . . 42
6.4. Payload . . . . . . . . . . . . . . . . . . . . . . . . . 42 6.3. Header Fields . . . . . . . . . . . . . . . . . . . . . . 43
6.4.1. Payload Semantics . . . . . . . . . . . . . . . . . . 43 6.4. Content . . . . . . . . . . . . . . . . . . . . . . . . . 43
6.4.2. Identifying Payloads . . . . . . . . . . . . . . . . 44 6.4.1. Content Semantics . . . . . . . . . . . . . . . . . . 44
6.5. Trailer Fields . . . . . . . . . . . . . . . . . . . . . 45 6.4.2. Identifying Content . . . . . . . . . . . . . . . . . 45
6.5.1. Limitations on use of Trailers . . . . . . . . . . . 45 6.5. Trailer Fields . . . . . . . . . . . . . . . . . . . . . 46
6.5.2. Processing Trailer Fields . . . . . . . . . . . . . . 46 6.5.1. Limitations on use of Trailers . . . . . . . . . . . 46
7. Routing HTTP Messages . . . . . . . . . . . . . . . . . . . . 47 6.5.2. Processing Trailer Fields . . . . . . . . . . . . . . 47
7.1. Determining the Target Resource . . . . . . . . . . . . . 47 7. Routing HTTP Messages . . . . . . . . . . . . . . . . . . . . 48
7.2. Host and :authority . . . . . . . . . . . . . . . . . . . 48 7.1. Determining the Target Resource . . . . . . . . . . . . . 48
7.3. Routing Inbound Requests . . . . . . . . . . . . . . . . 48 7.2. Host and :authority . . . . . . . . . . . . . . . . . . . 49
7.3.1. To a Cache . . . . . . . . . . . . . . . . . . . . . 48 7.3. Routing Inbound Requests . . . . . . . . . . . . . . . . 50
7.3.2. To a Proxy . . . . . . . . . . . . . . . . . . . . . 49 7.3.1. To a Cache . . . . . . . . . . . . . . . . . . . . . 50
7.3.3. To the Origin . . . . . . . . . . . . . . . . . . . . 49 7.3.2. To a Proxy . . . . . . . . . . . . . . . . . . . . . 50
7.4. Rejecting Misdirected Requests . . . . . . . . . . . . . 49 7.3.3. To the Origin . . . . . . . . . . . . . . . . . . . . 50
7.5. Response Correlation . . . . . . . . . . . . . . . . . . 49 7.4. Rejecting Misdirected Requests . . . . . . . . . . . . . 50
7.6. Message Forwarding . . . . . . . . . . . . . . . . . . . 50 7.5. Response Correlation . . . . . . . . . . . . . . . . . . 51
7.6.1. Connection . . . . . . . . . . . . . . . . . . . . . 50 7.6. Message Forwarding . . . . . . . . . . . . . . . . . . . 51
7.6.2. Max-Forwards . . . . . . . . . . . . . . . . . . . . 52 7.6.1. Connection . . . . . . . . . . . . . . . . . . . . . 51
7.6.3. Via . . . . . . . . . . . . . . . . . . . . . . . . . 52 7.6.2. Max-Forwards . . . . . . . . . . . . . . . . . . . . 53
7.7. Message Transformations . . . . . . . . . . . . . . . . . 54 7.6.3. Via . . . . . . . . . . . . . . . . . . . . . . . . . 54
7.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 55 7.7. Message Transformations . . . . . . . . . . . . . . . . . 55
8. Representations . . . . . . . . . . . . . . . . . . . . . . . 57 7.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 56
8.1. Selected Representations . . . . . . . . . . . . . . . . 58 8. Representation Data and Metadata . . . . . . . . . . . . . . 59
8.2. Representation Data . . . . . . . . . . . . . . . . . . . 58 8.1. Representation Data . . . . . . . . . . . . . . . . . . . 59
8.3. Representation Metadata . . . . . . . . . . . . . . . . . 58 8.2. Representation Metadata . . . . . . . . . . . . . . . . . 59
8.4. Content-Type . . . . . . . . . . . . . . . . . . . . . . 59 8.3. Content-Type . . . . . . . . . . . . . . . . . . . . . . 59
8.4.1. Media Type . . . . . . . . . . . . . . . . . . . . . 60 8.3.1. Media Type . . . . . . . . . . . . . . . . . . . . . 60
8.4.2. Charset . . . . . . . . . . . . . . . . . . . . . . . 60 8.3.2. Charset . . . . . . . . . . . . . . . . . . . . . . . 61
8.4.3. Canonicalization and Text Defaults . . . . . . . . . 61 8.3.3. Canonicalization and Text Defaults . . . . . . . . . 61
8.4.4. Multipart Types . . . . . . . . . . . . . . . . . . . 61 8.3.4. Multipart Types . . . . . . . . . . . . . . . . . . . 62
8.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . 62 8.4. Content-Encoding . . . . . . . . . . . . . . . . . . . . 62
8.5.1. Content Codings . . . . . . . . . . . . . . . . . . . 63 8.4.1. Content Codings . . . . . . . . . . . . . . . . . . . 63
8.6. Content-Language . . . . . . . . . . . . . . . . . . . . 64 8.5. Content-Language . . . . . . . . . . . . . . . . . . . . 64
8.6.1. Language Tags . . . . . . . . . . . . . . . . . . . . 65 8.5.1. Language Tags . . . . . . . . . . . . . . . . . . . . 65
8.7. Content-Length . . . . . . . . . . . . . . . . . . . . . 65 8.6. Content-Length . . . . . . . . . . . . . . . . . . . . . 66
8.8. Content-Location . . . . . . . . . . . . . . . . . . . . 67 8.7. Content-Location . . . . . . . . . . . . . . . . . . . . 67
8.9. Validator Fields . . . . . . . . . . . . . . . . . . . . 68 8.8. Validator Fields . . . . . . . . . . . . . . . . . . . . 69
8.9.1. Weak versus Strong . . . . . . . . . . . . . . . . . 69 8.8.1. Weak versus Strong . . . . . . . . . . . . . . . . . 70
8.9.2. Last-Modified . . . . . . . . . . . . . . . . . . . . 71 8.8.2. Last-Modified . . . . . . . . . . . . . . . . . . . . 71
8.9.3. ETag . . . . . . . . . . . . . . . . . . . . . . . . 73 8.8.3. ETag . . . . . . . . . . . . . . . . . . . . . . . . 73
8.9.4. When to Use Entity-Tags and Last-Modified Dates . . . 76 8.8.4. When to Use Entity-Tags and Last-Modified Dates . . . 77
9. Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 9. Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
9.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 77 9.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 77
9.2. Common Method Properties . . . . . . . . . . . . . . . . 78 9.2. Common Method Properties . . . . . . . . . . . . . . . . 79
9.2.1. Safe Methods . . . . . . . . . . . . . . . . . . . . 79 9.2.1. Safe Methods . . . . . . . . . . . . . . . . . . . . 80
9.2.2. Idempotent Methods . . . . . . . . . . . . . . . . . 80 9.2.2. Idempotent Methods . . . . . . . . . . . . . . . . . 81
9.2.3. Methods and Caching . . . . . . . . . . . . . . . . . 81 9.2.3. Methods and Caching . . . . . . . . . . . . . . . . . 82
9.3. Method Definitions . . . . . . . . . . . . . . . . . . . 81 9.3. Method Definitions . . . . . . . . . . . . . . . . . . . 82
9.3.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 81 9.3.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 82
9.3.2. HEAD . . . . . . . . . . . . . . . . . . . . . . . . 82 9.3.2. HEAD . . . . . . . . . . . . . . . . . . . . . . . . 83
9.3.3. POST . . . . . . . . . . . . . . . . . . . . . . . . 83 9.3.3. POST . . . . . . . . . . . . . . . . . . . . . . . . 84
9.3.4. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 84 9.3.4. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 85
9.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . 87 9.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . 88
9.3.6. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 88 9.3.6. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 89
9.3.7. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 90 9.3.7. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 90
9.3.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . 91 9.3.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . 91
10. Message Context . . . . . . . . . . . . . . . . . . . . . . . 91 10. Message Context . . . . . . . . . . . . . . . . . . . . . . . 92
10.1. Request Context Fields . . . . . . . . . . . . . . . . . 91 10.1. Request Context Fields . . . . . . . . . . . . . . . . . 92
10.1.1. Expect . . . . . . . . . . . . . . . . . . . . . . . 91 10.1.1. Expect . . . . . . . . . . . . . . . . . . . . . . . 92
10.1.2. From . . . . . . . . . . . . . . . . . . . . . . . . 94 10.1.2. From . . . . . . . . . . . . . . . . . . . . . . . . 94
10.1.3. Referer . . . . . . . . . . . . . . . . . . . . . . 94 10.1.3. Referer . . . . . . . . . . . . . . . . . . . . . . 95
10.1.4. TE . . . . . . . . . . . . . . . . . . . . . . . . . 95 10.1.4. TE . . . . . . . . . . . . . . . . . . . . . . . . . 96
10.1.5. Trailer . . . . . . . . . . . . . . . . . . . . . . 96 10.1.5. Trailer . . . . . . . . . . . . . . . . . . . . . . 97
10.1.6. User-Agent . . . . . . . . . . . . . . . . . . . . . 96 10.1.6. User-Agent . . . . . . . . . . . . . . . . . . . . . 97
10.2. Response Context Fields . . . . . . . . . . . . . . . . 97 10.2. Response Context Fields . . . . . . . . . . . . . . . . 98
10.2.1. Allow . . . . . . . . . . . . . . . . . . . . . . . 98 10.2.1. Allow . . . . . . . . . . . . . . . . . . . . . . . 99
10.2.2. Date . . . . . . . . . . . . . . . . . . . . . . . . 98 10.2.2. Date . . . . . . . . . . . . . . . . . . . . . . . . 99
10.2.3. Location . . . . . . . . . . . . . . . . . . . . . . 99 10.2.3. Location . . . . . . . . . . . . . . . . . . . . . . 100
10.2.4. Retry-After . . . . . . . . . . . . . . . . . . . . 101 10.2.4. Retry-After . . . . . . . . . . . . . . . . . . . . 102
10.2.5. Server . . . . . . . . . . . . . . . . . . . . . . . 101 10.2.5. Server . . . . . . . . . . . . . . . . . . . . . . . 102
11. HTTP Authentication . . . . . . . . . . . . . . . . . . . . . 102 11. HTTP Authentication . . . . . . . . . . . . . . . . . . . . . 103
11.1. Authentication Scheme . . . . . . . . . . . . . . . . . 102 11.1. Authentication Scheme . . . . . . . . . . . . . . . . . 103
11.2. Authentication Parameters . . . . . . . . . . . . . . . 102 11.2. Authentication Parameters . . . . . . . . . . . . . . . 103
11.3. Challenge and Response . . . . . . . . . . . . . . . . . 103 11.3. Challenge and Response . . . . . . . . . . . . . . . . . 104
11.4. Credentials . . . . . . . . . . . . . . . . . . . . . . 104 11.4. Credentials . . . . . . . . . . . . . . . . . . . . . . 105
11.5. Establishing a Protection Space (Realm) . . . . . . . . 104 11.5. Establishing a Protection Space (Realm) . . . . . . . . 105
11.6. Authenticating Users to Origin Servers . . . . . . . . . 105 11.6. Authenticating Users to Origin Servers . . . . . . . . . 106
11.6.1. WWW-Authenticate . . . . . . . . . . . . . . . . . . 105 11.6.1. WWW-Authenticate . . . . . . . . . . . . . . . . . . 106
11.6.2. Authorization . . . . . . . . . . . . . . . . . . . 106 11.6.2. Authorization . . . . . . . . . . . . . . . . . . . 107
11.6.3. Authentication-Info . . . . . . . . . . . . . . . . 107 11.6.3. Authentication-Info . . . . . . . . . . . . . . . . 108
11.7. Authenticating Clients to Proxies . . . . . . . . . . . 107 11.7. Authenticating Clients to Proxies . . . . . . . . . . . 108
11.7.1. Proxy-Authenticate . . . . . . . . . . . . . . . . . 107 11.7.1. Proxy-Authenticate . . . . . . . . . . . . . . . . . 108
11.7.2. Proxy-Authorization . . . . . . . . . . . . . . . . 108 11.7.2. Proxy-Authorization . . . . . . . . . . . . . . . . 109
11.7.3. Proxy-Authentication-Info . . . . . . . . . . . . . 108 11.7.3. Proxy-Authentication-Info . . . . . . . . . . . . . 109
12. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 109 12. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 110
12.1. Proactive Negotiation . . . . . . . . . . . . . . . . . 110 12.1. Proactive Negotiation . . . . . . . . . . . . . . . . . 111
12.2. Reactive Negotiation . . . . . . . . . . . . . . . . . . 111 12.2. Reactive Negotiation . . . . . . . . . . . . . . . . . . 112
12.3. Request Payload Negotiation . . . . . . . . . . . . . . 112 12.3. Request Content Negotiation . . . . . . . . . . . . . . 113
12.4. Content Negotiation Field Features . . . . . . . . . . . 112 12.4. Content Negotiation Field Features . . . . . . . . . . . 113
12.4.1. Absence . . . . . . . . . . . . . . . . . . . . . . 112 12.4.1. Absence . . . . . . . . . . . . . . . . . . . . . . 113
12.4.2. Quality Values . . . . . . . . . . . . . . . . . . . 113 12.4.2. Quality Values . . . . . . . . . . . . . . . . . . . 114
12.4.3. Wildcard Values . . . . . . . . . . . . . . . . . . 113 12.4.3. Wildcard Values . . . . . . . . . . . . . . . . . . 114
12.5. Content Negotiation Fields . . . . . . . . . . . . . . . 113 12.5. Content Negotiation Fields . . . . . . . . . . . . . . . 114
12.5.1. Accept . . . . . . . . . . . . . . . . . . . . . . . 114 12.5.1. Accept . . . . . . . . . . . . . . . . . . . . . . . 115
12.5.2. Accept-Charset . . . . . . . . . . . . . . . . . . . 116 12.5.2. Accept-Charset . . . . . . . . . . . . . . . . . . . 117
12.5.3. Accept-Encoding . . . . . . . . . . . . . . . . . . 116 12.5.3. Accept-Encoding . . . . . . . . . . . . . . . . . . 118
12.5.4. Accept-Language . . . . . . . . . . . . . . . . . . 118 12.5.4. Accept-Language . . . . . . . . . . . . . . . . . . 119
12.5.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . 119 12.5.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . 121
13. Conditional Requests . . . . . . . . . . . . . . . . . . . . 121 13. Conditional Requests . . . . . . . . . . . . . . . . . . . . 122
13.1. Preconditions . . . . . . . . . . . . . . . . . . . . . 121 13.1. Preconditions . . . . . . . . . . . . . . . . . . . . . 122
13.1.1. If-Match . . . . . . . . . . . . . . . . . . . . . . 121 13.1.1. If-Match . . . . . . . . . . . . . . . . . . . . . . 123
13.1.2. If-None-Match . . . . . . . . . . . . . . . . . . . 123 13.1.2. If-None-Match . . . . . . . . . . . . . . . . . . . 124
13.1.3. If-Modified-Since . . . . . . . . . . . . . . . . . 124 13.1.3. If-Modified-Since . . . . . . . . . . . . . . . . . 126
13.1.4. If-Unmodified-Since . . . . . . . . . . . . . . . . 126 13.1.4. If-Unmodified-Since . . . . . . . . . . . . . . . . 128
13.1.5. If-Range . . . . . . . . . . . . . . . . . . . . . . 127 13.1.5. If-Range . . . . . . . . . . . . . . . . . . . . . . 129
13.2. Evaluation of Preconditions . . . . . . . . . . . . . . 129 13.2. Evaluation of Preconditions . . . . . . . . . . . . . . 130
13.3. Precedence of Preconditions . . . . . . . . . . . . . . 130 13.2.1. When to Evaluate . . . . . . . . . . . . . . . . . . 131
14. Range Requests . . . . . . . . . . . . . . . . . . . . . . . 131 13.2.2. Precedence of Preconditions . . . . . . . . . . . . 132
14.1. Range Units . . . . . . . . . . . . . . . . . . . . . . 131 14. Range Requests . . . . . . . . . . . . . . . . . . . . . . . 133
14.1.1. Range Specifiers . . . . . . . . . . . . . . . . . . 132 14.1. Range Units . . . . . . . . . . . . . . . . . . . . . . 133
14.1.2. Byte Ranges . . . . . . . . . . . . . . . . . . . . 133 14.1.1. Range Specifiers . . . . . . . . . . . . . . . . . . 134
14.2. Range . . . . . . . . . . . . . . . . . . . . . . . . . 135 14.1.2. Byte Ranges . . . . . . . . . . . . . . . . . . . . 135
14.3. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 136 14.2. Range . . . . . . . . . . . . . . . . . . . . . . . . . 137
14.4. Content-Range . . . . . . . . . . . . . . . . . . . . . 137 14.3. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 138
14.5. Media Type multipart/byteranges . . . . . . . . . . . . 139 14.4. Content-Range . . . . . . . . . . . . . . . . . . . . . 139
15. Status Codes . . . . . . . . . . . . . . . . . . . . . . . . 140 14.5. Partial PUT . . . . . . . . . . . . . . . . . . . . . . 141
15.1. Overview of Status Codes . . . . . . . . . . . . . . . . 141 14.6. Media Type multipart/byteranges . . . . . . . . . . . . 141
15.2. Informational 1xx . . . . . . . . . . . . . . . . . . . 142 15. Status Codes . . . . . . . . . . . . . . . . . . . . . . . . 143
15.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 142 15.1. Overview of Status Codes . . . . . . . . . . . . . . . . 144
15.2.2. 101 Switching Protocols . . . . . . . . . . . . . . 143 15.2. Informational 1xx . . . . . . . . . . . . . . . . . . . 144
15.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . 143 15.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 145
15.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 143 15.2.2. 101 Switching Protocols . . . . . . . . . . . . . . 145
15.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . 144 15.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . 145
15.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . 144 15.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 146
15.3.4. 203 Non-Authoritative Information . . . . . . . . . 145 15.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . 146
15.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . 145 15.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . 147
15.3.6. 205 Reset Content . . . . . . . . . . . . . . . . . 146 15.3.4. 203 Non-Authoritative Information . . . . . . . . . 147
15.3.7. 206 Partial Content . . . . . . . . . . . . . . . . 146 15.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . 147
15.4. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 149 15.3.6. 205 Reset Content . . . . . . . . . . . . . . . . . 148
15.4.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 152 15.3.7. 206 Partial Content . . . . . . . . . . . . . . . . 148
15.4.2. 301 Moved Permanently . . . . . . . . . . . . . . . 153 15.4. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 152
15.4.3. 302 Found . . . . . . . . . . . . . . . . . . . . . 153 15.4.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 154
15.4.4. 303 See Other . . . . . . . . . . . . . . . . . . . 154 15.4.2. 301 Moved Permanently . . . . . . . . . . . . . . . 155
15.4.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 154 15.4.3. 302 Found . . . . . . . . . . . . . . . . . . . . . 155
15.4.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 155 15.4.4. 303 See Other . . . . . . . . . . . . . . . . . . . 156
15.4.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . 155 15.4.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 156
15.4.8. 307 Temporary Redirect . . . . . . . . . . . . . . . 155 15.4.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 157
15.4.9. 308 Permanent Redirect . . . . . . . . . . . . . . . 156 15.4.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . 157
15.5. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 156 15.4.8. 307 Temporary Redirect . . . . . . . . . . . . . . . 157
15.5.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 156 15.4.9. 308 Permanent Redirect . . . . . . . . . . . . . . . 158
15.5.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 156 15.5. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 158
15.5.3. 402 Payment Required . . . . . . . . . . . . . . . . 157 15.5.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 158
15.5.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 157 15.5.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 159
15.5.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 157 15.5.3. 402 Payment Required . . . . . . . . . . . . . . . . 159
15.5.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 158 15.5.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 159
15.5.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 158 15.5.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 159
15.5.8. 407 Proxy Authentication Required . . . . . . . . . 158 15.5.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 160
15.5.9. 408 Request Timeout . . . . . . . . . . . . . . . . 158 15.5.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 160
15.5.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . 159 15.5.8. 407 Proxy Authentication Required . . . . . . . . . 160
15.5.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 159 15.5.9. 408 Request Timeout . . . . . . . . . . . . . . . . 160
15.5.12. 411 Length Required . . . . . . . . . . . . . . . . 159 15.5.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . 161
15.5.13. 412 Precondition Failed . . . . . . . . . . . . . . 160 15.5.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 161
15.5.14. 413 Payload Too Large . . . . . . . . . . . . . . . 160 15.5.12. 411 Length Required . . . . . . . . . . . . . . . . 162
15.5.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . 160 15.5.13. 412 Precondition Failed . . . . . . . . . . . . . . 162
15.5.16. 415 Unsupported Media Type . . . . . . . . . . . . . 160 15.5.14. 413 Content Too Large . . . . . . . . . . . . . . . 162
15.5.17. 416 Range Not Satisfiable . . . . . . . . . . . . . 161 15.5.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . 162
15.5.18. 417 Expectation Failed . . . . . . . . . . . . . . . 161 15.5.16. 415 Unsupported Media Type . . . . . . . . . . . . . 163
15.5.19. 418 (Unused) . . . . . . . . . . . . . . . . . . . . 162 15.5.17. 416 Range Not Satisfiable . . . . . . . . . . . . . 163
15.5.20. 422 Unprocessable Payload . . . . . . . . . . . . . 162 15.5.18. 417 Expectation Failed . . . . . . . . . . . . . . . 164
15.5.21. 426 Upgrade Required . . . . . . . . . . . . . . . . 162 15.5.19. 418 (Unused) . . . . . . . . . . . . . . . . . . . . 164
15.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 163 15.5.20. 421 Misdirected Request . . . . . . . . . . . . . . 164
15.6.1. 500 Internal Server Error . . . . . . . . . . . . . 163 15.5.21. 422 Unprocessable Content . . . . . . . . . . . . . 165
15.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . 163 15.5.22. 426 Upgrade Required . . . . . . . . . . . . . . . . 165
15.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 163 15.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 165
15.6.4. 503 Service Unavailable . . . . . . . . . . . . . . 163 15.6.1. 500 Internal Server Error . . . . . . . . . . . . . 165
15.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 164 15.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . 166
15.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . 164 15.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 166
16. Extending HTTP . . . . . . . . . . . . . . . . . . . . . . . 164 15.6.4. 503 Service Unavailable . . . . . . . . . . . . . . 166
16.1. Method Extensibility . . . . . . . . . . . . . . . . . . 165 15.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 166
16.1.1. Method Registry . . . . . . . . . . . . . . . . . . 165 15.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . 166
16.1.2. Considerations for New Methods . . . . . . . . . . . 165 16. Extending HTTP . . . . . . . . . . . . . . . . . . . . . . . 167
16.2. Status Code Extensibility . . . . . . . . . . . . . . . 166 16.1. Method Extensibility . . . . . . . . . . . . . . . . . . 167
16.2.1. Status Code Registry . . . . . . . . . . . . . . . . 166 16.1.1. Method Registry . . . . . . . . . . . . . . . . . . 167
16.2.2. Considerations for New Status Codes . . . . . . . . 166 16.1.2. Considerations for New Methods . . . . . . . . . . . 168
16.3. Field Extensibility . . . . . . . . . . . . . . . . . . 167 16.2. Status Code Extensibility . . . . . . . . . . . . . . . 168
16.3.1. Field Name Registry . . . . . . . . . . . . . . . . 168 16.2.1. Status Code Registry . . . . . . . . . . . . . . . . 169
16.3.2. Considerations for New Field Names . . . . . . . . . 169 16.2.2. Considerations for New Status Codes . . . . . . . . 169
16.3.3. Considerations for New Field Values . . . . . . . . 169 16.3. Field Extensibility . . . . . . . . . . . . . . . . . . 170
16.4. Authentication Scheme Extensibility . . . . . . . . . . 171 16.3.1. Field Name Registry . . . . . . . . . . . . . . . . 170
16.4.1. Authentication Scheme Registry . . . . . . . . . . . 171 16.3.2. Considerations for New Fields . . . . . . . . . . . 172
16.4.2. Considerations for New Authentication Schemes . . . 171 16.4. Authentication Scheme Extensibility . . . . . . . . . . 174
16.5. Range Unit Extensibility . . . . . . . . . . . . . . . . 172 16.4.1. Authentication Scheme Registry . . . . . . . . . . . 174
16.5.1. Range Unit Registry . . . . . . . . . . . . . . . . 173 16.4.2. Considerations for New Authentication Schemes . . . 175
16.5.2. Considerations for New Range Units . . . . . . . . . 173 16.5. Range Unit Extensibility . . . . . . . . . . . . . . . . 176
16.6. Content Coding Extensibility . . . . . . . . . . . . . . 173 16.5.1. Range Unit Registry . . . . . . . . . . . . . . . . 176
16.6.1. Content Coding Registry . . . . . . . . . . . . . . 173 16.5.2. Considerations for New Range Units . . . . . . . . . 176
16.6.2. Considerations for New Content Codings . . . . . . . 174 16.6. Content Coding Extensibility . . . . . . . . . . . . . . 176
16.7. Upgrade Token Registry . . . . . . . . . . . . . . . . . 174 16.6.1. Content Coding Registry . . . . . . . . . . . . . . 177
17. Security Considerations . . . . . . . . . . . . . . . . . . . 175 16.6.2. Considerations for New Content Codings . . . . . . . 177
17.1. Establishing Authority . . . . . . . . . . . . . . . . . 175 16.7. Upgrade Token Registry . . . . . . . . . . . . . . . . . 177
17.2. Risks of Intermediaries . . . . . . . . . . . . . . . . 176 17. Security Considerations . . . . . . . . . . . . . . . . . . . 178
17.3. Attacks Based on File and Path Names . . . . . . . . . . 177 17.1. Establishing Authority . . . . . . . . . . . . . . . . . 178
17.4. Attacks Based on Command, Code, or Query Injection . . . 177 17.2. Risks of Intermediaries . . . . . . . . . . . . . . . . 179
17.5. Attacks via Protocol Element Length . . . . . . . . . . 178 17.3. Attacks Based on File and Path Names . . . . . . . . . . 180
17.6. Attacks using Shared-dictionary Compression . . . . . . 178 17.4. Attacks Based on Command, Code, or Query Injection . . . 181
17.7. Disclosure of Personal Information . . . . . . . . . . . 179 17.5. Attacks via Protocol Element Length . . . . . . . . . . 181
17.8. Privacy of Server Log Information . . . . . . . . . . . 179 17.6. Attacks using Shared-dictionary Compression . . . . . . 182
17.9. Disclosure of Sensitive Information in URIs . . . . . . 180 17.7. Disclosure of Personal Information . . . . . . . . . . . 182
17.10. Disclosure of Fragment after Redirects . . . . . . . . . 180 17.8. Privacy of Server Log Information . . . . . . . . . . . 182
17.11. Disclosure of Product Information . . . . . . . . . . . 181 17.9. Disclosure of Sensitive Information in URIs . . . . . . 183
17.12. Browser Fingerprinting . . . . . . . . . . . . . . . . . 181 17.10. Disclosure of Fragment after Redirects . . . . . . . . . 184
17.13. Validator Retention . . . . . . . . . . . . . . . . . . 182 17.11. Disclosure of Product Information . . . . . . . . . . . 184
17.14. Denial-of-Service Attacks Using Range . . . . . . . . . 182 17.12. Browser Fingerprinting . . . . . . . . . . . . . . . . . 184
17.15. Authentication Considerations . . . . . . . . . . . . . 183 17.13. Validator Retention . . . . . . . . . . . . . . . . . . 185
17.15.1. Confidentiality of Credentials . . . . . . . . . . 183 17.14. Denial-of-Service Attacks Using Range . . . . . . . . . 186
17.15.2. Credentials and Idle Clients . . . . . . . . . . . 183 17.15. Authentication Considerations . . . . . . . . . . . . . 186
17.15.3. Protection Spaces . . . . . . . . . . . . . . . . . 184 17.15.1. Confidentiality of Credentials . . . . . . . . . . 186
17.15.4. Additional Response Fields . . . . . . . . . . . . 184 17.15.2. Credentials and Idle Clients . . . . . . . . . . . 187
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 184 17.15.3. Protection Spaces . . . . . . . . . . . . . . . . . 187
18.1. URI Scheme Registration . . . . . . . . . . . . . . . . 185 17.15.4. Additional Response Fields . . . . . . . . . . . . 188
18.2. Method Registration . . . . . . . . . . . . . . . . . . 185 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 188
18.3. Status Code Registration . . . . . . . . . . . . . . . . 185 18.1. URI Scheme Registration . . . . . . . . . . . . . . . . 188
18.4. Field Name Registration . . . . . . . . . . . . . . . . 187 18.2. Method Registration . . . . . . . . . . . . . . . . . . 188
18.5. Authentication Scheme Registration . . . . . . . . . . . 189 18.3. Status Code Registration . . . . . . . . . . . . . . . . 189
18.6. Content Coding Registration . . . . . . . . . . . . . . 189 18.4. Field Name Registration . . . . . . . . . . . . . . . . 190
18.7. Range Unit Registration . . . . . . . . . . . . . . . . 189 18.5. Authentication Scheme Registration . . . . . . . . . . . 192
18.8. Media Type Registration . . . . . . . . . . . . . . . . 190 18.6. Content Coding Registration . . . . . . . . . . . . . . 192
18.9. Port Registration . . . . . . . . . . . . . . . . . . . 190 18.7. Range Unit Registration . . . . . . . . . . . . . . . . 193
18.10. Upgrade Token Registration . . . . . . . . . . . . . . . 190 18.8. Media Type Registration . . . . . . . . . . . . . . . . 193
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 190 18.9. Port Registration . . . . . . . . . . . . . . . . . . . 193
19.1. Normative References . . . . . . . . . . . . . . . . . . 190 18.10. Upgrade Token Registration . . . . . . . . . . . . . . . 194
19.2. Informative References . . . . . . . . . . . . . . . . . 192 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 194
Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 199 19.1. Normative References . . . . . . . . . . . . . . . . . . 194
Appendix B. Changes from previous RFCs . . . . . . . . . . . . . 203 19.2. Informative References . . . . . . . . . . . . . . . . . 196
B.1. Changes from RFC 2818 . . . . . . . . . . . . . . . . . . 203 Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 202
B.2. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 204 Appendix B. Changes from previous RFCs . . . . . . . . . . . . . 207
B.3. Changes from RFC 7231 . . . . . . . . . . . . . . . . . . 205 B.1. Changes from RFC 2818 . . . . . . . . . . . . . . . . . . 207
B.4. Changes from RFC 7232 . . . . . . . . . . . . . . . . . . 206 B.2. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 207
B.5. Changes from RFC 7233 . . . . . . . . . . . . . . . . . . 206 B.3. Changes from RFC 7231 . . . . . . . . . . . . . . . . . . 208
B.6. Changes from RFC 7235 . . . . . . . . . . . . . . . . . . 206 B.4. Changes from RFC 7232 . . . . . . . . . . . . . . . . . . 210
B.7. Changes from RFC 7538 . . . . . . . . . . . . . . . . . . 207 B.5. Changes from RFC 7233 . . . . . . . . . . . . . . . . . . 210
B.8. Changes from RFC 7615 . . . . . . . . . . . . . . . . . . 207 B.6. Changes from RFC 7235 . . . . . . . . . . . . . . . . . . 210
B.9. Changes from RFC 7694 . . . . . . . . . . . . . . . . . . 207 B.7. Changes from RFC 7538 . . . . . . . . . . . . . . . . . . 210
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 207 B.8. Changes from RFC 7615 . . . . . . . . . . . . . . . . . . 211
C.1. Between RFC723x and draft 00 . . . . . . . . . . . . . . 207 B.9. Changes from RFC 7694 . . . . . . . . . . . . . . . . . . 211
C.2. Since draft-ietf-httpbis-semantics-00 . . . . . . . . . . 207 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 211
C.3. Since draft-ietf-httpbis-semantics-01 . . . . . . . . . . 208 C.1. Between RFC723x and draft 00 . . . . . . . . . . . . . . 211
C.4. Since draft-ietf-httpbis-semantics-02 . . . . . . . . . . 209 C.2. Since draft-ietf-httpbis-semantics-00 . . . . . . . . . . 211
C.5. Since draft-ietf-httpbis-semantics-03 . . . . . . . . . . 210 C.3. Since draft-ietf-httpbis-semantics-01 . . . . . . . . . . 212
C.6. Since draft-ietf-httpbis-semantics-04 . . . . . . . . . . 211 C.4. Since draft-ietf-httpbis-semantics-02 . . . . . . . . . . 213
C.7. Since draft-ietf-httpbis-semantics-05 . . . . . . . . . . 211 C.5. Since draft-ietf-httpbis-semantics-03 . . . . . . . . . . 214
C.8. Since draft-ietf-httpbis-semantics-06 . . . . . . . . . . 213 C.6. Since draft-ietf-httpbis-semantics-04 . . . . . . . . . . 215
C.9. Since draft-ietf-httpbis-semantics-07 . . . . . . . . . . 214 C.7. Since draft-ietf-httpbis-semantics-05 . . . . . . . . . . 215
C.10. Since draft-ietf-httpbis-semantics-08 . . . . . . . . . . 215 C.8. Since draft-ietf-httpbis-semantics-06 . . . . . . . . . . 217
C.11. Since draft-ietf-httpbis-semantics-09 . . . . . . . . . . 217 C.9. Since draft-ietf-httpbis-semantics-07 . . . . . . . . . . 218
C.12. Since draft-ietf-httpbis-semantics-10 . . . . . . . . . . 217 C.10. Since draft-ietf-httpbis-semantics-08 . . . . . . . . . . 219
C.13. Since draft-ietf-httpbis-semantics-11 . . . . . . . . . . 219 C.11. Since draft-ietf-httpbis-semantics-09 . . . . . . . . . . 221
C.14. Since draft-ietf-httpbis-semantics-12 . . . . . . . . . . 219 C.12. Since draft-ietf-httpbis-semantics-10 . . . . . . . . . . 221
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 221 C.13. Since draft-ietf-httpbis-semantics-11 . . . . . . . . . . 222
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 222 C.14. Since draft-ietf-httpbis-semantics-12 . . . . . . . . . . 223
C.15. Since draft-ietf-httpbis-semantics-13 . . . . . . . . . . 225
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 225
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 226
1. Introduction 1. Introduction
1.1. Purpose 1.1. Purpose
The Hypertext Transfer Protocol (HTTP) is a family of stateless, The Hypertext Transfer Protocol (HTTP) is a family of stateless,
application-level, request/response protocols that share a generic application-level, request/response protocols that share a generic
interface, extensible semantics, and self-descriptive messages to interface, extensible semantics, and self-descriptive messages to
enable flexible interaction with network-based hypertext information enable flexible interaction with network-based hypertext information
systems. systems.
skipping to change at page 9, line 45 skipping to change at page 10, line 11
interface provided by servers. However, since multiple clients might interface provided by servers. However, since multiple clients might
act in parallel and perhaps at cross-purposes, we cannot require that act in parallel and perhaps at cross-purposes, we cannot require that
such changes be observable beyond the scope of a single response. such changes be observable beyond the scope of a single response.
1.2. History and Evolution 1.2. History and Evolution
HTTP has been the primary information transfer protocol for the World HTTP has been the primary information transfer protocol for the World
Wide Web since its introduction in 1990. It began as a trivial Wide Web since its introduction in 1990. It began as a trivial
mechanism for low-latency requests, with a single method (GET) to mechanism for low-latency requests, with a single method (GET) to
request transfer of a presumed hypertext document identified by a request transfer of a presumed hypertext document identified by a
given pathname. This original protocol is now referred to as given pathname. As the Web grew, HTTP was extended to enclose
HTTP/0.9 (see [HTTP/0.9]). requests and responses within messages, transfer arbitrary data
formats using MIME-like media types, and route requests through
As the Web grew, HTTP was extended to enclose requests and responses intermediaries. These protocols were eventually defined as HTTP/0.9
within messages, transfer arbitrary data formats using MIME-like and HTTP/1.0 (see [RFC1945]).
media types, and route requests through intermediaries, eventually
being defined as HTTP/1.0 [RFC1945].
HTTP/1.1 was designed to refine the protocol's features while HTTP/1.1 was designed to refine the protocol's features while
retaining compatibility with the existing text-based messaging retaining compatibility with the existing text-based messaging
syntax, improving its interoperability, scalability, and robustness syntax, improving its interoperability, scalability, and robustness
across the Internet. This included length-based payload delimiters across the Internet. This included length-based data delimiters for
for both fixed and dynamic (chunked) content, a consistent framework both fixed and dynamic (chunked) content, a consistent framework for
for content negotiation, opaque validators for conditional requests, content negotiation, opaque validators for conditional requests,
cache controls for better cache consistency, range requests for cache controls for better cache consistency, range requests for
partial updates, and default persistent connections. HTTP/1.1 was partial updates, and default persistent connections. HTTP/1.1 was
introduced in 1995 and published on the standards track in 1997 introduced in 1995 and published on the standards track in 1997
[RFC2068], 1999 [RFC2616], and 2014 ([RFC7230] - [RFC7235]). [RFC2068], revised in 1999 [RFC2616], and revised again in 2014
([RFC7230] - [RFC7235]).
HTTP/2 ([RFC7540]) introduced a multiplexed session layer on top of HTTP/2 ([RFC7540]) introduced a multiplexed session layer on top of
the existing TLS and TCP protocols for exchanging concurrent HTTP the existing TLS and TCP protocols for exchanging concurrent HTTP
messages with efficient field compression and server push. HTTP/3 messages with efficient field compression and server push. HTTP/3
([HTTP3]) provides greater independence for concurrent messages by ([HTTP3]) provides greater independence for concurrent messages by
using QUIC as a secure multiplexed transport over UDP instead of TCP. using QUIC as a secure multiplexed transport over UDP instead of TCP.
All three major versions of HTTP rely on the semantics defined by All three major versions of HTTP rely on the semantics defined by
this document. They have not obsoleted each other because each one this document. They have not obsoleted each other because each one
has specific benefits and limitations depending on the context of has specific benefits and limitations depending on the context of
skipping to change at page 10, line 36 skipping to change at page 10, line 49
transport and messaging syntax for their particular context. transport and messaging syntax for their particular context.
This revision of HTTP separates the definition of semantics (this This revision of HTTP separates the definition of semantics (this
document) and caching ([Caching]) from the current HTTP/1.1 messaging document) and caching ([Caching]) from the current HTTP/1.1 messaging
syntax ([Messaging]) to allow each major protocol version to progress syntax ([Messaging]) to allow each major protocol version to progress
independently while referring to the same core semantics. independently while referring to the same core semantics.
1.3. Core Semantics 1.3. Core Semantics
HTTP provides a uniform interface for interacting with a resource HTTP provides a uniform interface for interacting with a resource
(Section 3.1), regardless of its type, nature, or implementation, by (Section 3.1) - regardless of its type, nature, or implementation -
sending messages that manipulate or transfer representations by sending messages that manipulate or transfer representations
(Section 8). (Section 3.2).
Each message is either a request or a response. A client constructs Each message is either a request or a response. A client constructs
request messages that communicate its intentions and routes those request messages that communicate its intentions and routes those
messages toward an identified origin server. A server listens for messages toward an identified origin server. A server listens for
requests, parses each message received, interprets the message requests, parses each message received, interprets the message
semantics in relation to the identified target resource, and responds semantics in relation to the identified target resource, and responds
to that request with one or more response messages. The client to that request with one or more response messages. The client
examines received responses to see if its intentions were carried examines received responses to see if its intentions were carried
out, determining what to do next based on the received status and out, determining what to do next based on the status codes and
payloads. content received.
HTTP semantics include the intentions defined by each request method HTTP semantics include the intentions defined by each request method
(Section 9), extensions to those semantics that might be described in (Section 9), extensions to those semantics that might be described in
request header fields, status codes that describe the response request header fields, status codes that describe the response
(Section 15), and other control data and resource metadata that might (Section 15), and other control data and resource metadata that might
be given in response fields. be given in response fields.
Semantics also include representation metadata that describe how a Semantics also include representation metadata that describe how
payload is intended to be interpreted by a recipient, request header content is intended to be interpreted by a recipient, request header
fields that might influence content selection, and the various fields that might influence content selection, and the various
selection algorithms that are collectively referred to as "_content selection algorithms that are collectively referred to as _content
negotiation_" (Section 12). negotiation_ (Section 12).
1.4. Specifications Obsoleted by this Document 1.4. Specifications Obsoleted by this Document
This document obsoletes the following specifications: This document obsoletes the following specifications:
-------------------------------------------- ----------- --------- -------------------------------------------- ----------- ---------
Title Reference Changes Title Reference Changes
-------------------------------------------- ----------- --------- -------------------------------------------- ----------- ---------
HTTP Over TLS [RFC2818] B.1 HTTP Over TLS [RFC2818] B.1
HTTP/1.1 Message Syntax and Routing [*] [RFC7230] B.2 HTTP/1.1 Message Syntax and Routing [*] [RFC7230] B.2
skipping to change at page 12, line 6 skipping to change at page 12, line 14
2. Conformance 2. Conformance
2.1. Syntax Notation 2.1. Syntax Notation
This specification uses the Augmented Backus-Naur Form (ABNF) This specification uses the Augmented Backus-Naur Form (ABNF)
notation of [RFC5234], extended with the notation for case- notation of [RFC5234], extended with the notation for case-
sensitivity in strings defined in [RFC7405]. sensitivity in strings defined in [RFC7405].
It also uses a list extension, defined in Section 5.6.1, that allows It also uses a list extension, defined in Section 5.6.1, that allows
for compact definition of comma-separated lists using a '#' operator for compact definition of comma-separated lists using a "#" operator
(similar to how the '*' operator indicates repetition). Appendix A (similar to how the "*" operator indicates repetition). Appendix A
shows the collected grammar with all list operators expanded to shows the collected grammar with all list operators expanded to
standard ABNF notation. standard ABNF notation.
As a convention, ABNF rule names prefixed with "obs-" denote As a convention, ABNF rule names prefixed with "obs-" denote
"obsolete" grammar rules that appear for historical reasons. "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
Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return),
CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double
quote), HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF quote), HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF
skipping to change at page 13, line 16 skipping to change at page 13, line 24
elements. A sender MUST NOT generate protocol elements that convey a elements. A sender MUST NOT generate protocol elements that convey a
meaning that is known by that sender to be false. A sender MUST NOT meaning that is known by that sender to be false. A sender MUST NOT
generate protocol elements that do not match the grammar defined by generate protocol elements that do not match the grammar defined by
the corresponding ABNF rules. Within a given message, a sender MUST the corresponding ABNF rules. Within a given message, a sender MUST
NOT generate protocol elements or syntax alternatives that are only NOT generate protocol elements or syntax alternatives that are only
allowed to be generated by participants in other roles (i.e., a role allowed to be generated by participants in other roles (i.e., a role
that the sender does not have for that message). that the sender does not have for that message).
2.3. Length Requirements 2.3. Length Requirements
When a received protocol element is parsed, the recipient MUST be A recipient SHOULD parse a received protocol element defensively,
able to parse any value of reasonable length that is applicable to with only marginal expectations that the element will conform to its
the recipient's role and that matches the grammar defined by the ABNF grammar and fit within a reasonable buffer size.
corresponding ABNF rules. Note, however, that some received protocol
elements might not be parsed. For example, an intermediary
forwarding a message might parse a field into generic field name and
field value components, but then forward the field without further
parsing inside the field value.
HTTP does not have specific length limitations for many of its HTTP does not have specific length limitations for many of its
protocol elements because the lengths that might be appropriate will protocol elements because the lengths that might be appropriate will
vary widely, depending on the deployment context and purpose of the vary widely, depending on the deployment context and purpose of the
implementation. Hence, interoperability between senders and implementation. Hence, interoperability between senders and
recipients depends on shared expectations regarding what is a recipients depends on shared expectations regarding what is a
reasonable length for each protocol element. Furthermore, what is reasonable length for each protocol element. Furthermore, what is
commonly understood to be a reasonable length for some protocol commonly understood to be a reasonable length for some protocol
elements has changed over the course of the past two decades of HTTP elements has changed over the course of the past two decades of HTTP
use and is expected to continue changing in the future. use and is expected to continue changing in the future.
At a minimum, a recipient MUST be able to parse and process protocol At a minimum, a recipient MUST be able to parse and process protocol
element lengths that are at least as long as the values that it element lengths that are at least as long as the values that it
generates for those same protocol elements in other messages. For generates for those same protocol elements in other messages. For
example, an origin server that publishes very long URI references to example, an origin server that publishes very long URI references to
its own resources needs to be able to parse and process those same its own resources needs to be able to parse and process those same
references when received as a target URI. references when received as a target URI.
Many received protocol elements are only parsed to the extent
necessary to identify and forward that element downstream. For
example, an intermediary might parse a received field into its field
name and field value components, but then forward the field without
further parsing inside the field value.
2.4. Error Handling 2.4. Error Handling
A recipient MUST interpret a received protocol element according to A recipient MUST interpret a received protocol element according to
the semantics defined for it by this specification, including the semantics defined for it by this specification, including
extensions to this specification, unless the recipient has determined extensions to this specification, unless the recipient has determined
(through experience or configuration) that the sender incorrectly (through experience or configuration) that the sender incorrectly
implements what is implied by those semantics. For example, an implements what is implied by those semantics. For example, an
origin server might disregard the contents of a received origin server might disregard the contents of a received
Accept-Encoding header field if inspection of the User-Agent header Accept-Encoding header field if inspection of the User-Agent header
field indicates a specific implementation version that is known to field indicates a specific implementation version that is known to
skipping to change at page 15, line 19 skipping to change at page 15, line 30
3. Terminology and Core Concepts 3. Terminology and Core Concepts
HTTP was created for the World Wide Web (WWW) architecture and has HTTP was created for the World Wide Web (WWW) architecture and has
evolved over time to support the scalability needs of a worldwide evolved over time to support the scalability needs of a worldwide
hypertext system. Much of that architecture is reflected in the hypertext system. Much of that architecture is reflected in the
terminology and syntax productions used to define HTTP. terminology and syntax productions used to define HTTP.
3.1. Resources 3.1. Resources
The target of an HTTP request is called a "_resource_". HTTP does The target of an HTTP request is called a _resource_. HTTP does not
not limit the nature of a resource; it merely defines an interface limit the nature of a resource; it merely defines an interface that
that might be used to interact with resources. Most resources are might be used to interact with resources. Most resources are
identified by a Uniform Resource Identifier (URI), as described in identified by a Uniform Resource Identifier (URI), as described in
Section 4. Section 4.
One design goal of HTTP is to separate resource identification from One design goal of HTTP is to separate resource identification from
request semantics, which is made possible by vesting the request request semantics, which is made possible by vesting the request
semantics in the request method (Section 9) and a few request- semantics in the request method (Section 9) and a few request-
modifying header fields. If there is a conflict between the method modifying header fields. If there is a conflict between the method
semantics and any semantic implied by the URI itself, as described in semantics and any semantic implied by the URI itself, as described in
Section 9.2.1, the method semantics take precedence. Section 9.2.1, the method semantics take precedence.
HTTP relies upon the Uniform Resource Identifier (URI) standard HTTP relies upon the Uniform Resource Identifier (URI) standard
[RFC3986] to indicate the target resource (Section 7.1) and [RFC3986] to indicate the target resource (Section 7.1) and
relationships between resources. relationships between resources.
3.2. Connections 3.2. Representations
A _representation_ is information that is intended to reflect a past,
current, or desired state of a given resource, in a format that can
be readily communicated via the protocol. A representation consists
of a set of representation metadata and a potentially unbounded
stream of representation data (Section 8).
HTTP allows "information hiding" behind its uniform interface by
defining communication with respect to a transferable representation
of the resource state, rather than transferring the resource itself.
This allows the resource identified by a URI to be anything,
including temporal functions like "the current weather in Laguna
Beach", while potentially providing information that represents that
resource at the time a message is generated [REST].
The uniform interface is similar to a window through which one can
observe and act upon a thing only through the communication of
messages to an independent actor on the other side. A shared
abstraction is needed to represent ("take the place of") the current
or desired state of that thing in our communications. When a
representation is hypertext, it can provide both a representation of
the resource state and processing instructions that help guide the
recipient's future interactions.
A target resource might be provided with, or be capable of
generating, multiple representations that are each intended to
reflect the resource's current state. An algorithm, usually based on
content negotiation (Section 12), would be used to select one of
those representations as being most applicable to a given request.
This _selected representation_ provides the data and metadata for
evaluating conditional requests (Section 13) and constructing the
content for 200 (OK), 206 (Partial Content), and 304 (Not Modified)
responses to GET (Section 9.3.1).
3.3. Connections, Clients and Servers
HTTP is a client/server protocol that operates over a reliable HTTP is a client/server protocol that operates over a reliable
transport- or session-layer "_connection_". transport- or session-layer _connection_.
An HTTP "_client_" is a program that establishes a connection to a 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 for the purpose of sending one or more HTTP requests. An HTTP
"_server_" is a program that accepts connections in order to service _server_ is a program that accepts connections in order to service
HTTP requests by sending HTTP responses. HTTP requests by sending HTTP responses.
The terms "client" and "server" refer only to the roles that these The terms "client" and "server" refer only to the roles that these
programs perform for a particular connection. The same program might programs perform for a particular connection. The same program might
act as a client on some connections and a server on others. act as a client on some connections and a server on others.
3.3. Messages 3.4. Messages
HTTP is a stateless request/response protocol for exchanging HTTP is a stateless request/response protocol for exchanging
"_messages_" across a connection. The terms "_sender_" and _messages_ across a connection. The terms _sender_ and _recipient_
"_recipient_" refer to any implementation that sends or receives a refer to any implementation that sends or receives a given message,
given message, respectively. respectively.
A client sends requests to a server in the form of a _request_ A client sends requests to a server in the form of a _request_
message with a method (Section 9) and request target (Section 7.1). message with a method (Section 9) and request target (Section 7.1).
The request might also contain header fields (Section 6.3) for The request might also contain header fields (Section 6.3) for
request modifiers, client information, and representation metadata, a request modifiers, client information, and representation metadata,
payload (Section 6.4) to be processed in accordance with the method, content (Section 6.4) intended for processing in accordance with the
and trailer fields (Section 6.5) for metadata collected while sending method, and trailer fields (Section 6.5) to communicate information
the payload. collected while sending the content.
A server responds to a client's request by sending one or more A server responds to a client's request by sending one or more
_response_ messages, each including a status code (Section 15). The _response_ messages, each including a status code (Section 15). The
response might also contain header fields for server information, response might also contain header fields for server information,
resource metadata, and representation metadata, payload data to be resource metadata, and representation metadata, content to be
interpreted in accordance with the status code, and trailer fields interpreted in accordance with the status code, and trailer fields to
for metadata collected while sending the payload. communicate information collected while sending the content.
3.4. User Agent 3.5. User Agents
The term "_user agent_" refers to any of the various client programs The term _user agent_ refers to any of the various client programs
that initiate a request. that initiate a request.
The most familiar form of user agent is the general-purpose Web The most familiar form of user agent is the general-purpose Web
browser, but that's only a small percentage of implementations. browser, but that's only a small percentage of implementations.
Other common user agents include spiders (web-traversing robots), Other common user agents include spiders (web-traversing robots),
command-line tools, billboard screens, household appliances, scales, command-line tools, billboard screens, household appliances, scales,
light bulbs, firmware update scripts, mobile apps, and communication light bulbs, firmware update scripts, mobile apps, and communication
devices in a multitude of shapes and sizes. devices in a multitude of shapes and sizes.
Being a user agent does not imply that there is a human user directly Being a user agent does not imply that there is a human user directly
skipping to change at page 17, line 10 skipping to change at page 18, line 10
suggestions to their user or provide adequate warning for security or suggestions to their user or provide adequate warning for security or
privacy concerns. In the few cases where this specification requires privacy concerns. In the few cases where this specification requires
reporting of errors to the user, it is acceptable for such reporting reporting of errors to the user, it is acceptable for such reporting
to only be observable in an error console or log file. Likewise, to only be observable in an error console or log file. Likewise,
requirements that an automated action be confirmed by the user before requirements that an automated action be confirmed by the user before
proceeding might be met via advance configuration choices, run-time proceeding might be met via advance configuration choices, run-time
options, or simple avoidance of the unsafe action; confirmation does options, or simple avoidance of the unsafe action; confirmation does
not imply any specific user interface or interruption of normal not imply any specific user interface or interruption of normal
processing if the user has already made that choice. processing if the user has already made that choice.
3.5. Origin Server 3.6. Origin Server
The term "_origin server_" refers to a program that can originate The term _origin server_ refers to a program that can originate
authoritative responses for a given target resource. authoritative responses for a given target resource.
The most familiar form of origin server are large public websites. The most familiar form of origin server are large public websites.
However, like user agents being equated with browsers, it is easy to However, like user agents being equated with browsers, it is easy to
be misled into thinking that all origin servers are alike. Common be misled into thinking that all origin servers are alike. Common
origin servers also include home automation units, configurable origin servers also include home automation units, configurable
networking components, office machines, autonomous robots, news networking components, office machines, autonomous robots, news
feeds, traffic cameras, real-time ad selectors, and video-on-demand feeds, traffic cameras, real-time ad selectors, and video-on-demand
platforms. platforms.
skipping to change at page 17, line 35 skipping to change at page 18, line 35
case, this might be accomplished via a single bidirectional case, this might be accomplished via a single bidirectional
connection (===) between the user agent (UA) and the origin server connection (===) between the user agent (UA) and the origin server
(O). (O).
request > request >
UA ======================================= O UA ======================================= O
< response < response
Figure 1 Figure 1
3.6. Intermediaries 3.7. Intermediaries
HTTP enables the use of intermediaries to satisfy requests through a HTTP enables the use of intermediaries to satisfy requests through a
chain of connections. There are three common forms of HTTP chain of connections. There are three common forms of HTTP
_intermediary_: proxy, gateway, and tunnel. In some cases, a single _intermediary_: proxy, gateway, and tunnel. In some cases, a single
intermediary might act as an origin server, proxy, gateway, or intermediary might act as an origin server, proxy, gateway, or
tunnel, switching behavior based on the nature of each request. tunnel, switching behavior based on the nature of each request.
> > > > > > > >
UA =========== A =========== B =========== C =========== O UA =========== A =========== B =========== C =========== O
< < < < < < < <
skipping to change at page 18, line 16 skipping to change at page 19, line 16
with the nearest, non-tunnel neighbor, only to the endpoints of the with the nearest, non-tunnel neighbor, only to the endpoints of the
chain, or to all connections along the chain. Although the diagram chain, or to all connections along the chain. Although the diagram
is linear, each participant might be engaged in multiple, is linear, each participant might be engaged in multiple,
simultaneous communications. For example, B might be receiving simultaneous communications. For example, B might be receiving
requests from many clients other than A, and/or forwarding requests requests from many clients other than A, and/or forwarding requests
to servers other than C, at the same time that it is handling A's to servers other than C, at the same time that it is handling A's
request. Likewise, later requests might be sent through a different request. Likewise, later requests might be sent through a different
path of connections, often based on dynamic configuration for load path of connections, often based on dynamic configuration for load
balancing. balancing.
The terms "_upstream_" and "_downstream_" are used to describe The terms _upstream_ and _downstream_ are used to describe
directional requirements in relation to the message flow: all directional requirements in relation to the message flow: all
messages flow from upstream to downstream. The terms "inbound" and messages flow from upstream to downstream. The terms "inbound" and
"outbound" are used to describe directional requirements in relation "outbound" are used to describe directional requirements in relation
to the request route: "_inbound_" means toward the origin server and to the request route: _inbound_ means toward the origin server and
"_outbound_" means toward the user agent. _outbound_ means toward the user agent.
A "_proxy_" is a message-forwarding agent that is chosen by the A _proxy_ is a message-forwarding agent that is chosen by the client,
client, usually via local configuration rules, to receive requests usually via local configuration rules, to receive requests for some
for some type(s) of absolute URI and attempt to satisfy those type(s) of absolute URI and attempt to satisfy those requests via
requests via translation through the HTTP interface. Some translation through the HTTP interface. Some translations are
translations are minimal, such as for proxy requests for "http" URIs, minimal, such as for proxy requests for "http" URIs, whereas other
whereas other requests might require translation to and from entirely requests might require translation to and from entirely different
different application-level protocols. Proxies are often used to application-level protocols. Proxies are often used to group an
group an organization's HTTP requests through a common intermediary organization's HTTP requests through a common intermediary for the
for the sake of security, annotation services, or shared caching. sake of security, annotation services, or shared caching. Some
Some proxies are designed to apply transformations to selected proxies are designed to apply transformations to selected messages or
messages or payloads while they are being forwarded, as described in content while they are being forwarded, as described in Section 7.7.
Section 7.7.
A "_gateway_" (a.k.a. "_reverse proxy_") is an intermediary that acts A _gateway_ (a.k.a. _reverse proxy_) is an intermediary that acts as
as an origin server for the outbound connection but translates an origin server for the outbound connection but translates received
received requests and forwards them inbound to another server or requests and forwards them inbound to another server or servers.
servers. Gateways are often used to encapsulate legacy or untrusted Gateways are often used to encapsulate legacy or untrusted
information services, to improve server performance through information services, to improve server performance through
"_accelerator_" caching, and to enable partitioning or load balancing _accelerator_ caching, and to enable partitioning or load balancing
of HTTP services across multiple machines. of HTTP services across multiple machines.
All HTTP requirements applicable to an origin server also apply to All HTTP requirements applicable to an origin server also apply to
the outbound communication of a gateway. A gateway communicates with the outbound communication of a gateway. A gateway communicates with
inbound servers using any protocol that it desires, including private inbound servers using any protocol that it desires, including private
extensions to HTTP that are outside the scope of this specification. extensions to HTTP that are outside the scope of this specification.
However, an HTTP-to-HTTP gateway that wishes to interoperate with However, an HTTP-to-HTTP gateway that wishes to interoperate with
third-party HTTP servers ought to conform to user agent requirements third-party HTTP servers ought to conform to user agent requirements
on the gateway's inbound connection. on the gateway's inbound connection.
A "_tunnel_" acts as a blind relay between two connections without A _tunnel_ acts as a blind relay between two connections without
changing the messages. Once active, a tunnel is not considered a changing the messages. Once active, a tunnel is not considered a
party to the HTTP communication, though the tunnel might have been party to the HTTP communication, though the tunnel might have been
initiated by an HTTP request. A tunnel ceases to exist when both initiated by an HTTP request. A tunnel ceases to exist when both
ends of the relayed connection are closed. Tunnels are used to ends of the relayed connection are closed. Tunnels are used to
extend a virtual connection through an intermediary, such as when extend a virtual connection through an intermediary, such as when
Transport Layer Security (TLS, [RFC8446]) is used to establish Transport Layer Security (TLS, [RFC8446]) is used to establish
confidential communication through a shared firewall proxy. confidential communication through a shared firewall proxy.
The above categories for intermediary only consider those acting as The above categories for intermediary only consider those acting as
participants in the HTTP communication. There are also participants in the HTTP communication. There are also
intermediaries that can act on lower layers of the network protocol intermediaries that can act on lower layers of the network protocol
stack, filtering or redirecting HTTP traffic without the knowledge or stack, filtering or redirecting HTTP traffic without the knowledge or
permission of message senders. Network intermediaries are permission of message senders. Network intermediaries are
indistinguishable (at a protocol level) from an on-path attacker, indistinguishable (at a protocol level) from an on-path attacker,
often introducing security flaws or interoperability problems due to often introducing security flaws or interoperability problems due to
mistakenly violating HTTP semantics. mistakenly violating HTTP semantics.
For example, an "_interception proxy_" [RFC3040] (also commonly known For example, an _interception proxy_ [RFC3040] (also commonly known
as a "_transparent proxy_" [RFC1919] or "_captive portal_") differs as a _transparent proxy_ [RFC1919]) differs from an HTTP proxy
from an HTTP proxy because it is not chosen by the client. Instead, because it is not chosen by the client. Instead, an interception
an interception proxy filters or redirects outgoing TCP port 80 proxy filters or redirects outgoing TCP port 80 packets (and
packets (and occasionally other common port traffic). Interception occasionally other common port traffic). Interception proxies are
proxies are commonly found on public network access points, as a commonly found on public network access points, as a means of
means of enforcing account subscription prior to allowing use of non- enforcing account subscription prior to allowing use of non-local
local Internet services, and within corporate firewalls to enforce Internet services, and within corporate firewalls to enforce network
network usage policies. usage policies.
HTTP is defined as a stateless protocol, meaning that each request HTTP is defined as a stateless protocol, meaning that each request
message can be understood in isolation. Many implementations depend message can be understood in isolation. Many implementations depend
on HTTP's stateless design in order to reuse proxied connections or on HTTP's stateless design in order to reuse proxied connections or
dynamically load balance requests across multiple servers. Hence, a dynamically load balance requests across multiple servers. Hence, a
server MUST NOT assume that two requests on the same connection are server MUST NOT assume that two requests on the same connection are
from the same user agent unless the connection is secured and from the same user agent unless the connection is secured and
specific to that agent. Some non-standard HTTP extensions (e.g., specific to that agent. Some non-standard HTTP extensions (e.g.,
[RFC4559]) have been known to violate this requirement, resulting in [RFC4559]) have been known to violate this requirement, resulting in
security and interoperability problems. security and interoperability problems.
3.7. Caches 3.8. Caches
A "_cache_" is a local store of previous response messages and the A _cache_ is a local store of previous response messages and the
subsystem that controls its message storage, retrieval, and deletion. subsystem that controls its message storage, retrieval, and deletion.
A cache stores cacheable responses in order to reduce the response A cache stores cacheable responses in order to reduce the response
time and network bandwidth consumption on future, equivalent time and network bandwidth consumption on future, equivalent
requests. Any client or server MAY employ a cache, though a cache 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. cannot be used while acting as a tunnel.
The effect of a cache is that the request/response chain is shortened 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 if one of the participants along the chain has a cached response
applicable to that request. The following illustrates the resulting applicable to that request. The following illustrates the resulting
chain if B has a cached copy of an earlier response from O (via C) 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. for a request that has not been cached by UA or A.
> > > >
UA =========== A =========== B - - - - - - C - - - - - - O UA =========== A =========== B - - - - - - C - - - - - - O
< < < <
Figure 3 Figure 3
A response is "_cacheable_" if a cache is allowed to store a copy of A response is _cacheable_ if a cache is allowed to store a copy of
the response message for use in answering subsequent requests. Even the response message for use in answering subsequent requests. Even
when a response is cacheable, there might be additional constraints when a response is cacheable, there might be additional constraints
placed by the client or by the origin server on when that cached placed by the client or by the origin server on when that cached
response can be used for a particular request. HTTP requirements for response can be used for a particular request. HTTP requirements for
cache behavior and cacheable responses are defined in Section 2 of cache behavior and cacheable responses are defined in Section 2 of
[Caching]. [Caching].
There is a wide variety of architectures and configurations of caches There is a wide variety of architectures and configurations of caches
deployed across the World Wide Web and inside large organizations. deployed across the World Wide Web and inside large organizations.
These include national hierarchies of proxy caches to save These include national hierarchies of proxy caches to save bandwidth
transoceanic bandwidth, collaborative systems that broadcast or and reduce latency, Content Delivery Networks that use gateway
multicast cache entries, archives of pre-fetched cache entries for caching to optimise regional and global distribution of popular
use in off-line or high-latency environments, and so on. sites, 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.
3.8. Example Message Exchange 3.9. Example Message Exchange
The following example illustrates a typical HTTP/1.1 message exchange The following example illustrates a typical HTTP/1.1 message exchange
for a GET request (Section 9.3.1) on the URI "http://www.example.com/ for a GET request (Section 9.3.1) on the URI "http://www.example.com/
hello.txt": hello.txt":
Client request: Client request:
GET /hello.txt HTTP/1.1 GET /hello.txt HTTP/1.1
User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
Host: www.example.com Host: www.example.com
skipping to change at page 21, line 15 skipping to change at page 22, line 15
HTTP/1.1 200 OK HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache Server: Apache
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00" ETag: "34aa387-d-1568eb00"
Accept-Ranges: bytes Accept-Ranges: bytes
Content-Length: 51 Content-Length: 51
Vary: Accept-Encoding Vary: Accept-Encoding
Content-Type: text/plain Content-Type: text/plain
Hello World! My payload includes a trailing CRLF. Hello World! My content includes a trailing CRLF.
4. Identifiers in HTTP 4. Identifiers in HTTP
Uniform Resource Identifiers (URIs) [RFC3986] are used throughout Uniform Resource Identifiers (URIs) [RFC3986] are used throughout
HTTP as the means for identifying resources (Section 3.1). HTTP as the means for identifying resources (Section 3.1).
4.1. URI References 4.1. URI References
URI references are used to target requests, indicate redirects, and URI references are used to target requests, indicate redirects, and
define relationships. define relationships.
skipping to change at page 23, line 26 skipping to change at page 24, line 26
The hierarchical path component and optional query component identify The hierarchical path component and optional query component identify
the target resource within that origin server's name space. the target resource within that origin server's name space.
4.2.2. https URI Scheme 4.2.2. https URI Scheme
The "https" URI scheme is hereby defined for minting identifiers The "https" URI scheme is hereby defined for minting identifiers
within the hierarchical namespace governed by a potential origin within the hierarchical namespace governed by a potential origin
server listening for TCP connections on a given port and capable of server listening for TCP connections on a given port and capable of
establishing a TLS ([RFC8446]) connection that has been secured for establishing a TLS ([RFC8446]) connection that has been secured for
HTTP communication. In this context, "_secured_" specifically means HTTP communication. In this context, _secured_ specifically means
that the server has been authenticated as acting on behalf of the that the server has been authenticated as acting on behalf of the
identified authority and all HTTP communication with that server has identified authority and all HTTP communication with that server has
been protected for confidentiality and integrity through the use of been protected for confidentiality and integrity through the use of
strong encryption. strong encryption.
https-URI = "https" "://" authority path-abempty [ "?" query ] https-URI = "https" "://" authority path-abempty [ "?" query ]
The origin server for an "https" URI is identified by the authority The origin server for an "https" URI is identified by the authority
component, which includes a host identifier and optional port number component, which includes a host identifier and optional port number
([RFC3986], Section 3.2.2). If the port subcomponent is empty or not ([RFC3986], Section 3.2.2). If the port subcomponent is empty or not
skipping to change at page 25, line 43 skipping to change at page 26, line 43
Section 4.3.1 defines the concept of an origin as an aid to such Section 4.3.1 defines the concept of an origin as an aid to such
uses, and the subsequent subsections explain how to establish a uses, and the subsequent subsections explain how to establish a
peer's association with an authority to represent an origin. peer's association with an authority to represent an origin.
See Section 17.1 for security considerations related to establishing See Section 17.1 for security considerations related to establishing
authority. authority.
4.3.1. URI Origin 4.3.1. URI Origin
The "_origin_" for a given URI is the triple of scheme, host, and The _origin_ for a given URI is the triple of scheme, host, and port
port after normalizing the scheme and host to lowercase and after normalizing the scheme and host to lowercase and normalizing
normalizing the port to remove any leading zeros. If port is elided the port to remove any leading zeros. If port is elided from the
from the URI, the default port for that scheme is used. For example, URI, the default port for that scheme is used. For example, the URI
the URI
https://Example.Com/happy.js https://Example.Com/happy.js
would have the origin would have the origin
{ "https", "example.com", "443" } { "https", "example.com", "443" }
which can also be described as the normalized URI prefix with port which can also be described as the normalized URI prefix with port
always present: always present:
https://example.com:443 https://example.com:443
Each origin defines its own namespace and controls how identifiers Each origin defines its own namespace and controls how identifiers
within that namespace are mapped to resources. In turn, how the within that namespace are mapped to resources. In turn, how the
origin responds to valid requests, consistently over time, determines origin responds to valid requests, consistently over time, determines
skipping to change at page 29, line 20 skipping to change at page 30, line 20
agent MUST either notify the user (user agents MAY give the user an agent MUST either notify the user (user agents MAY give the user an
option to continue with the connection in any case) or terminate the option to continue with the connection in any case) or terminate the
connection with a bad certificate error. Automated clients MUST log connection with a bad certificate error. Automated clients MUST log
the error to an appropriate audit log (if available) and SHOULD the error to an appropriate audit log (if available) and SHOULD
terminate the connection (with a bad certificate error). Automated terminate the connection (with a bad certificate error). Automated
clients MAY provide a configuration setting that disables this check, clients MAY provide a configuration setting that disables this check,
but MUST provide a setting which enables it. but MUST provide a setting which enables it.
5. Fields 5. Fields
HTTP uses "_fields_" to provide data in the form of extensible key/ HTTP uses _fields_ to provide data in the form of extensible key/
value pairs with a registered key namespace. Fields are sent and value pairs with a registered key namespace. Fields are sent and
received within the header and trailer sections of messages received within the header and trailer sections of messages
(Section 6). (Section 6).
5.1. Field Names 5.1. Field Names
A field name labels the corresponding field value as having the A field name labels the corresponding field value as having the
semantics defined by that name. For example, the Date header field semantics defined by that name. For example, the Date header field
is defined in Section 10.2.2 as containing the origination timestamp is defined in Section 10.2.2 as containing the origination timestamp
for the message in which it appears. for the message in which it appears.
skipping to change at page 30, line 11 skipping to change at page 31, line 11
A proxy MUST forward unrecognized header fields unless the field name A proxy MUST forward unrecognized header fields unless the field name
is listed in the Connection header field (Section 7.6.1) or the proxy is listed in the Connection header field (Section 7.6.1) or the proxy
is specifically configured to block, or otherwise transform, such is specifically configured to block, or otherwise transform, such
fields. Other recipients SHOULD ignore unrecognized header and fields. Other recipients SHOULD ignore unrecognized header and
trailer fields. Adhering to these requirements allows HTTP's trailer fields. Adhering to these requirements allows HTTP's
functionality to be extended without updating or removing deployed functionality to be extended without updating or removing deployed
intermediaries. intermediaries.
5.2. Field Lines and Combined Field Value 5.2. Field Lines and Combined Field Value
Field sections are composed of any number of "_field lines_", each Field sections are composed of any number of _field lines_, each with
with a "_field name_" (see Section 5.1) identifying the field, and a a _field name_ (see Section 5.1) identifying the field, and a _field
"_field line value_" that conveys data for that instance of the line value_ that conveys data for that instance of the field.
field.
When a field name is only present once in a section, the combined When a field name is only present once in a section, the combined
"_field value_" for that field consists of the corresponding field _field value_ for that field consists of the corresponding field line
line value. When a field name is repeated within a section, its value. When a field name is repeated within a section, its combined
combined field value consists of the list of corresponding field line field value consists of the list of corresponding field line values
values within that section, concatenated in order, with each non- within that section, concatenated in order, with each non-empty field
empty field line value separated by a comma. line value separated by a comma.
For example, this section: For example, this section:
Example-Field: Foo, Bar Example-Field: Foo, Bar
Example-Field: Baz Example-Field: Baz
contains two field lines, both with the field name "Example-Field". contains two field lines, both with the field name "Example-Field".
The first field line has a field line value of "Foo, Bar", while the The first field line has a field line value of "Foo, Bar", while the
second field line value is "Baz". The field value for "Example- second field line value is "Baz". The field value for "Example-
Field" is a list with three members: "Foo", "Bar", and "Baz". Field" is a list with three members: "Foo", "Bar", and "Baz".
skipping to change at page 33, line 27 skipping to change at page 34, line 27
these: these:
Example-URI-Field: "http://example.com/a.html,foo", Example-URI-Field: "http://example.com/a.html,foo",
"http://without-a-comma.example.com/" "http://without-a-comma.example.com/"
Example-Date-Field: "Sat, 04 May 1996", "Wed, 14 Sep 2005" Example-Date-Field: "Sat, 04 May 1996", "Wed, 14 Sep 2005"
Note that double-quote delimiters almost always are used with the Note that double-quote delimiters almost always are used with the
quoted-string production; using a different syntax inside double- quoted-string production; using a different syntax inside double-
quotes will likely cause unnecessary confusion. quotes will likely cause unnecessary confusion.
Many fields (such as Content-Type, defined in Section 8.4) use a Many fields (such as Content-Type, defined in Section 8.3) use a
common syntax for parameters that allows both unquoted (token) and common syntax for parameters that allows both unquoted (token) and
quoted (quoted-string) syntax for a parameter value (Section 5.6.6). quoted (quoted-string) syntax for a parameter value (Section 5.6.6).
Use of common syntax allows recipients to reuse existing parser Use of common syntax allows recipients to reuse existing parser
components. When allowing both forms, the meaning of a parameter components. When allowing both forms, the meaning of a parameter
value ought to be the same whether it was received as a token or a value ought to be the same whether it was received as a token or a
quoted string. quoted string.
Historically, HTTP field values could be extended over multiple lines Historically, HTTP field values could be extended over multiple lines
by preceding each extra line with at least one space or horizontal by preceding each extra line with at least one space or horizontal
tab (obs-fold). This document assumes that any such obsolete line tab (obs-fold). This document assumes that any such obsolete line
skipping to change at page 37, line 29 skipping to change at page 38, line 29
preceding semicolon. preceding semicolon.
parameters = *( OWS ";" OWS [ parameter ] ) parameters = *( OWS ";" OWS [ parameter ] )
parameter = parameter-name "=" parameter-value parameter = parameter-name "=" parameter-value
parameter-name = token parameter-name = token
parameter-value = ( token / quoted-string ) parameter-value = ( token / quoted-string )
Parameter names are case-insensitive. Parameter values might or Parameter names are case-insensitive. Parameter values might or
might not be case-sensitive, depending on the semantics of the might not be case-sensitive, depending on the semantics of the
parameter name. Examples of parameters and some equivalent forms can parameter name. Examples of parameters and some equivalent forms can
be seen in media types (Section 8.4.1) and the Accept header field be seen in media types (Section 8.3.1) and the Accept header field
(Section 12.5.1). (Section 12.5.1).
A parameter value that matches the token production can be A parameter value that matches the token production can be
transmitted either as a token or within a quoted-string. The quoted transmitted either as a token or within a quoted-string. The quoted
and unquoted values are equivalent. and unquoted values are equivalent.
| *Note:* Parameters do not allow whitespace (not even "bad" | *Note:* Parameters do not allow whitespace (not even "bad"
| whitespace) around the "=" character. | whitespace) around the "=" character.
5.6.7. Date/Time Formats 5.6.7. Date/Time Formats
skipping to change at page 40, line 8 skipping to change at page 41, line 8
messages based on a generalization of those message characteristics, messages based on a generalization of those message characteristics,
common structure, and capacity for conveying semantics. This common structure, and capacity for conveying semantics. This
abstraction is used to define requirements on senders and recipients abstraction is used to define requirements on senders and recipients
that are independent of the HTTP version, such that a message in one that are independent of the HTTP version, such that a message in one
version can be relayed through other versions without changing its version can be relayed through other versions without changing its
meaning. meaning.
A _message_ consists of control data to describe and route the A _message_ consists of control data to describe and route the
message, a headers lookup table of key/value pairs for extending that message, a headers lookup table of key/value pairs for extending that
control data and conveying additional information about the sender, control data and conveying additional information about the sender,
message, payload, or context, a potentially unbounded stream of message, content, or context, a potentially unbounded stream of
payload data, and a trailers lookup table of key/value pairs for content, and a trailers lookup table of key/value pairs for
communicating information obtained while sending the payload. communicating information obtained while sending the content.
Framing and control data is sent first, followed by a header section Framing and control data is sent first, followed by a header section
containing fields for the headers table. When a message includes a containing fields for the headers table. When a message includes
payload, the payload data is sent after the header section and content, the content is sent after the header section and potentially
potentially interleaved with zero or more trailer sections containing interleaved with zero or more trailer sections containing fields for
fields for the trailers table. the trailers table.
Messages are expected to be processed as a stream, wherein the Messages are expected to be processed as a stream, wherein the
purpose of that stream and its continued processing is revealed while purpose of that stream and its continued processing is revealed while
being read. Hence, control data describes what the recipient needs being read. Hence, control data describes what the recipient needs
to know immediately, header fields describe what needs to be known to know immediately, header fields describe what needs to be known
before receiving a payload, the payload (when present) presumably before receiving content, the content (when present) presumably
contains what the recipient wants or needs to fulfill the message contains what the recipient wants or needs to fulfill the message
semantics, and trailer fields provide additional metadata that can be semantics, and trailer fields provide additional metadata that can be
dropped (safely ignored) when not desired. dropped (safely ignored) when not desired.
Messages are intended to be _self-descriptive_: everything a Messages are intended to be _self-descriptive_: everything a
recipient needs to know about the message can be determined by recipient needs to know about the message can be determined by
looking at the message itself, after decoding or reconstituting parts looking at the message itself, after decoding or reconstituting parts
that have been compressed or elided in transit, without requiring an that have been compressed or elided in transit, without requiring an
understanding of the sender's current application state (established understanding of the sender's current application state (established
via prior messages). via prior messages).
Note that this message abstraction is a generalization across many Note that this message abstraction is a generalization across many
versions of HTTP, including features that might not be found in some versions of HTTP, including features that might not be found in some
versions. For example, trailers were introduced within the HTTP/1.1 versions. For example, trailers were introduced within the HTTP/1.1
chunked transfer coding as a single trailer section at the end of the chunked transfer coding as a single trailer section after the
payload data. An equivalent feature is present in HTTP/2 and HTTP/3 content. An equivalent feature is present in HTTP/2 and HTTP/3
within the header block that terminates each stream. However, within the header block that terminates each stream. However,
multiple trailer sections interleaved with payload data have only multiple trailer sections interleaved with content have only been
been deployed as frame extensions. deployed as frame extensions.
6.1. Framing and Completeness 6.1. Framing and Completeness
Message framing indicates how each message begins and ends, such that Message framing indicates how each message begins and ends, such that
each message can be distinguished from other messages or noise on the each message can be distinguished from other messages or noise on the
same connection. Each major version of HTTP defines its own framing same connection. Each major version of HTTP defines its own framing
mechanism. mechanism.
HTTP/0.9 and early deployments of HTTP/1.0 used closure of the HTTP/0.9 and early deployments of HTTP/1.0 used closure of the
underlying connection to end a response. For backwards underlying connection to end a response. For backwards
skipping to change at page 42, line 24 skipping to change at page 43, line 24
recipient implements, the recipient SHOULD process the message as if recipient implements, the recipient SHOULD process the message as if
it were in the highest minor version within that major version to it were in the highest minor version within that major version to
which the recipient is conformant. A recipient can assume that a which the recipient is conformant. A recipient can assume that a
message with a higher minor version, when sent to a recipient that message with a higher minor version, when sent to a recipient that
has not yet indicated support for that higher version, is has not yet indicated support for that higher version, is
sufficiently backwards-compatible to be safely processed by any sufficiently backwards-compatible to be safely processed by any
implementation of the same major version. implementation of the same major version.
6.3. Header Fields 6.3. Header Fields
Fields (Section 5) that are sent/received before the payload are Fields (Section 5) that are sent/received before the content are
referred to as "header fields" (or just "headers", colloquially). referred to as "header fields" (or just "headers", colloquially).
The "_header section_" of a message consists of a sequence of of The _header section_ of a message consists of a sequence of of header
header field lines. Each header field might modify or extend message field lines. Each header field might modify or extend message
semantics, describe the sender, define the payload, or provide semantics, describe the sender, define the content, or provide
additional context. additional context.
| *Note:* We refer to named fields specifically as a "header | *Note:* We refer to named fields specifically as a "header
| field" when they are only allowed to be sent in the header | field" when they are only allowed to be sent in the header
| section. | section.
6.4. Payload 6.4. Content
HTTP messages often transfer a complete or partial representation as HTTP messages often transfer a complete or partial representation as
the message "_payload_", including both representation metadata the message _content_: a stream of octets sent after the header
transferred as fields and representation data transferred as _payload section, as delineated by the message framing.
data_: a stream of octets sent after the header section, as
delineated by the message framing.
This abstract definition of a payload reflects the data after it has This abstract definition of content reflects the data after it has
been extracted from the message framing. For example, an HTTP/1.1 been extracted from the message framing. For example, an HTTP/1.1
message body (Section 6 of [Messaging]) might consist of a stream of message body (Section 6 of [Messaging]) might consist of a stream of
data encoded with the chunked transfer coding-a sequence of data data encoded with the chunked transfer coding - a sequence of data
chunks, one zero-length chunk, and a trailer section-whereas the chunks, one zero-length chunk, and a trailer section - whereas the
payload data of that same message includes only the data stream after content of that same message includes only the data stream after the
the transfer coding has been decoded; it does not include the chunk transfer coding has been decoded; it does not include the chunk
lengths, chunked framing syntax, nor the trailer fields lengths, chunked framing syntax, nor the trailer fields
(Section 6.5). (Section 6.5).
6.4.1. Payload Semantics 6.4.1. Content Semantics
The purpose of a payload in a request is defined by the method The purpose of content in a request is defined by the method
semantics (Section 9). semantics (Section 9).
For example, a representation in the payload of a PUT request For example, a representation in the content of a PUT request
(Section 9.3.4) represents the desired state of the target resource (Section 9.3.4) represents the desired state of the target resource
after the request is successfully applied, whereas a representation after the request is successfully applied, whereas a representation
in the payload of a POST request (Section 9.3.3) represents in the content of a POST request (Section 9.3.3) represents
information to be processed by the target resource. information to be processed by the target resource.
In a response, the payload's purpose is defined by both the request In a response, the content's purpose is defined by both the request
method and the response status code (Section 15). For example, the method and the response status code (Section 15). For example, the
payload of a 200 (OK) response to GET (Section 9.3.1) represents the content of a 200 (OK) response to GET (Section 9.3.1) represents the
current state of the target resource, as observed at the time of the current state of the target resource, as observed at the time of the
message origination date (Section 10.2.2), whereas the payload of the message origination date (Section 10.2.2), whereas the content of the
same status code in a response to POST might represent either the same status code in a response to POST might represent either the
processing result or the new state of the target resource after processing result or the new state of the target resource after
applying the processing. applying the processing.
The payload of a 206 (Partial Content) response to GET contains The content of a 206 (Partial Content) response to GET contains
either a single part of the selected representation or a multipart either a single part of the selected representation or a multipart
message body containing multiple parts of that representation, as message body containing multiple parts of that representation, as
described in Section 15.3.7. described in Section 15.3.7.
Response messages with an error status code usually contain a payload Response messages with an error status code usually contain content
that represents the error condition, such that the payload data that represents the error condition, such that the content describes
describes the error state and what steps are suggested for resolving the error state and what steps are suggested for resolving it.
it.
Responses to the HEAD request method (Section 9.3.2) never include a Responses to the HEAD request method (Section 9.3.2) never include
payload because the associated response header fields indicate only content; the associated response header fields indicate only what
what their values would have been if the request method had been GET their values would have been if the request method had been GET
(Section 9.3.1). (Section 9.3.1).
2xx (Successful) responses to a CONNECT request method 2xx (Successful) responses to a CONNECT request method
(Section 9.3.6) switch the connection to tunnel mode instead of (Section 9.3.6) switch the connection to tunnel mode instead of
having a payload. having content.
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 payload. responses do not include content.
All other responses do include a payload, although that payload data All other responses do include content, although that content might
might be of zero length. be of zero length.
6.4.2. Identifying Payloads 6.4.2. Identifying Content
When a complete or partial representation is transferred in a message When a complete or partial representation is transferred as message
payload, it is often desirable for the sender to supply, or the content, it is often desirable for the sender to supply, or the
recipient to determine, an identifier for a resource corresponding to recipient to determine, an identifier for a resource corresponding to
that representation. that representation.
For a request message: For a request message:
o If the request has a Content-Location header field, then the o If the request has a Content-Location header field, then the
sender asserts that the payload is a representation of the sender asserts that the content is a representation of the
resource identified by the Content-Location field value. However, resource identified by the Content-Location field value. However,
such an assertion cannot be trusted unless it can be verified by such an assertion cannot be trusted unless it can be verified by
other means (not defined by this specification). The information other means (not defined by this specification). The information
might still be useful for revision history links. might still be useful for revision history links.
o Otherwise, the payload is unidentified. o Otherwise, the content is unidentified.
For a response message, the following rules are applied in order For a response message, the following rules are applied in order
until a match is found: until a match is found:
1. If the request method is GET or HEAD and the response status code 1. If the request method is HEAD or the response status code is 204
is 200 (OK), 204 (No Content), 206 (Partial Content), or 304 (Not (No Content) or 304 (Not Modified), there is no content in the
Modified), the payload is a representation of the resource response.
identified by the target URI (Section 7.1).
2. If the request method is GET or HEAD and the response status code 2. If the request method is GET and the response status code is 200
is 203 (Non-Authoritative Information), the payload is a (OK), the content is a representation of the resource identified
potentially modified or enhanced representation of the target by the target URI (Section 7.1).
resource as provided by an intermediary.
3. If the response has a Content-Location header field and its field 3. If the request method is GET and the response status code is 203
(Non-Authoritative Information), the content is a potentially
modified or enhanced representation of the target resource as
provided by an intermediary.
4. If the request method is GET and the response status code is 206
(Partial Content), the content is one or more parts of a
representation of the resource identified by the target URI
(Section 7.1).
5. If the response has a Content-Location header field and its field
value is a reference to the same URI as the target URI, the value is a reference to the same URI as the target URI, the
payload is a representation of the target resource. content is a representation of the target resource.
4. If the response has a Content-Location header field and its field 6. If the response has a Content-Location header field and its field
value is a reference to a URI different from the target URI, then value is a reference to a URI different from the target URI, then
the sender asserts that the payload is a representation of the the sender asserts that the content is a representation of the
resource identified by the Content-Location field value. resource identified by the Content-Location field value.
However, such an assertion cannot be trusted unless it can be However, such an assertion cannot be trusted unless it can be
verified by other means (not defined by this specification). verified by other means (not defined by this specification).
5. Otherwise, the payload is unidentified. 7. Otherwise, the content is unidentified.
6.5. Trailer Fields 6.5. Trailer Fields
Fields (Section 5) that are sent/received after the header section Fields (Section 5) that are sent/received after the header section
has ended (usually after the payload data begins to stream) are has ended (usually after the content begins to stream) are referred
referred to as "trailer fields" (or just "trailers", colloquially) to as "trailer fields" (or just "trailers", colloquially) and located
and located within a "_trailer section_". Trailer fields can be within a _trailer section_. Trailer fields can be useful for
useful for supplying message integrity checks, digital signatures, supplying message integrity checks, digital signatures, delivery
delivery metrics, or post-processing status information. metrics, or post-processing status information.
Trailer fields ought to be processed and stored separately from the Trailer fields ought to be processed and stored separately from the
fields in the header section to avoid contradicting message semantics fields in the header section to avoid contradicting message semantics
known at the time the header section was complete. The presence or known at the time the header section was complete. The presence or
absence of certain header fields might impact choices made for the absence of certain header fields might impact choices made for the
routing or processing of the message as a whole before the trailers routing or processing of the message as a whole before the trailers
are received; those choices cannot be unmade by the later discovery are received; those choices cannot be unmade by the later discovery
of trailer fields. of trailer fields.
6.5.1. Limitations on use of Trailers 6.5.1. Limitations on use of Trailers
Trailer sections are only possible when supported by the version of Trailer sections are only possible when supported by the version of
HTTP in use and enabled by an explicit framing mechanism. For HTTP in use and enabled by an explicit framing mechanism. For
example, the chunked coding in HTTP/1.1 allows a trailer section to example, the chunked coding in HTTP/1.1 allows a trailer section to
be sent after the payload data (Section 7.1.2 of [Messaging]). be sent after the content (Section 7.1.2 of [Messaging]).
Many fields cannot be processed outside the header section because Many fields cannot be processed outside the header section because
their evaluation is necessary prior to receiving the payload data, their evaluation is necessary prior to receiving the content, such as
such as those that describe message framing, routing, authentication, those that describe message framing, routing, authentication, request
request modifiers, response controls, or payload data format. A modifiers, response controls, or content format. A sender MUST NOT
sender MUST NOT generate a trailer field unless the sender knows the generate a trailer field unless the sender knows the corresponding
corresponding header field name's definition permits the field to be header field name's definition permits the field to be sent in
sent in trailers. trailers.
Trailer fields can be difficult to process by intermediaries that Trailer fields can be difficult to process by intermediaries that
forward messages from one protocol version to another. If the entire forward messages from one protocol version to another. If the entire
message can be buffered in transit, some intermediaries could merge message can be buffered in transit, some intermediaries could merge
trailer fields into the header section (as appropriate) before it is trailer fields into the header section (as appropriate) before it is
forwarded. However, in most cases, the trailers are simply forwarded. However, in most cases, the trailers are simply
discarded. A recipient MUST NOT merge a trailer field into a header discarded. A recipient MUST NOT merge a trailer field into a header
section unless the recipient understands the corresponding header section unless the recipient understands the corresponding header
field definition and that definition explicitly permits and defines field definition and that definition explicitly permits and defines
how trailer field values can be safely merged. how trailer field values can be safely merged.
skipping to change at page 46, line 35 skipping to change at page 47, line 52
received, a recipient that is looking for trailer fields will parse received, a recipient that is looking for trailer fields will parse
the received section into fields, invoke any associated processing the received section into fields, invoke any associated processing
for those fields at that point in the message processing, and then for those fields at that point in the message processing, and then
append those fields to the set of trailer fields received for the append those fields to the set of trailer fields received for the
overall message. overall message.
This behavior allows for iterative processing of trailer fields that This behavior allows for iterative processing of trailer fields that
contain incremental signatures or mid-stream status information, and contain incremental signatures or mid-stream status information, and
fields that might refer to each other's values within the same fields that might refer to each other's values within the same
section. However, there is no guarantee that trailer sections won't section. However, there is no guarantee that trailer sections won't
shift in relation to the payload data stream, or won't be recombined shift in relation to the content stream, or won't be recombined (or
(or dropped) in transit. Trailer fields that refer to data outside dropped) in transit. Trailer fields that refer to data outside the
the present trailer section need to use self-descriptive references present trailer section need to use self-descriptive references
(i.e., refer to the data by name, ordinal position, or an octet (i.e., refer to the data by name, ordinal position, or an octet
range) rather than assume it is the data most recently received. range) rather than assume it is the data most recently received.
Likewise, at the end of a message, a recipient MAY treat the entire Likewise, at the end of a message, a recipient MAY treat the entire
set of received trailer fields as one data structure to be considered set of received trailer fields as one data structure to be considered
as the message concludes. Additional processing expectations, if as the message concludes. Additional processing expectations, if
any, can be defined within the field specification for a field any, can be defined within the field specification for a field
intended for use in trailers. intended for use in trailers.
7. Routing HTTP Messages 7. Routing HTTP Messages
skipping to change at page 47, line 22 skipping to change at page 48, line 32
7.1. Determining the Target Resource 7.1. Determining the Target Resource
Although HTTP is used in a wide variety of applications, most clients Although HTTP is used in a wide variety of applications, most clients
rely on the same resource identification mechanism and configuration rely on the same resource identification mechanism and configuration
techniques as general-purpose Web browsers. Even when communication techniques as general-purpose Web browsers. Even when communication
options are hard-coded in a client's configuration, we can think of options are hard-coded in a client's configuration, we can think of
their combined effect as a URI reference (Section 4.1). their combined effect as a URI reference (Section 4.1).
A URI reference is resolved to its absolute form in order to obtain A URI reference is resolved to its absolute form in order to obtain
the "_target URI_". The target URI excludes the reference's fragment the _target URI_. The target URI excludes the reference's fragment
component, if any, since fragment identifiers are reserved for component, if any, since fragment identifiers are reserved for
client-side processing ([RFC3986], Section 3.5). client-side processing ([RFC3986], Section 3.5).
To perform an action on a "_target resource_", the client sends a To perform an action on a _target resource_, the client sends a
request message containing enough components of its parsed target URI request message containing enough components of its parsed target URI
to enable recipients to identify that same resource. For historical to enable recipients to identify that same resource. For historical
reasons, the parsed target URI components, collectively referred to reasons, the parsed target URI components, collectively referred to
as the "_request target_", are sent within the message control data as the _request target_, are sent within the message control data and
and the Host header field (Section 7.2). the Host header field (Section 7.2).
There are two unusual cases for which the request target components There are two unusual cases for which the request target components
are in a method-specific form: are in a method-specific form:
o For CONNECT (Section 9.3.6), the request target is the host name o For CONNECT (Section 9.3.6), the request target is the host name
and port number of the tunnel destination, separated by a colon. and port number of the tunnel destination, separated by a colon.
o For OPTIONS (Section 9.3.7), the request target can be a single o For OPTIONS (Section 9.3.7), the request target can be a single
asterisk ("*"). asterisk ("*").
skipping to change at page 49, line 39 skipping to change at page 50, line 50
misdirected, deliberately or accidentally, such that the information misdirected, deliberately or accidentally, such that the information
within a received Host header field differs from the connection's within a received Host header field differs from the connection's
host or port. host or port.
If the connection is from a trusted gateway, such inconsistency might If the connection is from a trusted gateway, such inconsistency might
be expected; otherwise, it might indicate an attempt to bypass be expected; otherwise, it might indicate an attempt to bypass
security filters, trick the server into delivering non-public security filters, trick the server into delivering non-public
content, or poison a cache. See Section 17 for security content, or poison a cache. See Section 17 for security
considerations regarding message routing. considerations regarding message routing.
The 421 (Misdirected Request) status code in a response indicates
that the origin server has rejected the request because it appears to
have been misdirected (Section 15.5.20).
7.5. Response Correlation 7.5. Response Correlation
A connection might be used for multiple request/response exchanges. A connection might be used for multiple request/response exchanges.
The mechanism used to correlate between request and response messages The mechanism used to correlate between request and response messages
is version dependent; some versions of HTTP use implicit ordering of is version dependent; some versions of HTTP use implicit ordering of
messages, while others use an explicit identifier. messages, while others use an explicit identifier.
Responses (both final and interim) can be sent at any time after a Responses (both final and interim) can be sent at any time after a
request is received, even if it is not yet complete. However, request is received, even if it is not yet complete. However,
clients (including intermediaries) might abandon a request if the clients (including intermediaries) might abandon a request if the
response is not forthcoming within a reasonable period of time. response is not forthcoming within a reasonable period of time.
7.6. Message Forwarding 7.6. Message Forwarding
As described in Section 3.6, intermediaries can serve a variety of As described in Section 3.7, intermediaries can serve a variety of
roles in the processing of HTTP requests and responses. Some roles in the processing of HTTP requests and responses. Some
intermediaries are used to improve performance or availability. intermediaries are used to improve performance or availability.
Others are used for access control or to filter content. Since an Others are used for access control or to filter content. Since an
HTTP stream has characteristics similar to a pipe-and-filter HTTP stream has characteristics similar to a pipe-and-filter
architecture, there are no inherent limits to the extent an architecture, there are no inherent limits to the extent an
intermediary can enhance (or interfere) with either direction of the intermediary can enhance (or interfere) with either direction of the
stream. stream.
An intermediary not acting as a tunnel MUST implement the Connection An intermediary not acting as a tunnel MUST implement the Connection
header field, as specified in Section 7.6.1, and exclude fields from header field, as specified in Section 7.6.1, and exclude fields from
skipping to change at page 50, line 30 skipping to change at page 51, line 42
An intermediary MUST NOT forward a message to itself unless it is An intermediary MUST NOT forward a message to itself unless it is
protected from an infinite request loop. In general, an intermediary protected from an infinite request loop. In general, an intermediary
ought to recognize its own server names, including any aliases, local ought to recognize its own server names, including any aliases, local
variations, or literal IP addresses, and respond to such requests variations, or literal IP addresses, and respond to such requests
directly. directly.
An HTTP message can be parsed as a stream for incremental processing An HTTP message can be parsed as a stream for incremental processing
or forwarding downstream. However, recipients cannot rely on or forwarding downstream. However, recipients cannot rely on
incremental delivery of partial messages, since some implementations incremental delivery of partial messages, since some implementations
will buffer or delay message forwarding for the sake of network will buffer or delay message forwarding for the sake of network
efficiency, security checks, or payload transformations. efficiency, security checks, or content transformations.
7.6.1. Connection 7.6.1. Connection
The "Connection" header field allows the sender to list desired The "Connection" header field allows the sender to list desired
control options for the current connection. control options for the current connection.
When a field aside from Connection is used to supply control When a 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. the corresponding field name within the Connection header field.
Note that some versions of HTTP prohibit the use of fields for such Note that some versions of HTTP prohibit the use of fields for such
skipping to change at page 51, line 34 skipping to change at page 53, line 6
o Upgrade (Section 7.8) o Upgrade (Section 7.8)
The Connection header field's value has the following grammar: The Connection header field's value has the following grammar:
Connection = #connection-option Connection = #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 field A sender MUST NOT send a connection option corresponding to a field
that is intended for all recipients of the payload. For example, that is intended for all recipients of the content. For example,
Cache-Control is never appropriate as a connection option 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 field present in The connection options do not always correspond to a field present in
the message, since a connection-specific field might not be needed if the message, since a connection-specific field might not be needed if
there are no parameters associated with a connection option. In there are no parameters associated with a connection option. In
contrast, a connection-specific field that is received without a contrast, a connection-specific field that is received without a
corresponding connection option usually indicates that the field has corresponding connection option usually indicates that the field has
been improperly forwarded by an intermediary and ought to be ignored been improperly forwarded by an intermediary and ought to be ignored
by the recipient. by the recipient.
skipping to change at page 54, line 17 skipping to change at page 55, line 43
Via: 1.0 ricky, 1.1 mertz, 1.0 lucy Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
A sender SHOULD NOT combine multiple list members unless they are all A sender SHOULD NOT combine multiple list members unless they are all
under the same organizational control and the hosts have already been under the same organizational control and the hosts have already been
replaced by pseudonyms. A sender MUST NOT combine members that have replaced by pseudonyms. A sender MUST NOT combine members that have
different received-protocol values. different received-protocol values.
7.7. Message Transformations 7.7. Message Transformations
Some intermediaries include features for transforming messages and Some intermediaries include features for transforming messages and
their payloads. A proxy might, for example, convert between image their content. A proxy might, for example, convert between image
formats in order to save cache space or to reduce the amount of formats in order to save cache space or to reduce the amount of
traffic on a slow link. However, operational problems might occur traffic on a slow link. However, operational problems might occur
when these transformations are applied to payloads intended for when these transformations are applied to content intended for
critical applications, such as medical imaging or scientific data critical applications, such as medical imaging or scientific data
analysis, particularly when integrity checks or digital signatures analysis, particularly when integrity checks or digital signatures
are used to ensure that the payload received is identical to the are used to ensure that the content received is identical to the
original. original.
An HTTP-to-HTTP proxy is called a "_transforming proxy_" if it is An HTTP-to-HTTP proxy is called a _transforming proxy_ if it is
designed or configured to modify messages in a semantically designed or configured to modify messages in a semantically
meaningful way (i.e., modifications, beyond those required by normal meaningful way (i.e., modifications, beyond those required by normal
HTTP processing, that change the message in a way that would be HTTP processing, that change the message in a way that would be
significant to the original sender or potentially significant to significant to the original sender or potentially significant to
downstream recipients). For example, a transforming proxy might be downstream recipients). For example, a transforming proxy might be
acting as a shared annotation server (modifying responses to include acting as a shared annotation server (modifying responses to include
references to a local annotation database), a malware filter, a references to a local annotation database), a malware filter, a
format transcoder, or a privacy filter. Such transformations are format transcoder, or a privacy filter. Such transformations are
presumed to be desired by whichever client (or client organization) presumed to be desired by whichever client (or client organization)
chose the proxy. chose the proxy.
If a proxy receives a target URI with a host name that is not a fully If a proxy receives a target URI with a host name that is not a fully
qualified domain name, it MAY add its own domain to the host name it 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 received when forwarding the request. A proxy MUST NOT change the
host name if the target URI contains a fully qualified domain name. host name if the target URI contains a fully qualified domain name.
A proxy MUST NOT modify the "absolute-path" and "query" parts of the A proxy MUST NOT modify the "absolute-path" and "query" parts of the
received target URI when forwarding it to the next inbound server, received target URI when forwarding it to the next inbound server,
except as noted above to replace an empty path with "/" or "*". except as noted above to replace an empty path with "/" or "*".
A proxy MUST NOT transform the payload (Section 6.4) of a message A proxy MUST NOT transform the content (Section 6.4) of a message
that contains a no-transform cache-control response directive that contains a no-transform cache-control response directive
(Section 5.2 of [Caching]). Note that this does not include changes (Section 5.2 of [Caching]). Note that this does not include changes
to the message body that do not affect the payload, such as transfer to the message body that do not affect the content, such as transfer
codings (Section 7 of [Messaging]). codings (Section 7 of [Messaging]).
A proxy MAY transform the payload of a message that does not contain A proxy MAY transform the content of a message that does not contain
a no-transform cache-control directive. A proxy that transforms the a no-transform cache-control directive. A proxy that transforms the
payload of a 200 (OK) response can inform downstream recipients that content of a 200 (OK) response can inform downstream recipients that
a transformation has been applied by changing the response status a transformation has been applied by changing the response status
code to 203 (Non-Authoritative Information) (Section 15.3.4). code to 203 (Non-Authoritative Information) (Section 15.3.4).
A proxy SHOULD NOT modify header fields that provide information A proxy SHOULD NOT modify header fields that provide information
about the endpoints of the communication chain, the resource state, about the endpoints of the communication chain, the resource state,
or the selected representation (other than the payload) unless the or the selected representation (other than the content) unless the
field's definition specifically allows such modification or the field's definition specifically allows such modification or the
modification is deemed necessary for privacy or security. modification is deemed necessary for privacy or security.
7.8. Upgrade 7.8. 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. connection.
A client MAY send a list of protocol names in the Upgrade header A client MAY send a list of protocol names in the Upgrade header
skipping to change at page 57, line 33 skipping to change at page 59, line 11
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 15.4). (Section 15.4).
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.5 and future updates to this version rules of Section 2.5 and future updates to this
specification. Additional protocol names ought to be registered specification. Additional protocol names ought to be registered
using the registration procedure defined in Section 16.7. using the registration procedure defined in Section 16.7.
8. Representations 8. Representation Data and Metadata
A "_representation_" is information that is intended to reflect a
past, current, or desired state of a given resource, in a format that
can be readily communicated via the protocol. A representation
consists of a set of representation metadata and a potentially
unbounded stream of representation data.
HTTP allows "information hiding" behind its uniform interface by
phrasing communication with respect to a transferable representation
of the resource state, rather than transferring the resource itself.
This allows the resource identified by a URI to be anything,
including temporal functions like "the current weather in Laguna
Beach", while potentially providing information that represents that
resource at the time a message is generated [REST].
The uniform interface is similar to a window through which one can
observe and act upon a thing only through the communication of
messages to an independent actor on the other side. A shared
abstraction is needed to represent ("take the place of") the current
or desired state of that thing in our communications. When a
representation is hypertext, it can provide both a representation of
the resource state and processing instructions that help guide the
recipient's future interactions.
8.1. Selected Representations
An origin server might be provided with, or be capable of generating,
multiple representations that are each intended to reflect the
current state of a target resource. In such cases, some algorithm is
used by the origin server to select one of those representations as
most applicable to a given request, usually based on content
negotiation. This "_selected representation_" is used to provide the
data and metadata for evaluating conditional requests (Section 13.1)
and constructing the payload for 200 (OK), 206 (Partial Content), and
304 (Not Modified) responses to GET (Section 9.3.1).
8.2. Representation Data 8.1. Representation Data
The representation data associated with an HTTP message is either The representation data associated with an HTTP message is either
provided as the payload data of the message or referred to by the provided as the content of the message or referred to by the message
message semantics and the target URI. The representation data is in semantics and the target URI. The representation data is in a format
a format and encoding defined by the representation metadata header and encoding defined by the representation metadata header fields.
fields.
The data type of the representation data is determined via the header The data type of the representation data is determined via the header
fields Content-Type and Content-Encoding. These define a two-layer, fields Content-Type and Content-Encoding. These define a two-layer,
ordered encoding model: ordered encoding model:
representation-data := Content-Encoding( Content-Type( bits ) ) representation-data := Content-Encoding( Content-Type( bits ) )
8.3. Representation Metadata 8.2. Representation Metadata
Representation header fields provide metadata about the Representation header fields provide metadata about the
representation. When a message includes payload data, the representation. When a message includes content, the representation
representation header fields describe how to interpret that data. In header fields describe how to interpret that data. In a response to
a response to a HEAD request, the representation header fields a HEAD request, the representation header fields describe the
describe the representation data that would have been enclosed in the representation data that would have been enclosed in the content if
payload if the same request had been a GET. the same request had been a GET.
8.4. Content-Type 8.3. Content-Type
The "Content-Type" header field indicates the media type of the The "Content-Type" header field indicates the media type of the
associated representation: either the representation enclosed in the associated representation: either the representation enclosed in the
message payload or the selected representation, as determined by the message content or the selected representation, as determined by the
message semantics. The indicated media type defines both the data message semantics. The indicated media type defines both the data
format and how that data is intended to be processed by a recipient, format and how that data is intended to be processed by a recipient,
within the scope of the received message semantics, after any content within the scope of the received message semantics, after any content
codings indicated by Content-Encoding are decoded. codings indicated by Content-Encoding are decoded.
Content-Type = media-type Content-Type = media-type
Media types are defined in Section 8.4.1. An example of the field is Media types are defined in Section 8.3.1. An example of the field is
Content-Type: text/html; charset=ISO-8859-4 Content-Type: text/html; charset=ISO-8859-4
A sender that generates a message containing payload data SHOULD A sender that generates a message containing content SHOULD generate
generate a Content-Type header field in that message unless the a Content-Type header field in that message unless the intended media
intended media type of the enclosed representation is unknown to the type of the enclosed representation is unknown to the sender. If a
sender. If a Content-Type header field is not present, the recipient Content-Type header field is not present, the recipient MAY either
MAY either assume a media type of "application/octet-stream" assume a media type of "application/octet-stream" ([RFC2046],
([RFC2046], Section 4.5.1) or examine the data to determine its type. Section 4.5.1) or examine the data to determine its type.
In practice, resource owners do not always properly configure their In practice, resource owners do not always properly configure their
origin server to provide the correct Content-Type for a given origin server to provide the correct Content-Type for a given
representation. Some user agents examine a payload's content and, in representation. Some user agents examine the content and, in certain
certain cases, override the received type (for example, see cases, override the received type (for example, see [Sniffing]).
[Sniffing]). This "MIME sniffing" risks drawing incorrect This "MIME sniffing" risks drawing incorrect conclusions about the
conclusions about the data, which might expose the user to additional data, which might expose the user to additional security risks (e.g.,
security risks (e.g., "privilege escalation"). Furthermore, it is "privilege escalation"). Furthermore, it is impossible to determine
impossible to determine the sender's intended processing model by the sender's intended processing model by examining the data format:
examining the data format: many data formats match multiple media many data formats match multiple media types that differ only in
types that differ only in processing semantics. Implementers are processing semantics. Implementers are encouraged to provide a means
encouraged to provide a means to disable such sniffing. to disable such sniffing.
Furthermore, although Content-Type is defined as a singleton field, Furthermore, although Content-Type is defined as a singleton field,
it is sometimes incorrectly generated multiple times, resulting in a it is sometimes incorrectly generated multiple times, resulting in a
combined field value that appears to be a list. Recipients often combined field value that appears to be a list. Recipients often
attempt to handle this error by using the last syntactically valid attempt to handle this error by using the last syntactically valid
member of the list, but note that some implementations might have member of the list, but note that some implementations might have
different error handling behaviors, leading to interoperability and/ different error handling behaviors, leading to interoperability and/
or security issues. or security issues.
8.4.1. Media Type 8.3.1. Media Type
HTTP uses media types [RFC2046] in the Content-Type (Section 8.4) and HTTP uses media types [RFC2046] in the Content-Type (Section 8.3) and
Accept (Section 12.5.1) header fields in order to provide open and Accept (Section 12.5.1) header fields in order to provide open and
extensible data typing and type negotiation. Media types define both extensible data typing and type negotiation. Media types define both
a data format and various processing models: how to process that data a data format and various processing models: how to process that data
in accordance with each context in which it is received. in accordance with each context in which it is received.
media-type = type "/" subtype parameters media-type = type "/" subtype parameters
type = token type = token
subtype = token subtype = token
The type and subtype tokens are case-insensitive. The type and subtype tokens are case-insensitive.
skipping to change at page 60, line 39 skipping to change at page 61, line 18
is defined as being case-insensitive in [RFC2046], Section 4.1.2): is defined as being case-insensitive in [RFC2046], Section 4.1.2):
text/html;charset=utf-8 text/html;charset=utf-8
Text/HTML;Charset="utf-8" Text/HTML;Charset="utf-8"
text/html; charset="utf-8" text/html; charset="utf-8"
text/html;charset=UTF-8 text/html;charset=UTF-8
Media types ought to be registered with IANA according to the Media types ought to be registered with IANA according to the
procedures defined in [BCP13]. procedures defined in [BCP13].
8.4.2. Charset 8.3.2. Charset
HTTP uses _charset_ names to indicate or negotiate the character HTTP uses _charset_ names to indicate or negotiate the character
encoding scheme of a textual representation [RFC6365]. A charset is encoding scheme of a textual representation [RFC6365]. A charset is
identified by a case-insensitive token. identified by a case-insensitive token.
charset = token charset = token
Charset names ought to be registered in the IANA "Character Sets" Charset names ought to be registered in the IANA "Character Sets"
registry (<https://www.iana.org/assignments/character-sets>) registry (<https://www.iana.org/assignments/character-sets>)
according to the procedures defined in Section 2 of [RFC2978]. according to the procedures defined in Section 2 of [RFC2978].
| *Note:* In theory, charset names are defined by the "mime- | *Note:* In theory, charset names are defined by the "mime-
| charset" ABNF rule defined in Section 2.3 of [RFC2978] (as | charset" ABNF rule defined in Section 2.3 of [RFC2978] (as
| corrected in [Err1912]). That rule allows two characters that | corrected in [Err1912]). That rule allows two characters that
| are not included in "token" ("{" and "}"), but no charset name | are not included in "token" ("{" and "}"), but no charset name
| registered at the time of this writing includes braces (see | registered at the time of this writing includes braces (see
| [Err5433]). | [Err5433]).
8.4.3. Canonicalization and Text Defaults 8.3.3. Canonicalization and Text Defaults
Media types are registered with a canonical form in order to be Media types are registered with a canonical form in order to be
interoperable among systems with varying native encoding formats. interoperable among systems with varying native encoding formats.
Representations selected or transferred via HTTP ought to be in Representations selected or transferred via HTTP ought to be in
canonical form, for many of the same reasons described by the canonical form, for many of the same reasons described by the
Multipurpose Internet Mail Extensions (MIME) [RFC2045]. However, the Multipurpose Internet Mail Extensions (MIME) [RFC2045]. However, the
performance characteristics of email deployments (i.e., store and performance characteristics of email deployments (i.e., store and
forward messages to peers) are significantly different from those forward messages to peers) are significantly different from those
common to HTTP and the Web (server-based information services). common to HTTP and the Web (server-based information services).
Furthermore, MIME's constraints for the sake of compatibility with Furthermore, MIME's constraints for the sake of compatibility with
skipping to change at page 61, line 36 skipping to change at page 62, line 15
MIME's canonical form requires that media subtypes of the "text" type MIME's canonical form requires that media subtypes of the "text" type
use CRLF as the text line break. HTTP allows the transfer of text use CRLF as the text line break. HTTP allows the transfer of text
media with plain CR or LF alone representing a line break, when such media with plain CR or LF alone representing a line break, when such
line breaks are consistent for an entire representation. An HTTP line breaks are consistent for an entire representation. An HTTP
sender MAY generate, and a recipient MUST be able to parse, line sender MAY generate, and a recipient MUST be able to parse, line
breaks in text media that consist of CRLF, bare CR, or bare LF. In breaks in text media that consist of CRLF, bare CR, or bare LF. In
addition, text media in HTTP is not limited to charsets that use addition, text media in HTTP is not limited to charsets that use
octets 13 and 10 for CR and LF, respectively. This flexibility octets 13 and 10 for CR and LF, respectively. This flexibility
regarding line breaks applies only to text within a representation regarding line breaks applies only to text within a representation
that has been assigned a "text" media type; it does not apply to that has been assigned a "text" media type; it does not apply to
"multipart" types or HTTP elements outside the payload data (e.g., "multipart" types or HTTP elements outside the content (e.g., header
header fields). fields).
If a representation is encoded with a content-coding, the underlying If a representation is encoded with a content-coding, the underlying
data ought to be in a form defined above prior to being encoded. data ought to be in a form defined above prior to being encoded.
8.4.4. Multipart Types 8.3.4. Multipart Types
MIME provides for a number of "multipart" types - encapsulations of MIME provides for a number of "multipart" types - encapsulations of
one or more representations within a single message body. All one or more representations within a single message body. All
multipart types share a common syntax, as defined in Section 5.1.1 of multipart types share a common syntax, as defined in Section 5.1.1 of
[RFC2046], and include a boundary parameter as part of the media type [RFC2046], and include a boundary parameter as part of the media type
value. The message body is itself a protocol element; a sender MUST value. The message body is itself a protocol element; a sender MUST
generate only CRLF to represent line breaks between body parts. generate only CRLF to represent line breaks between body parts.
HTTP message framing does not use the multipart boundary as an HTTP message framing does not use the multipart boundary as an
indicator of message body length, though it might be used by indicator of message body length, though it might be used by
implementations that generate or process the payload. For example, implementations that generate or process the content. For example,
the "multipart/form-data" type is often used for carrying form data the "multipart/form-data" type is often used for carrying form data
in a request, as described in [RFC7578], and the "multipart/ in a request, as described in [RFC7578], and the "multipart/
byteranges" type is defined by this specification for use in some 206 byteranges" type is defined by this specification for use in some 206
(Partial Content) responses (see Section 15.3.7). (Partial Content) responses (see Section 15.3.7).
8.5. Content-Encoding 8.4. Content-Encoding
The "Content-Encoding" header field indicates what content codings The "Content-Encoding" header field indicates what content codings
have been applied to the representation, beyond those inherent in the have been applied to the representation, beyond those inherent in the
media type, and thus what decoding mechanisms have to be applied in media type, and thus what decoding mechanisms have to be applied in
order to obtain data in the media type referenced by the Content-Type order to obtain data in the media type referenced by the Content-Type
header field. Content-Encoding is primarily used to allow a header field. Content-Encoding is primarily used to allow a
representation's data to be compressed without losing the identity of representation's data to be compressed without losing the identity of
its underlying media type. its underlying media type.
Content-Encoding = #content-coding Content-Encoding = #content-coding
skipping to change at page 63, line 14 skipping to change at page 63, line 39
choose to publish the same data as multiple representations that choose to publish the same data as multiple representations that
differ only in whether the coding is defined as part of Content-Type differ only in whether the coding is defined as part of Content-Type
or Content-Encoding, since some user agents will behave differently or Content-Encoding, since some user agents will behave differently
in their handling of each response (e.g., open a "Save as ..." dialog in their handling of each response (e.g., open a "Save as ..." dialog
instead of automatic decompression and rendering of content). instead of automatic decompression and rendering of content).
An origin server MAY respond with a status code of 415 (Unsupported An origin server MAY respond with a status code of 415 (Unsupported
Media Type) if a representation in the request message has a content Media Type) if a representation in the request message has a content
coding that is not acceptable. coding that is not acceptable.
8.5.1. Content Codings 8.4.1. Content Codings
Content coding values indicate an encoding transformation that has Content coding values indicate an encoding transformation that has
been or can be applied to a representation. Content codings are been or can be applied to a representation. Content codings are
primarily used to allow a representation to be compressed or primarily used to allow a representation to be compressed or
otherwise usefully transformed without losing the identity of its otherwise usefully transformed without losing the identity of its
underlying media type and without loss of information. Frequently, underlying media type and without loss of information. Frequently,
the representation is stored in coded form, transmitted directly, and the representation is stored in coded form, transmitted directly, and
only decoded by the final recipient. only decoded by the final recipient.
content-coding = token content-coding = token
All content codings are case-insensitive and ought to be registered All content codings are case-insensitive and ought to be registered
within the "HTTP Content Coding Registry", as described in within the "HTTP Content Coding Registry", as described in
Section 16.6 Section 16.6
Content-coding values are used in the Accept-Encoding Content-coding values are used in the Accept-Encoding
(Section 12.5.3) and Content-Encoding (Section 8.5) header fields. (Section 12.5.3) and Content-Encoding (Section 8.4) header fields.
8.5.1.1. Compress Coding 8.4.1.1. Compress Coding
The "compress" coding is an adaptive Lempel-Ziv-Welch (LZW) coding The "compress" coding is an adaptive Lempel-Ziv-Welch (LZW) coding
[Welch] that is commonly produced by the UNIX file compression [Welch] that is commonly produced by the UNIX file compression
program "compress". A recipient SHOULD consider "x-compress" to be program "compress". A recipient SHOULD consider "x-compress" to be
equivalent to "compress". equivalent to "compress".
8.5.1.2. Deflate Coding 8.4.1.2. Deflate Coding
The "deflate" coding is a "zlib" data format [RFC1950] containing a The "deflate" coding is a "zlib" data format [RFC1950] containing a
"deflate" compressed data stream [RFC1951] that uses a combination of "deflate" compressed data stream [RFC1951] that uses a combination of
the Lempel-Ziv (LZ77) compression algorithm and Huffman coding. the Lempel-Ziv (LZ77) compression algorithm and Huffman coding.
| *Note:* Some non-conformant implementations send the "deflate" | *Note:* Some non-conformant implementations send the "deflate"
| compressed data without the zlib wrapper. | compressed data without the zlib wrapper.
8.5.1.3. Gzip Coding 8.4.1.3. Gzip Coding
The "gzip" coding is an LZ77 coding with a 32-bit Cyclic Redundancy The "gzip" coding is an LZ77 coding with a 32-bit Cyclic Redundancy
Check (CRC) that is commonly produced by the gzip file compression Check (CRC) that is commonly produced by the gzip file compression
program [RFC1952]. A recipient SHOULD consider "x-gzip" to be program [RFC1952]. A recipient SHOULD consider "x-gzip" to be
equivalent to "gzip". equivalent to "gzip".
8.6. Content-Language 8.5. Content-Language
The "Content-Language" header field describes the natural language(s) The "Content-Language" header field describes the natural language(s)
of the intended audience for the representation. Note that this of the intended audience for the representation. Note that this
might not be equivalent to all the languages used within the might not be equivalent to all the languages used within the
representation. representation.
Content-Language = #language-tag Content-Language = #language-tag
Language tags are defined in Section 8.6.1. The primary purpose of Language tags are defined in Section 8.5.1. The primary purpose of
Content-Language is to allow a user to identify and differentiate Content-Language is to allow a user to identify and differentiate
representations according to the users' own preferred language. representations according to the users' own preferred language.
Thus, if the content is intended only for a Danish-literate audience, Thus, if the content is intended only for a Danish-literate audience,
the appropriate field is the appropriate field is
Content-Language: da Content-Language: da
If no Content-Language is specified, the default is that the content If no Content-Language is specified, the default is that the content
is intended for all language audiences. This might mean that the is intended for all language audiences. This might mean that the
sender does not consider it to be specific to any natural language, sender does not consider it to be specific to any natural language,
skipping to change at page 65, line 5 skipping to change at page 65, line 27
However, just because multiple languages are present within a However, just because multiple languages are present within a
representation does not mean that it is intended for multiple representation does not mean that it is intended for multiple
linguistic audiences. An example would be a beginner's language linguistic audiences. An example would be a beginner's language
primer, such as "A First Lesson in Latin", which is clearly intended primer, such as "A First Lesson in Latin", which is clearly intended
to be used by an English-literate audience. In this case, the to be used by an English-literate audience. In this case, the
Content-Language would properly only include "en". Content-Language would properly only include "en".
Content-Language MAY be applied to any media type - it is not limited Content-Language MAY be applied to any media type - it is not limited
to textual documents. to textual documents.
8.6.1. Language Tags 8.5.1. Language Tags
A language tag, as defined in [RFC5646], identifies a natural A language tag, as defined in [RFC5646], identifies a natural
language spoken, written, or otherwise conveyed by human beings for language spoken, written, or otherwise conveyed by human beings for
communication of information to other human beings. Computer communication of information to other human beings. Computer
languages are explicitly excluded. languages are explicitly excluded.
HTTP uses language tags within the Accept-Language and HTTP uses language tags within the Accept-Language and
Content-Language header fields. Accept-Language uses the broader Content-Language header fields. Accept-Language uses the broader
language-range production defined in Section 12.5.4, whereas language-range production defined in Section 12.5.4, whereas
Content-Language uses the language-tag production defined below. Content-Language uses the language-tag production defined below.
skipping to change at page 65, line 32 skipping to change at page 66, line 5
broad family of related languages (e.g., "en" = English), which is broad family of related languages (e.g., "en" = English), which is
optionally followed by a series of subtags that refine or narrow that optionally followed by a series of subtags that refine or narrow that
language's range (e.g., "en-CA" = the variety of English as language's range (e.g., "en-CA" = the variety of English as
communicated in Canada). Whitespace is not allowed within a language communicated in Canada). Whitespace is not allowed within a language
tag. Example tags include: tag. Example tags include:
fr, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN fr, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN
See [RFC5646] for further information. See [RFC5646] for further information.
8.7. Content-Length 8.6. Content-Length
The "Content-Length" header field indicates the associated The "Content-Length" header field indicates the associated
representation's data length as a decimal non-negative integer number representation's data length as a decimal non-negative integer number
of octets. When transferring a representation as a payload, Content- of octets. When transferring a representation as content, Content-
Length refers specifically to the amount of data enclosed so that it Length refers specifically to the amount of data enclosed so that it
can be used to delimit framing (e.g., Section 6.2 of [Messaging]). can be used to delimit framing (e.g., Section 6.2 of [Messaging]).
In other cases, Content-Length indicates the selected In other cases, Content-Length indicates the selected
representation's current length, which can be used by recipients to representation's current length, which can be used by recipients to
estimate transfer time or compare to previously stored estimate transfer time or compare to previously stored
representations. representations.
Content-Length = 1*DIGIT Content-Length = 1*DIGIT
An example is An example is
Content-Length: 3495 Content-Length: 3495
A sender MUST NOT send a Content-Length header field in any message A sender MUST NOT send a Content-Length header field in any message
that contains a Transfer-Encoding header field. that contains a Transfer-Encoding header field.
A user agent SHOULD send a Content-Length in a request message when A user agent SHOULD send a Content-Length in a request message when
no Transfer-Encoding is sent and the request method defines a meaning no Transfer-Encoding is sent and the request method defines a meaning
for an enclosed payload. For example, a Content-Length header field for enclosed content. For example, a Content-Length header field is
is normally sent in a POST request even when the value is 0 normally sent in a POST request even when the value is 0 (indicating
(indicating an empty payload data). A user agent SHOULD NOT send a empty content). A user agent SHOULD NOT send a Content-Length header
Content-Length header field when the request message does not contain field when the request message does not contain content and the
a payload data and the method semantics do not anticipate such data. method semantics do not anticipate such data.
A server MAY send a Content-Length header field in a response to a A server MAY send a Content-Length header field in a response to a
HEAD request (Section 9.3.2); a server MUST NOT send Content-Length HEAD request (Section 9.3.2); a server MUST NOT send Content-Length
in such a response unless its field value equals the decimal number in such a response unless its field value equals the decimal number
of octets that would have been sent in the payload of a response if of octets that would have been sent in the content of a response if
the same request had used the GET method. the same request had used the GET method.
A server MAY send a Content-Length header field in a 304 (Not A server MAY send a Content-Length header field in a 304 (Not
Modified) response to a conditional GET request (Section 15.4.5); a Modified) response to a conditional GET request (Section 15.4.5); a
server MUST NOT send Content-Length in such a response unless its server MUST NOT send Content-Length in such a response unless its
field value equals the decimal number of octets that would have been field value equals the decimal number of octets that would have been
sent in the payload data of a 200 (OK) response to the same request. sent in the content of a 200 (OK) response to the same request.
A server MUST NOT send a Content-Length header field in any response A server MUST NOT send a Content-Length header field in any response
with a status code of 1xx (Informational) or 204 (No Content). A with a status code of 1xx (Informational) or 204 (No Content). A
server MUST NOT send a Content-Length header field in any 2xx server MUST NOT send a Content-Length header field in any 2xx
(Successful) response to a CONNECT request (Section 9.3.6). (Successful) response to a CONNECT request (Section 9.3.6).
Aside from the cases defined above, in the absence of Transfer- Aside from the cases defined above, in the absence of Transfer-
Encoding, an origin server SHOULD send a Content-Length header field Encoding, an origin server SHOULD send a Content-Length header field
when the payload data size is known prior to sending the complete when the content size is known prior to sending the complete header
header section. This will allow downstream recipients to measure section. This will allow downstream recipients to measure transfer
transfer progress, know when a received message is complete, and progress, know when a received message is complete, and potentially
potentially reuse the connection for additional requests. reuse the connection for additional requests.
Any Content-Length field value greater than or equal to zero is Any Content-Length field value greater than or equal to zero is
valid. Since there is no predefined limit to the length of a valid. Since there is no predefined limit to the length of content,
payload, a recipient MUST anticipate potentially large decimal a recipient MUST anticipate potentially large decimal numerals and
numerals and prevent parsing errors due to integer conversion prevent parsing errors due to integer conversion overflows
overflows (Section 17.5). (Section 17.5).
If a message is received that has a Content-Length header field value If a message is received that has a Content-Length header field value
consisting of the same decimal value as a comma-separated list consisting of the same decimal value as a comma-separated list
(Section 5.6.1) - for example, "Content-Length: 42, 42" - indicating (Section 5.6.1) - for example, "Content-Length: 42, 42" - indicating
that duplicate Content-Length header fields have been generated or that duplicate Content-Length header fields have been generated or
combined by an upstream message processor, then the recipient MUST combined by an upstream message processor, then the recipient MUST
either reject the message as invalid or replace the duplicated field either reject the message as invalid or replace the duplicated field
values with a single valid Content-Length field containing that values with a single valid Content-Length field containing that
decimal value. decimal value.
8.8. Content-Location 8.7. Content-Location
The "Content-Location" header field references a URI that can be used The "Content-Location" header field references a URI that can be used
as an identifier for a specific resource corresponding to the as an identifier for a specific resource corresponding to the
representation in this message's payload. In other words, if one representation in this message's content. In other words, if one
were to perform a GET request on this URI at the time of this were to perform a GET request on this URI at the time of this
message's generation, then a 200 (OK) response would contain the same message's generation, then a 200 (OK) response would contain the same
representation that is enclosed as payload in this message. representation that is enclosed as content in this message.
Content-Location = absolute-URI / partial-URI Content-Location = absolute-URI / partial-URI
The field value is either an absolute-URI or a partial-URI. In the The field value is either an absolute-URI or a partial-URI. In the
latter case (Section 4), the referenced URI is relative to the target latter case (Section 4), the referenced URI is relative to the target
URI ([RFC3986], Section 5). URI ([RFC3986], Section 5).
The Content-Location value is not a replacement for the target URI The Content-Location value is not a replacement for the target URI
(Section 7.1). It is representation metadata. It has the same (Section 7.1). It is representation metadata. It has the same
syntax and semantics as the header field of the same name defined for syntax and semantics as the header field of the same name defined for
MIME body parts in Section 4 of [RFC2557]. However, its appearance MIME body parts in Section 4 of [RFC2557]. However, its appearance
in an HTTP message has some special implications for HTTP recipients. in an HTTP message has some special implications for HTTP recipients.
If Content-Location is included in a 2xx (Successful) response If Content-Location is included in a 2xx (Successful) response
message and its value refers (after conversion to absolute form) to a message and its value refers (after conversion to absolute form) to a
URI that is the same as the target URI, then the recipient MAY URI that is the same as the target URI, then the recipient MAY
consider the payload to be a current representation of that resource consider the content to be a current representation of that resource
at the time indicated by the message origination date. For a GET at the time indicated by the message origination date. For a GET
(Section 9.3.1) or HEAD (Section 9.3.2) request, this is the same as (Section 9.3.1) or HEAD (Section 9.3.2) request, this is the same as
the default semantics when no Content-Location is provided by the the default semantics when no Content-Location is provided by the
server. For a state-changing request like PUT (Section 9.3.4) or server. For a state-changing request like PUT (Section 9.3.4) or
POST (Section 9.3.3), it implies that the server's response contains POST (Section 9.3.3), it implies that the server's response contains
the new representation of that resource, thereby distinguishing it the new representation of that resource, thereby distinguishing it
from representations that might only report about the action (e.g., from representations that might only report about the action (e.g.,
"It worked!"). This allows authoring applications to update their "It worked!"). This allows authoring applications to update their
local copies without the need for a subsequent GET request. local copies without the need for a subsequent GET request.
skipping to change at page 68, line 7 skipping to change at page 68, line 28
share the same resource owner, which cannot be programmatically share the same resource owner, which cannot be programmatically
determined via HTTP. determined via HTTP.
o For a response to a GET or HEAD request, this is an indication o For a response to a GET or HEAD request, this is an indication
that the target URI refers to a resource that is subject to that the target URI refers to a resource that is subject to
content negotiation and the Content-Location field value is a more content negotiation and the Content-Location field value is a more
specific identifier for the selected representation. specific identifier for the selected representation.
o For a 201 (Created) response to a state-changing method, a o For a 201 (Created) response to a state-changing method, a
Content-Location field value that is identical to the Location Content-Location field value that is identical to the Location
field value indicates that this payload is a current field value indicates that this content is a current
representation of the newly created resource. representation of the newly created resource.
o Otherwise, such a Content-Location indicates that this payload is o Otherwise, such a Content-Location indicates that this content is
a representation reporting on the requested action's status and a representation reporting on the requested action's status and
that the same report is available (for future access with GET) at that the same report is available (for future access with GET) at
the given URI. For example, a purchase transaction made via a the given URI. For example, a purchase transaction made via a
POST request might include a receipt document as the payload of POST request might include a receipt document as the content of
the 200 (OK) response; the Content-Location field value provides the 200 (OK) response; the Content-Location field value provides
an identifier for retrieving a copy of that same receipt in the an identifier for retrieving a copy of that same receipt in the
future. future.
A user agent that sends Content-Location in a request message is A user agent that sends Content-Location in a request message is
stating that its value refers to where the user agent originally stating that its value refers to where the user agent originally
obtained the content of the enclosed representation (prior to any obtained the content of the enclosed representation (prior to any
modifications made by that user agent). In other words, the user modifications made by that user agent). In other words, the user
agent is providing a back link to the source of the original agent is providing a back link to the source of the original
representation. representation.
skipping to change at page 68, line 43 skipping to change at page 69, line 22
For example, if a client makes a PUT request on a negotiated resource For example, if a client makes a PUT request on a negotiated resource
and the origin server accepts that PUT (without redirection), then and the origin server accepts that PUT (without redirection), then
the new state of that resource is expected to be consistent with the the new state of that resource is expected to be consistent with the
one representation supplied in that PUT; the Content-Location cannot one representation supplied in that PUT; the Content-Location cannot
be used as a form of reverse content selection identifier to update be used as a form of reverse content selection identifier to update
only one of the negotiated representations. If the user agent had only one of the negotiated representations. If the user agent had
wanted the latter semantics, it would have applied the PUT directly wanted the latter semantics, it would have applied the PUT directly
to the Content-Location URI. to the Content-Location URI.
8.9. Validator Fields 8.8. Validator Fields
Validator fields convey metadata about the selected representation Validator fields convey metadata about the selected representation
(Section 8). In responses to safe requests, validator fields (Section 3.2). In responses to safe requests, validator fields
describe the selected representation chosen by the origin server describe the selected representation chosen by the origin server
while handling the response. Note that, depending on the status code while handling the response. Note that, depending on the status code
semantics, the selected representation for a given response is not semantics, the selected representation for a given response is not
necessarily the same as the representation enclosed as response necessarily the same as the representation enclosed as response
payload. content.
In a successful response to a state-changing request, validator In a successful response to a state-changing request, validator
fields describe the new representation that has replaced the prior fields describe the new representation that has replaced the prior
selected representation as a result of processing the request. selected representation as a result of processing the request.
For example, an ETag field in a 201 (Created) response communicates For example, an ETag field in a 201 (Created) response communicates
the entity-tag of the newly created resource's representation, so the entity-tag of the newly created resource's representation, so
that it can be used in later conditional requests to prevent the that it can be used in later conditional requests to prevent the
"lost update" problem Section 13.1. "lost update" problem Section 13.1.
This specification defines two forms of metadata that are commonly This specification defines two forms of metadata that are commonly
used to observe resource state and test for preconditions: used to observe resource state and test for preconditions:
modification dates (Section 8.9.2) and opaque entity tags modification dates (Section 8.8.2) and opaque entity tags
(Section 8.9.3). Additional metadata that reflects resource state (Section 8.8.3). Additional metadata that reflects resource state
has been defined by various extensions of HTTP, such as Web has been defined by various extensions of HTTP, such as Web
Distributed Authoring and Versioning (WebDAV, [RFC4918]), that are Distributed Authoring and Versioning (WebDAV, [RFC4918]), that are
beyond the scope of this specification. A resource metadata value is beyond the scope of this specification. A resource metadata value is
referred to as a "_validator_" when it is used within a precondition. referred to as a _validator_ when it is used within a precondition.
8.9.1. Weak versus Strong 8.8.1. Weak versus Strong
Validators come in two flavors: strong or weak. Weak validators are Validators come in two flavors: strong or weak. Weak validators are
easy to generate but are far less useful for comparisons. Strong easy to generate but are far less useful for comparisons. Strong
validators are ideal for comparisons but can be very difficult (and validators are ideal for comparisons but can be very difficult (and
occasionally impossible) to generate efficiently. Rather than impose occasionally impossible) to generate efficiently. Rather than impose
that all forms of resource adhere to the same strength of validator, that all forms of resource adhere to the same strength of validator,
HTTP exposes the type of validator in use and imposes restrictions on HTTP exposes the type of validator in use and imposes restrictions on
when weak validators can be used as preconditions. when weak validators can be used as preconditions.
A "_strong validator_" is representation metadata that changes value A _strong validator_ is representation metadata that changes value
whenever a change occurs to the representation data that would be whenever a change occurs to the representation data that would be
observable in the payload data of a 200 (OK) response to GET. observable in the content of a 200 (OK) response to GET.
A strong validator might change for reasons other than a change to A strong validator might change for reasons other than a change to
the representation data, such as when a semantically significant part the representation data, such as when a semantically significant part
of the representation metadata is changed (e.g., Content-Type), but of the representation metadata is changed (e.g., Content-Type), but
it is in the best interests of the origin server to only change the it is in the best interests of the origin server to only change the
value when it is necessary to invalidate the stored responses held by value when it is necessary to invalidate the stored responses held by
remote caches and authoring tools. remote caches and authoring tools.
Cache entries might persist for arbitrarily long periods, regardless Cache entries might persist for arbitrarily long periods, regardless
of expiration times. Thus, a cache might attempt to validate an of expiration times. Thus, a cache might attempt to validate an
skipping to change at page 70, line 19 skipping to change at page 70, line 50
accessible to GET. A collision-resistant hash function applied to accessible to GET. A collision-resistant hash function applied to
the representation data is also sufficient if the data is available the representation data is also sufficient if the data is available
prior to the response header fields being sent and the digest does prior to the response header fields being sent and the digest does
not need to be recalculated every time a validation request is not need to be recalculated every time a validation request is
received. However, if a resource has distinct representations that received. However, if a resource has distinct representations that
differ only in their metadata, such as might occur with content differ only in their metadata, such as might occur with content
negotiation over media types that happen to share the same data negotiation over media types that happen to share the same data
format, then the origin server needs to incorporate additional format, then the origin server needs to incorporate additional
information in the validator to distinguish those representations. information in the validator to distinguish those representations.
In contrast, a "_weak validator_" is representation metadata that In contrast, a _weak validator_ is representation metadata that might
might not change for every change to the representation data. This not change for every change to the representation data. This
weakness might be due to limitations in how the value is calculated, weakness might be due to limitations in how the value is calculated,
such as clock resolution, an inability to ensure uniqueness for all such as clock resolution, an inability to ensure uniqueness for all
possible representations of the resource, or a desire of the resource possible representations of the resource, or a desire of the resource
owner to group representations by some self-determined set of owner to group representations by some self-determined set of
equivalency rather than unique sequences of data. An origin server equivalency rather than unique sequences of data. An origin server
SHOULD change a weak entity-tag whenever it considers prior SHOULD change a weak entity-tag whenever it considers prior
representations to be unacceptable as a substitute for the current representations to be unacceptable as a substitute for the current
representation. In other words, a weak entity-tag ought to change representation. In other words, a weak entity-tag ought to change
whenever the origin server wants caches to invalidate old responses. whenever the origin server wants caches to invalidate old responses.
skipping to change at page 71, line 12 skipping to change at page 71, line 41
they differ only in the representation metadata, such as when two they differ only in the representation metadata, such as when two
different media types are available for the same representation data. different media types are available for the same representation data.
Strong validators are usable for all conditional requests, including Strong validators are usable for all conditional requests, including
cache validation, partial content ranges, and "lost update" cache validation, partial content ranges, and "lost update"
avoidance. Weak validators are only usable when the client does not avoidance. Weak validators are only usable when the client does not
require exact equality with previously obtained representation data, require exact equality with previously obtained representation data,
such as when validating a cache entry or limiting a web traversal to such as when validating a cache entry or limiting a web traversal to
recent changes. recent changes.
8.9.2. Last-Modified 8.8.2. Last-Modified
The "Last-Modified" header field in a response provides a timestamp The "Last-Modified" header field in a response provides a timestamp
indicating the date and time at which the origin server believes the indicating the date and time at which the origin server believes the
selected representation was last modified, as determined at the selected representation was last modified, as determined at the
conclusion of handling the request. conclusion of handling the request.
Last-Modified = HTTP-date Last-Modified = HTTP-date
An example of its use is An example of its use is
Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
8.9.2.1. Generation 8.8.2.1. Generation
An origin server SHOULD send Last-Modified for any selected An origin server SHOULD send Last-Modified for any selected
representation for which a last modification date can be reasonably representation for which a last modification date can be reasonably
and consistently determined, since its use in conditional requests and consistently determined, since its use in conditional requests
and evaluating cache freshness ([Caching]) results in a substantial and evaluating cache freshness ([Caching]) results in a substantial
reduction of HTTP traffic on the Internet and can be a significant reduction of HTTP traffic on the Internet and can be a significant
factor in improving service scalability and reliability. factor in improving service scalability and reliability.
A representation is typically the sum of many parts behind the A representation is typically the sum of many parts behind the
resource interface. The last-modified time would usually be the most resource interface. The last-modified time would usually be the most
skipping to change at page 72, line 13 skipping to change at page 72, line 43
the last modification time is derived from implementation-specific the last modification time is derived from implementation-specific
metadata that evaluates to some time in the future, according to the metadata that evaluates to some time in the future, according to the
origin server's clock, then the origin server MUST replace that value origin server's clock, then the origin server MUST replace that value
with the message origination date. This prevents a future with the message origination date. This prevents a future
modification date from having an adverse impact on cache validation. modification date from having an adverse impact on cache validation.
An origin server without a clock MUST NOT assign Last-Modified values An origin server without a clock MUST NOT assign Last-Modified values
to a response unless these values were associated with the resource to a response unless these values were associated with the resource
by some other system or user with a reliable clock. by some other system or user with a reliable clock.
8.9.2.2. Comparison 8.8.2.2. Comparison
A Last-Modified time, when used as a validator in a request, is A Last-Modified time, when used as a validator in a request, is
implicitly weak unless it is possible to deduce that it is strong, implicitly weak unless it is possible to deduce that it is strong,
using the following rules: using the following rules:
o The validator is being compared by an origin server to the actual o The validator is being compared by an origin server to the actual
current validator for the representation and, current validator for the representation and,
o That origin server reliably knows that the associated o That origin server reliably knows that the associated
representation did not change twice during the second covered by representation did not change twice during the second covered by
skipping to change at page 73, line 10 skipping to change at page 73, line 38
second after the Last-Modified value and the cache has reason to second after the Last-Modified value and the cache has reason to
believe that they were generated by the same clock or that there believe that they were generated by the same clock or that there
is enough difference between the Last-Modified and Date values to is enough difference between the Last-Modified and Date values to
make clock synchronization issues unlikely. make clock synchronization issues unlikely.
This method relies on the fact that if two different responses were This method relies on the fact that if two different responses were
sent by the origin server during the same second, but both had the sent by the origin server during the same second, but both had the
same Last-Modified time, then at least one of those responses would same Last-Modified time, then at least one of those responses would
have a Date value equal to its Last-Modified time. have a Date value equal to its Last-Modified time.
8.9.3. ETag 8.8.3. ETag
The "ETag" field in a response provides the current entity-tag for The "ETag" field in a response provides the current entity-tag for
the selected representation, as determined at the conclusion of the selected representation, as determined at the conclusion of
handling the request. An entity-tag is an opaque validator for handling the request. An entity-tag is an opaque validator for
differentiating between multiple representations of the same differentiating between multiple representations of the same
resource, regardless of whether those multiple representations are resource, regardless of whether those multiple representations are
due to resource state changes over time, content negotiation due to resource state changes over time, content negotiation
resulting in multiple representations being valid at the same time, resulting in multiple representations being valid at the same time,
or both. An entity-tag consists of an opaque quoted string, possibly or both. An entity-tag consists of an opaque quoted string, possibly
prefixed by a weakness indicator. prefixed by a weakness indicator.
skipping to change at page 73, line 50 skipping to change at page 74, line 33
Examples: Examples:
ETag: "xyzzy" ETag: "xyzzy"
ETag: W/"xyzzy" ETag: W/"xyzzy"
ETag: "" ETag: ""
An entity-tag can be either a weak or strong validator, with strong An entity-tag can be either a weak or strong validator, with strong
being the default. If an origin server provides an entity-tag for a being the default. If an origin server provides an entity-tag for a
representation and the generation of that entity-tag does not satisfy representation and the generation of that entity-tag does not satisfy
all of the characteristics of a strong validator (Section 8.9.1), all of the characteristics of a strong validator (Section 8.8.1),
then the origin server MUST mark the entity-tag as weak by prefixing then the origin server MUST mark the entity-tag as weak by prefixing
its opaque value with "W/" (case-sensitive). its opaque value with "W/" (case-sensitive).
A sender MAY send the Etag field in a trailer section (see A sender MAY send the Etag field in a trailer section (see
Section 6.5). However, since trailers are often ignored, it is Section 6.5). However, since trailers are often ignored, it is
preferable to send Etag as a header field unless the entity-tag is preferable to send Etag as a header field unless the entity-tag is
generated while sending the payload data. generated while sending the content.
8.9.3.1. Generation 8.8.3.1. Generation
The principle behind entity-tags is that only the service author The principle behind entity-tags is that only the service author
knows the implementation of a resource well enough to select the most knows the implementation of a resource well enough to select the most
accurate and efficient validation mechanism for that resource, and accurate and efficient validation mechanism for that resource, and
that any such mechanism can be mapped to a simple sequence of octets that any such mechanism can be mapped to a simple sequence of octets
for easy comparison. Since the value is opaque, there is no need for for easy comparison. Since the value is opaque, there is no need for
the client to be aware of how each entity-tag is constructed. the client to be aware of how each entity-tag is constructed.
For example, a resource that has implementation-specific versioning For example, a resource that has implementation-specific versioning
applied to all changes might use an internal revision number, perhaps applied to all changes might use an internal revision number, perhaps
skipping to change at page 74, line 34 skipping to change at page 75, line 20
representation content, a combination of various file attributes, or representation content, a combination of various file attributes, or
a modification timestamp that has sub-second resolution. a modification timestamp that has sub-second resolution.
An origin server SHOULD send an ETag for any selected representation An origin server SHOULD send an ETag for any selected representation
for which detection of changes can be reasonably and consistently for which detection of changes can be reasonably and consistently
determined, since the entity-tag's use in conditional requests and determined, since the entity-tag's use in conditional requests and
evaluating cache freshness ([Caching]) can result in a substantial evaluating cache freshness ([Caching]) can result in a substantial
reduction of HTTP network traffic and can be a significant factor in reduction of HTTP network traffic and can be a significant factor in
improving service scalability and reliability. improving service scalability and reliability.
8.9.3.2. Comparison 8.8.3.2. Comparison
There are two entity-tag comparison functions, depending on whether There are two entity-tag comparison functions, depending on whether
or not the comparison context allows the use of weak validators: or not the comparison context allows the use of weak validators:
_Strong comparison_: two entity-tags are equivalent if both are not _Strong comparison_: two entity-tags are equivalent if both are not
weak and their opaque-tags match character-by-character. weak and their opaque-tags match character-by-character.
_Weak comparison_: two entity-tags are equivalent if their opaque- _Weak comparison_: two entity-tags are equivalent if their opaque-
tags match character-by-character, regardless of either or both tags match character-by-character, regardless of either or both
being tagged as "weak". being tagged as "weak".
skipping to change at page 75, line 16 skipping to change at page 75, line 46
ETag 1 ETag 2 Strong Comparison Weak Comparison ETag 1 ETag 2 Strong Comparison Weak Comparison
-------- -------- ------------------- ----------------- -------- -------- ------------------- -----------------
W/"1" W/"1" no match match W/"1" W/"1" no match match
W/"1" W/"2" no match no match W/"1" W/"2" no match no match
W/"1" "1" no match match W/"1" "1" no match match
"1" "1" match match "1" "1" match match
-------- -------- ------------------- ----------------- -------- -------- ------------------- -----------------
Table 3 Table 3
8.9.3.3. Example: Entity-Tags Varying on Content-Negotiated Resources 8.8.3.3. Example: Entity-Tags Varying on Content-Negotiated Resources
Consider a resource that is subject to content negotiation Consider a resource that is subject to content negotiation
(Section 12), and where the representations sent in response to a GET (Section 12), and where the representations sent in response to a GET
request vary based on the Accept-Encoding request header field request vary based on the Accept-Encoding request header field
(Section 12.5.3): (Section 12.5.3):
>> Request: >> Request:
GET /index HTTP/1.1 GET /index HTTP/1.1
Host: www.example.com Host: www.example.com
skipping to change at page 76, line 23 skipping to change at page 77, line 5
...binary data... ...binary data...
| *Note:* Content codings are a property of the representation | *Note:* Content codings are a property of the representation
| data, so a strong entity-tag for a content-encoded | data, so a strong entity-tag for a content-encoded
| representation has to be distinct from the entity tag of an | representation has to be distinct from the entity tag of an
| unencoded representation to prevent potential conflicts during | unencoded representation to prevent potential conflicts during
| cache updates and range requests. In contrast, transfer | cache updates and range requests. In contrast, transfer
| codings (Section 7 of [Messaging]) apply only during message | codings (Section 7 of [Messaging]) apply only during message
| transfer and do not result in distinct entity-tags. | transfer and do not result in distinct entity-tags.
8.9.4. When to Use Entity-Tags and Last-Modified Dates 8.8.4. When to Use Entity-Tags and Last-Modified Dates
In 200 (OK) responses to GET or HEAD, an origin server: In 200 (OK) responses to GET or HEAD, an origin server:
o SHOULD send an entity-tag validator unless it is not feasible to o SHOULD send an entity-tag validator unless it is not feasible to
generate one. generate one.
o MAY send a weak entity-tag instead of a strong entity-tag, if o MAY send a weak entity-tag instead of a strong entity-tag, if
performance considerations support the use of weak entity-tags, or performance considerations support the use of weak entity-tags, or
if it is unfeasible to send a strong entity-tag. if it is unfeasible to send a strong entity-tag.
skipping to change at page 78, line 11 skipping to change at page 79, line 11
This specification defines a number of standardized methods that are This specification defines a number of standardized methods that are
commonly used in HTTP, as outlined by the following table. commonly used in HTTP, as outlined by the following table.
--------- -------------------------------------------- ------- --------- -------------------------------------------- -------
Method Description Ref. Method Description Ref.
--------- -------------------------------------------- ------- --------- -------------------------------------------- -------
GET Transfer a current representation of the 9.3.1 GET Transfer a current representation of the 9.3.1
target resource. target resource.
HEAD Same as GET, but do not transfer the 9.3.2 HEAD Same as GET, but do not transfer the 9.3.2
response payload. response content.
POST Perform resource-specific processing on 9.3.3 POST Perform resource-specific processing on 9.3.3
the request payload. the request content.
PUT Replace all current representations of the 9.3.4 PUT Replace all current representations of the 9.3.4
target resource with the request payload. target resource with the request content.
DELETE Remove all current representations of the 9.3.5 DELETE Remove all current representations of the 9.3.5
target resource. target resource.
CONNECT Establish a tunnel to the server 9.3.6 CONNECT Establish a tunnel to the server 9.3.6
identified by the target resource. identified by the target resource.
OPTIONS Describe the communication options for the 9.3.7 OPTIONS Describe the communication options for the 9.3.7
target resource. target resource.
TRACE Perform a message loop-back test along the 9.3.8 TRACE Perform a message loop-back test along the 9.3.8
path to the target resource. path to the target resource.
--------- -------------------------------------------- ------- --------- -------------------------------------------- -------
skipping to change at page 79, line 6 skipping to change at page 80, line 6
SHOULD respond with the 405 (Method Not Allowed) status code. SHOULD respond with the 405 (Method Not Allowed) status code.
Additional methods, outside the scope of this specification, have Additional methods, outside the scope of this specification, have
been specified for use in HTTP. All such methods ought to be been specified for use in HTTP. All such methods ought to be
registered within the "Hypertext Transfer Protocol (HTTP) Method registered within the "Hypertext Transfer Protocol (HTTP) Method
Registry", as described in Section 16.1. Registry", as described in Section 16.1.
9.2. Common Method Properties 9.2. Common Method Properties
9.2.1. Safe Methods 9.2.1. Safe Methods
Request methods are considered "_safe_" if their defined semantics Request methods are considered _safe_ if their defined semantics are
are essentially read-only; i.e., the client does not request, and essentially read-only; i.e., the client does not request, and does
does not expect, any state change on the origin server as a result of not expect, any state change on the origin server as a result of
applying a safe method to a target resource. Likewise, reasonable applying a safe method to a target resource. Likewise, reasonable
use of a safe method is not expected to cause any harm, loss of use of a safe method is not expected to cause any harm, loss of
property, or unusual burden on the origin server. property, or unusual burden on the origin server.
This definition of safe methods does not prevent an implementation This definition of safe methods does not prevent an implementation
from including behavior that is potentially harmful, that is not from including behavior that is potentially harmful, that is not
entirely read-only, or that causes side effects while invoking a safe entirely read-only, or that causes side effects while invoking a safe
method. What is important, however, is that the client did not method. What is important, however, is that the client did not
request that additional behavior and cannot be held accountable for request that additional behavior and cannot be held accountable for
it. For example, most servers append request information to access it. For example, most servers append request information to access
skipping to change at page 80, line 7 skipping to change at page 81, line 7
parameters, such as "page?do=delete". If the purpose of such a parameters, such as "page?do=delete". If the purpose of such a
resource is to perform an unsafe action, then the resource owner MUST resource is to perform an unsafe action, then the resource owner MUST
disable or disallow that action when it is accessed using a safe disable or disallow that action when it is accessed using a safe
request method. Failure to do so will result in unfortunate side request method. Failure to do so will result in unfortunate side
effects when automated processes perform a GET on every URI reference effects when automated processes perform a GET on every URI reference
for the sake of link maintenance, pre-fetching, building a search for the sake of link maintenance, pre-fetching, building a search
index, etc. index, etc.
9.2.2. Idempotent Methods 9.2.2. Idempotent Methods
A request method is considered "_idempotent_" if the intended effect A request method is considered _idempotent_ if the intended effect on
on the server of multiple identical requests with that method is the the server of multiple identical requests with that method is the
same as the effect for a single such request. Of the request methods same as the effect for a single such request. Of the request methods
defined by this specification, PUT, DELETE, and safe request methods defined by this specification, PUT, DELETE, and safe request methods
are idempotent. are idempotent.
Like the definition of safe, the idempotent property only applies to Like the definition of safe, the idempotent property only applies to
what has been requested by the user; a server is free to log each what has been requested by the user; a server is free to log each
request separately, retain a revision control history, or implement request separately, retain a revision control history, or implement
other non-idempotent side effects for each idempotent request. other non-idempotent side effects for each idempotent request.
Idempotent methods are distinguished because the request can be Idempotent methods are distinguished because the request can be
skipping to change at page 82, line 10 skipping to change at page 83, line 10
files directly. Regardless, only the origin server needs to know how files directly. Regardless, only the origin server needs to know how
each of its resource identifiers corresponds to an implementation and each of its resource identifiers corresponds to an implementation and
how each implementation manages to select and send a current how each implementation manages to select and send a current
representation of the target resource in a response to GET. representation of the target resource in a response to GET.
A client can alter the semantics of GET to be a "range request", A client can alter the semantics of GET to be a "range request",
requesting transfer of only some part(s) of the selected requesting transfer of only some part(s) of the selected
representation, by sending a Range header field in the request representation, by sending a Range header field in the request
(Section 14.2). (Section 14.2).
A client SHOULD NOT generate payload data in a GET request. A A client SHOULD NOT generate content in a GET request. Content
payload received in a GET request has no defined semantics, cannot received in a GET request has no defined semantics, cannot alter the
alter the meaning or target of the request, and might lead some meaning or target of the request, and might lead some implementations
implementations to reject the request and close the connection to reject the request and close the connection because of its
because of its potential as a request smuggling attack (Section 11.2 potential as a request smuggling attack (Section 11.2 of
of [Messaging]). [Messaging]).
The response to a GET request is cacheable; a cache MAY use it to The response to a GET request is cacheable; a cache MAY use it to
satisfy subsequent GET and HEAD requests unless otherwise indicated satisfy subsequent GET and HEAD requests unless otherwise indicated
by the Cache-Control header field (Section 5.2 of [Caching]). A by the Cache-Control header field (Section 5.2 of [Caching]).
cache that receives a payload in a GET request is likely to ignore
that payload and cache regardless of the payload contents.
When information retrieval is performed with a mechanism that When information retrieval is performed with a mechanism that
constructs a target URI from user-provided information, such as the constructs a target URI from user-provided information, such as the
query fields of a form using GET, potentially sensitive data might be query fields of a form using GET, potentially sensitive data might be
provided that would not be appropriate for disclosure within a URI provided that would not be appropriate for disclosure within a URI
(see Section 17.9). In some cases, the data can be filtered or (see Section 17.9). In some cases, the data can be filtered or
transformed such that it would not reveal such information. In transformed such that it would not reveal such information. In
others, particularly when there is no benefit from caching a others, particularly when there is no benefit from caching a
response, using the POST method (Section 9.3.3) instead of GET can response, using the POST method (Section 9.3.3) instead of GET can
transmit such information in the request payload rather than within transmit such information in the request content rather than within
the target URI. the target URI.
9.3.2. HEAD 9.3.2. HEAD
The HEAD method is identical to GET except that the server MUST NOT The HEAD method is identical to GET except that the server MUST NOT
send payload data in the response and the response always terminates send content in the response and the response always terminates at
at the end of the header section. HEAD is used to obtain metadata the end of the header section. HEAD is used to obtain metadata about
about the selected representation without transferring its the selected representation without transferring its representation
representation data, often for the sake of testing hypertext links or data, often for the sake of testing hypertext links or finding recent
finding recent modifications. modifications.
The server SHOULD send the same header fields in response to a HEAD The server SHOULD send the same header fields in response to a HEAD
request as it would have sent if the request method had been GET. request as it would have sent if the request method had been GET.
However, a server MAY omit header fields for which a value is However, a server MAY omit header fields for which a value is
determined only while generating the payload data. For example, some determined only while generating the content. For example, some
servers buffer a dynamic response to GET until a minimum amount of servers buffer a dynamic response to GET until a minimum amount of
data is generated so that they can more efficiently delimit small data is generated so that they can more efficiently delimit small
responses or make late decisions with regard to content selection. responses or make late decisions with regard to content selection.
Such a response to GET might contain Content-Length and Vary fields, Such a response to GET might contain Content-Length and Vary fields,
for example, that are not generated within a HEAD response. These for example, that are not generated within a HEAD response. These
minor inconsistencies are considered preferable to generating and minor inconsistencies are considered preferable to generating and
discarding the payload data for a HEAD request, since HEAD is usually discarding the content for a HEAD request, since HEAD is usually
requested for the sake of efficiency. requested for the sake of efficiency.
A payload within a HEAD request message has no defined semantics; A content within a HEAD request message has no defined semantics;
sending payload data in a HEAD request might cause some existing sending content in a HEAD request might cause some existing
implementations to reject the request. implementations to reject the request.
The response to a HEAD request is cacheable; a cache MAY use it to The response to a HEAD request is cacheable; a cache MAY use it to
satisfy subsequent HEAD requests unless otherwise indicated by the satisfy subsequent HEAD requests unless otherwise indicated by the
Cache-Control header field (Section 5.2 of [Caching]). A HEAD Cache-Control header field (Section 5.2 of [Caching]). A HEAD
response might also affect previously cached responses to GET; see response might also affect previously cached responses to GET; see
Section 4.3.5 of [Caching]. Section 4.3.5 of [Caching].
9.3.3. POST 9.3.3. POST
skipping to change at page 84, line 15 skipping to change at page 85, line 8
If one or more resources has been created on the origin server as a If one or more resources has been created on the origin server as a
result of successfully processing a POST request, the origin server result of successfully processing a POST request, the origin server
SHOULD send a 201 (Created) response containing a Location header SHOULD send a 201 (Created) response containing a Location header
field that provides an identifier for the primary resource created field that provides an identifier for the primary resource created
(Section 10.2.3) and a representation that describes the status of (Section 10.2.3) and a representation that describes the status of
the request while referring to the new resource(s). the request while referring to the new resource(s).
Responses to POST requests are only cacheable when they include Responses to POST requests are only cacheable when they include
explicit freshness information (see Section 4.2.1 of [Caching]) and a explicit freshness information (see Section 4.2.1 of [Caching]) and a
Content-Location header field that has the same value as the POST's Content-Location header field that has the same value as the POST's
target URI (Section 8.8). A cached POST response can be reused to target URI (Section 8.7). A cached POST response can be reused to
satisfy a later GET or HEAD request, but not a POST request, since satisfy a later GET or HEAD request, but not a POST request, since
POST is required to be written through to the origin server, because POST is required to be written through to the origin server, because
it is unsafe; see Section 4 of [Caching]. it is unsafe; see Section 4 of [Caching].
If the result of processing a POST would be equivalent to a If the result of processing a POST would be equivalent to a
representation of an existing resource, an origin server MAY redirect representation of an existing resource, an origin server MAY redirect
the user agent to that resource by sending a 303 (See Other) response the user agent to that resource by sending a 303 (See Other) response
with the existing resource's identifier in the Location field. This with the existing resource's identifier in the Location field. This
has the benefits of providing the user agent a resource identifier has the benefits of providing the user agent a resource identifier
and transferring the representation via a method more amenable to and transferring the representation via a method more amenable to
shared caching, though at the cost of an extra request if the user shared caching, though at the cost of an extra request if the user
agent does not already have the representation cached. agent does not already have the representation cached.
9.3.4. PUT 9.3.4. PUT
The PUT method requests that the state of the target resource be The PUT method requests that the state of the target resource be
created or replaced with the state defined by the representation created or replaced with the state defined by the representation
enclosed in the request message payload. A successful PUT of a given enclosed in the request message content. A successful PUT of a given
representation would suggest that a subsequent GET on that same representation would suggest that a subsequent GET on that same
target resource will result in an equivalent representation being target resource will result in an equivalent representation being
sent in a 200 (OK) response. However, there is no guarantee that sent in a 200 (OK) response. However, there is no guarantee that
such a state change will be observable, since the target resource such a state change will be observable, since the target resource
might be acted upon by other user agents in parallel, or might be might be acted upon by other user agents in parallel, or might be
subject to dynamic processing by the origin server, before any subject to dynamic processing by the origin server, before any
subsequent GET is received. A successful response only implies that subsequent GET is received. A successful response only implies that
the user agent's intent was achieved at the time of its processing by the user agent's intent was achieved at the time of its processing by
the origin server. the origin server.
skipping to change at page 86, line 5 skipping to change at page 86, line 44
intentionally hidden by the server. intentionally hidden by the server.
This extends to how header and trailer fields are stored; while This extends to how header and trailer fields are stored; while
common header fields like Content-Type will typically be stored and common header fields like Content-Type will typically be stored and
returned upon subsequent GET requests, header and trailer field returned upon subsequent GET requests, header and trailer field
handling is specific to the resource that received the request. As a handling is specific to the resource that received the request. As a
result, an origin server SHOULD ignore unrecognized header and result, an origin server SHOULD ignore unrecognized header and
trailer fields received in a PUT request (i.e., do not save them as trailer fields received in a PUT request (i.e., do not save them as
part of the resource state). part of the resource state).
An origin server MUST NOT send a validator field (Section 8.9), such An origin server MUST NOT send a validator field (Section 8.8), such
as an ETag or Last-Modified field, in a successful response to PUT as an ETag or Last-Modified field, in a successful response to PUT
unless the request's representation data was saved without any unless the request's representation data was saved without any
transformation applied to the payload data (i.e., the resource's new transformation applied to the content (i.e., the resource's new
representation data is identical to the payload data received in the representation data is identical to the content received in the PUT
PUT request) and the validator field value reflects the new request) and the validator field value reflects the new
representation. This requirement allows a user agent to know when representation. This requirement allows a user agent to know when
the representation it has in memory remains current as a result of the representation it has in memory remains current as a result of
the PUT, thus not in need of being retrieved again from the origin the PUT, thus not in need of being retrieved again from the origin
server, and that the new validator(s) received in the response can be server, and that the new validator(s) received in the response can be
used for future conditional requests in order to prevent accidental used for future conditional requests in order to prevent accidental
overwrites (Section 13.1). overwrites (Section 13.1).
The fundamental difference between the POST and PUT methods is The fundamental difference between the POST and PUT methods is
highlighted by the different intent for the enclosed representation. highlighted by the different intent for the enclosed representation.
The target resource in a POST request is intended to handle the The target resource in a POST request is intended to handle the
skipping to change at page 86, line 48 skipping to change at page 87, line 39
A PUT request applied to the target resource can have side effects on A PUT request applied to the target resource can have side effects on
other resources. For example, an article might have a URI for other resources. For example, an article might have a URI for
identifying "the current version" (a resource) that is separate from identifying "the current version" (a resource) that is separate from
the URIs identifying each particular version (different resources the URIs identifying each particular version (different resources
that at one point shared the same state as the current version that at one point shared the same state as the current version
resource). A successful PUT request on "the current version" URI resource). A successful PUT request on "the current version" URI
might therefore create a new version resource in addition to changing might therefore create a new version resource in addition to changing
the state of the target resource, and might also cause links to be the state of the target resource, and might also cause links to be
added between the related resources. added between the related resources.
An origin server that allows PUT on a given target resource MUST send Some origin servers support use of the Content-Range header field
a 400 (Bad Request) response to a PUT request that contains a (Section 14.4) as a request modifier to perform a partial PUT, as
Content-Range header field (Section 14.4), since the payload is described in Section 14.5.
likely to be partial content that has been mistakenly PUT as a full
representation. Partial content updates are possible by targeting a
separately identified resource with state that overlaps a portion of
the larger resource, or by using a different method that has been
specifically defined for partial updates (for example, the PATCH
method defined in [RFC5789]).
Responses to the PUT method are not cacheable. If a successful PUT Responses to the PUT method are not cacheable. If a successful PUT
request passes through a cache that has one or more stored responses request passes through a cache that has one or more stored responses
for the target URI, those stored responses will be invalidated (see for the target URI, those stored responses will be invalidated (see
Section 4.4 of [Caching]). Section 4.4 of [Caching]).
9.3.5. DELETE 9.3.5. DELETE
The DELETE method requests that the origin server remove the The DELETE method requests that the origin server remove the
association between the target resource and its current association between the target resource and its current
skipping to change at page 88, line 11 skipping to change at page 88, line 48
o a 202 (Accepted) status code if the action will likely succeed but o a 202 (Accepted) status code if the action will likely succeed but
has not yet been enacted, has not yet been enacted,
o a 204 (No Content) status code if the action has been enacted and o a 204 (No Content) status code if the action has been enacted and
no further information is to be supplied, or no further information is to be supplied, or
o a 200 (OK) status code if the action has been enacted and the o a 200 (OK) status code if the action has been enacted and the
response message includes a representation describing the status. response message includes a representation describing the status.
A client SHOULD NOT generate a payload in a DELETE request. A A client SHOULD NOT generate content in a DELETE request. Content
payload received in a DELETE request has no defined semantics, cannot received in a DELETE request has no defined semantics, cannot alter
alter the meaning or target of the request, and might lead some the meaning or target of the request, and might lead some
implementations to reject the request. implementations to reject the request.
Responses to the DELETE method are not cacheable. If a successful Responses to the DELETE method are not cacheable. If a successful
DELETE request passes through a cache that has one or more stored DELETE request passes through a cache that has one or more stored
responses for the target URI, those stored responses will be responses for the target URI, those stored responses will be
invalidated (see Section 4.4 of [Caching]). invalidated (see Section 4.4 of [Caching]).
9.3.6. CONNECT 9.3.6. CONNECT
The CONNECT method requests that the recipient establish a tunnel to The CONNECT method requests that the recipient establish a tunnel to
skipping to change at page 89, line 38 skipping to change at page 90, line 32
the reserved port for SMTP traffic; if allowed, that could trick the the reserved port for SMTP traffic; if allowed, that could trick the
proxy into relaying spam email. Proxies that support CONNECT SHOULD proxy into relaying spam email. Proxies that support CONNECT SHOULD
restrict its use to a limited set of known ports or a configurable restrict its use to a limited set of known ports or a configurable
whitelist of safe request targets. whitelist of safe request targets.
A server MUST NOT send any Transfer-Encoding or Content-Length header A server MUST NOT send any Transfer-Encoding or Content-Length header
fields in a 2xx (Successful) response to CONNECT. A client MUST fields in a 2xx (Successful) response to CONNECT. A client MUST
ignore any Content-Length or Transfer-Encoding header fields received ignore any Content-Length or Transfer-Encoding header fields received
in a successful response to CONNECT. in a successful response to CONNECT.
A payload within a CONNECT request message has no defined semantics; Content within a CONNECT request message has no defined semantics;
sending payload data in a CONNECT request might cause some existing sending content in a CONNECT request might cause some existing
implementations to reject the request. implementations to reject the request.
Responses to the CONNECT method are not cacheable. Responses to the CONNECT method are not cacheable.
9.3.7. OPTIONS 9.3.7. OPTIONS
The OPTIONS method requests information about the communication The OPTIONS method requests information about the communication
options available for the target resource, at either the origin options available for the target resource, at either the origin
server or an intervening intermediary. This method allows a client server or an intervening intermediary. This method allows a client
to determine the options and/or requirements associated with a to determine the options and/or requirements associated with a
skipping to change at page 90, line 30 skipping to change at page 91, line 21
to test a proxy for HTTP/1.1 conformance (or lack thereof). to test a proxy for HTTP/1.1 conformance (or lack thereof).
If the request target is not an asterisk, the OPTIONS request applies If the request target is not an asterisk, the OPTIONS request applies
to the options that are available when communicating with the target to the options that are available when communicating with the target
resource. resource.
A server generating a successful response to OPTIONS SHOULD send any A server generating a successful response to OPTIONS SHOULD send any
header that might indicate optional features implemented by the header that might indicate optional features implemented by the
server and applicable to the target resource (e.g., Allow), including server and applicable to the target resource (e.g., Allow), including
potential extensions not defined by this specification. The response potential extensions not defined by this specification. The response
payload, if any, might also describe the communication options in a content, if any, might also describe the communication options in a
machine or human-readable representation. A standard format for such machine or human-readable representation. A standard format for such
a representation is not defined by this specification, but might be a representation is not defined by this specification, but might be
defined by future extensions to HTTP. defined by future extensions to HTTP.
A client MAY send a Max-Forwards header field in an OPTIONS request A client MAY send a Max-Forwards header field in an OPTIONS request
to target a specific recipient in the request chain (see to target a specific recipient in the request chain (see
Section 7.6.2). A proxy MUST NOT generate a Max-Forwards header Section 7.6.2). A proxy MUST NOT generate a Max-Forwards header
field while forwarding a request unless that request was received field while forwarding a request unless that request was received
with a Max-Forwards field. with a Max-Forwards field.
A client that generates an OPTIONS request containing payload data A client that generates an OPTIONS request containing content MUST
MUST send a valid Content-Type header field describing the send a valid Content-Type header field describing the representation
representation media type. Note that this specification does not media type. Note that this specification does not define any use for
define any use for such a payload. such content.
Responses to the OPTIONS method are not cacheable. Responses to the OPTIONS method are not cacheable.
9.3.8. TRACE 9.3.8. TRACE
The TRACE method requests a remote, application-level loop-back of The TRACE method requests a remote, application-level loop-back of
the request message. The final recipient of the request SHOULD the request message. The final recipient of the request SHOULD
reflect the message received, excluding some fields described below, reflect the message received, excluding some fields described below,
back to the client as the payload data of a 200 (OK) response with a back to the client as the content of a 200 (OK) response with a
Content-Type of "message/http" (Section 10.1 of [Messaging]). The Content-Type of "message/http" (Section 10.1 of [Messaging]). The
final recipient is either the origin server or the first server to final recipient is either the origin server or the first server to
receive a Max-Forwards value of zero (0) in the request receive a Max-Forwards value of zero (0) in the request
(Section 7.6.2). (Section 7.6.2).
A client MUST NOT generate fields in a TRACE request containing A client MUST NOT generate fields in a TRACE request containing
sensitive data that might be disclosed by the response. For example, sensitive data that might be disclosed by the response. For example,
it would be foolish for a user agent to send stored user credentials it would be foolish for a user agent to send stored user credentials
(Section 11) or cookies [RFC6265] in a TRACE request. The final (Section 11) or cookies [RFC6265] in a TRACE request. The final
recipient of the request SHOULD exclude any request fields that are recipient of the request SHOULD exclude any request fields that are
likely to contain sensitive data when that recipient generates the likely to contain sensitive data when that recipient generates the
response payload. response content.
TRACE allows the client to see what is being received at the other TRACE allows the client to see what is being received at the other
end of the request chain and use that data for testing or diagnostic end of the request chain and use that data for testing or diagnostic
information. The value of the Via header field (Section 7.6.3) is of information. The value of the Via header field (Section 7.6.3) is of
particular interest, since it acts as a trace of the request chain. particular interest, since it acts as a trace of the request chain.
Use of the Max-Forwards header field allows the client to limit the Use of the Max-Forwards header field allows the client to limit the
length of the request chain, which is useful for testing a chain of length of the request chain, which is useful for testing a chain of
proxies forwarding messages in an infinite loop. proxies forwarding messages in an infinite loop.
A client MUST NOT send payload data in a TRACE request. A client MUST NOT send content in a TRACE request.
Responses to the TRACE method are not cacheable. Responses to the TRACE method are not cacheable.
10. Message Context 10. Message Context
10.1. Request Context Fields 10.1. Request Context Fields
The request header fields below provide additional information about The request header fields below provide additional information about
the request context, including information about the user, user the request context, including information about the user, user
agent, and resource behind the request. agent, and resource behind the request.
skipping to change at page 92, line 16 skipping to change at page 92, line 49
The only expectation defined by this specification is "100-continue" The only expectation defined by this specification is "100-continue"
(with no defined parameters). (with no defined parameters).
A server that receives an Expect field value containing a member A server that receives an Expect field value containing a member
other than 100-continue MAY respond with a 417 (Expectation Failed) other than 100-continue MAY respond with a 417 (Expectation Failed)
status code to indicate that the unexpected expectation cannot be status code to indicate that the unexpected expectation cannot be
met. met.
A _100-continue_ expectation informs recipients that the client is A _100-continue_ expectation informs recipients that the client is
about to send a (presumably large) payload in this request and wishes about to send (presumably large) content in this request and wishes
to receive a 100 (Continue) interim response if the method, target to receive a 100 (Continue) interim response if the method, target
URI, and header fields are not sufficient to cause an immediate URI, and header fields are not sufficient to cause an immediate
success, redirect, or error response. This allows the client to wait success, redirect, or error response. This allows the client to wait
for an indication that it is worthwhile to send the payload data for an indication that it is worthwhile to send the content before
before actually doing so, which can improve efficiency when the data actually doing so, which can improve efficiency when the data is huge
is huge or when the client anticipates that an error is likely (e.g., or when the client anticipates that an error is likely (e.g., when
when sending a state-changing method, for the first time, without sending a state-changing method, for the first time, without
previously verified authentication credentials). previously verified authentication credentials).
For example, a request that begins with For example, a request that begins with
PUT /somewhere/fun HTTP/1.1 PUT /somewhere/fun HTTP/1.1
Host: origin.example.com Host: origin.example.com
Content-Type: video/h264 Content-Type: video/h264
Content-Length: 1234567890987 Content-Length: 1234567890987
Expect: 100-continue Expect: 100-continue
allows the origin server to immediately respond with an error allows the origin server to immediately respond with an error
message, such as 401 (Unauthorized) or 405 (Method Not Allowed), message, such as 401 (Unauthorized) or 405 (Method Not Allowed),
before the client starts filling the pipes with an unnecessary data before the client starts filling the pipes with an unnecessary data
transfer. transfer.
Requirements for clients: Requirements for clients:
o A client MUST NOT generate a 100-continue expectation in a request o A client MUST NOT generate a 100-continue expectation in a request
that does not include payload data. that does not include content.
o A client that will wait for a 100 (Continue) response before o A client that will wait for a 100 (Continue) response before
sending the request payload data MUST send an Expect header field sending the request content MUST send an Expect header field
containing a 100-continue expectation. containing a 100-continue expectation.
o A client that sends a 100-continue expectation is not required to o A client that sends a 100-continue expectation is not required to
wait for any specific length of time; such a client MAY proceed to wait for any specific length of time; such a client MAY proceed to
send the payload even if it has not yet received a response. send the content even if it has not yet received a response.
Furthermore, since 100 (Continue) responses cannot be sent through Furthermore, since 100 (Continue) responses cannot be sent through
an HTTP/1.0 intermediary, such a client SHOULD NOT wait for an an HTTP/1.0 intermediary, such a client SHOULD NOT wait for an
indefinite period before sending the payload. indefinite period before sending the content.
o A client that receives a 417 (Expectation Failed) status code in o A client that receives a 417 (Expectation Failed) status code in
response to a request containing a 100-continue expectation SHOULD response to a request containing a 100-continue expectation SHOULD
repeat that request without a 100-continue expectation, since the repeat that request without a 100-continue expectation, since the
417 response merely indicates that the response chain does not 417 response merely indicates that the response chain does not
support expectations (e.g., it passes through an HTTP/1.0 server). support expectations (e.g., it passes through an HTTP/1.0 server).
Requirements for servers: Requirements for servers:
o A server that receives a 100-continue expectation in an HTTP/1.0 o A server that receives a 100-continue expectation in an HTTP/1.0
request MUST ignore that expectation. request MUST ignore that expectation.
o A server MAY omit sending a 100 (Continue) response if it has o A server MAY omit sending a 100 (Continue) response if it has
already received some or all of the payload for the corresponding already received some or all of the content for the corresponding
request, or if the framing indicates that there is no payload. request, or if the framing indicates that there is no content.
o A server that sends a 100 (Continue) response MUST ultimately send o A server that sends a 100 (Continue) response MUST ultimately send
a final status code, once the payload is received and processed, a final status code, once the request content is received and
unless the connection is closed prematurely. processed, unless the connection is closed prematurely.
o A server that responds with a final status code before reading the o A server that responds with a final status code before reading the
entire request payload SHOULD indicate whether it intends to close entire request content SHOULD indicate whether it intends to close
the connection (e.g., see Section 9.6 of [Messaging]) or continue the connection (e.g., see Section 9.6 of [Messaging]) or continue
reading the request payload. reading the request content.
An origin server MUST, upon receiving an HTTP/1.1 (or later) request An origin server MUST, upon receiving an HTTP/1.1 (or later) request
that has a method, target URI, and complete header section that that has a method, target URI, and complete header section that
contains a 100-continue expectation and indicates a request payload contains a 100-continue expectation and an indication that request
will follow, either send an immediate response with a final status content will follow, either send an immediate response with a final
code, if that status can be determined by examining just the method, status code, if that status can be determined by examining just the
target URI, and header fields, or send an immediate 100 (Continue) method, target URI, and header fields, or send an immediate 100
response to encourage the client to send the request payload. The (Continue) response to encourage the client to send the request
origin server MUST NOT wait for the payload before sending the 100 content. The origin server MUST NOT wait for the content before
(Continue) response. sending the 100 (Continue) response.
A proxy MUST, upon receiving an HTTP/1.1 (or later) request that has A proxy MUST, upon receiving an HTTP/1.1 (or later) request that has
a method, target URI, and complete header section that contains a a method, target URI, and complete header section that contains a
100-continue expectation and indicates a request payload will follow, 100-continue expectation and indicates a request content will follow,
either send an immediate response with a final status code, if that either send an immediate response with a final status code, if that
status can be determined by examining just the method, target URI, status can be determined by examining just the method, target URI,
and header fields, or begin forwarding the request toward the origin and header fields, or begin forwarding the request toward the origin
server by sending a corresponding request-line and header section to server by sending a corresponding request-line and header section to
the next inbound server. If the proxy believes (from configuration the next inbound server. If the proxy believes (from configuration
or past interaction) that the next inbound server only supports or past interaction) that the next inbound server only supports
HTTP/1.0, the proxy MAY generate an immediate 100 (Continue) response HTTP/1.0, the proxy MAY generate an immediate 100 (Continue) response
to encourage the client to begin sending the payload. to encourage the client to begin sending the content.
10.1.2. From 10.1.2. From
The "From" header field contains an Internet email address for a The "From" header field contains an Internet email address for a
human user who controls the requesting user agent. The address ought human user who controls the requesting user agent. The address ought
to be machine-usable, as defined by "mailbox" in Section 3.4 of to be machine-usable, as defined by "mailbox" in Section 3.4 of
[RFC5322]: [RFC5322]:
From = mailbox From = mailbox
skipping to change at page 96, line 6 skipping to change at page 96, line 36
when the field value shares the same scheme and host as the target when the field value shares the same scheme and host as the target
URI. URI.
10.1.4. TE 10.1.4. TE
The "TE" header field in a request can be used to indicate that the The "TE" header field in a request can be used to indicate that the
sender will not discard trailer fields when it contains a "trailers" sender will not discard trailer fields when it contains a "trailers"
member, as described in Section 6.5. member, as described in Section 6.5.
Additionally, specific HTTP versions can use it to indicate the Additionally, specific HTTP versions can use it to indicate the
transfer codings the client is willing to accept in the response. transfer codings the client is willing to accept in the response. As
of publication, only HTTP/1.1 uses transfer codings (see Section 7 of
[Messaging]).
The TE field value consists of a list of tokens, each allowing for The TE field value consists of a list of tokens, each allowing for
optional parameters (except for the special case "trailers"). optional parameters (except for the special case "trailers").
TE = #t-codings TE = #t-codings
t-codings = "trailers" / ( transfer-coding [ weight ] ) t-codings = "trailers" / ( transfer-coding [ weight ] )
transfer-coding = token *( OWS ";" OWS transfer-parameter ) transfer-coding = token *( OWS ";" OWS transfer-parameter )
transfer-parameter = token BWS "=" BWS ( token / quoted-string ) transfer-parameter = token BWS "=" BWS ( token / quoted-string )
10.1.5. Trailer 10.1.5. Trailer
The "Trailer" header field provides a list of field names that the The "Trailer" header field provides a list of field names that the
sender anticipates sending as trailer fields within that message. sender anticipates sending as trailer fields within that message.
This allows a recipient to prepare for receipt of the indicated This allows a recipient to prepare for receipt of the indicated
metadata before it starts processing the payload. metadata before it starts processing the content.
Trailer = #field-name Trailer = #field-name
For example, a sender might indicate that a message integrity check For example, a sender might indicate that a message integrity check
will be computed as the payload is being streamed and provide the will be computed as the content is being streamed and provide the
final signature as a trailer field. This allows a recipient to final signature as a trailer field. This allows a recipient to
perform the same check on the fly as the payload data is received. perform the same check on the fly as the content is received.
A sender that intends to generate one or more trailer fields in a A sender that intends to generate one or more trailer fields in a
message SHOULD generate a Trailer header field in the header section message SHOULD generate a Trailer header field in the header section
of that message to indicate which fields might be present in the of that message to indicate which fields might be present in the
trailers. trailers.
10.1.6. User-Agent 10.1.6. User-Agent
The "User-Agent" header field contains information about the user The "User-Agent" header field contains information about the user
agent originating the request, which is often used by servers to help agent originating the request, which is often used by servers to help
skipping to change at page 99, line 8 skipping to change at page 99, line 45
Date = HTTP-date Date = HTTP-date
An example is An example is
Date: Tue, 15 Nov 1994 08:12:31 GMT Date: Tue, 15 Nov 1994 08:12:31 GMT
When a Date header field is generated, the sender SHOULD generate its When a Date header field is generated, the sender SHOULD generate its
field value as the best available approximation of the date and time field value as the best available approximation of the date and time
of message generation. In theory, the date ought to represent the of message generation. In theory, the date ought to represent the
moment just before the payload is generated. In practice, the date moment just before the content is generated. In practice, the date
can be generated at any time during message origination. can be generated at any time during message origination.
An origin server MUST NOT send a Date header field if it does not An origin server MUST NOT send a Date header field if it does not
have a clock capable of providing a reasonable approximation of the have a clock capable of providing a reasonable approximation of the
current instance in Coordinated Universal Time. An origin server MAY current instance in Coordinated Universal Time. An origin server MAY
send a Date header field if the response is in the 1xx send a Date header field if the response is in the 1xx
(Informational) or 5xx (Server Error) class of status codes. An (Informational) or 5xx (Server Error) class of status codes. An
origin server MUST send a Date header field in all other cases. origin server MUST send a Date header field in all other cases.
A recipient with a clock that receives a response message without a A recipient with a clock that receives a response message without a
Date header field MUST record the time it was received and append a Date header field MUST record the time it was received and append a
corresponding Date header field to the message's header section if it corresponding Date header field to the message's header section if it
is cached or forwarded downstream. is cached or forwarded downstream.
A recipient with a clock that receives a response with an invalid
Date header field value MAY replace that value with the time that
response was received.
A user agent MAY send a Date header field in a request, though A user agent MAY send a Date header field in a request, though
generally will not do so unless it is believed to convey useful generally will not do so unless it is believed to convey useful
information to the server. For example, custom applications of HTTP information to the server. For example, custom applications of HTTP
might convey a Date if the server is expected to adjust its might convey a Date if the server is expected to adjust its
interpretation of the user's request based on differences between the interpretation of the user's request based on differences between the
user agent and server clocks. user agent and server clocks.
10.2.3. Location 10.2.3. Location
The "Location" header field is used in some responses to refer to a The "Location" header field is used in some responses to refer to a
skipping to change at page 100, line 46 skipping to change at page 101, line 40
| fields that are not valid URI references. This specification | fields that are not valid URI references. This specification
| does not mandate or define such processing, but does allow it | does not mandate or define such processing, but does allow it
| for the sake of robustness. A Location field value cannot | for the sake of robustness. A Location field value cannot
| allow a list of members because the comma list separator is a | allow a list of members because the comma list separator is a
| valid data character within a URI-reference. If an invalid | valid data character within a URI-reference. If an invalid
| message is sent with multiple Location field lines, a recipient | message is sent with multiple Location field lines, a recipient
| along the path might combine those field lines into one value. | along the path might combine those field lines into one value.
| Recovery of a valid Location field value from that situation is | Recovery of a valid Location field value from that situation is
| difficult and not interoperable across implementations. | difficult and not interoperable across implementations.
| *Note:* The Content-Location header field (Section 8.8) differs | *Note:* The Content-Location header field (Section 8.7) differs
| from Location in that the Content-Location refers to the most | from Location in that the Content-Location refers to the most
| specific resource corresponding to the enclosed representation. | specific resource corresponding to the enclosed representation.
| It is therefore possible for a response to contain both the | It is therefore possible for a response to contain both the
| Location and Content-Location header fields. | Location and Content-Location header fields.
10.2.4. Retry-After 10.2.4. Retry-After
Servers send the "Retry-After" header field to indicate how long the Servers send the "Retry-After" header field to indicate how long the
user agent ought to wait before making a follow-up request. When user agent ought to wait before making a follow-up request. When
sent with a 503 (Service Unavailable) response, Retry-After indicates sent with a 503 (Service Unavailable) response, Retry-After indicates
skipping to change at page 104, line 51 skipping to change at page 105, line 51
encapsulation, and with additional header fields specifying encapsulation, and with additional header fields specifying
authentication information. However, such additional mechanisms are authentication information. However, such additional mechanisms are
not defined by this specification. not defined by this specification.
Note that various custom mechanisms for user authentication use the Note that various custom mechanisms for user authentication use the
Set-Cookie and Cookie header fields, defined in [RFC6265], for Set-Cookie and Cookie header fields, defined in [RFC6265], for
passing tokens related to authentication. passing tokens related to authentication.
11.5. Establishing a Protection Space (Realm) 11.5. Establishing a Protection Space (Realm)
The "_realm_" authentication parameter is reserved for use by The _realm_ authentication parameter is reserved for use by
authentication schemes that wish to indicate a scope of protection. authentication schemes that wish to indicate a scope of protection.
A _protection space_ is defined by the origin (see Section 4.3.1) of A _protection space_ is defined by the origin (see Section 4.3.1) of
the server being accessed, in combination with the realm value if the server being accessed, in combination with the realm value if
present. These realms allow the protected resources on a server to present. These realms allow the protected resources on a server to
be partitioned into a set of protection spaces, each with its own be partitioned into a set of protection spaces, each with its own
authentication scheme and/or authorization database. The realm value authentication scheme and/or authorization database. The realm value
is a string, generally assigned by the origin server, that can have is a string, generally assigned by the origin server, that can have
additional semantics specific to the authentication scheme. Note additional semantics specific to the authentication scheme. Note
that a response can have multiple challenges with the same auth- that a response can have multiple challenges with the same auth-
skipping to change at page 106, line 43 skipping to change at page 107, line 43
Authorization = credentials Authorization = credentials
If a request is authenticated and a realm specified, the same If a request is authenticated and a realm specified, the same
credentials are presumed to be valid for all other requests within credentials are presumed to be valid for all other requests within
this realm (assuming that the authentication scheme itself does not this realm (assuming that the authentication scheme itself does not
require otherwise, such as credentials that vary according to a require otherwise, such as credentials that vary according to a
challenge value or using synchronized clocks). challenge value or using synchronized clocks).
A proxy forwarding a request MUST NOT modify any Authorization header A proxy forwarding a request MUST NOT modify any Authorization header
fields in that request. See Section 3.4 of [Caching] for details of fields in that request. See Section 3.5 of [Caching] for details of
and requirements pertaining to handling of the Authorization header and requirements pertaining to handling of the Authorization header
field by HTTP caches. field by HTTP caches.
11.6.3. Authentication-Info 11.6.3. Authentication-Info
HTTP authentication schemes can use the Authentication-Info response HTTP authentication schemes can use the Authentication-Info response
field to communicate information after the client's authentication field to communicate information after the client's authentication
credentials have been accepted. This information can include a credentials have been accepted. This information can include a
finalization message from the server (e.g., it can contain the server finalization message from the server (e.g., it can contain the server
authentication). authentication).
skipping to change at page 109, line 13 skipping to change at page 110, line 13
However, when multiple proxies are used within the same However, when multiple proxies are used within the same
administrative domain, such as office and regional caching proxies administrative domain, such as office and regional caching proxies
within a large corporate network, it is common for credentials to be within a large corporate network, it is common for credentials to be
generated by the user agent and passed through the hierarchy until generated by the user agent and passed through the hierarchy until
consumed. Hence, in such a configuration, it will appear as if consumed. Hence, in such a configuration, it will appear as if
Proxy-Authentication-Info is being forwarded because each proxy will Proxy-Authentication-Info is being forwarded because each proxy will
send the same field value. send the same field value.
12. Content Negotiation 12. Content Negotiation
When responses convey payload information, whether indicating a When responses convey content, whether indicating a success or an
success or an error, the origin server often has different ways of error, the origin server often has different ways of representing
representing that information; for example, in different formats, that information; for example, in different formats, languages, or
languages, or encodings. Likewise, different users or user agents encodings. Likewise, different users or user agents might have
might have differing capabilities, characteristics, or preferences differing capabilities, characteristics, or preferences that could
that could influence which representation, among those available, influence which representation, among those available, would be best
would be best to deliver. For this reason, HTTP provides mechanisms to deliver. For this reason, HTTP provides mechanisms for content
for content negotiation. negotiation.
This specification defines three patterns of content negotiation that This specification defines three patterns of content negotiation that
can be made visible within the protocol: "proactive" negotiation, can be made visible within the protocol: "proactive" negotiation,
where the server selects the representation based upon the user where the server selects the representation based upon the user
agent's stated preferences, "reactive" negotiation, where the server agent's stated preferences, "reactive" negotiation, where the server
provides a list of representations for the user agent to choose from, provides a list of representations for the user agent to choose from,
and "request payload" negotiation, where the user agent selects the and "request content" negotiation, where the user agent selects the
representation for a future request based upon the server's stated representation for a future request based upon the server's stated
preferences in past responses. preferences in past responses.
Other patterns of content negotiation include "conditional content", Other patterns of content negotiation include "conditional content",
where the representation consists of multiple parts that are where the representation consists of multiple parts that are
selectively rendered based on user agent parameters, "active selectively rendered based on user agent parameters, "active
content", where the representation contains a script that makes content", where the representation contains a script that makes
additional (more specific) requests based on the user agent additional (more specific) requests based on the user agent
characteristics, and "Transparent Content Negotiation" ([RFC2295]), characteristics, and "Transparent Content Negotiation" ([RFC2295]),
where content selection is performed by an intermediary. These where content selection is performed by an intermediary. These
skipping to change at page 112, line 19 skipping to change at page 113, line 19
caches are used to distribute server load and reduce network usage. caches are used to distribute server load and reduce network usage.
Reactive negotiation suffers from the disadvantages of transmitting a Reactive negotiation suffers from the disadvantages of transmitting a
list of alternatives to the user agent, which degrades user-perceived list of alternatives to the user agent, which degrades user-perceived
latency if transmitted in the header section, and needing a second latency if transmitted in the header section, and needing a second
request to obtain an alternate representation. Furthermore, this request to obtain an alternate representation. Furthermore, this
specification does not define a mechanism for supporting automatic specification does not define a mechanism for supporting automatic
selection, though it does not prevent such a mechanism from being selection, though it does not prevent such a mechanism from being
developed as an extension. developed as an extension.
12.3. Request Payload Negotiation 12.3. Request Content Negotiation
When content negotiation preferences are sent in a server's response, When content negotiation preferences are sent in a server's response,
the listed preferences are called _request payload negotiation_ the listed preferences are called _request content negotiation_
because they intend to influence selection of an appropriate payload because they intend to influence selection of an appropriate content
for subsequent requests to that resource. For example, the Accept for subsequent requests to that resource. For example, the Accept
(Section 12.5.1) and Accept-Encoding (Section 12.5.3) header fields (Section 12.5.1) and Accept-Encoding (Section 12.5.3) header fields
can be sent in a response to indicate preferred media types and can be sent in a response to indicate preferred media types and
content codings for subsequent requests to that resource. content codings for subsequent requests to that resource.
Similarly, Section 3.1 of [RFC5789] defines the "Accept-Patch" Similarly, Section 3.1 of [RFC5789] defines the "Accept-Patch"
response header field which allows discovery of which content types response header field which allows discovery of which content types
are accepted in PATCH requests. are accepted in PATCH requests.
12.4. Content Negotiation Field Features 12.4. Content Negotiation Field Features
skipping to change at page 114, line 13 skipping to change at page 115, line 13
12.5. Content Negotiation Fields 12.5. Content Negotiation Fields
12.5.1. Accept 12.5.1. Accept
The "Accept" header field can be used by user agents to specify their The "Accept" header field can be used by user agents to specify their
preferences regarding response media types. For example, Accept preferences regarding response media types. For example, Accept
header fields can be used to indicate that the request is header fields can be used to indicate that the request is
specifically limited to a small set of desired types, as in the case specifically limited to a small set of desired types, as in the case
of a request for an in-line image. of a request for an in-line image.
When sent by a server in a response, Accept provides information When sent by a server in a response, Accept provides information
about what content types are preferred in the payload of a subsequent about what content types are preferred in the content of a subsequent
request to the same resource. request to the same resource.
Accept = #( media-range [ accept-params ] ) Accept = #( media-range [ weight ] )
media-range = ( "*/*" media-range = ( "*/*"
/ ( type "/" "*" ) / ( type "/" "*" )
/ ( type "/" subtype ) / ( type "/" subtype )
) parameters ) parameters
accept-params = weight *( accept-ext )
accept-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ]
The asterisk "*" character is used to group media types into ranges, The asterisk "*" character is used to group media types into ranges,
with "*/*" indicating all media types and "type/*" indicating all with "*/*" indicating all media types and "type/*" indicating all
subtypes of that type. The media-range can include media type subtypes of that type. The media-range can include media type
parameters that are applicable to that range. parameters that are applicable to that range.
Each media-range might be followed by zero or more applicable media Each media-range might be followed by optional applicable media type
type parameters (e.g., charset), an optional "q" parameter for parameters (e.g., charset), followed by an optional "q" parameter for
indicating a relative weight (Section 12.4.2), and then zero or more indicating a relative weight (Section 12.4.2).
extension parameters. The "q" parameter is necessary if any
extensions (accept-ext) are present, since it acts as a separator
between the two parameter sets.
| *Note:* Use of the "q" parameter name to separate media type Previous specifications allowed additional extension parameters to
| parameters from Accept extension parameters is due to appear after the weight parameter. The accept extension grammar
| historical practice. Although this prevents any media type (accept-ext) has been removed because it had a complicated
| parameter named "q" from being used with a media range, such an definition, was not being used in practice, and is more easily
| event is believed to be unlikely given the lack of any "q" deployed through new header fields. Senders using weights SHOULD
| parameters in the IANA media type registry and the rare usage send "q" last (after all media-range parameters). Recipients SHOULD
| of any media type parameters in Accept. Future media types are process any parameter named "q" as weight, regardless of parameter
| discouraged from registering any parameter named "q". ordering.
The example | *Note:* Use of the "q" parameter name to control content
| negotiation is due to historical practice. Although this
| prevents any media type parameter named "q" from being used
| with a media range, such an event is believed to be unlikely
| given the lack of any "q" parameters in the IANA media type
| registry and the rare usage of any media type parameters in
| Accept. Future media types are discouraged from registering
| any parameter named "q".
The example
Accept: audio/*; q=0.2, audio/basic Accept: audio/*; q=0.2, audio/basic
is interpreted as "I prefer audio/basic, but send me any audio type is interpreted as "I prefer audio/basic, but send me any audio type
if it is the best available after an 80% markdown in quality". if it is the best available after an 80% markdown in quality".
A more elaborate example is A more elaborate example is
Accept: text/plain; q=0.5, text/html, Accept: text/plain; q=0.5, text/html,
text/x-dvi; q=0.8, text/x-c text/x-dvi; q=0.8, text/x-c
skipping to change at page 116, line 22 skipping to change at page 117, line 35
The "Accept-Charset" header field can be sent by a user agent to The "Accept-Charset" header field can be sent by a user agent to
indicate its preferences for charsets in textual response content. indicate its preferences for charsets in textual response content.
For example, this field allows user agents capable of understanding For example, this field allows user agents capable of understanding
more comprehensive or special-purpose charsets to signal that more comprehensive or special-purpose charsets to signal that
capability to an origin server that is capable of representing capability to an origin server that is capable of representing
information in those charsets. information in those charsets.
Accept-Charset = #( ( charset / "*" ) [ weight ] ) Accept-Charset = #( ( charset / "*" ) [ weight ] )
Charset names are defined in Section 8.4.2. A user agent MAY Charset names are defined in Section 8.3.2. A user agent MAY
associate a quality value with each charset to indicate the user's associate a quality value with each charset to indicate the user's
relative preference for that charset, as defined in Section 12.4.2. relative preference for that charset, as defined in Section 12.4.2.
An example is An example is
Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
The special value "*", if present in the Accept-Charset header field, The special value "*", if present in the Accept-Charset header field,
matches every charset that is not mentioned elsewhere in the field. matches every charset that is not mentioned elsewhere in the field.
| *Note:* Accept-Charset is deprecated because UTF-8 has become | *Note:* Accept-Charset is deprecated because UTF-8 has become
| nearly ubiquitous and sending a detailed list of user-preferred | nearly ubiquitous and sending a detailed list of user-preferred
| charsets wastes bandwidth, increases latency, and makes passive | charsets wastes bandwidth, increases latency, and makes passive
| fingerprinting far too easy (Section 17.12). Most general- | fingerprinting far too easy (Section 17.12). Most general-
| purpose user agents do not send Accept-Charset, unless | purpose user agents do not send Accept-Charset, unless
| specifically configured to do so. | specifically configured to do so.
12.5.3. Accept-Encoding 12.5.3. Accept-Encoding
The "Accept-Encoding" header field can be used to indicate The "Accept-Encoding" header field can be used to indicate
preferences regarding the use of content codings (Section 8.5.1). preferences regarding the use of content codings (Section 8.4.1).
When sent by a user agent in a request, Accept-Encoding indicates the When sent by a user agent in a request, Accept-Encoding indicates the
content codings acceptable in a response. content codings acceptable in a response.
When sent by a server in a response, Accept-Encoding provides When sent by a server in a response, Accept-Encoding provides
information about what content codings are preferred in the payload information about what content codings are preferred in the content
of a subsequent request to the same resource. of a subsequent request to the same resource.
An "identity" token is used as a synonym for "no encoding" in order An "identity" token is used as a synonym for "no encoding" in order
to communicate when no encoding is preferred. to communicate when no encoding is preferred.
Accept-Encoding = #( codings [ weight ] ) Accept-Encoding = #( codings [ weight ] )
codings = content-coding / "identity" / "*" codings = content-coding / "identity" / "*"
Each codings value MAY be given an associated quality value Each codings value MAY be given an associated quality value
representing the preference for that encoding, as defined in representing the preference for that encoding, as defined in
skipping to change at page 118, line 24 skipping to change at page 119, line 39
media types. In order to avoid confusion with issues related to media types. In order to avoid confusion with issues related to
media types, servers that fail a request with a 415 status for media types, servers that fail a request with a 415 status for
reasons unrelated to content codings MUST NOT include the Accept- reasons unrelated to content codings MUST NOT include the Accept-
Encoding header field. Encoding header field.
The most common use of Accept-Encoding is in responses with a 415 The most common use of Accept-Encoding is in responses with a 415
(Unsupported Media Type) status code, in response to optimistic use (Unsupported Media Type) status code, in response to optimistic use
of a content coding by clients. However, the header field can also of a content coding by clients. However, the header field can also
be used to indicate to clients that content codings are supported, to be used to indicate to clients that content codings are supported, to
optimize future interactions. For example, a resource might include optimize future interactions. For example, a resource might include
it in a 2xx (Successful) response when the request payload was big it in a 2xx (Successful) response when the request content was big
enough to justify use of a compression coding but the client failed enough to justify use of a compression coding but the client failed
do so. do so.
| *Note:* Most HTTP/1.0 applications do not recognize or obey | *Note:* Most HTTP/1.0 applications do not recognize or obey
| qvalues associated with content-codings. This means that | qvalues associated with content-codings. This means that
| qvalues might not work and are not permitted with x-gzip or | qvalues might not work and are not permitted with x-gzip or
| x-compress. | x-compress.
12.5.4. Accept-Language 12.5.4. Accept-Language
The "Accept-Language" header field can be used by user agents to The "Accept-Language" header field can be used by user agents to
indicate the set of natural languages that are preferred in the indicate the set of natural languages that are preferred in the
response. Language tags are defined in Section 8.6.1. response. Language tags are defined in Section 8.5.1.
Accept-Language = #( language-range [ weight ] ) Accept-Language = #( language-range [ weight ] )
language-range = language-range =
<language-range, see [RFC4647], Section 2.1> <language-range, see [RFC4647], Section 2.1>
Each language-range can be given an associated quality value Each language-range can be given an associated quality value
representing an estimate of the user's preference for the languages representing an estimate of the user's preference for the languages
specified by that range, as defined in Section 12.4.2. For example, specified by that range, as defined in Section 12.4.2. For example,
Accept-Language: da, en-gb;q=0.8, en;q=0.7 Accept-Language: da, en-gb;q=0.8, en;q=0.7
skipping to change at page 121, line 10 skipping to change at page 122, line 22
Likewise, an origin server might use Cache-Control response Likewise, an origin server might use Cache-Control response
directives (Section 5.2 of [Caching]) to supplant Vary if it directives (Section 5.2 of [Caching]) to supplant Vary if it
considers the variance less significant than the performance cost of considers the variance less significant than the performance cost of
Vary's impact on caching. Vary's impact on caching.
13. Conditional Requests 13. Conditional Requests
A conditional request is an HTTP request with one or more request A conditional request is an HTTP request with one or more request
header fields that indicate a precondition to be tested before header fields that indicate a precondition to be tested before
applying the request method to the target resource. Section 13.2 applying the request method to the target resource. Section 13.2
defines when preconditions are applied. Section 13.3 defines the defines when to evaluate preconditions and their order of precedence
order of evaluation when more than one precondition is present. when more than one precondition is present.
Conditional GET requests are the most efficient mechanism for HTTP Conditional GET requests are the most efficient mechanism for HTTP
cache updates [Caching]. Conditionals can also be applied to state- cache updates [Caching]. Conditionals can also be applied to state-
changing methods, such as PUT and DELETE, to prevent the "lost changing methods, such as PUT and DELETE, to prevent the "lost
update" problem: one client accidentally overwriting the work of update" problem: one client accidentally overwriting the work of
another client that has been acting in parallel. another client that has been acting in parallel.
Conditional request preconditions are based on the state of the Conditional request preconditions are based on the state of the
target resource as a whole (its current value set) or the state as target resource as a whole (its current value set) or the state as
observed in a previously obtained representation (one value in that observed in a previously obtained representation (one value in that
set). A resource might have multiple current representations, each set). A resource might have multiple current representations, each
with its own observable state. The conditional request mechanisms with its own observable state. The conditional request mechanisms
assume that the mapping of requests to a selected representation assume that the mapping of requests to a selected representation
(Section 8) will be consistent over time if the server intends to (Section 3.2) will be consistent over time if the server intends to
take advantage of conditionals. Regardless, if the mapping is take advantage of conditionals. Regardless, if the mapping is
inconsistent and the server is unable to select the appropriate inconsistent and the server is unable to select the appropriate
representation, then no harm will result when the precondition representation, then no harm will result when the precondition
evaluates to false. evaluates to false.
13.1. Preconditions 13.1. Preconditions
The request header fields below allow a client to place a The request header fields below allow a client to place a
precondition on the state of the target resource, so that the action precondition on the state of the target resource, so that the action
corresponding to the method semantics will not be applied if the corresponding to the method semantics will not be applied if the
precondition evaluates to false. Each precondition defined by this precondition evaluates to false. Each precondition defined by this
specification consists of a comparison between a set of validators specification consists of a comparison between a set of validators
obtained from prior representations of the target resource to the obtained from prior representations of the target resource to the
current state of validators for the selected representation current state of validators for the selected representation
(Section 8.9). Hence, these preconditions evaluate whether the state (Section 8.8). Hence, these preconditions evaluate whether the state
of the target resource has changed since a given state known by the of the target resource has changed since a given state known by the
client. The effect of such an evaluation depends on the method client. The effect of such an evaluation depends on the method
semantics and choice of conditional, as defined in Section 13.2. semantics and choice of conditional, as defined in Section 13.2.
13.1.1. If-Match 13.1.1. If-Match
The "If-Match" header field makes the request method conditional on The "If-Match" header field makes the request method conditional on
the recipient origin server either having at least one current the recipient origin server either having at least one current
representation of the target resource, when the field value is "*", representation of the target resource, when the field value is "*",
or having a current representation of the target resource that has an or having a current representation of the target resource that has an
entity-tag matching a member of the list of entity-tags provided in entity-tag matching a member of the list of entity-tags provided in
the field value. the field value.
An origin server MUST use the strong comparison function when An origin server MUST use the strong comparison function when
comparing entity-tags for If-Match (Section 8.9.3.2), since the comparing entity-tags for If-Match (Section 8.8.3.2), since the
client intends this precondition to prevent the method from being client intends this precondition to prevent the method from being
applied if there have been any changes to the representation data. applied if there have been any changes to the representation data.
If-Match = "*" / #entity-tag If-Match = "*" / #entity-tag
Examples: Examples:
If-Match: "xyzzy" If-Match: "xyzzy"
If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-Match: * If-Match: *
skipping to change at page 123, line 34 skipping to change at page 124, line 45
13.1.2. If-None-Match 13.1.2. If-None-Match
The "If-None-Match" header field makes the request method conditional The "If-None-Match" header field makes the request method conditional
on a recipient cache or origin server either not having any current on a recipient cache or origin server either not having any current
representation of the target resource, when the field value is "*", representation of the target resource, when the field value is "*",
or having a selected representation with an entity-tag that does not or having a selected representation with an entity-tag that does not
match any of those listed in the field value. match any of those listed in the field value.
A recipient MUST use the weak comparison function when comparing A recipient MUST use the weak comparison function when comparing
entity-tags for If-None-Match (Section 8.9.3.2), since weak entity- entity-tags for If-None-Match (Section 8.8.3.2), since weak entity-
tags can be used for cache validation even if there have been changes tags can be used for cache validation even if there have been changes
to the representation data. to the representation data.
If-None-Match = "*" / #entity-tag If-None-Match = "*" / #entity-tag
Examples: Examples:
If-None-Match: "xyzzy" If-None-Match: "xyzzy"
If-None-Match: W/"xyzzy" If-None-Match: W/"xyzzy"
If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
skipping to change at page 124, line 31 skipping to change at page 125, line 43
1. If the field value is "*", the condition is false if the origin 1. If the field value is "*", the condition is false if the origin
server has a current representation for the target resource. server has a current representation for the target resource.
2. If the field value is a list of entity-tags, the condition is 2. If the field value is a list of entity-tags, the condition is
false if one of the listed tags matches the entity-tag of the false if one of the listed tags matches the entity-tag of the
selected representation. selected representation.
3. Otherwise, the condition is true. 3. Otherwise, the condition is true.
An origin server MUST NOT perform the requested method if the An origin server MUST NOT perform the requested method if a received
condition evaluates to false; instead, the origin server MUST respond If-None-Match condition evaluates to false; instead, the origin
with either a) the 304 (Not Modified) status code if the request server MUST respond with either a) the 304 (Not Modified) status code
method is GET or HEAD or b) the 412 (Precondition Failed) status code if the request method is GET or HEAD or b) the 412 (Precondition
for all other request methods. Failed) status code for all other request methods.
Requirements on cache handling of a received If-None-Match header Requirements on cache handling of a received If-None-Match header
field are defined in Section 4.3.2 of [Caching]. field are defined in Section 4.3.2 of [Caching].
Note that an If-None-Match header field with a list value containing Note that an If-None-Match header field with a list value containing
"*" and other values (including other instances of "*") is unlikely "*" and other values (including other instances of "*") is unlikely
to be interoperable. to be interoperable.
13.1.3. If-Modified-Since 13.1.3. If-Modified-Since
skipping to change at page 126, line 7 skipping to change at page 127, line 29
window, a user agent will generate an If-Modified-Since field value window, a user agent will generate an If-Modified-Since field value
based on either its own local clock or a Date header field received based on either its own local clock or a Date header field received
from the server in a prior response. Origin servers that choose an from the server in a prior response. Origin servers that choose an
exact timestamp match based on the selected representation's exact timestamp match based on the selected representation's
Last-Modified header field will not be able to help the user agent Last-Modified header field will not be able to help the user agent
limit its data transfers to only those changed during the specified limit its data transfers to only those changed during the specified
window. window.
An origin server that receives an If-Modified-Since header field An origin server that receives an If-Modified-Since header field
SHOULD evaluate the condition as per Section 13.2 prior to performing SHOULD evaluate the condition as per Section 13.2 prior to performing
the method. The origin server SHOULD NOT perform the requested the method.
method if the selected representation's last modification date is
earlier than or equal to the date provided in the field value; To evaluate a received If-Modified-Since header field:
instead, the origin server SHOULD generate a 304 (Not Modified)
response, including only those metadata that are useful for 1. If the selected representation's last modification date is
identifying or updating a previously cached response. earlier or equal to the date provided in the field value, the
condition is false.
2. Otherwise, the condition is true.
An origin server SHOULD NOT perform the requested method if a
received If-Modified-Since condition evaluates to false; instead, the
origin server SHOULD generate a 304 (Not Modified) response,
including only those metadata that are useful for identifying or
updating a previously cached response.
Requirements on cache handling of a received If-Modified-Since header Requirements on cache handling of a received If-Modified-Since header
field are defined in Section 4.3.2 of [Caching]. field are defined in Section 4.3.2 of [Caching].
13.1.4. If-Unmodified-Since 13.1.4. If-Unmodified-Since
The "If-Unmodified-Since" header field makes the request method The "If-Unmodified-Since" header field makes the request method
conditional on the selected representation's last modification date conditional on the selected representation's last modification date
being earlier than or equal to the date provided in the field value. being earlier than or equal to the date provided in the field value.
This field accomplishes the same purpose as If-Match for cases where This field accomplishes the same purpose as If-Match for cases where
skipping to change at page 127, line 6 skipping to change at page 128, line 42
If-Unmodified-Since is most often used with state-changing methods If-Unmodified-Since is most often used with state-changing methods
(e.g., POST, PUT, DELETE) to prevent accidental overwrites when (e.g., POST, PUT, DELETE) to prevent accidental overwrites when
multiple user agents might be acting in parallel on a resource that multiple user agents might be acting in parallel on a resource that
does not supply entity-tags with its representations (i.e., to does not supply entity-tags with its representations (i.e., to
prevent the "lost update" problem). It can also be used with any prevent the "lost update" problem). It can also be used with any
method to abort a request if the selected representation does not method to abort a request if the selected representation does not
match one that the client already stored (or partially stored) from a match one that the client already stored (or partially stored) from a
prior request. prior request.
An origin server that receives an If-Unmodified-Since header field An origin server that receives an If-Unmodified-Since header field
MUST evaluate the condition as per Section 13.2 prior to performing without an If-Match header field MUST evaluate the condition as per
the method. Section 13.2 prior to performing the method.
If the selected representation has a last modification date, the To evaluate a received If-Unmodified-Since header field:
origin server MUST NOT perform the requested method if that date is
more recent than the date provided in the field value. Instead, the 1. If the selected representation's last modification date is
origin server MAY indicate that the conditional request failed by earlier than or equal to the date provided in the field value,
responding with a 412 (Precondition Failed) status code. the condition is true.
Alternatively, if the request is a state-changing operation that
appears to have already been applied to the selected representation, 2. Otherwise, the condition is false.
the origin server MAY respond with a 2xx (Successful) status code
(i.e., the change requested by the user agent has already succeeded, An origin server MUST NOT perform the requested method if an If-
but the user agent might not be aware of it, perhaps because the Unmodified-Since condition evaluates to false. Instead, the origin
prior response was lost or an equivalent change was made by some server MAY indicate that the conditional request failed by responding
other user agent). with a 412 (Precondition Failed) status code. Alternatively, if the
request is a state-changing operation that appears to have already
been applied to the selected representation, the origin server MAY
respond with a 2xx (Successful) status code (i.e., the change
requested by the user agent has already succeeded, but the user agent
might not be aware of it, perhaps because the prior response was lost
or an equivalent change was made by some other user agent).
Allowing an origin server to send a success response when a change Allowing an origin server to send a success response when a change
request appears to have already been applied is more efficient for request appears to have already been applied is more efficient for
many authoring use cases, but comes with some risk if multiple user many authoring use cases, but comes with some risk if multiple user
agents are making change requests that are very similar but not agents are making change requests that are very similar but not
cooperative. In those cases, an origin server is better off being cooperative. In those cases, an origin server is better off being
stringent in sending 412 for every failed precondition on an unsafe stringent in sending 412 for every failed precondition on an unsafe
method. method.
The If-Unmodified-Since header field can be ignored by caches and The If-Unmodified-Since header field can be ignored by caches and
skipping to change at page 128, line 12 skipping to change at page 129, line 51
then have to make a second request to obtain the entire current then have to make a second request to obtain the entire current
representation. representation.
The "If-Range" header field allows a client to "short-circuit" the The "If-Range" header field allows a client to "short-circuit" the
second request. Informally, its meaning is as follows: if the second request. Informally, its meaning is as follows: if the
representation is unchanged, send me the part(s) that I am requesting representation is unchanged, send me the part(s) that I am requesting
in Range; otherwise, send me the entire representation. in Range; otherwise, send me the entire representation.
If-Range = entity-tag / HTTP-date If-Range = entity-tag / HTTP-date
A valid entity-tag can be distinguished from a valid HTTP-date by
examining the first three characters for a DQUOTE.
A client MUST NOT generate an If-Range header field in a request that A client MUST NOT generate an If-Range header field in a request that
does not contain a Range header field. A server MUST ignore an If- does not contain a Range header field. A server MUST ignore an If-
Range header field received in a request that does not contain a Range header field received in a request that does not contain a
Range header field. An origin server MUST ignore an If-Range header Range header field. An origin server MUST ignore an If-Range header
field received in a request for a target resource that does not field received in a request for a target resource that does not
support Range requests. support Range requests.
A client MUST NOT generate an If-Range header field containing an A client MUST NOT generate an If-Range header field containing an
entity-tag that is marked as weak. A client MUST NOT generate an If- entity-tag that is marked as weak. A client MUST NOT generate an If-
Range header field containing an HTTP-date unless the client has no Range header field containing an HTTP-date unless the client has no
entity-tag for the corresponding representation and the date is a entity-tag for the corresponding representation and the date is a
strong validator in the sense defined by Section 8.9.2.2. strong validator in the sense defined by Section 8.8.2.2.
A server that evaluates an If-Range precondition MUST use the strong A server that receives an If-Range header field on a Range request
comparison function when comparing entity-tags (Section 8.9.3.2) and MUST evaluate the condition as per Section 13.2 prior to performing
MUST evaluate the condition as false if an HTTP-date validator is the method.
provided that is not a strong validator in the sense defined by
Section 8.9.2.2. A valid entity-tag can be distinguished from a
valid HTTP-date by examining the first three characters for a DQUOTE.
If the validator given in the If-Range header field matches the To evaluate a received If-Range header field containing an HTTP-date:
current validator for the selected representation of the target
resource, then the server SHOULD process the Range header field as 1. If the HTTP-date validator provided is not a strong validator in
requested. If the validator does not match, the server MUST ignore the sense defined by Section 8.8.2.2, the condition is false.
the Range header field. Note that this comparison by exact match,
including when the validator is an HTTP-date, differs from the 2. If the HTTP-date validator provided exactly matches the
"earlier than or equal to" comparison used when evaluating an Last-Modified field value for the selected representation, the
If-Unmodified-Since conditional. condition is true.
3. Otherwise, the condition is false.
To evaluate a received If-Range header field containing an
entity-tag:
1. If the entity-tag validator provided exactly matches the ETag
field value for the selected representation using the strong
comparison function (Section 8.8.3.2), the condition is true.
2. Otherwise, the condition is false.
A recipient of an If-Range header field MUST ignore the Range header
field if the If-Range condition evaluates to false. Otherwise, the
recipient SHOULD process the Range header field as requested.
Note that the If-Range comparison by exact match, including when the
validator is an HTTP-date, differs from the "earlier than or equal
to" comparison used when evaluating an If-Unmodified-Since
conditional.
13.2. Evaluation of Preconditions 13.2. Evaluation of Preconditions
13.2.1. When to Evaluate
Except when excluded below, a recipient cache or origin server MUST Except when excluded below, a recipient cache or origin server MUST
evaluate received request preconditions after it has successfully evaluate received request preconditions after it has successfully
performed its normal request checks and just before it would process performed its normal request checks and just before it would process
the request payload (if any) or perform the action associated with the request content (if any) or perform the action associated with
the request method. A server MUST ignore all received preconditions the request method. A server MUST ignore all received preconditions
if its response to the same request without those conditions, prior if its response to the same request without those conditions, prior
to processing the request payload, would have been a status code to processing the request content, would have been a status code
other than a 2xx (Successful) or 412 (Precondition Failed). In other other than a 2xx (Successful) or 412 (Precondition Failed). In other
words, redirects and failures that can be detected before significant words, redirects and failures that can be detected before significant
processing occurs take precedence over the evaluation of processing occurs take precedence over the evaluation of
preconditions. preconditions.
A server that is not the origin server for the target resource and A server that is not the origin server for the target resource and
cannot act as a cache for requests on the target resource MUST NOT cannot act as a cache for requests on the target resource MUST NOT
evaluate the conditional request header fields defined by this evaluate the conditional request header fields defined by this
specification, and it MUST forward them if the request is forwarded, specification, and it MUST forward them if the request is forwarded,
since the generating client intends that they be evaluated by a since the generating client intends that they be evaluated by a
skipping to change at page 130, line 5 skipping to change at page 132, line 5
if the recipient understands and implements that field ([RFC4918], if the recipient understands and implements that field ([RFC4918],
Section 10.4). Section 10.4).
Although conditional request header fields are defined as being Although conditional request header fields are defined as being
usable with the HEAD method (to keep HEAD's semantics consistent with usable with the HEAD method (to keep HEAD's semantics consistent with
those of GET), there is no point in sending a conditional HEAD those of GET), there is no point in sending a conditional HEAD
because a successful response is around the same size as a 304 (Not because a successful response is around the same size as a 304 (Not
Modified) response and more useful than a 412 (Precondition Failed) Modified) response and more useful than a 412 (Precondition Failed)
response. response.
13.3. Precedence of Preconditions 13.2.2. Precedence of Preconditions
When more than one conditional request header field is present in a When more than one conditional request header field is present in a
request, the order in which the fields are evaluated becomes request, the order in which the fields are evaluated becomes
important. In practice, the fields defined in this document are important. In practice, the fields defined in this document are
consistently implemented in a single, logical order, since "lost consistently implemented in a single, logical order, since "lost
update" preconditions have more strict requirements than cache update" preconditions have more strict requirements than cache
validation, a validated cache is more efficient than a partial validation, a validated cache is more efficient than a partial
response, and entity tags are presumed to be more accurate than date response, and entity tags are presumed to be more accurate than date
validators. validators.
skipping to change at page 132, line 5 skipping to change at page 134, line 5
14.1. Range Units 14.1. Range Units
Representation data can be partitioned into subranges when there are Representation data can be partitioned into subranges when there are
addressable structural units inherent to that data's content coding addressable structural units inherent to that data's content coding
or media type. For example, octet (a.k.a., byte) boundaries are a or media type. For example, octet (a.k.a., byte) boundaries are a
structural unit common to all representation data, allowing structural unit common to all representation data, allowing
partitions of the data to be identified as a range of bytes at some partitions of the data to be identified as a range of bytes at some
offset from the start or end of that data. offset from the start or end of that data.
This general notion of a "_range unit_" is used in the Accept-Ranges This general notion of a _range unit_ is used in the Accept-Ranges
(Section 14.3) response header field to advertise support for range (Section 14.3) response header field to advertise support for range
requests, the Range (Section 14.2) request header field to delineate requests, the Range (Section 14.2) request header field to delineate
the parts of a representation that are requested, and the the parts of a representation that are requested, and the
Content-Range (Section 14.4) payload header field to describe which Content-Range (Section 14.4) header field to describe which part of a
part of a representation is being transferred. representation is being transferred.
range-unit = token range-unit = token
All range unit names are case-insensitive and ought to be registered All range unit names are case-insensitive and ought to be registered
within the "HTTP Range Unit Registry", as defined in Section 16.5.1 within the "HTTP Range Unit Registry", as defined in Section 16.5.1
Range units are intended to be extensible, as described in Range units are intended to be extensible, as described in
Section 16.5. Section 16.5.
14.1.1. Range Specifiers 14.1.1. Range Specifiers
skipping to change at page 135, line 7 skipping to change at page 137, line 7
first-pos that is less than the current length of the representation, first-pos that is less than the current length of the representation,
or at least one suffix-range with a non-zero suffix-length, then the or at least one suffix-range with a non-zero suffix-length, then the
bytes range-set is satisfiable. Otherwise, the bytes range-set is bytes range-set is satisfiable. Otherwise, the bytes range-set is
unsatisfiable. unsatisfiable.
If the selected representation has zero length, the only satisfiable If the selected representation has zero length, the only satisfiable
form of range-spec is a suffix-range with a non-zero suffix-length. form of range-spec is a suffix-range with a non-zero suffix-length.
In the byte-range syntax, first-pos, last-pos, and suffix-length are In the byte-range syntax, first-pos, last-pos, and suffix-length are
expressed as decimal number of octets. Since there is no predefined expressed as decimal number of octets. Since there is no predefined
limit to the length of a payload, recipients MUST anticipate limit to the length of content, recipients MUST anticipate
potentially large decimal numerals and prevent parsing errors due to potentially large decimal numerals and prevent parsing errors due to
integer conversion overflows. integer conversion overflows.
14.2. Range 14.2. Range
The "Range" header field on a GET request modifies the method The "Range" header field on a GET request modifies the method
semantics to request transfer of only one or more subranges of the semantics to request transfer of only one or more subranges of the
selected representation data (Section 8.2), rather than the entire selected representation data (Section 8.1), rather than the entire
selected representation. selected representation.
Range = ranges-specifier Range = ranges-specifier
A server MAY ignore the Range header field. However, origin servers A server MAY ignore the Range header field. However, origin servers
and intermediate caches ought to support byte ranges when possible, and intermediate caches ought to support byte ranges when possible,
since they support efficient recovery from partially failed transfers since they support efficient recovery from partially failed transfers
and partial retrieval of large representations. and partial retrieval of large representations.
A server MUST ignore a Range header field received with a request A server MUST ignore a Range header field received with a request
skipping to change at page 135, line 43 skipping to change at page 137, line 43
A server that supports range requests MAY ignore or reject a Range A server that supports range requests MAY ignore or reject a Range
header field that consists of more than two overlapping ranges, or a header field that consists of more than two overlapping ranges, or a
set of many small ranges that are not listed in ascending order, set of many small ranges that are not listed in ascending order,
since both are indications of either a broken client or a deliberate since both are indications of either a broken client or a deliberate
denial-of-service attack (Section 17.14). A client SHOULD NOT denial-of-service attack (Section 17.14). A client SHOULD NOT
request multiple ranges that are inherently less efficient to process request multiple ranges that are inherently less efficient to process
and transfer than a single range that encompasses the same data. and transfer than a single range that encompasses the same data.
A server that supports range requests MAY ignore a Range header field A server that supports range requests MAY ignore a Range header field
when the selected representation has no payload data (i.e., the when the selected representation has no content (i.e., the selected
selected representation's data is of zero length). representation's data is of zero length).
A client that is requesting multiple ranges SHOULD list those ranges A client that is requesting multiple ranges SHOULD list those ranges
in ascending order (the order in which they would typically be in ascending order (the order in which they would typically be
received in a complete representation) unless there is a specific received in a complete representation) unless there is a specific
need to request a later part earlier. For example, a user agent need to request a later part earlier. For example, a user agent
processing a large representation with an internal catalog of parts processing a large representation with an internal catalog of parts
might need to request later parts first, particularly if the might need to request later parts first, particularly if the
representation consists of pages stored in reverse order and the user representation consists of pages stored in reverse order and the user
agent wishes to transfer one page at a time. agent wishes to transfer one page at a time.
skipping to change at page 136, line 26 skipping to change at page 138, line 26
absence of the Range header field would be a 200 (OK) response. In absence of the Range header field would be a 200 (OK) response. In
other words, Range is ignored when a conditional GET would result in other words, Range is ignored when a conditional GET would result in
a 304 (Not Modified) response. a 304 (Not Modified) response.
The If-Range header field (Section 13.1.5) can be used as a The If-Range header field (Section 13.1.5) can be used as a
precondition to applying the Range header field. precondition to applying the Range header field.
If all of the preconditions are true, the server supports the Range If all of the preconditions are true, the server supports the Range
header field for the target resource, and the specified range(s) are header field for the target resource, and the specified range(s) are
valid and satisfiable (as defined in Section 14.1.2), the server valid and satisfiable (as defined in Section 14.1.2), the server
SHOULD send a 206 (Partial Content) response with a payload SHOULD send a 206 (Partial Content) response with a content
containing one or more partial representations that correspond to the containing one or more partial representations that correspond to the
satisfiable ranges requested. satisfiable ranges requested.
The above does not imply that a server will send all requested The above does not imply that a server will send all requested
ranges. In some cases, it may only be possible (or efficient) to ranges. In some cases, it may only be possible (or efficient) to
send a portion of the requested ranges first, while expecting the send a portion of the requested ranges first, while expecting the
client to re-request the remaining portions later if they are still client to re-request the remaining portions later if they are still
desired (see Section 15.3.7). desired (see Section 15.3.7).
If all of the preconditions are true, the server supports the Range If all of the preconditions are true, the server supports the Range
skipping to change at page 137, line 20 skipping to change at page 139, line 20
target resource MAY send target resource MAY send
Accept-Ranges: none Accept-Ranges: none
to advise the client not to attempt a range request. to advise the client not to attempt a range request.
14.4. Content-Range 14.4. Content-Range
The "Content-Range" header field is sent in a single part 206 The "Content-Range" header field is sent in a single part 206
(Partial Content) response to indicate the partial range of the (Partial Content) response to indicate the partial range of the
selected representation enclosed as the message payload, sent in each selected representation enclosed as the message content, sent in each
part of a multipart 206 response to indicate the range enclosed part of a multipart 206 response to indicate the range enclosed
within each body part, and sent in 416 (Range Not Satisfiable) within each body part, and sent in 416 (Range Not Satisfiable)
responses to provide information about the selected representation. responses to provide information about the selected representation.
Content-Range = range-unit SP Content-Range = range-unit SP
( range-resp / unsatisfied-range ) ( range-resp / unsatisfied-range )
range-resp = incl-range "/" ( complete-length / "*" ) range-resp = incl-range "/" ( complete-length / "*" )
incl-range = first-pos "-" last-pos incl-range = first-pos "-" last-pos
unsatisfied-range = "*/" complete-length unsatisfied-range = "*/" complete-length
complete-length = 1*DIGIT complete-length = 1*DIGIT
If a 206 (Partial Content) response contains a Content-Range header If a 206 (Partial Content) response contains a Content-Range header
field with a range unit (Section 14.1) that the recipient does not field with a range unit (Section 14.1) that the recipient does not
understand, the recipient MUST NOT attempt to recombine it with a understand, the recipient MUST NOT attempt to recombine it with a
stored representation. A proxy that receives such a message SHOULD stored representation. A proxy that receives such a message SHOULD
forward it downstream. forward it downstream.
Content-Range might also be sent as a request modifier to request a
partial PUT, as described in Section 14.5, based on private
agreements between client and origin server. A server MUST ignore a
Content-Range header field received in a request with a method for
which Content-Range support is not defined.
For byte ranges, a sender SHOULD indicate the complete length of the For byte ranges, a sender SHOULD indicate the complete length of the
representation from which the range has been extracted, unless the representation from which the range has been extracted, unless the
complete length is unknown or difficult to determine. An asterisk complete length is unknown or difficult to determine. An asterisk
character ("*") in place of the complete-length indicates that the character ("*") in place of the complete-length indicates that the
representation length was unknown when the header field was representation length was unknown when the header field was
generated. generated.
The following example illustrates when the complete length of the The following example illustrates when the complete length of the
selected representation is known by the sender to be 1234 bytes: selected representation is known by the sender to be 1234 bytes:
skipping to change at page 139, line 5 skipping to change at page 141, line 5
Content-Range: bytes 500-999/1234 Content-Range: bytes 500-999/1234
o All except for the first 500 bytes: o All except for the first 500 bytes:
Content-Range: bytes 500-1233/1234 Content-Range: bytes 500-1233/1234
o The last 500 bytes: o The last 500 bytes:
Content-Range: bytes 734-1233/1234 Content-Range: bytes 734-1233/1234
14.5. Media Type multipart/byteranges 14.5. Partial PUT
Some origin servers support PUT of a partial representation when a
Content-Range header field (Section 14.4) is sent in the request,
though such support is inconsistent and depends on private agreements
with user agents. In general, it requests that the state of the
target resource be partly replaced with the enclosed content at an
offset and length indicated by the Content-Range value, where the
offset is relative to the current selected representation.
An origin server SHOULD respond with a 400 (Bad Request) status code
if it receives Content-Range on a PUT for a target resource that does
not support partial PUT requests.
Partial PUT is not backwards compatible with the original definition
of PUT. It may result in the content being written as a complete
replacement for the current representation.
Partial resource updates are also possible by targeting a separately
identified resource with state that overlaps or extends a portion of
the larger resource, or by using a different method that has been
specifically defined for partial updates (for example, the PATCH
method defined in [RFC5789]).
14.6. Media Type multipart/byteranges
When a 206 (Partial Content) response message includes the content of When a 206 (Partial Content) response message includes the content of
multiple ranges, they are transmitted as body parts in a multipart multiple ranges, they are transmitted as body parts in a multipart
message body ([RFC2046], Section 5.1) with the media type of message body ([RFC2046], Section 5.1) with the media type of
"multipart/byteranges". "multipart/byteranges".
The multipart/byteranges media type includes one or more body parts, The multipart/byteranges media type includes one or more body parts,
each with its own Content-Type and Content-Range fields. The each with its own Content-Type and Content-Range fields. The
required boundary parameter specifies the boundary string used to required boundary parameter specifies the boundary string used to
separate each body part. separate each body part.
skipping to change at page 140, line 23 skipping to change at page 142, line 50
Optional parameters: N/A Optional parameters: N/A
Encoding considerations: only "7bit", "8bit", or "binary" are Encoding considerations: only "7bit", "8bit", or "binary" are
permitted permitted
Security considerations: see Section 17 Security considerations: see Section 17
Interoperability considerations: N/A Interoperability considerations: N/A
Published specification: This specification (see Section 14.5). Published specification: This specification (see Section 14.6).
Applications that use this media type: HTTP components supporting Applications that use this media type: HTTP components supporting
multiple ranges in a single request. multiple ranges in a single request.
Fragment identifier considerations: N/A Fragment identifier considerations: N/A
Additional information: Deprecated alias names for this type: N/A Additional information: Deprecated alias names for this type: N/A
Magic number(s): N/A Magic number(s): N/A
skipping to change at page 142, line 26 skipping to change at page 144, line 49
15.2. Informational 1xx 15.2. Informational 1xx
The _1xx (Informational)_ class of status code indicates an interim The _1xx (Informational)_ class of status code indicates an interim
response for communicating connection status or request progress response for communicating connection status or request progress
prior to completing the requested action and sending a final prior to completing the requested action and sending a final
response. Since HTTP/1.0 did not define any 1xx status codes, a response. Since HTTP/1.0 did not define any 1xx status codes, a
server MUST NOT send a 1xx response to an HTTP/1.0 client. server MUST NOT send a 1xx response to an HTTP/1.0 client.
A 1xx response is terminated by the end of the header section; it A 1xx response is terminated by the end of the header section; it
cannot contain payload data or trailers. cannot contain content or trailers.
A client MUST be able to parse one or more 1xx responses received A client MUST be able to parse one or more 1xx responses received
prior to a final response, even if the client does not expect one. A prior to a final response, even if the client does not expect one. A
user agent MAY ignore unexpected 1xx responses. user agent MAY ignore unexpected 1xx responses.
A proxy MUST forward 1xx responses unless the proxy itself requested A proxy MUST forward 1xx responses unless the proxy itself requested
the generation of the 1xx response. For example, if a proxy adds an the generation of the 1xx response. For example, if a proxy adds an
"Expect: 100-continue" header field when it forwards a request, then "Expect: 100-continue" header field when it forwards a request, then
it need not forward the corresponding 100 (Continue) response(s). it need not forward the corresponding 100 (Continue) response(s).
15.2.1. 100 Continue 15.2.1. 100 Continue
The _100 (Continue)_ status code indicates that the initial part of a The _100 (Continue)_ status code indicates that the initial part of a
request has been received and has not yet been rejected by the request has been received and has not yet been rejected by the
server. The server intends to send a final response after the server. The server intends to send a final response after the
request has been fully received and acted upon. request has been fully received and acted upon.
When the request contains an Expect header field that includes a When the request contains an Expect header field that includes a
100-continue expectation, the 100 response indicates that the server 100-continue expectation, the 100 response indicates that the server
wishes to receive the request payload, as described in wishes to receive the request content, as described in
Section 10.1.1. The client ought to continue sending the request and Section 10.1.1. The client ought to continue sending the request and
discard the 100 response. discard the 100 response.
If the request did not contain an Expect header field containing the If the request did not contain an Expect header field containing the
100-continue expectation, the client can simply discard this interim 100-continue expectation, the client can simply discard this interim
response. response.
15.2.2. 101 Switching Protocols 15.2.2. 101 Switching Protocols
The _101 (Switching Protocols)_ status code indicates that the server The _101 (Switching Protocols)_ status code indicates that the server
skipping to change at page 143, line 29 skipping to change at page 146, line 8
when delivering resources that use such features. when delivering resources that use such features.
15.3. Successful 2xx 15.3. Successful 2xx
The _2xx (Successful)_ class of status code indicates that the The _2xx (Successful)_ class of status code indicates that the
client's request was successfully received, understood, and accepted. client's request was successfully received, understood, and accepted.
15.3.1. 200 OK 15.3.1. 200 OK
The _200 (OK)_ status code indicates that the request has succeeded. The _200 (OK)_ status code indicates that the request has succeeded.
The payload sent in a 200 response depends on the request method. The content sent in a 200 response depends on the request method.
For the methods defined by this specification, the intended meaning For the methods defined by this specification, the intended meaning
of the payload can be summarized as: of the content can be summarized as:
---------------- -------------------------------------------- ---------------- --------------------------------------------
request method response payload is a representation of request method response content is a representation of
---------------- -------------------------------------------- ---------------- --------------------------------------------
GET the target resource GET the target resource
HEAD the target resource, like GET, but without HEAD the target resource, like GET, but without
transferring the representation data transferring the representation data
POST the status of, or results obtained from, POST the status of, or results obtained from,
the action the action
PUT, DELETE the status of the action PUT, DELETE the status of the action
OPTIONS communication options for the target OPTIONS communication options for the target
resource resource
TRACE the request message as received by the TRACE the request message as received by the
server returning the trace server returning the trace
---------------- -------------------------------------------- ---------------- --------------------------------------------
Table 6 Table 6
Aside from responses to CONNECT, a 200 response always has a payload, Aside from responses to CONNECT, a 200 response always has content,
though an origin server MAY generate payload data of zero length. If though an origin server MAY generate content of zero length. If no
no payload is desired, an origin server ought to send _204 (No content is desired, an origin server ought to send _204 (No Content)_
Content)_ instead. For CONNECT, no payload is allowed because the instead. For CONNECT, no content is allowed because the successful
successful result is a tunnel, which begins immediately after the 200 result is a tunnel, which begins immediately after the 200 response
response header section. header section.
A 200 response is heuristically cacheable; i.e., unless otherwise A 200 response is heuristically cacheable; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [Caching]). Section 4.2.2 of [Caching]).
15.3.2. 201 Created 15.3.2. 201 Created
The _201 (Created)_ status code indicates that the request has been The _201 (Created)_ status code indicates that the request has been
fulfilled and has resulted in one or more new resources being fulfilled and has resulted in one or more new resources being
created. The primary resource created by the request is identified created. The primary resource created by the request is identified
by either a Location header field in the response or, if no Location by either a Location header field in the response or, if no Location
header field is received, by the target URI. header field is received, by the target URI.
The 201 response payload typically describes and links to the The 201 response content typically describes and links to the
resource(s) created. See Section 8.9 for a discussion of the meaning resource(s) created. See Section 8.8 for a discussion of the meaning
and purpose of validator fields, such as ETag and Last-Modified, in a and purpose of validator fields, such as ETag and Last-Modified, in a
201 response. 201 response.
15.3.3. 202 Accepted 15.3.3. 202 Accepted
The _202 (Accepted)_ status code indicates that the request has been The _202 (Accepted)_ status code indicates that the request has been
accepted for processing, but the processing has not been completed. accepted for processing, but the processing has not been completed.
The request might or might not eventually be acted upon, as it might The request might or might not eventually be acted upon, as it might
be disallowed when processing actually takes place. There is no be disallowed when processing actually takes place. There is no
facility in HTTP for re-sending a status code from an asynchronous facility in HTTP for re-sending a status code from an asynchronous
skipping to change at page 145, line 8 skipping to change at page 147, line 26
batch-oriented process that is only run once per day) without batch-oriented process that is only run once per day) without
requiring that the user agent's connection to the server persist requiring that the user agent's connection to the server persist
until the process is completed. The representation sent with this until the process is completed. The representation sent with this
response ought to describe the request's current status and point to response ought to describe the request's current status and point to
(or embed) a status monitor that can provide the user with an (or embed) a status monitor that can provide the user with an
estimate of when the request will be fulfilled. estimate of when the request will be fulfilled.
15.3.4. 203 Non-Authoritative Information 15.3.4. 203 Non-Authoritative Information
The _203 (Non-Authoritative Information)_ status code indicates that The _203 (Non-Authoritative Information)_ status code indicates that
the request was successful but the enclosed payload has been modified the request was successful but the enclosed content has been modified
from that of the origin server's 200 (OK) response by a transforming from that of the origin server's 200 (OK) response by a transforming
proxy (Section 7.7). This status code allows the proxy to notify proxy (Section 7.7). This status code allows the proxy to notify
recipients when a transformation has been applied, since that recipients when a transformation has been applied, since that
knowledge might impact later decisions regarding the content. For knowledge might impact later decisions regarding the content. For
example, future cache validation requests for the content might only example, future cache validation requests for the content might only
be applicable along the same request path (through the same proxies). be applicable along the same request path (through the same proxies).
A 203 response is heuristically cacheable; i.e., unless otherwise A 203 response is heuristically cacheable; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [Caching]). Section 4.2.2 of [Caching]).
15.3.5. 204 No Content 15.3.5. 204 No Content
The _204 (No Content)_ status code indicates that the server has The _204 (No Content)_ status code indicates that the server has
successfully fulfilled the request and that there is no additional successfully fulfilled the request and that there is no additional
content to send in the response payload data. Metadata in the content to send in the response content. Metadata in the response
response header fields refer to the target resource and its selected header fields refer to the target resource and its selected
representation after the requested action was applied. representation after the requested action was applied.
For example, if a 204 status code is received in response to a PUT For example, if a 204 status code is received in response to a PUT
request and the response contains an ETag field, then the PUT was request and the response contains an ETag field, then the PUT was
successful and the ETag field value contains the entity-tag for the successful and the ETag field value contains the entity-tag for the
new representation of that target resource. new representation of that target resource.
The 204 response allows a server to indicate that the action has been The 204 response allows a server to indicate that the action has been
successfully applied to the target resource, while implying that the successfully applied to the target resource, while implying that the
user agent does not need to traverse away from its current "document user agent does not need to traverse away from its current "document
skipping to change at page 145, line 48 skipping to change at page 148, line 20
interface, and apply any new or updated metadata in the response to interface, and apply any new or updated metadata in the response to
its active representation. its active representation.
For example, a 204 status code is commonly used with document editing For example, a 204 status code is commonly used with document editing
interfaces corresponding to a "save" action, such that the document interfaces corresponding to a "save" action, such that the document
being saved remains available to the user for editing. It is also being saved remains available to the user for editing. It is also
frequently used with interfaces that expect automated data transfers frequently used with interfaces that expect automated data transfers
to be prevalent, such as within distributed version control systems. to be prevalent, such as within distributed version control systems.
A 204 response is terminated by the end of the header section; it A 204 response is terminated by the end of the header section; it
cannot contain payload data or trailers. cannot contain content or trailers.
A 204 response is heuristically cacheable; i.e., unless otherwise A 204 response is heuristically cacheable; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [Caching]). Section 4.2.2 of [Caching]).
15.3.6. 205 Reset Content 15.3.6. 205 Reset Content
The _205 (Reset Content)_ status code indicates that the server has The _205 (Reset Content)_ status code indicates that the server has
fulfilled the request and desires that the user agent reset the fulfilled the request and desires that the user agent reset the
"document view", which caused the request to be sent, to its original "document view", which caused the request to be sent, to its original
state as received from the origin server. state as received from the origin server.
This response is intended to support a common data entry use case This response is intended to support a common data entry use case
where the user receives content that supports data entry (a form, where the user receives content that supports data entry (a form,
notepad, canvas, etc.), enters or manipulates data in that space, notepad, canvas, etc.), enters or manipulates data in that space,
causes the entered data to be submitted in a request, and then the causes the entered data to be submitted in a request, and then the
data entry mechanism is reset for the next entry so that the user can data entry mechanism is reset for the next entry so that the user can
easily initiate another input action. easily initiate another input action.
Since the 205 status code implies that no additional content will be Since the 205 status code implies that no additional content will be
provided, a server MUST NOT generate a payload in a 205 response. provided, a server MUST NOT generate content in a 205 response.
15.3.7. 206 Partial Content 15.3.7. 206 Partial Content
The _206 (Partial Content)_ status code indicates that the server is The _206 (Partial Content)_ status code indicates that the server is
successfully fulfilling a range request for the target resource by successfully fulfilling a range request for the target resource by
transferring one or more parts of the selected representation. transferring one or more parts of the selected representation.
A server that supports range requests (Section 14) will usually A server that supports range requests (Section 14) will usually
attempt to satisfy all of the requested ranges, since sending less attempt to satisfy all of the requested ranges, since sending less
data will likely result in another client request for the remainder. data will likely result in another client request for the remainder.
skipping to change at page 146, line 48 skipping to change at page 149, line 20
field(s) to determine what parts are enclosed and whether additional field(s) to determine what parts are enclosed and whether additional
requests are needed. requests are needed.
When a 206 response is generated, the server MUST generate the When a 206 response is generated, the server MUST generate the
following header fields, in addition to those required in the following header fields, in addition to those required in the
subsections below, if the field would have been sent in a 200 (OK) subsections below, if the field would have been sent in a 200 (OK)
response to the same request: Date, Cache-Control, ETag, Expires, response to the same request: Date, Cache-Control, ETag, Expires,
Content-Location, and Vary. Content-Location, and Vary.
A Content-Length header field present in a 206 response indicates the A Content-Length header field present in a 206 response indicates the
number of octets in the payload data of this message, which is number of octets in the content of this message, which is usually not
usually not the complete length of the selected representation. Each the complete length of the selected representation. Each
Content-Range header field includes information about the selected Content-Range header field includes information about the selected
representation's complete length. representation's complete length.
If a 206 is generated in response to a request with an If-Range If a 206 is generated in response to a request with an If-Range
header field, the sender SHOULD NOT generate other representation header field, the sender SHOULD NOT generate other representation
header fields beyond those required, because the client is understood header fields beyond those required, because the client is understood
to already have a prior response containing those header fields. to already have a prior response containing those header fields.
Otherwise, the sender MUST generate all of the representation header Otherwise, the sender MUST generate all of the representation header
fields that would have been sent in a 200 (OK) response to the same fields that would have been sent in a 200 (OK) response to the same
request. request.
A 206 response is heuristically cacheable; i.e., unless otherwise A 206 response is heuristically cacheable; i.e., unless otherwise
indicated by explicit cache controls (see Section 4.2.2 of indicated by explicit cache controls (see Section 4.2.2 of
[Caching]). [Caching]).
15.3.7.1. Single Part 15.3.7.1. Single Part
If a single part is being transferred, the server generating the 206 If a single part is being transferred, the server generating the 206
response MUST generate a Content-Range header field, describing what response MUST generate a Content-Range header field, describing what
range of the selected representation is enclosed, and a payload range of the selected representation is enclosed, and a content
consisting of the range. For example: consisting of the range. For example:
HTTP/1.1 206 Partial Content HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 1995 06:25:24 GMT Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Range: bytes 21010-47021/47022 Content-Range: bytes 21010-47021/47022
Content-Length: 26012 Content-Length: 26012
Content-Type: image/gif Content-Type: image/gif
... 26012 bytes of partial image data ... ... 26012 bytes of partial image data ...
15.3.7.2. Multiple Parts 15.3.7.2. Multiple Parts
If multiple parts are being transferred, the server generating the If multiple parts are being transferred, the server generating the
206 response MUST generate a "multipart/byteranges" payload, as 206 response MUST generate "multipart/byteranges" content, as defined
defined in Section 14.5, and a Content-Type header field containing in Section 14.6, and a Content-Type header field containing the
the multipart/byteranges media type and its required boundary multipart/byteranges media type and its required boundary parameter.
parameter. To avoid confusion with single-part responses, a server To avoid confusion with single-part responses, a server MUST NOT
MUST NOT generate a Content-Range header field in the HTTP header generate a Content-Range header field in the HTTP header section of a
section of a multiple part response (this field will be sent in each multiple part response (this field will be sent in each part
part instead). instead).
Within the header area of each body part in the multipart payload, Within the header area of each body part in the multipart content,
the server MUST generate a Content-Range header field corresponding the server MUST generate a Content-Range header field corresponding
to the range being enclosed in that body part. If the selected to the range being enclosed in that body part. If the selected
representation would have had a Content-Type header field in a 200 representation would have had a Content-Type header field in a 200
(OK) response, the server SHOULD generate that same Content-Type (OK) response, the server SHOULD generate that same Content-Type
header field in the header area of each body part. For example: header field in the header area of each body part. For example:
HTTP/1.1 206 Partial Content HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 1995 06:25:24 GMT Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Length: 1741 Content-Length: 1741
skipping to change at page 148, line 27 skipping to change at page 150, line 45
Content-Type: application/pdf Content-Type: application/pdf
Content-Range: bytes 7000-7999/8000 Content-Range: bytes 7000-7999/8000
...the second range ...the second range
--THIS_STRING_SEPARATES-- --THIS_STRING_SEPARATES--
When multiple ranges are requested, a server MAY coalesce any of the When multiple ranges are requested, a server MAY coalesce any of the
ranges that overlap, or that are separated by a gap that is smaller ranges that overlap, or that are separated by a gap that is smaller
than the overhead of sending multiple parts, regardless of the order than the overhead of sending multiple parts, regardless of the order
in which the corresponding range-spec appeared in the received Range in which the corresponding range-spec appeared in the received Range
header field. Since the typical overhead between parts of a header field. Since the typical overhead between each part of a
multipart/byteranges payload is around 80 bytes, depending on the multipart/byteranges is around 80 bytes, depending on the selected
selected representation's media type and the chosen boundary representation's media type and the chosen boundary parameter length,
parameter length, it can be less efficient to transfer many small it can be less efficient to transfer many small disjoint parts than
disjoint parts than it is to transfer the entire selected it is to transfer the entire selected representation.
representation.
A server MUST NOT generate a multipart response to a request for a A server MUST NOT generate a multipart response to a request for a
single range, since a client that does not request multiple parts single range, since a client that does not request multiple parts
might not support multipart responses. However, a server MAY might not support multipart responses. However, a server MAY
generate a multipart/byteranges payload with only a single body part generate a multipart/byteranges response with only a single body part
if multiple ranges were requested and only one range was found to be if multiple ranges were requested and only one range was found to be
satisfiable or only one range remained after coalescing. A client satisfiable or only one range remained after coalescing. A client
that cannot process a multipart/byteranges response MUST NOT generate that cannot process a multipart/byteranges response MUST NOT generate
a request that asks for multiple ranges. a request that asks for multiple ranges.
When a multipart response payload is generated, the server SHOULD When a multipart response is generated, the server SHOULD send the
send the parts in the same order that the corresponding range-spec parts in the same order that the corresponding range-spec appeared in
appeared in the received Range header field, excluding those ranges the received Range header field, excluding those ranges that were
that were deemed unsatisfiable or that were coalesced into other deemed unsatisfiable or that were coalesced into other ranges. A
ranges. A client that receives a multipart response MUST inspect the client that receives a multipart response MUST inspect the
Content-Range header field present in each body part in order to Content-Range header field present in each body part in order to
determine which range is contained in that body part; a client cannot determine which range is contained in that body part; a client cannot
rely on receiving the same ranges that it requested, nor the same rely on receiving the same ranges that it requested, nor the same
order that it requested. order that it requested.
15.3.7.3. Combining Parts 15.3.7.3. Combining Parts
A response might transfer only a subrange of a representation if the A response might transfer only a subrange of a representation if the
connection closed prematurely or if the request used one or more connection closed prematurely or if the request used one or more
Range specifications. After several such transfers, a client might Range specifications. After several such transfers, a client might
have received several ranges of the same representation. These have received several ranges of the same representation. These
ranges can only be safely combined if they all have in common the ranges can only be safely combined if they all have in common the
same strong validator (Section 8.9.1). same strong validator (Section 8.8.1).
A client that has received multiple partial responses to GET requests A client that has received multiple partial responses to GET requests
on a target resource MAY combine those responses into a larger on a target resource MAY combine those responses into a larger
continuous range if they share the same strong validator. continuous range if they share the same strong validator.
If the most recent response is an incomplete 200 (OK) response, then If the most recent response is an incomplete 200 (OK) response, then
the header fields of that response are used for any combined response the header fields of that response are used for any combined response
and replace those of the matching stored responses. and replace those of the matching stored responses.
If the most recent response is a 206 (Partial Content) response and If the most recent response is a 206 (Partial Content) response and
at least one of the matching stored responses is a 200 (OK), then the at least one of the matching stored responses is a 200 (OK), then the
combined response header fields consist of the most recent 200 combined response header fields consist of the most recent 200
response's header fields. If all of the matching stored responses response's header fields. If all of the matching stored responses
are 206 responses, then the stored response with the most recent are 206 responses, then the stored response with the most recent
header fields is used as the source of header fields for the combined header fields is used as the source of header fields for the combined
response, except that the client MUST use other header fields response, except that the client MUST use other header fields
provided in the new response, aside from Content-Range, to replace provided in the new response, aside from Content-Range, to replace
all instances of the corresponding header fields in the stored all instances of the corresponding header fields in the stored
response. response.
The combined response payload data consists of the union of partial The combined response content consists of the union of partial
content ranges in the new response and each of the selected content ranges in the new response and each of the selected
responses. If the union consists of the entire range of the responses. If the union consists of the entire range of the
representation, then the client MUST process the combined response as representation, then the client MUST process the combined response as
if it were a complete 200 (OK) response, including a Content-Length if it were a complete 200 (OK) response, including a Content-Length
header field that reflects the complete length. Otherwise, the header field that reflects the complete length. Otherwise, the
client MUST process the set of continuous ranges as one of the client MUST process the set of continuous ranges as one of the
following: an incomplete 200 (OK) response if the combined response following: an incomplete 200 (OK) response if the combined response
is a prefix of the representation, a single 206 (Partial Content) is a prefix of the representation, a single 206 (Partial Content)
response containing a multipart/byteranges payload, or multiple 206 response containing multipart/byteranges content, or multiple 206
(Partial Content) responses, each with one continuous range that is (Partial Content) responses, each with one continuous range that is
indicated by a Content-Range header field. indicated by a Content-Range header field.
15.4. Redirection 3xx 15.4. Redirection 3xx
The _3xx (Redirection)_ class of status code indicates that further The _3xx (Redirection)_ class of status code indicates that further
action needs to be taken by the user agent in order to fulfill the action needs to be taken by the user agent in order to fulfill the
request. There are several types of redirects: request. There are several types of redirects:
1. Redirects that indicate this resource might be available at a 1. Redirects that indicate this resource might be available at a
skipping to change at page 152, line 21 skipping to change at page 154, line 34
representation by redirecting its request to one or more of those representation by redirecting its request to one or more of those
identifiers. In other words, the server desires that the user agent identifiers. In other words, the server desires that the user agent
engage in reactive negotiation to select the most appropriate engage in reactive negotiation to select the most appropriate
representation(s) for its needs (Section 12). representation(s) for its needs (Section 12).
If the server has a preferred choice, the server SHOULD generate a If the server has a preferred choice, the server SHOULD generate a
Location header field containing a preferred choice's URI reference. Location header field containing a preferred choice's URI reference.
The user agent MAY use the Location field value for automatic The user agent MAY use the Location field value for automatic
redirection. redirection.
For request methods other than HEAD, the server SHOULD generate a For request methods other than HEAD, the server SHOULD generate
payload in the 300 response containing a list of representation content in the 300 response containing a list of representation
metadata and URI reference(s) from which the user or user agent can metadata and URI reference(s) from which the user or user agent can
choose the one most preferred. The user agent MAY make a selection choose the one most preferred. The user agent MAY make a selection
from that list automatically if it understands the provided media from that list automatically if it understands the provided media
type. A specific format for automatic selection is not defined by type. A specific format for automatic selection is not defined by
this specification because HTTP tries to remain orthogonal to the this specification because HTTP tries to remain orthogonal to the
definition of its payloads. In practice, the representation is definition of its content. In practice, the representation is
provided in some easily parsed format believed to be acceptable to provided in some easily parsed format believed to be acceptable to
the user agent, as determined by shared design or content the user agent, as determined by shared design or content
negotiation, or in some commonly accepted hypertext format. negotiation, or in some commonly accepted hypertext format.
A 300 response is heuristically cacheable; i.e., unless otherwise A 300 response is heuristically cacheable; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [Caching]). Section 4.2.2 of [Caching]).
| *Note:* The original proposal for the 300 status code defined | *Note:* The original proposal for the 300 status code defined
| the URI header field as providing a list of alternative | the URI header field as providing a list of alternative
skipping to change at page 153, line 17 skipping to change at page 155, line 28
The _301 (Moved Permanently)_ status code indicates that the target The _301 (Moved Permanently)_ status code indicates that the target
resource has been assigned a new permanent URI and any future resource has been assigned a new permanent URI and any future
references to this resource ought to use one of the enclosed URIs. references to this resource ought to use one of the enclosed URIs.
Clients with link-editing capabilities ought to automatically re-link Clients with link-editing capabilities ought to automatically re-link
references to the target URI to one or more of the new references references to the target URI to one or more of the new references
sent by the server, where possible. sent by the server, where possible.
The server SHOULD generate a Location header field in the response The server SHOULD generate a Location header field in the response
containing a preferred URI reference for the new permanent URI. The containing a preferred URI reference for the new permanent URI. The
user agent MAY use the Location field value for automatic user agent MAY use the Location field value for automatic
redirection. The server's response payload usually contains a short redirection. The server's response content usually contains a short
hypertext note with a hyperlink to the new URI(s). hypertext note with a hyperlink to the new URI(s).
| *Note:* For historical reasons, a user agent MAY change the | *Note:* For historical reasons, a user agent MAY change the
| request method from POST to GET for the subsequent request. If | request method from POST to GET for the subsequent request. If
| this behavior is undesired, the 308 (Permanent Redirect) status | this behavior is undesired, the 308 (Permanent Redirect) status
| code can be used instead. | code can be used instead.
A 301 response is heuristically cacheable; i.e., unless otherwise A 301 response is heuristically cacheable; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [Caching]). Section 4.2.2 of [Caching]).
skipping to change at page 153, line 39 skipping to change at page 155, line 50
15.4.3. 302 Found 15.4.3. 302 Found
The _302 (Found)_ status code indicates that the target resource The _302 (Found)_ status code indicates that the target resource
resides temporarily under a different URI. Since the redirection resides temporarily under a different URI. Since the redirection
might be altered on occasion, the client ought to continue to use the might be altered on occasion, the client ought to continue to use the
target URI for future requests. target URI for future requests.
The server SHOULD generate a Location header field in the response The server SHOULD generate a Location header field in the response
containing a URI reference for the different URI. The user agent MAY containing a URI reference for the different URI. The user agent MAY
use the Location field value for automatic redirection. The server's use the Location field value for automatic redirection. The server's
response payload usually contains a short hypertext note with a response content usually contains a short hypertext note with a
hyperlink to the different URI(s). hyperlink to the different URI(s).
| *Note:* For historical reasons, a user agent MAY change the | *Note:* For historical reasons, a user agent MAY change the
| request method from POST to GET for the subsequent request. If | request method from POST to GET for the subsequent request. If
| this behavior is undesired, the 307 (Temporary Redirect) status | this behavior is undesired, the 307 (Temporary Redirect) status
| code can be used instead. | code can be used instead.
15.4.4. 303 See Other 15.4.4. 303 See Other
The _303 (See Other)_ status code indicates that the server is The _303 (See Other)_ status code indicates that the server is
skipping to change at page 154, line 49 skipping to change at page 157, line 5
15.4.5. 304 Not Modified 15.4.5. 304 Not Modified
The _304 (Not Modified)_ status code indicates that a conditional GET The _304 (Not Modified)_ status code indicates that a conditional GET
or HEAD request has been received and would have resulted in a 200 or HEAD request has been received and would have resulted in a 200
(OK) response if it were not for the fact that the condition (OK) response if it were not for the fact that the condition
evaluated to false. In other words, there is no need for the server evaluated to false. In other words, there is no need for the server
to transfer a representation of the target resource because the to transfer a representation of the target resource because the
request indicates that the client, which made the request request indicates that the client, which made the request
conditional, already has a valid representation; the server is conditional, already has a valid representation; the server is
therefore redirecting the client to make use of that stored therefore redirecting the client to make use of that stored
representation as if it were the payload of a 200 (OK) response. representation as if it were the content of a 200 (OK) response.
The server generating a 304 response MUST generate any of the The server generating a 304 response MUST generate any of the
following header fields that would have been sent in a 200 (OK) following header fields that would have been sent in a 200 (OK)
response to the same request: Cache-Control, Content-Location, Date, response to the same request: Cache-Control, Content-Location, Date,
ETag, Expires, and Vary. ETag, Expires, and Vary.
Since the goal of a 304 response is to minimize information transfer Since the goal of a 304 response is to minimize information transfer
when the recipient already has one or more cached representations, a when the recipient already has one or more cached representations, a
sender SHOULD NOT generate representation metadata other than the sender SHOULD NOT generate representation metadata other than the
above listed fields unless said metadata exists for the purpose of above listed fields unless said metadata exists for the purpose of
guiding cache updates (e.g., Last-Modified might be useful if the guiding cache updates (e.g., Last-Modified might be useful if the
response does not have an ETag field). response does not have an ETag field).
Requirements on a cache that receives a 304 response are defined in Requirements on a cache that receives a 304 response are defined in
Section 4.3.4 of [Caching]. If the conditional request originated Section 4.3.4 of [Caching]. If the conditional request originated
with an outbound client, such as a user agent with its own cache with an outbound client, such as a user agent with its own cache
sending a conditional GET to a shared proxy, then the proxy SHOULD sending a conditional GET to a shared proxy, then the proxy SHOULD
forward the 304 response to that client. forward the 304 response to that client.
A 304 response is terminated by the end of the header section; it A 304 response is terminated by the end of the header section; it
cannot contain payload data or trailers. cannot contain content or trailers.
15.4.6. 305 Use Proxy 15.4.6. 305 Use Proxy
The _305 (Use Proxy)_ status code was defined in a previous version The _305 (Use Proxy)_ status code was defined in a previous version
of this specification and is now deprecated (Appendix B of of this specification and is now deprecated (Appendix B of
[RFC7231]). [RFC7231]).
15.4.7. 306 (Unused) 15.4.7. 306 (Unused)
The 306 status code was defined in a previous version of this The 306 status code was defined in a previous version of this
skipping to change at page 155, line 49 skipping to change at page 158, line 8
The _307 (Temporary Redirect)_ status code indicates that the target The _307 (Temporary Redirect)_ status code indicates that the target
resource resides temporarily under a different URI and the user agent resource resides temporarily under a different URI and the user agent
MUST NOT change the request method if it performs an automatic MUST NOT change the request method if it performs an automatic
redirection to that URI. Since the redirection can change over time, redirection to that URI. Since the redirection can change over time,
the client ought to continue using the original target URI for future the client ought to continue using the original target URI for future
requests. requests.
The server SHOULD generate a Location header field in the response The server SHOULD generate a Location header field in the response
containing a URI reference for the different URI. The user agent MAY containing a URI reference for the different URI. The user agent MAY
use the Location field value for automatic redirection. The server's use the Location field value for automatic redirection. The server's
response payload usually contains a short hypertext note with a response content usually contains a short hypertext note with a
hyperlink to the different URI(s). hyperlink to the different URI(s).
15.4.9. 308 Permanent Redirect 15.4.9. 308 Permanent Redirect
The _308 (Permanent Redirect)_ status code indicates that the target The _308 (Permanent Redirect)_ status code indicates that the target
resource has been assigned a new permanent URI and any future resource has been assigned a new permanent URI and any future
references to this resource ought to use one of the enclosed URIs. references to this resource ought to use one of the enclosed URIs.
Clients with link editing capabilities ought to automatically re-link Clients with link editing capabilities ought to automatically re-link
references to the target URI to one or more of the new references references to the target URI to one or more of the new references
sent by the server, where possible. sent by the server, where possible.
The server SHOULD generate a Location header field in the response The server SHOULD generate a Location header field in the response
containing a preferred URI reference for the new permanent URI. The containing a preferred URI reference for the new permanent URI. The
user agent MAY use the Location field value for automatic user agent MAY use the Location field value for automatic
redirection. The server's response payload usually contains a short redirection. The server's response content usually contains a short
hypertext note with a hyperlink to the new URI(s). hypertext note with a hyperlink to the new URI(s).
A 308 response is heuristically cacheable; i.e., unless otherwise A 308 response is heuristically cacheable; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [Caching]). Section 4.2.2 of [Caching]).
| *Note:* This status code is much younger (June 2014) than its | *Note:* This status code is much younger (June 2014) than its
| sibling codes, and thus might not be recognized everywhere. | sibling codes, and thus might not be recognized everywhere.
| See Section 4 of [RFC7538] for deployment considerations. | See Section 4 of [RFC7538] for deployment considerations.
skipping to change at page 157, line 23 skipping to change at page 159, line 31
15.5.3. 402 Payment Required 15.5.3. 402 Payment Required
The _402 (Payment Required)_ status code is reserved for future use. The _402 (Payment Required)_ status code is reserved for future use.
15.5.4. 403 Forbidden 15.5.4. 403 Forbidden
The _403 (Forbidden)_ status code indicates that the server The _403 (Forbidden)_ status code indicates that the server
understood the request but refuses to fulfill it. A server that understood the request but refuses to fulfill it. A server that
wishes to make public why the request has been forbidden can describe wishes to make public why the request has been forbidden can describe
that reason in the response payload (if any). that reason in the response content (if any).
If authentication credentials were provided in the request, the If authentication credentials were provided in the request, the
server considers them insufficient to grant access. The client server considers them insufficient to grant access. The client
SHOULD NOT automatically repeat the request with the same SHOULD NOT automatically repeat the request with the same
credentials. The client MAY repeat the request with new or different credentials. The client MAY repeat the request with new or different
credentials. However, a request might be forbidden for reasons credentials. However, a request might be forbidden for reasons
unrelated to the credentials. unrelated to the credentials.
An origin server that wishes to "hide" the current existence of a An origin server that wishes to "hide" the current existence of a
forbidden target resource MAY instead respond with a status code of forbidden target resource MAY instead respond with a status code of
skipping to change at page 158, line 25 skipping to change at page 160, line 29
Section 4.2.2 of [Caching]). Section 4.2.2 of [Caching]).
15.5.7. 406 Not Acceptable 15.5.7. 406 Not Acceptable
The _406 (Not Acceptable)_ status code indicates that the target The _406 (Not Acceptable)_ status code indicates that the target
resource does not have a current representation that would be resource does not have a current representation that would be
acceptable to the user agent, according to the proactive negotiation acceptable to the user agent, according to the proactive negotiation
header fields received in the request (Section 12.1), and the server header fields received in the request (Section 12.1), and the server
is unwilling to supply a default representation. is unwilling to supply a default representation.
The server SHOULD generate a payload containing a list of available The server SHOULD generate content containing a list of available
representation characteristics and corresponding resource identifiers representation characteristics and corresponding resource identifiers
from which the user or user agent can choose the one most from which the user or user agent can choose the one most
appropriate. A user agent MAY automatically select the most appropriate. A user agent MAY automatically select the most
appropriate choice from that list. However, this specification does appropriate choice from that list. However, this specification does
not define any standard for such automatic selection, as described in not define any standard for such automatic selection, as described in
Section 15.4.1. Section 15.4.1.
15.5.8. 407 Proxy Authentication Required 15.5.8. 407 Proxy Authentication Required
The _407 (Proxy Authentication Required)_ status code is similar to The _407 (Proxy Authentication Required)_ status code is similar to
skipping to change at page 159, line 11 skipping to change at page 161, line 16
that request. If the current connection is not usable (e.g., as it that request. If the current connection is not usable (e.g., as it
would be in HTTP/1.1, because request delimitation is lost), a new would be in HTTP/1.1, because request delimitation is lost), a new
connection will be used. connection will be used.
15.5.10. 409 Conflict 15.5.10. 409 Conflict
The _409 (Conflict)_ status code indicates that the request could not The _409 (Conflict)_ status code indicates that the request could not
be completed due to a conflict with the current state of the target be completed due to a conflict with the current state of the target
resource. This code is used in situations where the user might be resource. This code is used in situations where the user might be
able to resolve the conflict and resubmit the request. The server able to resolve the conflict and resubmit the request. The server
SHOULD generate a payload that includes enough information for a user SHOULD generate content that includes enough information for a user
to recognize the source of the conflict. to recognize the source of the conflict.
Conflicts are most likely to occur in response to a PUT request. For Conflicts are most likely to occur in response to a PUT request. For
example, if versioning were being used and the representation being example, if versioning were being used and the representation being
PUT included changes to a resource that conflict with those made by PUT included changes to a resource that conflict with those made by
an earlier (third-party) request, the origin server might use a 409 an earlier (third-party) request, the origin server might use a 409
response to indicate that it can't complete the request. In this response to indicate that it can't complete the request. In this
case, the response representation would likely contain information case, the response representation would likely contain information
useful for merging the differences based on the revision history. useful for merging the differences based on the revision history.
skipping to change at page 159, line 49 skipping to change at page 162, line 9
the discretion of the server owner. the discretion of the server owner.
A 410 response is heuristically cacheable; i.e., unless otherwise A 410 response is heuristically cacheable; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [Caching]). Section 4.2.2 of [Caching]).
15.5.12. 411 Length Required 15.5.12. 411 Length Required
The _411 (Length Required)_ status code indicates that the server The _411 (Length Required)_ status code indicates that the server
refuses to accept the request without a defined Content-Length refuses to accept the request without a defined Content-Length
(Section 8.7). The client MAY repeat the request if it adds a valid (Section 8.6). The client MAY repeat the request if it adds a valid
Content-Length header field containing the length of the request Content-Length header field containing the length of the request
payload data. content.
15.5.13. 412 Precondition Failed 15.5.13. 412 Precondition Failed
The _412 (Precondition Failed)_ status code indicates that one or The _412 (Precondition Failed)_ status code indicates that one or
more conditions given in the request header fields evaluated to false more conditions given in the request header fields evaluated to false
when tested on the server. This response status code allows the when tested on the server. This response status code allows the
client to place preconditions on the current resource state (its client to place preconditions on the current resource state (its
current representations and metadata) and, thus, prevent the request current representations and metadata) and, thus, prevent the request
method from being applied if the target resource is in an unexpected method from being applied if the target resource is in an unexpected
state. state.
15.5.14. 413 Payload Too Large 15.5.14. 413 Content Too Large
The _413 (Payload Too Large)_ status code indicates that the server The _413 (Content Too Large)_ status code indicates that the server
is refusing to process a request because the request payload is is refusing to process a request because the request content is
larger than the server is willing or able to process. The server MAY larger than the server is willing or able to process. The server MAY
terminate the request, if the protocol version in use allows it; terminate the request, if the protocol version in use allows it;
otherwise, the server MAY close the connection. otherwise, the server MAY close the connection.
If the condition is temporary, the server SHOULD generate a If the condition is temporary, the server SHOULD generate a
Retry-After header field to indicate that it is temporary and after Retry-After header field to indicate that it is temporary and after
what time the client MAY try again. what time the client MAY try again.
15.5.15. 414 URI Too Long 15.5.15. 414 URI Too Long
skipping to change at page 160, line 45 skipping to change at page 163, line 8
prefix that points to a suffix of itself) or when the server is under prefix that points to a suffix of itself) or when the server is under
attack by a client attempting to exploit potential security holes. attack by a client attempting to exploit potential security holes.
A 414 response is heuristically cacheable; i.e., unless otherwise A 414 response is heuristically cacheable; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [Caching]). Section 4.2.2 of [Caching]).
15.5.16. 415 Unsupported Media Type 15.5.16. 415 Unsupported Media Type
The _415 (Unsupported Media Type)_ status code indicates that the The _415 (Unsupported Media Type)_ status code indicates that the
origin server is refusing to service the request because the payload origin server is refusing to service the request because the content
is in a format not supported by this method on the target resource. is in a format not supported by this method on the target resource.
The format problem might be due to the request's indicated The format problem might be due to the request's indicated
Content-Type or Content-Encoding, or as a result of inspecting the Content-Type or Content-Encoding, or as a result of inspecting the
data directly. data directly.
If the problem was caused by an unsupported content coding, the If the problem was caused by an unsupported content coding, the
Accept-Encoding response header field (Section 12.5.3) ought to be Accept-Encoding response header field (Section 12.5.3) ought to be
used to indicate what (if any) content codings would have been used to indicate what (if any) content codings would have been
accepted in the request. accepted in the request.
skipping to change at page 161, line 42 skipping to change at page 163, line 52
HTTP/1.1 416 Range Not Satisfiable HTTP/1.1 416 Range Not Satisfiable
Date: Fri, 20 Jan 2012 15:41:54 GMT Date: Fri, 20 Jan 2012 15:41:54 GMT
Content-Range: bytes */47022 Content-Range: bytes */47022
| *Note:* Because servers are free to ignore Range, many | *Note:* Because servers are free to ignore Range, many
| implementations will respond with the entire selected | implementations will respond with the entire selected
| representation in a 200 (OK) response. That is partly because | representation in a 200 (OK) response. That is partly because
| most clients are prepared to receive a 200 (OK) to complete the | most clients are prepared to receive a 200 (OK) to complete the
| task (albeit less efficiently) and partly because clients might | task (albeit less efficiently) and partly because clients might
| not stop making an invalid partial request until they have | not stop making an invalid range request until they have
| received a complete representation. Thus, clients cannot | received a complete representation. Thus, clients cannot
| depend on receiving a 416 (Range Not Satisfiable) response even | depend on receiving a 416 (Range Not Satisfiable) response even
| when it is most appropriate. | when it is most appropriate.
15.5.18. 417 Expectation Failed 15.5.18. 417 Expectation Failed
The _417 (Expectation Failed)_ status code indicates that the The _417 (Expectation Failed)_ status code indicates that the
expectation given in the request's Expect header field expectation given in the request's Expect header field
(Section 10.1.1) could not be met by at least one of the inbound (Section 10.1.1) could not be met by at least one of the inbound
servers. servers.
skipping to change at page 162, line 19 skipping to change at page 164, line 29
418 status code. In the intervening years, this status code has been 418 status code. In the intervening years, this status code has been
widely implemented as an "Easter Egg", and therefore is effectively widely implemented as an "Easter Egg", and therefore is effectively
consumed by this use. consumed by this use.
Therefore, the 418 status code is reserved in the IANA HTTP Status Therefore, the 418 status code is reserved in the IANA HTTP Status
Code Registry. This indicates that the status code cannot be Code Registry. This indicates that the status code cannot be
assigned to other applications currently. If future circumstances assigned to other applications currently. If future circumstances
require its use (e.g., exhaustion of 4NN status codes), it can be re- require its use (e.g., exhaustion of 4NN status codes), it can be re-
assigned to another use. assigned to another use.
15.5.20. 422 Unprocessable Payload 15.5.20. 421 Misdirected Request
The 422 (Unprocessable Payload) status code indicates that the server The 421 (Misdirected Request) status code indicates that the request
understands the content type of the request payload (hence a 415 was directed at a server that is unable or unwilling to produce an
authoritative response for the target URI. A 421 is sent when an
origin server (or gateway acting on behalf of the origin server)
rejects a target URI that does not match an origin for which the
server has been configured (Section 4.3.1) or does not match the
connection context over which the request was received (Section 7.4).
A client that receives a 421 (Misdirected Request) response MAY retry
the request, whether or not the request method is idempotent, over a
different connection, such as a fresh connection specific to the
target resource's origin, or via an alternative service [RFC7838].
A proxy MUST NOT generate a 421 response.
15.5.21. 422 Unprocessable Content
The 422 (Unprocessable Content) status code indicates that the server
understands the content type of the request content (hence a 415
(Unsupported Media Type) status code is inappropriate), and the (Unsupported Media Type) status code is inappropriate), and the
syntax of the request payload is correct, but was unable to process syntax of the request content is correct, but was unable to process
the contained instructions. For example, this status code can be the contained instructions. For example, this status code can be
sent if an XML request payload contains well-formed (i.e., sent if an XML request content contains well-formed (i.e.,
syntactically correct), but semantically erroneous XML instructions. syntactically correct), but semantically erroneous XML instructions.
15.5.21. 426 Upgrade Required 15.5.22. 426 Upgrade Required
The _426 (Upgrade Required)_ status code indicates that the server The _426 (Upgrade Required)_ status code indicates that the server
refuses to perform the request using the current protocol but might refuses to perform the request using the current protocol but might
be willing to do so after the client upgrades to a different be willing to do so after the client upgrades to a different
protocol. The server MUST send an Upgrade header field in a 426 protocol. The server MUST send an Upgrade header field in a 426
response to indicate the required protocol(s) (Section 7.8). response to indicate the required protocol(s) (Section 7.8).
Example: Example:
HTTP/1.1 426 Upgrade Required HTTP/1.1 426 Upgrade Required
skipping to change at page 165, line 24 skipping to change at page 168, line 4
by IANA at <https://www.iana.org/assignments/http-methods>, registers by IANA at <https://www.iana.org/assignments/http-methods>, registers
method names. method names.
HTTP method registrations MUST include the following fields: HTTP method registrations MUST include the following fields:
o Method Name (see Section 9) o Method Name (see Section 9)
o Safe ("yes" or "no", see Section 9.2.1) o Safe ("yes" or "no", see Section 9.2.1)
o Idempotent ("yes" or "no", see Section 9.2.2) o Idempotent ("yes" or "no", see Section 9.2.2)
o Pointer to specification text o Pointer to specification text
Values to be added to this namespace require IETF Review (see Values to be added to this namespace require IETF Review (see
[RFC8126], Section 4.8). [RFC8126], Section 4.8).
16.1.2. Considerations for New Methods 16.1.2. Considerations for New Methods
Standardized methods are generic; that is, they are potentially Standardized methods are generic; that is, they are potentially
applicable to any resource, not just one particular media type, kind applicable to any resource, not just one particular media type, kind
of resource, or application. As such, it is preferred that new of resource, or application. As such, it is preferred that new
methods be registered in a document that isn't specific to a single methods be registered in a document that isn't specific to a single
application or data format, since orthogonal technologies deserve application or data format, since orthogonal technologies deserve
orthogonal specification. orthogonal specification.
Since message parsing (Section 6 of [Messaging]) needs to be Since message parsing (Section 6 of [Messaging]) needs to be
independent of method semantics (aside from responses to HEAD), independent of method semantics (aside from responses to HEAD),
definitions of new methods cannot change the parsing algorithm or definitions of new methods cannot change the parsing algorithm or
prohibit the presence of payload data on either the request or the prohibit the presence of content on either the request or the
response message. Definitions of new methods can specify that only a response message. Definitions of new methods can specify that only a
zero-length payload data is allowed by requiring a Content-Length zero-length content is allowed by requiring a Content-Length header
header field with a value of "0". field with a value of "0".
Likewise, new methods cannot use the special host:port and asterisk
forms of request target that are allowed for CONNECT and OPTIONS,
respectively (Section 7.1). A full URI in absolute form is needed
for the target URI, which means either the request target needs to be
sent in absolute form or the target URI will be reconstructed from
the request context in the same way it is for other methods.
A new method definition needs to indicate whether it is safe A new method definition needs to indicate whether it is safe
(Section 9.2.1), idempotent (Section 9.2.2), cacheable (Section 9.2.1), idempotent (Section 9.2.2), cacheable
(Section 9.2.3), what semantics are to be associated with the request (Section 9.2.3), what semantics are to be associated with the request
payload (if any), and what refinements the method makes to header content (if any), and what refinements the method makes to header
field or status code semantics. If the new method is cacheable, its field or status code semantics. If the new method is cacheable, its
definition ought to describe how, and under what conditions, a cache definition ought to describe how, and under what conditions, a cache
can store a response and use it to satisfy a subsequent request. The can store a response and use it to satisfy a subsequent request. The
new method ought to describe whether it can be made conditional new method ought to describe whether it can be made conditional
(Section 13.1) and, if so, how a server responds when the condition (Section 13.1) and, if so, how a server responds when the condition
is false. Likewise, if the new method might have some use for is false. Likewise, if the new method might have some use for
partial response semantics (Section 14.2), it ought to document this, partial response semantics (Section 14.2), it ought to document this,
too. too.
| *Note:* Avoid defining a method name that starts with "M-", | *Note:* Avoid defining a method name that starts with "M-",
skipping to change at page 166, line 46 skipping to change at page 169, line 33
When it is necessary to express semantics for a response that are not When it is necessary to express semantics for a response that are not
defined by current status codes, a new status code can be registered. defined by current status codes, a new status code can be registered.
Status codes are generic; they are potentially applicable to any Status codes are generic; they are potentially applicable to any
resource, not just one particular media type, kind of resource, or resource, not just one particular media type, kind of resource, or
application of HTTP. As such, it is preferred that new status codes application of HTTP. As such, it is preferred that new status codes
be registered in a document that isn't specific to a single be registered in a document that isn't specific to a single
application. application.
New status codes are required to fall under one of the categories New status codes are required to fall under one of the categories
defined in Section 15. To allow existing parsers to process the defined in Section 15. To allow existing parsers to process the
response message, new status codes cannot disallow a payload, response message, new status codes cannot disallow content, although
although they can mandate a zero-length payload data. they can mandate a zero-length content.
Proposals for new status codes that are not yet widely deployed ought Proposals for new status codes that are not yet widely deployed ought
to avoid allocating a specific number for the code until there is to avoid allocating a specific number for the code until there is
clear consensus that it will be registered; instead, early drafts can clear consensus that it will be registered; instead, early drafts can
use a notation such as "4NN", or "3N0" .. "3N9", to indicate the use a notation such as "4NN", or "3N0" .. "3N9", to indicate the
class of the proposed status code(s) without consuming a number class of the proposed status code(s) without consuming a number
prematurely. prematurely.
The definition of a new status code ought to explain the request The definition of a new status code ought to explain the request
conditions that would cause a response containing that status code conditions that would cause a response containing that status code
skipping to change at page 167, line 32 skipping to change at page 170, line 22
The definition of a new status code ought to specify whether or not The definition of a new status code ought to specify whether or not
it is cacheable. Note that all status codes can be cached if the it is cacheable. Note that all status codes can be cached if the
response they occur in has explicit freshness information; however, response they occur in has explicit freshness information; however,
status codes that are defined as being cacheable are allowed to be status codes that are defined as being cacheable are allowed to be
cached without explicit freshness information. Likewise, the cached without explicit freshness information. Likewise, the
definition of a status code can place constraints upon cache definition of a status code can place constraints upon cache
behavior. See [Caching] for more information. behavior. See [Caching] for more information.
Finally, the definition of a new status code ought to indicate Finally, the definition of a new status code ought to indicate
whether the payload has any implied association with an identified whether the content has any implied association with an identified
resource (Section 6.4.2). resource (Section 6.4.2).
16.3. Field Extensibility 16.3. Field Extensibility
HTTP's most widely used extensibility point is the definition of new HTTP's most widely used extensibility point is the definition of new
header and trailer fields. header and trailer fields.
New fields can be defined such that, when they are understood by a New fields can be defined such that, when they are understood by a
recipient, they override or enhance the interpretation of previously recipient, they override or enhance the interpretation of previously
defined fields, define preconditions on request evaluation, or refine defined fields, define preconditions on request evaluation, or refine
skipping to change at page 168, line 14 skipping to change at page 171, line 6
direct inspection of support might be possible through an OPTIONS direct inspection of support might be possible through an OPTIONS
request or by interacting with a defined well-known URI [RFC8615] if request or by interacting with a defined well-known URI [RFC8615] if
such inspection is defined along with the field being introduced. such inspection is defined along with the field being introduced.
16.3.1. Field Name Registry 16.3.1. Field Name Registry
The "Hypertext Transfer Protocol (HTTP) Field Name Registry" defines The "Hypertext Transfer Protocol (HTTP) Field Name Registry" defines
the namespace for HTTP field names. the namespace for HTTP field names.
Any party can request registration of a HTTP field. See Any party can request registration of a HTTP field. See
Section 16.3.3 for considerations to take into account when creating Section 16.3.2 for considerations to take into account when creating
a new HTTP field. a new HTTP field.
The "Hypertext Transfer Protocol (HTTP) Field Name Registry" is The "Hypertext Transfer Protocol (HTTP) Field Name Registry" is
located at <https://www.iana.org/assignments/http-fields/>. located at <https://www.iana.org/assignments/http-fields/>.
Registration requests can be made by following the instructions Registration requests can be made by following the instructions
located there or by sending an email to the "ietf-http-wg@ietf.org" located there or by sending an email to the "ietf-http-wg@ietf.org"
mailing list. mailing list.
Field names are registered on the advice of a Designated Expert Field names are registered on the advice of a Designated Expert
(appointed by the IESG or their delegate). Fields with the status (appointed by the IESG or their delegate). Fields with the status
skipping to change at page 169, line 20 skipping to change at page 172, line 10
Provisional entries can be removed by the Expert(s) if - in Provisional entries can be removed by the Expert(s) if - in
consultation with the community - the Expert(s) find that they are consultation with the community - the Expert(s) find that they are
not in use. The Experts can change a provisional entry's status to not in use. The Experts can change a provisional entry's status to
permanent at any time. permanent at any time.
Note that names can be registered by third parties (including the Note that names can be registered by third parties (including the
Expert(s)), if the Expert(s) determines that an unregistered name is Expert(s)), if the Expert(s) determines that an unregistered name is
widely deployed and not likely to be registered in a timely manner widely deployed and not likely to be registered in a timely manner
otherwise. otherwise.
16.3.2. Considerations for New Field Names 16.3.2. Considerations for New Fields
HTTP header and trailer fields are a widely-used extension point for
the protocol. While they can be used in an ad hoc fashion, fields
that are intended for wider use need to be carefully documented to
ensure interoperability.
In particular, authors of specifications defining new fields are
advised to consider and, where appropriate, document the following
aspects:
o Under what conditions the field can be used; e.g., only in
responses or requests, in all messages, only on responses to a
particular request method, etc.
o Whether the field semantics are further refined by their context,
such as their use with certain request methods or status codes.
o The scope of applicability for the information conveyed. By
default, fields apply only to the message they are associated
with, but some response fields are designed to apply to all
representations of a resource, the resource itself, or an even
broader scope. Specifications that expand the scope of a response
field will need to carefully consider issues such as content
negotiation, the time period of applicability, and (in some cases)
multi-tenant server deployments.
o Under what conditions intermediaries are allowed to insert,
delete, or modify the field's value.
o If the field is allowable in trailers; by default, it will not be
(see Section 6.5.1).
o Whether it is appropriate to list the field name in the Connection
header field (i.e., if the field is to be hop-by-hop; see
Section 7.6.1).
o Whether the field introduces any additional security
considerations, such as disclosure of privacy-related data.
Request header fields have additional considerations that need to be
documented if the default behaviour is not appropriate:
o If it is appropriate to list the field name in a Vary response
header field (e.g., when the request header field is used by an
origin server's content selection algorithm; see Section 12.5.5).
o If the field is intended to be stored when received in a PUT
request (see Section 9.3.4).
o If the field ought to be removed when automatically redirecting a
request, due to security concerns (see Section 15.4).
16.3.2.1. Considerations for New Field Names
Authors of specifications defining new fields are advised to choose a Authors of specifications defining new fields are advised to choose a
short but descriptive field name. Short names avoid needless data short but descriptive field name. Short names avoid needless data
transmission; descriptive names avoid confusion and "squatting" on transmission; descriptive names avoid confusion and "squatting" on
names that might have broader uses. names that might have broader uses.
To that end, limited-use fields (such as a header confined to a To that end, limited-use fields (such as a header confined to a
single application or use case) are encouraged to use a name that single application or use case) are encouraged to use a name that
includes its name (or an abbreviation) as a prefix; for example, if includes that use (or an abbreviation) as a prefix; for example, if
the Foo Application needs a Description field, it might use "Foo- the Foo Application needs a Description field, it might use "Foo-
Desc"; "Description" is too generic, and "Foo-Description" is Desc"; "Description" is too generic, and "Foo-Description" is
needlessly long. needlessly long.
While the field-name syntax is defined to allow any token character, While the field-name syntax is defined to allow any token character,
in practice some implementations place limits on the characters they in practice some implementations place limits on the characters they
accept in field-names. To be interoperable, new field names SHOULD accept in field-names. To be interoperable, new field names SHOULD
constrain themselves to alphanumeric characters, "-", and ".", and constrain themselves to alphanumeric characters, "-", and ".", and
SHOULD begin with an alphanumeric character. SHOULD begin with an alphanumeric character.
Field names ought not be prefixed with "X-"; see [BCP178] for further Field names ought not be prefixed with "X-"; see [BCP178] for further
information. information.
Other prefixes are sometimes used in HTTP field names; for example, Other prefixes are sometimes used in HTTP field names; for example,
"Accept-" is used in many content negotiation headers. These "Accept-" is used in many content negotiation headers. These
prefixes are only an aid to recognizing the purpose of a field, and prefixes are only an aid to recognizing the purpose of a field, and
do not trigger automatic processing. do not trigger automatic processing.
16.3.3. Considerations for New Field Values 16.3.2.2. Considerations for New Field Values
Authors of specifications defining new fields are advised to consider
documenting:
o Whether the field has a singleton or list-based value (see
Section 5.5).
If it is a singleton field, document how to treat messages where
the multiple members are present (a sensible default would be to
ignore the field, but this might not always be the right choice).
Note that intermediaries and software libraries might combine
multiple field lines into a single one, despite the field being
defined as a singleton. A robust format enables recipients to
discover these situations (good example: "Content-Type", as the
comma can only appear inside quoted strings; bad example:
"Location", as a comma can occur inside a URI).
o Under what conditions the field can be used; e.g., only in
responses or requests, in all messages, only on responses to a
particular request method, etc.
o What the scope of applicability for the information conveyed in
the field is. By default, fields apply only to the message they
are associated with, but some response fields are designed to
apply to all representations of a resource, the resource itself,
or an even broader scope. Specifications that expand the scope of
a response field will need to carefully consider issues such as
content negotiation, the time period of applicability, and (in
some cases) multi-tenant server deployments.
o Whether the field should be stored by origin servers that
understand it upon a PUT request.
o Whether the field semantics are further refined by the context,
such as by existing request methods or status codes.
o Whether it is appropriate to list the field name in the Connection A major task in the definition of a new HTTP field is the
header field (i.e., if the field is to be hop-by-hop; see specification of the field value syntax: what senders should
Section 7.6.1). generate, and how recipients should infer semantics from what is
received.
o Under what conditions intermediaries are allowed to insert, Authors are encouraged (but not required) to use either the ABNF
delete, or modify the field's value. rules in this specification or those in [RFCSTRF] to define the
syntax of new field values.
o Whether it is appropriate to list the field name in a Vary Authors are advised to carefully consider how the combination of
response header field (e.g., when the request header field is used multiple field lines will impact them (see Section 5.3). Because
by an origin server's content selection algorithm; see senders might send erroneously send multiple values, and both
Section 12.5.5). intermediaries and HTTP libraries can perform combination
automatically, this applies to all field values - even when only a
single value is anticipated.
o Whether the field is allowable in trailers (see Section 6.5). Therefore, authors are advised to delimit or encode values that
contain commas (e.g., with the quoted-string rule of Section 5.6.4,
the String data type of [RFCSTRF]), or a field-specific encoding).
This ensures that commas within field data are not confused with the
commas that delimit a list value.
o Whether the field ought to be preserved across redirects. For example, the Content-Type field value only allows commas inside
quoted strings, which can be reliably parsed even when multiple
values are present. The Location field value provides a counter-
example that should not be emulated: because URIs can include commas,
it is not possible to reliably distinguish between a single value
that includes a comma from two values.
o Whether it introduces any additional security considerations, such Authors of fields with a singleton value (see Section 5.5) are
as disclosure of privacy-related data. additionally advised to document how to treat messages where the
multiple members are present (a sensible default would be to ignore
the field, but this might not always be the right choice).
16.4. Authentication Scheme Extensibility 16.4. Authentication Scheme Extensibility
16.4.1. Authentication Scheme Registry 16.4.1. Authentication Scheme Registry
The "Hypertext Transfer Protocol (HTTP) Authentication Scheme The "Hypertext Transfer Protocol (HTTP) Authentication Scheme
Registry" defines the namespace for the authentication schemes in Registry" defines the namespace for the authentication schemes in
challenges and credentials. It is maintained at challenges and credentials. It is maintained at
<https://www.iana.org/assignments/http-authschemes>. <https://www.iana.org/assignments/http-authschemes>.
skipping to change at page 171, line 40 skipping to change at page 175, line 17
There are certain aspects of the HTTP Authentication framework that There are certain aspects of the HTTP Authentication framework that
put constraints on how new authentication schemes can work: put constraints on how new authentication schemes can work:
o HTTP authentication is presumed to be stateless: all of the o HTTP authentication is presumed to be stateless: all of the
information necessary to authenticate a request MUST be provided information necessary to authenticate a request MUST be provided
in the request, rather than be dependent on the server remembering in the request, rather than be dependent on the server remembering
prior requests. Authentication based on, or bound to, the prior requests. Authentication based on, or bound to, the
underlying connection is outside the scope of this specification underlying connection is outside the scope of this specification
and inherently flawed unless steps are taken to ensure that the and inherently flawed unless steps are taken to ensure that the
connection cannot be used by any party other than the connection cannot be used by any party other than the
authenticated user (see Section 3.6). authenticated user (see Section 3.7).
o The authentication parameter "realm" is reserved for defining o The authentication parameter "realm" is reserved for defining
protection spaces as described in Section 11.5. New schemes MUST protection spaces as described in Section 11.5. New schemes MUST
NOT use it in a way incompatible with that definition. NOT use it in a way incompatible with that definition.
o The "token68" notation was introduced for compatibility with o The "token68" notation was introduced for compatibility with
existing authentication schemes and can only be used once per existing authentication schemes and can only be used once per
challenge or credential. Thus, new schemes ought to use the auth- challenge or credential. Thus, new schemes ought to use the auth-
param syntax instead, because otherwise future extensions will be param syntax instead, because otherwise future extensions will be
impossible. impossible.
skipping to change at page 173, line 30 skipping to change at page 177, line 4
16.5.2. Considerations for New Range Units 16.5.2. Considerations for New Range Units
Other range units, such as format-specific boundaries like pages, Other range units, such as format-specific boundaries like pages,
sections, records, rows, or time, are potentially usable in HTTP for sections, records, rows, or time, are potentially usable in HTTP for
application-specific purposes, but are not commonly used in practice. application-specific purposes, but are not commonly used in practice.
Implementors of alternative range units ought to consider how they Implementors of alternative range units ought to consider how they
would work with content codings and general-purpose intermediaries. would work with content codings and general-purpose intermediaries.
16.6. Content Coding Extensibility 16.6. Content Coding Extensibility
16.6.1. Content Coding Registry 16.6.1. Content Coding Registry
The "HTTP Content Coding Registry", maintained by IANA at The "HTTP Content Coding Registry", maintained by IANA at
<https://www.iana.org/assignments/http-parameters/>, registers <https://www.iana.org/assignments/http-parameters/>, registers
content-coding names. content-coding names.
Content coding registrations MUST include the following fields: Content coding registrations MUST include the following fields:
o Name o Name
o Description o Description
o Pointer to specification text o Pointer to specification text
Names of content codings MUST NOT overlap with names of transfer Names of content codings MUST NOT overlap with names of transfer
codings (Section 7 of [Messaging]), unless the encoding codings (Section 7 of [Messaging]), unless the encoding
transformation is identical (as is the case for the compression transformation is identical (as is the case for the compression
codings defined in Section 8.5.1). codings defined in Section 8.4.1).
Values to be added to this namespace require IETF Review (see Values to be added to this namespace require IETF Review (see
Section 4.8 of [RFC8126]) and MUST conform to the purpose of content Section 4.8 of [RFC8126]) and MUST conform to the purpose of content
coding defined in Section 8.5.1. coding defined in Section 8.4.1.
16.6.2. Considerations for New Content Codings 16.6.2. Considerations for New Content Codings
New content codings ought to be self-descriptive whenever possible, New content codings ought to be self-descriptive whenever possible,
with optional parameters discoverable within the coding format with optional parameters discoverable within the coding format
itself, rather than rely on external metadata that might be lost itself, rather than rely on external metadata that might be lost
during transit. during transit.
16.7. Upgrade Token Registry 16.7. Upgrade Token Registry
skipping to change at page 175, line 17 skipping to change at page 178, line 36
This section is meant to inform developers, information providers, This section is meant to inform developers, information providers,
and users of known security concerns relevant to HTTP semantics and and users of known security concerns relevant to HTTP semantics and
its use for transferring information over the Internet. its use for transferring information over the Internet.
Considerations related to caching are discussed in Section 7 of Considerations related to caching are discussed in Section 7 of
[Caching] and considerations related to HTTP/1.1 message syntax and [Caching] and considerations related to HTTP/1.1 message syntax and
parsing are discussed in Section 11 of [Messaging]. parsing are discussed in Section 11 of [Messaging].
The list of considerations below is not exhaustive. Most security The list of considerations below is not exhaustive. Most security
concerns related to HTTP semantics are about securing server-side concerns related to HTTP semantics are about securing server-side
applications (code behind the HTTP interface), securing user agent applications (code behind the HTTP interface), securing user agent
processing of payloads received via HTTP, or secure use of the processing of content received via HTTP, or secure use of the
Internet in general, rather than security of the protocol. Various Internet in general, rather than security of the protocol. Various
organizations maintain topical information and links to current organizations maintain topical information and links to current
research on Web application security (e.g., [OWASP]). research on Web application security (e.g., [OWASP]).
17.1. Establishing Authority 17.1. Establishing Authority
HTTP relies on the notion of an _authoritative response_: a response HTTP relies on the notion of an _authoritative response_: a response
that has been determined by (or at the direction of) the origin that has been determined by (or at the direction of) the origin
server identified within the target URI to be the most appropriate server identified within the target URI to be the most appropriate
response for that request given the state of the target resource at response for that request given the state of the target resource at
skipping to change at page 177, line 35 skipping to change at page 181, line 11
of-service (e.g., telling the server to read from a COM port) or of-service (e.g., telling the server to read from a COM port) or
disclosure of configuration and source files that are not meant to be disclosure of configuration and source files that are not meant to be
served. served.
17.4. Attacks Based on Command, Code, or Query Injection 17.4. Attacks Based on Command, Code, or Query Injection
Origin servers often use parameters within the URI as a means of Origin servers often use parameters within the URI as a means of
identifying system services, selecting database entries, or choosing identifying system services, selecting database entries, or choosing
a data source. However, data received in a request cannot be a data source. However, data received in a request cannot be
trusted. An attacker could construct any of the request data trusted. An attacker could construct any of the request data
elements (method, target URI, header fields, or payload data) to elements (method, target URI, header fields, or content) to contain
contain data that might be misinterpreted as a command, code, or data that might be misinterpreted as a command, code, or query when
query when passed through a command invocation, language interpreter, passed through a command invocation, language interpreter, or
or database interface. database interface.
For example, SQL injection is a common attack wherein additional For example, SQL injection is a common attack wherein additional
query language is inserted within some part of the target URI or query language is inserted within some part of the target URI or
header fields (e.g., Host, Referer, etc.). If the received data is header fields (e.g., Host, Referer, etc.). If the received data is
used directly within a SELECT statement, the query language might be used directly within a SELECT statement, the query language might be
interpreted as a database command instead of a simple string value. interpreted as a database command instead of a simple string value.
This type of implementation vulnerability is extremely common, in This type of implementation vulnerability is extremely common, in
spite of being easy to prevent. spite of being easy to prevent.
In general, resource implementations ought to avoid use of request In general, resource implementations ought to avoid use of request
skipping to change at page 178, line 31 skipping to change at page 181, line 50
slow) streams of data, particularly where an implementation is slow) streams of data, particularly where an implementation is
expecting a protocol element with no predefined length (Section 2.3). expecting a protocol element with no predefined length (Section 2.3).
To promote interoperability, specific recommendations are made for To promote interoperability, specific recommendations are made for
minimum size limits on fields (Section 5.4). These are minimum minimum size limits on fields (Section 5.4). These are minimum
recommendations, chosen to be supportable even by implementations recommendations, chosen to be supportable even by implementations
with limited resources; it is expected that most implementations will with limited resources; it is expected that most implementations will
choose substantially higher limits. choose substantially higher limits.
A server can reject a message that has a target URI that is too long A server can reject a message that has a target URI that is too long
(Section 15.5.15) or a request payload that is too large (Section 15.5.15) or request content that is too large
(Section 15.5.14). Additional status codes related to capacity (Section 15.5.14). Additional status codes related to capacity
limits have been defined by extensions to HTTP [RFC6585]. limits have been defined by extensions to HTTP [RFC6585].
Recipients ought to carefully limit the extent to which they process Recipients ought to carefully limit the extent to which they process
other protocol elements, including (but not limited to) request other protocol elements, including (but not limited to) request
methods, response status phrases, field names, numeric values, and methods, response status phrases, field names, numeric values, and
chunk lengths. Failure to limit such processing can result in buffer chunk lengths. Failure to limit such processing can result in buffer
overflows, arithmetic overflows, or increased vulnerability to overflows, arithmetic overflows, or increased vulnerability to
denial-of-service attacks. denial-of-service attacks.
skipping to change at page 180, line 22 skipping to change at page 183, line 35
third parties. It is therefore unwise to include information within third parties. It is therefore unwise to include information within
a URI that is sensitive, personally identifiable, or a risk to a URI that is sensitive, personally identifiable, or a risk to
disclose. disclose.
When an application uses client-side mechanisms to construct a target When an application uses client-side mechanisms to construct a target
URI out of user-provided information, such as the query fields of a URI out of user-provided information, such as the query fields of a
form using GET, potentially sensitive data might be provided that form using GET, potentially sensitive data might be provided that
would not be appropriate for disclosure within a URI. POST is often would not be appropriate for disclosure within a URI. POST is often
preferred in such cases because it usually doesn't construct a URI; preferred in such cases because it usually doesn't construct a URI;
instead, POST of a form transmits the potentially sensitive data in instead, POST of a form transmits the potentially sensitive data in
the request payload data. However, this hinders caching and uses an the request content. However, this hinders caching and uses an
unsafe method for what would otherwise be a safe request. unsafe method for what would otherwise be a safe request.
Alternative workarounds include transforming the user-provided data Alternative workarounds include transforming the user-provided data
prior to constructing the URI, or filtering the data to only include prior to constructing the URI, or filtering the data to only include
common values that are not sensitive. Likewise, redirecting the common values that are not sensitive. Likewise, redirecting the
result of a query to a different (server-generated) URI can remove result of a query to a different (server-generated) URI can remove
potentially sensitive data from later links and provide a cacheable potentially sensitive data from later links and provide a cacheable
response for later reuse. response for later reuse.
Since the Referer header field tells a target site about the context Since the Referer header field tells a target site about the context
that resulted in a request, it has the potential to reveal that resulted in a request, it has the potential to reveal
skipping to change at page 186, line 30 skipping to change at page 190, line 17
403 Forbidden 15.5.4 403 Forbidden 15.5.4
404 Not Found 15.5.5 404 Not Found 15.5.5
405 Method Not Allowed 15.5.6 405 Method Not Allowed 15.5.6
406 Not Acceptable 15.5.7 406 Not Acceptable 15.5.7
407 Proxy Authentication Required 15.5.8 407 Proxy Authentication Required 15.5.8
408 Request Timeout 15.5.9 408 Request Timeout 15.5.9
409 Conflict 15.5.10 409 Conflict 15.5.10
410 Gone 15.5.11 410 Gone 15.5.11
411 Length Required 15.5.12 411 Length Required 15.5.12
412 Precondition Failed 15.5.13 412 Precondition Failed 15.5.13
413 Payload Too Large 15.5.14 413 Content Too Large 15.5.14
414 URI Too Long 15.5.15 414 URI Too Long 15.5.15
415 Unsupported Media Type 15.5.16 415 Unsupported Media Type 15.5.16
416 Range Not Satisfiable 15.5.17 416 Range Not Satisfiable 15.5.17
417 Expectation Failed 15.5.18 417 Expectation Failed 15.5.18
418 (Unused) 15.5.19 418 (Unused) 15.5.19
422 Unprocessable Payload 15.5.20 421 Misdirected Request 15.5.20
426 Upgrade Required 15.5.21 422 Unprocessable Content 15.5.21
426 Upgrade Required 15.5.22
500 Internal Server Error 15.6.1 500 Internal Server Error 15.6.1
501 Not Implemented 15.6.2 501 Not Implemented 15.6.2
502 Bad Gateway 15.6.3 502 Bad Gateway 15.6.3
503 Service Unavailable 15.6.4 503 Service Unavailable 15.6.4
504 Gateway Timeout 15.6.5 504 Gateway Timeout 15.6.5
505 HTTP Version Not Supported 15.6.6 505 HTTP Version Not Supported 15.6.6
------- ------------------------------- --------- ------- ------------------------------- ---------
Table 8 Table 8
skipping to change at page 187, line 50 skipping to change at page 191, line 35
--------------------------- ------------ -------- ------------ --------------------------- ------------ -------- ------------
Accept standard 12.5.1 Accept standard 12.5.1
Accept-Charset deprecated 12.5.2 Accept-Charset deprecated 12.5.2
Accept-Encoding standard 12.5.3 Accept-Encoding standard 12.5.3
Accept-Language standard 12.5.4 Accept-Language standard 12.5.4
Accept-Ranges standard 14.3 Accept-Ranges standard 14.3
Allow standard 10.2.1 Allow standard 10.2.1
Authentication-Info standard 11.6.3 Authentication-Info standard 11.6.3
Authorization standard 11.6.2 Authorization standard 11.6.2
Connection standard 7.6.1 Connection standard 7.6.1
Content-Encoding standard 8.5 Content-Encoding standard 8.4
Content-Language standard 8.6 Content-Language standard 8.5
Content-Length standard 8.7 Content-Length standard 8.6
Content-Location standard 8.8 Content-Location standard 8.7
Content-Range standard 14.4 Content-Range standard 14.4
Content-Type standard 8.4 Content-Type standard 8.3
Date standard 10.2.2 Date standard 10.2.2
ETag standard 8.9.3 ETag standard 8.8.3
Expect standard 10.1.1 Expect standard 10.1.1
From standard 10.1.2 From standard 10.1.2
Host standard 7.2 Host standard 7.2
If-Match standard 13.1.1 If-Match standard 13.1.1
If-Modified-Since standard 13.1.3 If-Modified-Since standard 13.1.3
If-None-Match standard 13.1.2 If-None-Match standard 13.1.2
If-Range standard 13.1.5 If-Range standard 13.1.5
If-Unmodified-Since standard 13.1.4 If-Unmodified-Since standard 13.1.4
Last-Modified standard 8.9.2 Last-Modified standard 8.8.2
Location standard 10.2.3 Location standard 10.2.3
Max-Forwards standard 7.6.2 Max-Forwards standard 7.6.2
Proxy-Authenticate standard 11.7.1 Proxy-Authenticate standard 11.7.1
Proxy-Authentication-Info standard 11.7.3 Proxy-Authentication-Info standard 11.7.3
Proxy-Authorization standard 11.7.2 Proxy-Authorization standard 11.7.2
Range standard 14.2 Range standard 14.2
Referer standard 10.1.3 Referer standard 10.1.3
Retry-After standard 10.2.4 Retry-After standard 10.2.4
Server standard 10.2.5 Server standard 10.2.5
TE standard 10.1.4 TE standard 10.1.4
skipping to change at page 189, line 22 skipping to change at page 193, line 8
18.6. Content Coding Registration 18.6. Content Coding Registration
Please update the "HTTP Content Coding Registry" at Please update the "HTTP Content Coding Registry" at
<https://www.iana.org/assignments/http-parameters/> with the <https://www.iana.org/assignments/http-parameters/> with the
registration procedure of Section 16.6.1 and the content coding names registration procedure of Section 16.6.1 and the content coding names
summarized in the table below. summarized in the table below.
------------ ------------------------------------------- --------- ------------ ------------------------------------------- ---------
Name Description Ref. Name Description Ref.
------------ ------------------------------------------- --------- ------------ ------------------------------------------- ---------
compress UNIX "compress" data format [Welch] 8.5.1.1 compress UNIX "compress" data format [Welch] 8.4.1.1
deflate "deflate" compressed data ([RFC1951]) 8.5.1.2 deflate "deflate" compressed data ([RFC1951]) 8.4.1.2
inside the "zlib" data format ([RFC1950]) inside the "zlib" data format ([RFC1950])
gzip GZIP file format [RFC1952] 8.5.1.3 gzip GZIP file format [RFC1952] 8.4.1.3
identity Reserved 12.5.3 identity Reserved 12.5.3
x-compress Deprecated (alias for compress) 8.5.1.1 x-compress Deprecated (alias for compress) 8.4.1.1
x-gzip Deprecated (alias for gzip) 8.5.1.3 x-gzip Deprecated (alias for gzip) 8.4.1.3
------------ ------------------------------------------- --------- ------------ ------------------------------------------- ---------
Table 10 Table 10
18.7. Range Unit Registration 18.7. Range Unit Registration
Please update the "HTTP Range Unit Registry" at Please update the "HTTP Range Unit Registry" at
<https://www.iana.org/assignments/http-parameters/> with the <https://www.iana.org/assignments/http-parameters/> with the
registration procedure of Section 16.5.1 and the range unit names registration procedure of Section 16.5.1 and the range unit names
summarized in the table below. summarized in the table below.
skipping to change at page 190, line 9 skipping to change at page 193, line 40
none reserved as keyword to indicate 14.3 none reserved as keyword to indicate 14.3
range requests are not supported range requests are not supported
----------------- ---------------------------------- -------- ----------------- ---------------------------------- --------
Table 11 Table 11
18.8. Media Type Registration 18.8. Media Type Registration
Please update the "Media Types" registry at Please update the "Media Types" registry at
<https://www.iana.org/assignments/media-types> with the registration <https://www.iana.org/assignments/media-types> with the registration
information in Section 14.5 for the media type "multipart/ information in Section 14.6 for the media type "multipart/
byteranges". byteranges".
18.9. Port Registration 18.9. Port Registration
Please update the "Service Name and Transport Protocol Port Number" Please update the "Service Name and Transport Protocol Port Number"
registry at <https://www.iana.org/assignments/service-names-port- registry at <https://www.iana.org/assignments/service-names-port-
numbers/> for the services on ports 80 and 443 that use UDP or TCP numbers/> for the services on ports 80 and 443 that use UDP or TCP
to: to:
1. use this document as "Reference", and 1. use this document as "Reference", and
skipping to change at page 190, line 46 skipping to change at page 194, line 29
------ ------------------- ------------------------- ------ ------ ------------------- ------------------------- ------
Table 12 Table 12
19. References 19. References
19.1. Normative References 19.1. Normative References
[Caching] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [Caching] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Caching", Work in Progress, Internet-Draft, Ed., "HTTP Caching", Work in Progress, Internet-Draft,
draft-ietf-httpbis-cache-13, December 14, 2020, draft-ietf-httpbis-cache-14, January 13, 2021,
<https://tools.ietf.org/html/draft-ietf-httpbis-cache-13>. <https://tools.ietf.org/html/draft-ietf-httpbis-cache-14>.
[Messaging] [Messaging]
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP/1.1", Work in Progress, Internet-Draft, draft- Ed., "HTTP/1.1", Work in Progress, Internet-Draft, draft-
ietf-httpbis-messaging-13, December 14, 2020, ietf-httpbis-messaging-14, January 13, 2021,
<https://tools.ietf.org/html/draft-ietf-httpbis-messaging- <https://tools.ietf.org/html/draft-ietf-httpbis-messaging-
13>. 14>.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>. <https://www.rfc-editor.org/info/rfc793>.
[RFC1950] Deutsch, L.P. and J-L. Gailly, "ZLIB Compressed Data [RFC1950] Deutsch, L.P. and J-L. Gailly, "ZLIB Compressed Data
Format Specification version 3.3", RFC 1950, Format 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>.
skipping to change at page 193, line 46 skipping to change at page 197, line 26
<https://www.rfc-editor.org/errata/eid5433>. <https://www.rfc-editor.org/errata/eid5433>.
[Georgiev] Georgiev, M., Iyengar, S., Jana, S., Anubhai, R., Boneh, [Georgiev] Georgiev, M., Iyengar, S., Jana, S., Anubhai, R., Boneh,
D., and V. Shmatikov, "The Most Dangerous Code in the D., and V. Shmatikov, "The Most Dangerous Code in the
World: Validating SSL Certificates in Non-browser World: Validating SSL Certificates in Non-browser
Software", DOI 10.1145/2382196.2382204, In Proceedings of Software", DOI 10.1145/2382196.2382204, In Proceedings of
the 2012 ACM Conference on Computer and Communications the 2012 ACM Conference on Computer and Communications
Security (CCS '12), pp. 38-49, October 2012, Security (CCS '12), pp. 38-49, October 2012,
<https://doi.org/10.1145/2382196.2382204>. <https://doi.org/10.1145/2382196.2382204>.
[HTTP/0.9] Berners-Lee, T., "The Original HTTP as defined in 1991",
October 1996,
<https://www.w3.org/Protocols/HTTP/AsImplemented.html>.
[HTTP3] Bishop, M., "Hypertext Transfer Protocol Version 3 [HTTP3] Bishop, M., "Hypertext Transfer Protocol Version 3
(HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf-
quic-http-32, October 20, 2020, quic-http-33, December 15, 2020,
<https://tools.ietf.org/html/draft-ietf-quic-http-32>. <https://tools.ietf.org/html/draft-ietf-quic-http-33>.
[ISO-8859-1] [ISO-8859-1]
International Organization for Standardization, International Organization for Standardization,
"Information technology -- 8-bit single-byte coded graphic "Information technology -- 8-bit single-byte coded graphic
character sets -- Part 1: Latin alphabet No. 1", ISO/ character sets -- Part 1: Latin alphabet No. 1", ISO/
IEC 8859-1:1998, 1998. IEC 8859-1:1998, 1998.
[Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and [Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and
Politics", ACM Transactions on Internet Technology 1(2), Politics", ACM Transactions on Internet Technology 1(2),
November 2001, <http://arxiv.org/abs/cs.SE/0105018>. November 2001, <http://arxiv.org/abs/cs.SE/0105018>.
skipping to change at page 198, line 49 skipping to change at page 202, line 21
<https://www.rfc-editor.org/info/rfc8288>. <https://www.rfc-editor.org/info/rfc8288>.
[RFC8336] Nottingham, M. and E. Nygren, "The ORIGIN HTTP/2 Frame", [RFC8336] Nottingham, M. and E. Nygren, "The ORIGIN HTTP/2 Frame",
RFC 8336, DOI 10.17487/RFC8336, March 2018, RFC 8336, DOI 10.17487/RFC8336, March 2018,
<https://www.rfc-editor.org/info/rfc8336>. <https://www.rfc-editor.org/info/rfc8336>.
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
<https://www.rfc-editor.org/info/rfc8615>. <https://www.rfc-editor.org/info/rfc8615>.
[RFCSTRF] Nottingham, M. and P-H. Kamp, "Structured Field Values for
HTTP", Work in Progress, Internet-Draft, draft-ietf-
httpbis-header-structure-19, June 2020,
<https://tools.ietf.org/html/draft-ietf-httpbis-header-
structure-19>.
[Sniffing] WHATWG, "MIME Sniffing", [Sniffing] WHATWG, "MIME Sniffing",
<https://mimesniff.spec.whatwg.org>. <https://mimesniff.spec.whatwg.org>.
Appendix A. Collected ABNF Appendix A. Collected ABNF
In the collected ABNF below, list rules are expanded as per In the collected ABNF below, list rules are expanded as per
Section 5.6.1.1. Section 5.6.1.1.
Accept = [ ( media-range [ accept-params ] ) *( OWS "," OWS ( Accept = [ ( media-range [ weight ] ) *( OWS "," OWS ( media-range [
media-range [ accept-params ] ) ) ] weight ] ) ) ]
Accept-Charset = [ ( ( charset / "*" ) [ weight ] ) *( OWS "," OWS ( Accept-Charset = [ ( ( charset / "*" ) [ weight ] ) *( OWS "," OWS (
( charset / "*" ) [ weight ] ) ) ] ( charset / "*" ) [ weight ] ) ) ]
Accept-Encoding = [ ( codings [ weight ] ) *( OWS "," OWS ( codings [ Accept-Encoding = [ ( codings [ weight ] ) *( OWS "," OWS ( codings [
weight ] ) ) ] weight ] ) ) ]
Accept-Language = [ ( language-range [ weight ] ) *( OWS "," OWS ( Accept-Language = [ ( language-range [ weight ] ) *( OWS "," OWS (
language-range [ weight ] ) ) ] language-range [ weight ] ) ) ]
Accept-Ranges = acceptable-ranges Accept-Ranges = acceptable-ranges
Allow = [ method *( OWS "," OWS method ) ] Allow = [ method *( OWS "," OWS method ) ]
Authentication-Info = [ auth-param *( OWS "," OWS auth-param ) ] Authentication-Info = [ auth-param *( OWS "," OWS auth-param ) ]
Authorization = credentials Authorization = credentials
skipping to change at page 200, line 25 skipping to change at page 204, line 4
RWS = 1*( SP / HTAB ) RWS = 1*( SP / HTAB )
Range = ranges-specifier Range = ranges-specifier
Referer = absolute-URI / partial-URI Referer = absolute-URI / partial-URI
Retry-After = HTTP-date / delay-seconds Retry-After = HTTP-date / delay-seconds
Server = product *( RWS ( product / comment ) ) Server = product *( RWS ( product / comment ) )
TE = [ t-codings *( OWS "," OWS t-codings ) ] TE = [ t-codings *( OWS "," OWS t-codings ) ]
Trailer = [ field-name *( OWS "," OWS field-name ) ] Trailer = [ field-name *( OWS "," OWS field-name ) ]
URI-reference = <URI-reference, see [RFC3986], Section 4.1> URI-reference = <URI-reference, see [RFC3986], Section 4.1>
Upgrade = [ protocol *( OWS "," OWS protocol ) ] Upgrade = [ protocol *( OWS "," OWS protocol ) ]
User-Agent = product *( RWS ( product / comment ) ) User-Agent = product *( RWS ( product / comment ) )
Vary = [ ( "*" / field-name ) *( OWS "," OWS ( "*" / field-name ) ) Vary = [ ( "*" / field-name ) *( OWS "," OWS ( "*" / field-name ) )
] ]
Via = [ ( received-protocol RWS received-by [ RWS comment ] ) *( OWS Via = [ ( received-protocol RWS received-by [ RWS comment ] ) *( OWS
"," OWS ( received-protocol RWS received-by [ RWS comment ] ) ) ] "," OWS ( received-protocol RWS received-by [ RWS comment ] ) ) ]
WWW-Authenticate = [ challenge *( OWS "," OWS challenge ) ] WWW-Authenticate = [ challenge *( OWS "," OWS challenge ) ]
absolute-URI = <absolute-URI, see [RFC3986], Section 4.3> absolute-URI = <absolute-URI, see [RFC3986], Section 4.3>
absolute-path = 1*( "/" segment ) absolute-path = 1*( "/" segment )
accept-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ]
accept-params = weight *accept-ext
acceptable-ranges = ( range-unit *( OWS "," OWS range-unit ) ) / acceptable-ranges = ( range-unit *( OWS "," OWS range-unit ) ) /
"none" "none"
asctime-date = day-name SP date3 SP time-of-day SP year asctime-date = day-name SP date3 SP time-of-day SP year
auth-param = token BWS "=" BWS ( token / quoted-string ) auth-param = token BWS "=" BWS ( token / quoted-string )
auth-scheme = token auth-scheme = token
authority = <authority, see [RFC3986], Section 3.2> authority = <authority, see [RFC3986], Section 3.2>
challenge = auth-scheme [ 1*SP ( token68 / [ auth-param *( OWS "," challenge = auth-scheme [ 1*SP ( token68 / [ auth-param *( OWS ","
OWS auth-param ) ] ) ] OWS auth-param ) ] ) ]
charset = token charset = token
skipping to change at page 203, line 29 skipping to change at page 207, line 4
second = 2DIGIT second = 2DIGIT
segment = <segment, see [RFC3986], Section 3.3> segment = <segment, see [RFC3986], Section 3.3>
subtype = token subtype = token
suffix-length = 1*DIGIT suffix-length = 1*DIGIT
suffix-range = "-" suffix-length suffix-range = "-" suffix-length
t-codings = "trailers" / ( transfer-coding [ weight ] ) t-codings = "trailers" / ( transfer-coding [ weight ] )
tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." / tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." /
"^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA
time-of-day = hour ":" minute ":" second time-of-day = hour ":" minute ":" second
token = 1*tchar token = 1*tchar
token68 = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" ) token68 = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" )
*"=" *"="
transfer-coding = token *( OWS ";" OWS transfer-parameter ) transfer-coding = token *( OWS ";" OWS transfer-parameter )
transfer-parameter = token BWS "=" BWS ( token / quoted-string ) transfer-parameter = token BWS "=" BWS ( token / quoted-string )
type = token type = token
unsatisfied-range = "*/" complete-length unsatisfied-range = "*/" complete-length
uri-host = <host, see [RFC3986], Section 3.2.2> uri-host = <host, see [RFC3986], Section 3.2.2>
weak = %x57.2F ; W/ weak = %x57.2F ; W/
weight = OWS ";" OWS "q=" qvalue weight = OWS ";" OWS "q=" qvalue
year = 4DIGIT year = 4DIGIT
Appendix B. Changes from previous RFCs Appendix B. Changes from previous RFCs
B.1. Changes from RFC 2818 B.1. Changes from RFC 2818
None yet. None.
B.2. Changes from RFC 7230 B.2. Changes from RFC 7230
The sections introducing HTTP's design goals, history, architecture, The sections introducing HTTP's design goals, history, architecture,
conformance criteria, protocol versioning, URIs, message routing, and conformance criteria, protocol versioning, URIs, message routing, and
header fields have been moved here (without substantive change). header fields have been moved here (without substantive change).
The description of an origin and authoritative access to origin The description of an origin and authoritative access to origin
servers has been extended for both "http" and "https" URIs to account servers has been extended for both "http" and "https" URIs to account
for alternative services and secured connections that are not for alternative services and secured connections that are not
skipping to change at page 205, line 21 skipping to change at page 208, line 46
mapped to SP. (Section 5.5) mapped to SP. (Section 5.5)
Parameters in media type, media range, and expectation can be empty Parameters in media type, media range, and expectation can be empty
via one or more trailing semicolons. (Section 5.6.6) via one or more trailing semicolons. (Section 5.6.6)
An abstract data type for HTTP messages has been introduced to define An abstract data type for HTTP messages has been introduced to define
the components of a message and their semantics as an abstraction the components of a message and their semantics as an abstraction
across multiple HTTP versions, rather than in terms of the specific across multiple HTTP versions, rather than in terms of the specific
syntax form of HTTP/1.1 in [Messaging], and reflect the contents syntax form of HTTP/1.1 in [Messaging], and reflect the contents
after the message is parsed. This makes it easier to distinguish after the message is parsed. This makes it easier to distinguish
between requirements on the payload data (what is conveyed) versus between requirements on the content (what is conveyed) versus
requirements on the messaging syntax (how it is conveyed) and avoids requirements on the messaging syntax (how it is conveyed) and avoids
baking limitations of early protocol versions into the future of baking limitations of early protocol versions into the future of
HTTP. (Section 6) HTTP. (Section 6)
The term "effective request URI" has been replaced with "target URI". The term "effective request URI" has been replaced with "target URI".
(Section 7.1) (Section 7.1)
Restrictions on client retries have been loosened, to reflect Restrictions on client retries have been loosened, to reflect
implementation behavior. (Section 9.2.2) implementation behavior. (Section 9.2.2)
Clarified that request bodies on GET and DELETE are not Clarified that request bodies on GET and DELETE are not
interoperable. (Section 9.3.1, Section 9.3.5) interoperable. (Section 9.3.1, Section 9.3.5)
Removed a superfluous requirement about setting Content-Length from Removed a superfluous requirement about setting Content-Length from
the description of the OPTIONS method. (Section 9.3.7) the description of the OPTIONS method. (Section 9.3.7)
Restore list-based grammar for Expect for compatibility with RFC Restore list-based grammar for Expect for compatibility with RFC
2616. (Section 10.1.1) 2616. (Section 10.1.1)
The semantics of "*" in the Vary header field when other values are
present was clarified. (Section 12.5.5)
Allow Accept and Accept-Encoding in response messages; the latter was Allow Accept and Accept-Encoding in response messages; the latter was
introduced by [RFC7694]. (Section 12.3) introduced by [RFC7694]. (Section 12.3)
"Accept Parameters" (accept-params) have been removed from the
definition of the Accept field. (Section 12.5.1)
The semantics of "*" in the Vary header field when other values are
present was clarified. (Section 12.5.5)
Range units are compared in a case insensitive fashion. Range units are compared in a case insensitive fashion.
(Section 14.1) (Section 14.1)
The process of creating a redirected request has been clarified. The process of creating a redirected request has been clarified.
(Section 15.4) (Section 15.4)
Added status code 308 (previously defined in [RFC7538]) so that it's Added status code 308 (previously defined in [RFC7538]) so that it's
defined closer to status codes 301, 302, and 307. (Section 15.4.9) defined closer to status codes 301, 302, and 307. (Section 15.4.9)
Added status code 421 (previously defined in Section 9.1.2 of
[RFC7540]) because of its general applicability. 421 is no longer
defined as heuristically cacheable, since the response is specific to
the connection (not the target resource). (Section 15.5.20)
Added status code 422 (previously defined in Section 11.2 of Added status code 422 (previously defined in Section 11.2 of
[RFC4918]) because of its general applicability. (Section 15.5.20) [RFC4918]) because of its general applicability. (Section 15.5.21)
Allowed use of the Content-Range header field (Section 14.4) as a
request modifier on PUT. (Section 9.3.4)
B.4. Changes from RFC 7232 B.4. Changes from RFC 7232
Previous revisions of HTTP imposed an arbitrary 60-second limit on Previous revisions of HTTP imposed an arbitrary 60-second limit on
the determination of whether Last-Modified was a strong validator to the determination of whether Last-Modified was a strong validator to
guard against the possibility that the Date and Last-Modified values guard against the possibility that the Date and Last-Modified values
are generated from different clocks or at somewhat different times are generated from different clocks or at somewhat different times
during the preparation of the response. This specification has during the preparation of the response. This specification has
relaxed that to allow reasonable discretion. (Section 8.9.2.2) relaxed that to allow reasonable discretion. (Section 8.8.2.2)
Removed edge case requirement on If-Match and If-Unmodified-Since Removed edge case requirement on If-Match and If-Unmodified-Since
that a validator not be sent in a 2xx response when validation fails that a validator not be sent in a 2xx response when validation fails
and the server decides that the same change request has already been and the server decides that the same change request has already been
applied. (Section 13.1.1 and Section 13.1.4) applied. (Section 13.1.1 and Section 13.1.4)
Clarified that If-Unmodified-Since doesn't apply to a resource Clarified that If-Unmodified-Since doesn't apply to a resource
without a concept of modification time. (Section 13.1.4) without a concept of modification time. (Section 13.1.4)
Preconditions can now be evaluated before the request payload is Preconditions can now be evaluated before the request content is
processed rather than waiting until the response would otherwise be processed rather than waiting until the response would otherwise be
successful. (Section 13.2) successful. (Section 13.2)
B.5. Changes from RFC 7233 B.5. Changes from RFC 7233
Refactored the range-unit and ranges-specifier grammars to simplify Refactored the range-unit and ranges-specifier grammars to simplify
and reduce artificial distinctions between bytes and other and reduce artificial distinctions between bytes and other
(extension) range units, removing the overlapping grammar of other- (extension) range units, removing the overlapping grammar of other-
range-unit by defining range units generically as a token and placing range-unit by defining range units generically as a token and placing
extensions within the scope of a range-spec (other-range). This extensions within the scope of a range-spec (other-range). This
disambiguates the role of list syntax (commas) in all range sets, disambiguates the role of list syntax (commas) in all range sets,
including extension range units, for indicating a range-set of more including extension range units, for indicating a range-set of more
than one range. Moving the extension grammar into range specifiers than one range. Moving the extension grammar into range specifiers
also allows protocol specific to byte ranges to be specified also allows protocol specific to byte ranges to be specified
separately. separately.
It is now possible to define Range handling on extension methods. It is now possible to define Range handling on extension methods.
(Section 14.2) (Section 14.2)
Described use of the Content-Range header field (Section 14.4) as a
request modifier to perform a partial PUT. (Section 14.5)
B.6. Changes from RFC 7235 B.6. Changes from RFC 7235
None yet. None.
B.7. Changes from RFC 7538 B.7. Changes from RFC 7538
None yet. None.
B.8. Changes from RFC 7615 B.8. Changes from RFC 7615
None yet. None.
B.9. Changes from RFC 7694 B.9. Changes from RFC 7694
This specification includes the extension defined in [RFC7694], but This specification includes the extension defined in [RFC7694], but
leaves out examples and deployment considerations. leaves out examples and deployment considerations.
Appendix C. Change Log Appendix C. Change Log
This section is to be removed before publishing as an RFC. This section is to be removed before publishing as an RFC.
skipping to change at page 209, line 49 skipping to change at page 213, line 45
o Included (Proxy-)Auth-Info header field definition from RFC 7615 o Included (Proxy-)Auth-Info header field definition from RFC 7615
(<https://github.com/httpwg/http-core/issues/9>) (<https://github.com/httpwg/http-core/issues/9>)
o In Section 9.3.3, clarify POST caching o In Section 9.3.3, clarify POST caching
(<https://github.com/httpwg/http-core/issues/17>) (<https://github.com/httpwg/http-core/issues/17>)
o Add Section 15.5.19 to reserve the 418 status code o Add Section 15.5.19 to reserve the 418 status code
(<https://github.com/httpwg/http-core/issues/43>) (<https://github.com/httpwg/http-core/issues/43>)
o In Section 3.3 and Section 10.1.1, clarified when a response can o In Section 3.4 and Section 10.1.1, clarified when a response can
be sent (<https://github.com/httpwg/http-core/issues/82>) be sent (<https://github.com/httpwg/http-core/issues/82>)
o In Section 8.4.2, explain the difference between the "token" o In Section 8.3.2, explain the difference between the "token"
production, the RFC 2978 ABNF for charset names, and the actual production, the RFC 2978 ABNF for charset names, and the actual
registration practice (<https://github.com/httpwg/http-core/ registration practice (<https://github.com/httpwg/http-core/
issues/100>, <https://www.rfc-editor.org/errata/eid4689>) issues/100>, <https://www.rfc-editor.org/errata/eid4689>)
o In Section 3.1, removed the fragment component in the URI scheme o In Section 3.1, removed the fragment component in the URI scheme
definitions as per Section 4.3 of [RFC3986], furthermore moved definitions as per Section 4.3 of [RFC3986], furthermore moved
fragment discussion into a separate section fragment discussion into a separate section
(<https://github.com/httpwg/http-core/issues/103>, (<https://github.com/httpwg/http-core/issues/103>,
<https://www.rfc-editor.org/errata/eid4251>, <https://www.rfc- <https://www.rfc-editor.org/errata/eid4251>, <https://www.rfc-
editor.org/errata/eid4252>) editor.org/errata/eid4252>)
o In Section 2.5, add language about minor HTTP version number o In Section 2.5, add language about minor HTTP version number
defaulting (<https://github.com/httpwg/http-core/issues/115>) defaulting (<https://github.com/httpwg/http-core/issues/115>)
o Added Section 15.5.20 for status code 422, previously defined in o Added Section 15.5.21 for status code 422, previously defined in
Section 11.2 of [RFC4918] (<https://github.com/httpwg/http-core/ Section 11.2 of [RFC4918] (<https://github.com/httpwg/http-core/
issues/123>) issues/123>)
o In Section 15.5.17, fixed prose about byte range comparison o In Section 15.5.17, fixed prose about byte range comparison
(<https://github.com/httpwg/http-core/issues/135>, (<https://github.com/httpwg/http-core/issues/135>,
<https://www.rfc-editor.org/errata/eid5474>) <https://www.rfc-editor.org/errata/eid5474>)
o In Section 3.3, explain that request/response correlation is o In Section 3.4, explain that request/response correlation is
version specific (<https://github.com/httpwg/http-core/ version specific (<https://github.com/httpwg/http-core/
issues/145>) issues/145>)
C.5. Since draft-ietf-httpbis-semantics-03 C.5. Since draft-ietf-httpbis-semantics-03
o In Section 15.4.9, include status code 308 from RFC 7538 o In Section 15.4.9, include status code 308 from RFC 7538
(<https://github.com/httpwg/http-core/issues/3>) (<https://github.com/httpwg/http-core/issues/3>)
o In Section 8.4.1, clarify that the charset parameter value is o In Section 8.3.1, clarify that the charset parameter value is
case-insensitive due to the definition in RFC 2046 case-insensitive due to the definition in RFC 2046
(<https://github.com/httpwg/http-core/issues/13>) (<https://github.com/httpwg/http-core/issues/13>)
o Define a separate registry for HTTP header field names o Define a separate registry for HTTP header field names
(<https://github.com/httpwg/http-core/issues/42>) (<https://github.com/httpwg/http-core/issues/42>)
o In Section 12.1, refactor and clarify description of wildcard o In Section 12.1, refactor and clarify description of wildcard
("*") handling (<https://github.com/httpwg/http-core/issues/46>) ("*") handling (<https://github.com/httpwg/http-core/issues/46>)
o Deprecate Accept-Charset (<https://github.com/httpwg/http-core/ o Deprecate Accept-Charset (<https://github.com/httpwg/http-core/
skipping to change at page 211, line 14 skipping to change at page 215, line 8
o In Section 5.3, clarify when header field combination is allowed o In Section 5.3, clarify when header field combination is allowed
(<https://github.com/httpwg/http-core/issues/74>) (<https://github.com/httpwg/http-core/issues/74>)
o In Section 18.4, instruct IANA to mark Content-MD5 as obsolete o In Section 18.4, instruct IANA to mark Content-MD5 as obsolete
(<https://github.com/httpwg/http-core/issues/93>) (<https://github.com/httpwg/http-core/issues/93>)
o Use RFC 7405 ABNF notation for case-sensitive string constants o Use RFC 7405 ABNF notation for case-sensitive string constants
(<https://github.com/httpwg/http-core/issues/133>) (<https://github.com/httpwg/http-core/issues/133>)
o Rework Section 3.3 to be more version-independent o Rework Section 3.4 to be more version-independent
(<https://github.com/httpwg/http-core/issues/142>) (<https://github.com/httpwg/http-core/issues/142>)
o In Section 9.3.5, clarify that DELETE needs to be successful to o In Section 9.3.5, clarify that DELETE needs to be successful to
invalidate cache (<https://github.com/httpwg/http-core/ invalidate cache (<https://github.com/httpwg/http-core/
issues/167>, <https://www.rfc-editor.org/errata/eid5541>) issues/167>, <https://www.rfc-editor.org/errata/eid5541>)
C.6. Since draft-ietf-httpbis-semantics-04 C.6. Since draft-ietf-httpbis-semantics-04
o In Section 5.5, fix field-content ABNF o In Section 5.5, fix field-content ABNF
(<https://github.com/httpwg/http-core/issues/19>, (<https://github.com/httpwg/http-core/issues/19>,
<https://www.rfc-editor.org/errata/eid4189>) <https://www.rfc-editor.org/errata/eid4189>)
o Move Section 5.6.6 into its own section o Move Section 5.6.6 into its own section
(<https://github.com/httpwg/http-core/issues/45>) (<https://github.com/httpwg/http-core/issues/45>)
o In Section 8.4, reference MIME Sniffing o In Section 8.3, reference MIME Sniffing
(<https://github.com/httpwg/http-core/issues/51>) (<https://github.com/httpwg/http-core/issues/51>)
o In Section 5.6.1, simplify the #rule mapping for recipients o In Section 5.6.1, simplify the #rule mapping for recipients
(<https://github.com/httpwg/http-core/issues/164>, (<https://github.com/httpwg/http-core/issues/164>,
<https://www.rfc-editor.org/errata/eid5257>) <https://www.rfc-editor.org/errata/eid5257>)
o In Section 9.3.7, remove misleading text about "extension" of HTTP o In Section 9.3.7, remove misleading text about "extension" of HTTP
is needed to define method payloads (<https://github.com/httpwg/ is needed to define method content (<https://github.com/httpwg/
http-core/issues/204>) http-core/issues/204>)
o Fix editorial issue in Section 8 (<https://github.com/httpwg/http- o Fix editorial issue in Section 3.2 (<https://github.com/httpwg/
core/issues/223>) http-core/issues/223>)
o In Section 15.5.20, rephrase language not to use "entity" anymore, o In Section 15.5.21, rephrase language not to use "entity" anymore,
and also avoid lowercase "may" (<https://github.com/httpwg/http- and also avoid lowercase "may" (<https://github.com/httpwg/http-
core/issues/224>) core/issues/224>)
o Move discussion of retries from [Messaging] into Section 9.2.2 o Move discussion of retries from [Messaging] into Section 9.2.2
(<https://github.com/httpwg/http-core/issues/230>) (<https://github.com/httpwg/http-core/issues/230>)
C.7. Since draft-ietf-httpbis-semantics-05 C.7. Since draft-ietf-httpbis-semantics-05
o Moved transport-independent part of the description of trailers o Moved transport-independent part of the description of trailers
into Section 6.5 (<https://github.com/httpwg/http-core/issues/16>) into Section 6.5 (<https://github.com/httpwg/http-core/issues/16>)
o Loosen requirements on retries based upon implementation behavior o Loosen requirements on retries based upon implementation behavior
(<https://github.com/httpwg/http-core/issues/27>) (<https://github.com/httpwg/http-core/issues/27>)
o In Section 18.9, update IANA port registry for TCP/UDP on ports 80 o In Section 18.9, update IANA port registry for TCP/UDP on ports 80
and 443 (<https://github.com/httpwg/http-core/issues/36>) and 443 (<https://github.com/httpwg/http-core/issues/36>)
o In Section 16.3.3, revise guidelines for new header field names o In Section 16.3.2.2, revise guidelines for new header field names
(<https://github.com/httpwg/http-core/issues/47>) (<https://github.com/httpwg/http-core/issues/47>)
o In Section 9.2.3, remove concept of "cacheable methods" in favor o In Section 9.2.3, remove concept of "cacheable methods" in favor
of prose (<https://github.com/httpwg/http-core/issues/54>, of prose (<https://github.com/httpwg/http-core/issues/54>,
<https://www.rfc-editor.org/errata/eid5300>) <https://www.rfc-editor.org/errata/eid5300>)
o In Section 17.1, mention that the concept of authority can be o In Section 17.1, mention that the concept of authority can be
modified by protocol extensions (<https://github.com/httpwg/http- modified by protocol extensions (<https://github.com/httpwg/http-
core/issues/143>) core/issues/143>)
o Create new subsection on payload in Section 6.4, taken from o Create new subsection on content in Section 6.4, taken from
portions of message body (<https://github.com/httpwg/http-core/ portions of message body (<https://github.com/httpwg/http-core/
issues/159>) issues/159>)
o Moved definition of "Whitespace" into new container "Generic o Moved definition of "Whitespace" into new container "Generic
Syntax" (<https://github.com/httpwg/http-core/issues/162>) Syntax" (<https://github.com/httpwg/http-core/issues/162>)
o In Section 3.1, recommend minimum URI size support for o In Section 3.1, recommend minimum URI size support for
implementations (<https://github.com/httpwg/http-core/issues/169>) implementations (<https://github.com/httpwg/http-core/issues/169>)
o In Section 14.1, refactored the range-unit and ranges-specifier o In Section 14.1, refactored the range-unit and ranges-specifier
grammars (<https://github.com/httpwg/http-core/issues/196>, grammars (<https://github.com/httpwg/http-core/issues/196>,
<https://www.rfc-editor.org/errata/eid5620>) <https://www.rfc-editor.org/errata/eid5620>)
o In Section 9.3.1, caution against a request payload more strongly o In Section 9.3.1, caution against a request content more strongly
(<https://github.com/httpwg/http-core/issues/202>) (<https://github.com/httpwg/http-core/issues/202>)
o Reorganized text in Section 16.3.3 (<https://github.com/httpwg/ o Reorganized text in Section 16.3.2.2 (<https://github.com/httpwg/
http-core/issues/214>) http-core/issues/214>)
o In Section 15.5.4, replace "authorize" with "fulfill" o In Section 15.5.4, replace "authorize" with "fulfill"
(<https://github.com/httpwg/http-core/issues/218>) (<https://github.com/httpwg/http-core/issues/218>)
o In Section 9.3.7, removed a misleading statement about Content- o In Section 9.3.7, removed a misleading statement about Content-
Length (<https://github.com/httpwg/http-core/issues/235>, Length (<https://github.com/httpwg/http-core/issues/235>,
<https://www.rfc-editor.org/errata/eid5806>) <https://www.rfc-editor.org/errata/eid5806>)
o In Section 17.1, add text from RFC 2818 o In Section 17.1, add text from RFC 2818
skipping to change at page 213, line 35 skipping to change at page 217, line 29
consistently throughout (<https://github.com/httpwg/http-core/ consistently throughout (<https://github.com/httpwg/http-core/
issues/111>) issues/111>)
o Moved #rule definition into Section 5.5 and whitespace into o Moved #rule definition into Section 5.5 and whitespace into
Section 2.1 (<https://github.com/httpwg/http-core/issues/162>) Section 2.1 (<https://github.com/httpwg/http-core/issues/162>)
o In Section 14.1, explicitly call out range unit names as case- o In Section 14.1, explicitly call out range unit names as case-
insensitive, and encourage registration insensitive, and encourage registration
(<https://github.com/httpwg/http-core/issues/179>) (<https://github.com/httpwg/http-core/issues/179>)
o In Section 8.5.1, explicitly call out content codings as case- o In Section 8.4.1, explicitly call out content codings as case-
insensitive, and encourage registration insensitive, and encourage registration
(<https://github.com/httpwg/http-core/issues/179>) (<https://github.com/httpwg/http-core/issues/179>)
o In Section 5.1, explicitly call out field names as case- o In Section 5.1, explicitly call out field names as case-
insensitive (<https://github.com/httpwg/http-core/issues/179>) insensitive (<https://github.com/httpwg/http-core/issues/179>)
o In Section 17.12, cite [Bujlow] (<https://github.com/httpwg/http- o In Section 17.12, cite [Bujlow] (<https://github.com/httpwg/http-
core/issues/185>) core/issues/185>)
o In Section 15, formally define "final" and "interim" status codes o In Section 15, formally define "final" and "interim" status codes
(<https://github.com/httpwg/http-core/issues/245>) (<https://github.com/httpwg/http-core/issues/245>)
o In Section 9.3.5, caution against a request payload more strongly o In Section 9.3.5, caution against a request content more strongly
(<https://github.com/httpwg/http-core/issues/258>) (<https://github.com/httpwg/http-core/issues/258>)
o In Section 8.9.3, note that Etag can be used in trailers o In Section 8.8.3, note that Etag can be used in trailers
(<https://github.com/httpwg/http-core/issues/262>) (<https://github.com/httpwg/http-core/issues/262>)
o In Section 18.4, consider reserved fields as well o In Section 18.4, consider reserved fields as well
(<https://github.com/httpwg/http-core/issues/273>) (<https://github.com/httpwg/http-core/issues/273>)
o In Section 4.2.4, be more correct about what was deprecated by RFC o In Section 4.2.4, be more correct about what was deprecated by RFC
3986 (<https://github.com/httpwg/http-core/issues/278>, 3986 (<https://github.com/httpwg/http-core/issues/278>,
<https://www.rfc-editor.org/errata/eid5964>) <https://www.rfc-editor.org/errata/eid5964>)
o In Section 5.3, recommend comma SP when combining field lines o In Section 5.3, recommend comma SP when combining field lines
skipping to change at page 214, line 38 skipping to change at page 218, line 35
C.9. Since draft-ietf-httpbis-semantics-07 C.9. Since draft-ietf-httpbis-semantics-07
o In Section 14.2, explicitly reference the definition of o In Section 14.2, explicitly reference the definition of
representation data as including any content codings representation data as including any content codings
(<https://github.com/httpwg/http-core/issues/11>) (<https://github.com/httpwg/http-core/issues/11>)
o Move TE: trailers from [Messaging] into Section 6.5.1 o Move TE: trailers from [Messaging] into Section 6.5.1
(<https://github.com/httpwg/http-core/issues/18>) (<https://github.com/httpwg/http-core/issues/18>)
o In Section 8.7, adjust requirements for handling multiple content- o In Section 8.6, adjust requirements for handling multiple content-
length values (<https://github.com/httpwg/http-core/issues/59>) length values (<https://github.com/httpwg/http-core/issues/59>)
o In Section 13.1.1 and Section 13.1.2, clarified condition o In Section 13.1.1 and Section 13.1.2, clarified condition
evaluation (<https://github.com/httpwg/http-core/issues/72>) evaluation (<https://github.com/httpwg/http-core/issues/72>)
o In Section 5.5, remove concept of obs-fold, as that is o In Section 5.5, remove concept of obs-fold, as that is
HTTP/1-specific (<https://github.com/httpwg/http-core/issues/116>) HTTP/1-specific (<https://github.com/httpwg/http-core/issues/116>)
o In Section 12, introduce the concept of request payload o In Section 12, introduce the concept of request content
negotiation (Section 12.3) and define for Accept-Encoding negotiation (Section 12.3) and define for Accept-Encoding
(<https://github.com/httpwg/http-core/issues/119>) (<https://github.com/httpwg/http-core/issues/119>)
o In Section 15.3.6, Section 15.5.9, and Section 15.5.14, remove o In Section 15.3.6, Section 15.5.9, and Section 15.5.14, remove
HTTP/1-specific, connection-related requirements HTTP/1-specific, connection-related requirements
(<https://github.com/httpwg/http-core/issues/144>) (<https://github.com/httpwg/http-core/issues/144>)
o In Section 9.3.6, correct language about what is forwarded o In Section 9.3.6, correct language about what is forwarded
(<https://github.com/httpwg/http-core/issues/170>) (<https://github.com/httpwg/http-core/issues/170>)
o Throughout, replace "effective request URI", "request-target" and o Throughout, replace "effective request URI", "request-target" and
similar with "target URI" (<https://github.com/httpwg/http-core/ similar with "target URI" (<https://github.com/httpwg/http-core/
issues/259>) issues/259>)
o In Section 16.3.3 and Section 16.2.2, describe how extensions o In Section 16.3.2.2 and Section 16.2.2, describe how extensions
should consider scope of applicability should consider scope of applicability
(<https://github.com/httpwg/http-core/issues/265>) (<https://github.com/httpwg/http-core/issues/265>)
o In Section 3.3, don't rely on the HTTP/1.1 Messaging specification o In Section 3.4, don't rely on the HTTP/1.1 Messaging specification
to define "message" (<https://github.com/httpwg/http-core/ to define "message" (<https://github.com/httpwg/http-core/
issues/311>) issues/311>)
o In Section 8.8 and Section 10.1.3, note that URL resolution is o In Section 8.7 and Section 10.1.3, note that URL resolution is
necessary (<https://github.com/httpwg/http-core/issues/321>) necessary (<https://github.com/httpwg/http-core/issues/321>)
o In Section 8, explicitly reference 206 as one of the status codes o In Section 3.2, explicitly reference 206 as one of the status
that provide representation data (<https://github.com/httpwg/http- codes that provide representation data
core/issues/325>) (<https://github.com/httpwg/http-core/issues/325>)
o In Section 13.1.4, refine requirements so that they don't apply to o In Section 13.1.4, refine requirements so that they don't apply to
resources without a concept of modification time resources without a concept of modification time
(<https://github.com/httpwg/http-core/issues/326>) (<https://github.com/httpwg/http-core/issues/326>)
o In Section 11.7.1, specify the scope as a request, not a target o In Section 11.7.1, specify the scope as a request, not a target
resource (<https://github.com/httpwg/http-core/issues/331>) resource (<https://github.com/httpwg/http-core/issues/331>)
o In Section 3.3, introduce concept of "complete" messages o In Section 3.4, introduce concept of "complete" messages
(<https://github.com/httpwg/http-core/issues/334>) (<https://github.com/httpwg/http-core/issues/334>)
o In Section 7.1, Section 9.3.6, and Section 9.3.7, refine use of o In Section 7.1, Section 9.3.6, and Section 9.3.7, refine use of
"request target" (<https://github.com/httpwg/http-core/ "request target" (<https://github.com/httpwg/http-core/
issues/340>) issues/340>)
o Throughout, remove "status-line" and "request-line", as these are o Throughout, remove "status-line" and "request-line", as these are
HTTP/1.1-specific (<https://github.com/httpwg/http-core/ HTTP/1.1-specific (<https://github.com/httpwg/http-core/
issues/361>) issues/361>)
skipping to change at page 216, line 39 skipping to change at page 220, line 36
(<https://github.com/httpwg/http-core/issues/274>) (<https://github.com/httpwg/http-core/issues/274>)
o In Section 13.1.1 and Section 13.1.2, state that multiple "*" is o In Section 13.1.1 and Section 13.1.2, state that multiple "*" is
unlikely to be interoperable (<https://github.com/httpwg/http- unlikely to be interoperable (<https://github.com/httpwg/http-
core/issues/305>) core/issues/305>)
o In Section 12.5.1, avoid use of obsolete media type parameter on o In Section 12.5.1, avoid use of obsolete media type parameter on
text/html (<https://github.com/httpwg/http-core/issues/375>, text/html (<https://github.com/httpwg/http-core/issues/375>,
<https://www.rfc-editor.org/errata/eid6149>) <https://www.rfc-editor.org/errata/eid6149>)
o Rephrase prose in Section 3.3 to become version-agnostic o Rephrase prose in Section 3.4 to become version-agnostic
(<https://github.com/httpwg/http-core/issues/372>) (<https://github.com/httpwg/http-core/issues/372>)
o In Section 5.5, instruct recipients how to deal with control o In Section 5.5, instruct recipients how to deal with control
characters in field values (<https://github.com/httpwg/http-core/ characters in field values (<https://github.com/httpwg/http-core/
issues/377>) issues/377>)
o In Section 5.5, update note about field ABNF o In Section 5.5, update note about field ABNF
(<https://github.com/httpwg/http-core/issues/380>) (<https://github.com/httpwg/http-core/issues/380>)
o Add Section 16 about Extending and Versioning HTTP o Add Section 16 about Extending and Versioning HTTP
(<https://github.com/httpwg/http-core/issues/384>) (<https://github.com/httpwg/http-core/issues/384>)
o In Section 15.1, include status 308 in list of heuristically o In Section 15.1, include status 308 in list of heuristically
cacheable status codes (<https://github.com/httpwg/http-core/ cacheable status codes (<https://github.com/httpwg/http-core/
issues/385>) issues/385>)
o In Section 8.5, make it clearer that "identity" is not to be o In Section 8.4, make it clearer that "identity" is not to be
included (<https://github.com/httpwg/http-core/issues/388>) included (<https://github.com/httpwg/http-core/issues/388>)
C.11. Since draft-ietf-httpbis-semantics-09 C.11. Since draft-ietf-httpbis-semantics-09
o Switch to xml2rfc v3 mode for draft generation o Switch to xml2rfc v3 mode for draft generation
(<https://github.com/httpwg/http-core/issues/394>) (<https://github.com/httpwg/http-core/issues/394>)
C.12. Since draft-ietf-httpbis-semantics-10 C.12. Since draft-ietf-httpbis-semantics-10
o In Section 17.6, mention compression attacks o In Section 17.6, mention compression attacks
skipping to change at page 217, line 33 skipping to change at page 221, line 29
descriptive (<https://github.com/httpwg/http-core/issues/21>) descriptive (<https://github.com/httpwg/http-core/issues/21>)
o In Section 5.6.6, introduced the "parameters" ABNF rule, allowing o In Section 5.6.6, introduced the "parameters" ABNF rule, allowing
empty parameters and trailing semicolons within media type, media empty parameters and trailing semicolons within media type, media
range, and expectation (<https://github.com/httpwg/http-core/ range, and expectation (<https://github.com/httpwg/http-core/
issues/33>) issues/33>)
o In Section 15.4, explain how to create a redirected request o In Section 15.4, explain how to create a redirected request
(<https://github.com/httpwg/http-core/issues/38>) (<https://github.com/httpwg/http-core/issues/38>)
o In Section 8.4, defined error handling for multiple members o In Section 8.3, defined error handling for multiple members
(<https://github.com/httpwg/http-core/issues/39>) (<https://github.com/httpwg/http-core/issues/39>)
o In Section 1, revise the introduction and introduce HTTP/2 and o In Section 1, revise the introduction and introduce HTTP/2 and
HTTP/3 (<https://github.com/httpwg/http-core/issues/64>) HTTP/3 (<https://github.com/httpwg/http-core/issues/64>)
o In Section 8.7, added a definition for Content-Length that o In Section 8.6, added a definition for Content-Length that
encompasses its various roles in describing message payload or encompasses its various roles in describing message content or
selected representation length; in Section 15.3.7, noted that selected representation length; in Section 15.3.7, noted that
Content-Length counts only the message payload (not the selected Content-Length counts only the message content (not the selected
representation) and that the representation length is in each representation) and that the representation length is in each
Content-Range (<https://github.com/httpwg/http-core/issues/118>) Content-Range (<https://github.com/httpwg/http-core/issues/118>)
o Noted that "WWW-Authenticate" with more than one value on a line o Noted that "WWW-Authenticate" with more than one value on a line
is sometimes not interoperable [Messaging] is sometimes not interoperable [Messaging]
(<https://github.com/httpwg/http-core/issues/136>) (<https://github.com/httpwg/http-core/issues/136>)
o In Section 13.1.1 and Section 13.1.4, removed requirement that a o In Section 13.1.1 and Section 13.1.4, removed requirement that a
validator not be sent in a 2xx response when validation fails and validator not be sent in a 2xx response when validation fails and
the server decides that the same change request has already been the server decides that the same change request has already been
skipping to change at page 218, line 23 skipping to change at page 222, line 15
o In Section 5.5, introduce the terms "singleton field" and "list- o In Section 5.5, introduce the terms "singleton field" and "list-
based field" (also - in various places - discuss what to do when a based field" (also - in various places - discuss what to do when a
singleton field is received as a list) singleton field is received as a list)
(<https://github.com/httpwg/http-core/issues/193>) (<https://github.com/httpwg/http-core/issues/193>)
o In Section 10.1.1, change the ABNF back to be a list of o In Section 10.1.1, change the ABNF back to be a list of
expectations, as defined in RFC 2616 (<https://github.com/httpwg/ expectations, as defined in RFC 2616 (<https://github.com/httpwg/
http-core/issues/203>) http-core/issues/203>)
o In Section 10.1.5 (Trailer), Section 7.6.3 (Via), Section 7.8 o In Section 10.1.5 (Trailer), Section 7.6.3 (Via), Section 7.8
(Upgrade), Section 7.6.1 (Connection), Section 8.5 (Upgrade), Section 7.6.1 (Connection), Section 8.4
(Content-Encoding), Section 8.6 (Content-Language), Section 10.1.1 (Content-Encoding), Section 8.5 (Content-Language), Section 10.1.1
(Expect), Section 13.1.1 (If-Match), Section 13.1.2 (Expect), Section 13.1.1 (If-Match), Section 13.1.2
(If-None-Match), Section 12.5.2 (Accept-Charset), Section 12.5.4 (If-None-Match), Section 12.5.2 (Accept-Charset), Section 12.5.4
(Accept-Language), Section 12.5.5 (Vary), Section 11.6.1 (Accept-Language), Section 12.5.5 (Vary), Section 11.6.1
(WWW-Authenticate), and Section 11.7.1 (Proxy-Authenticate), (WWW-Authenticate), and Section 11.7.1 (Proxy-Authenticate),
adjust ABNF to allow empty lists (<https://github.com/httpwg/http- adjust ABNF to allow empty lists (<https://github.com/httpwg/http-
core/issues/210>) core/issues/210>)
o In Section 9.3.1 and Section 17.9, provide a more nuanced o In Section 9.3.1 and Section 17.9, provide a more nuanced
explanation of sensitive data in GET-based forms and describe explanation of sensitive data in GET-based forms and describe
workarounds (<https://github.com/httpwg/http-core/issues/277>) workarounds (<https://github.com/httpwg/http-core/issues/277>)
o In Section 13.2, allow preconditions to be evaluated before the o In Section 13.2, allow preconditions to be evaluated before the
request payload (if any) is processed (<https://github.com/httpwg/ request content (if any) is processed (<https://github.com/httpwg/
http-core/issues/261>) http-core/issues/261>)
o In Section 6.3 and Section 6.5.2, allow for trailer fields in o In Section 6.3 and Section 6.5.2, allow for trailer fields in
multiple trailer sections, depending on the HTTP version and multiple trailer sections, depending on the HTTP version and
framing in use, with processing being iterative as each section is framing in use, with processing being iterative as each section is
received (<https://github.com/httpwg/http-core/issues/313>) received (<https://github.com/httpwg/http-core/issues/313>)
o Moved definitions of "TE" and "Upgrade" from [Messaging] o Moved definitions of "TE" and "Upgrade" from [Messaging]
(<https://github.com/httpwg/http-core/issues/392>) (<https://github.com/httpwg/http-core/issues/392>)
skipping to change at page 219, line 39 skipping to change at page 223, line 30
o In Section 5.3, constrain field combination to be within a section o In Section 5.3, constrain field combination to be within a section
(<https://github.com/httpwg/http-core/issues/454>) (<https://github.com/httpwg/http-core/issues/454>)
o In Section 5.6.7, mention that caching relaxes date sensitivity o In Section 5.6.7, mention that caching relaxes date sensitivity
(<https://github.com/httpwg/http-core/issues/473>) (<https://github.com/httpwg/http-core/issues/473>)
o In Section 18.4, moved "*" field registration into main table o In Section 18.4, moved "*" field registration into main table
(<https://github.com/httpwg/http-core/issues/476>) (<https://github.com/httpwg/http-core/issues/476>)
o In Section 1.2, reference [HTTP/0.9] (<https://github.com/httpwg/ o In Section 1.2, reference HTTP/0.9 (<https://github.com/httpwg/
http-core/issues/497>) http-core/issues/497>)
o In Section 9.3.4, clarify handling of unrecognized fields o In Section 9.3.4, clarify handling of unrecognized fields
(<https://github.com/httpwg/http-core/issues/502>) (<https://github.com/httpwg/http-core/issues/502>)
o In Section 15.2, align language about bodies and trailers with 204 o In Section 15.2, align language about bodies and trailers with 204
and 304 (<https://github.com/httpwg/http-core/issues/503>) and 304 (<https://github.com/httpwg/http-core/issues/503>)
o Moved table of content codings into Section 18.6, moved table of o Moved table of content codings into Section 18.6, moved table of
range units into Section 18.7 (<https://github.com/httpwg/http- range units into Section 18.7 (<https://github.com/httpwg/http-
core/issues/506>) core/issues/506>)
o In Section 6, add an abstract data type for message to help define o In Section 6, add an abstract data type for message to help define
semantics without being dependent on the specific structure of semantics without being dependent on the specific structure of
HTTP/1.1 (<https://github.com/httpwg/http-core/issues/557>) HTTP/1.1 (<https://github.com/httpwg/http-core/issues/557>)
o In Section 8.9.2.2, relax arbitrary 60-second comparison limit o In Section 8.8.2.2, relax arbitrary 60-second comparison limit
(<https://github.com/httpwg/http-core/issues/510>) (<https://github.com/httpwg/http-core/issues/510>)
o In Section 7.2, add ":authority" pseudo-header to Host discussion o In Section 7.2, add ":authority" pseudo-header to Host discussion
and make section applicable to both (<https://github.com/httpwg/ and make section applicable to both (<https://github.com/httpwg/
http-core/issues/511>) http-core/issues/511>)
o In Section 18.4, note that this document updates [RFC3864] o In Section 18.4, note that this document updates [RFC3864]
(<https://github.com/httpwg/http-core/issues/515>) (<https://github.com/httpwg/http-core/issues/515>)
o Moved transfer-coding ABNF from [Messaging] to Section 10.1.4 and o Moved transfer-coding ABNF from [Messaging] to Section 10.1.4 and
replaced "t-ranking" ABNF by equivalent "weight" replaced "t-ranking" ABNF by equivalent "weight"
(<https://github.com/httpwg/http-core/issues/531>) (<https://github.com/httpwg/http-core/issues/531>)
o In Section 11.5, replace "canonical root URI" by "origin" o In Section 11.5, replace "canonical root URI" by "origin"
(<https://github.com/httpwg/http-core/issues/542>) (<https://github.com/httpwg/http-core/issues/542>)
o In Section 10.1.1, remove obsolete note about a change in RFC 723x o In Section 10.1.1, remove obsolete note about a change in RFC 723x
(<https://github.com/httpwg/http-core/issues/547>) (<https://github.com/httpwg/http-core/issues/547>)
o Changed to using "payload data" when defining requirements about o Changed to using "payload" when defining requirements about the
the data being conveyed within a message, instead of the terms data being conveyed within a message, instead of the terms
"payload body" or "response body" or "representation body", since "payload body" or "response body" or "representation body", since
they often get confused with the HTTP/1.1 message body (which they often get confused with the HTTP/1.1 message body (which
includes transfer coding) (<https://github.com/httpwg/http-core/ includes transfer coding) (<https://github.com/httpwg/http-core/
issues/553>) issues/553>)
o Rewrite definition of HEAD method (<https://github.com/httpwg/ o Rewrite definition of HEAD method (<https://github.com/httpwg/
http-core/issues/559>) http-core/issues/559>)
o In Section 13.1.5, fix an off-by-one bug about how many chars to o In Section 13.1.5, fix an off-by-one bug about how many chars to
consider when checking for etags (<https://github.com/httpwg/http- consider when checking for etags (<https://github.com/httpwg/http-
skipping to change at page 221, line 17 skipping to change at page 225, line 5
o In Section 18.3, remove redundant text about status code 418 o In Section 18.3, remove redundant text about status code 418
(<https://github.com/httpwg/http-core/issues/583>) (<https://github.com/httpwg/http-core/issues/583>)
o In Section 17.15.1, rewrite requirement to refer to "secured o In Section 17.15.1, rewrite requirement to refer to "secured
connection" (<https://github.com/httpwg/http-core/issues/587>) connection" (<https://github.com/httpwg/http-core/issues/587>)
o Make reference to [RFC8446] normative (<https://github.com/httpwg/ o Make reference to [RFC8446] normative (<https://github.com/httpwg/
http-core/issues/589>) http-core/issues/589>)
C.15. Since draft-ietf-httpbis-semantics-13
o In Section 12.5.1, remove the unused "accept parameters"
(<https://github.com/httpwg/http-core/issues/568>)
o In Section 1.2, mention that RFC 1945 describes HTTP/0.9 as well
(<https://github.com/httpwg/http-core/issues/614>)
o In Section 14.5, describe non-standard use of the Content-Range
header field (Section 14.4) as a request modifier to perform a
partial PUT (<https://github.com/httpwg/http-core/issues/618>)
o In Section 15.5.20, import the 421 (Misdirected Request) status
code from [RFC7540] (<https://github.com/httpwg/http-core/
issues/622>)
o In Section 2.3, rephrase the actual recipient parsing requirements
(<https://github.com/httpwg/http-core/issues/634>)
o In Section 16.1.2, mention request target forms in considerations
for new methods (<https://github.com/httpwg/http-core/issues/636>)
o Changed to using "content" instead of "payload" or "payload data"
to avoid confusion with the payload of version-specific messaging
frames (<https://github.com/httpwg/http-core/issues/654>)
o In Section 13.1.3, Section 13.1.4, and Section 13.1.5, specify
evaluation in a way similar to other conditional header fields
(<https://github.com/httpwg/http-core/issues/665>)
o In Section 10.2.2, specify that recipients can replace an invalid
Date header field value with the time received
(<https://github.com/httpwg/http-core/issues/669>)
Acknowledgments Acknowledgments
This edition of the HTTP specification builds on the many This edition of the HTTP specification builds on the many
contributions that went into RFC 1945, RFC 2068, RFC 2145, RFC 2616, contributions that went into RFC 1945, RFC 2068, RFC 2145, RFC 2616,
and RFC 2818, including substantial contributions made by the and RFC 2818, including substantial contributions made by the
previous authors, editors, and Working Group Chairs: Tim Berners-Lee, previous authors, editors, and Working Group Chairs: Tim Berners-Lee,
Jean-François Groff, Ari Luotonen, Roy T. Fielding, Henrik Frystyk Jean-François Groff, Ari Luotonen, Roy T. Fielding, Henrik Frystyk
Nielsen, Jim Gettys, Jeffrey C. Mogul, Larry Masinter, Paul J. Nielsen, Jim Gettys, Jeffrey C. Mogul, Larry Masinter, Paul J.
Leach, Eric Rescorla, and Yves Lafon. Leach, Eric Rescorla, and Yves Lafon.
skipping to change at page 222, line 13 skipping to change at page 226, line 24
reviewing text, and evaluating open issues: reviewing text, and evaluating open issues:
Alan Egerton, Alex Rousskov, Amichai Rothman, Amos Jeffries, Anders Alan Egerton, Alex Rousskov, Amichai Rothman, Amos Jeffries, Anders
Kaseorg, Andreas Gebhardt, Anne van Kesteren, Armin Abfalterer, Aron Kaseorg, Andreas Gebhardt, Anne van Kesteren, Armin Abfalterer, Aron
Duby, Asanka Herath, Asbjørn Ulsberg, Attila Gulyas, Austin Wright, Duby, Asanka Herath, Asbjørn Ulsberg, Attila Gulyas, Austin Wright,
Barry Pollard, Ben Burkert, Björn Höhrmann, Brad Fitzpatrick, Chris Barry Pollard, Ben Burkert, Björn Höhrmann, Brad Fitzpatrick, Chris
Pacejo, Colin Bendell, Cory Benfield, Cory Nelson, Daisuke Miyakawa, Pacejo, Colin Bendell, Cory Benfield, Cory Nelson, Daisuke Miyakawa,
Daniel Stenberg, Danil Suits, David Benjamin, David Matson, David Daniel Stenberg, Danil Suits, David Benjamin, David Matson, David
Schinazi, Дилян Палаузов (Dilyan Palauzov), Eric Anderson, Eric Schinazi, Дилян Палаузов (Dilyan Palauzov), Eric Anderson, Eric
Rescorla, Erwin Pe, Etan Kissling, Evert Pot, Evgeny Vrublevsky, Rescorla, Erwin Pe, Etan Kissling, Evert Pot, Evgeny Vrublevsky,
Florian Best, Igor Lubashev, James Callahan, Jeffrey Yasskin, Kalin Florian Best, Igor Lubashev, James Callahan, James Peach, Jeffrey
Gyokov, Kannan Goundan, Kazuho Oku, Ken Murchison, Lucas Pardue, Yasskin, Kalin Gyokov, Kannan Goundan, 奥 一穂 (Kazuho Oku), Ken
Martin Dürst, Martin Thomson, Martynas Jusevičius, Matt Menke, Murchison, Lucas Pardue, Martin Dürst, Martin Thomson, Martynas
Matthias Pigulla, Michael Osipov, Mike Bishop, Mike Pennisi, Mike Jusevičius, Matt Menke, Matthias Pigulla, Michael Osipov, Mike
West, Nicholas Hurley, Nikita Piskunov, Patrick McManus, Piotr Bishop, Mike Pennisi, Mike West, Nicholas Hurley, Nikita Piskunov,
Sikora, Poul-Henning Kamp, Rick van Rein, Roberto Polli, Semyon Patrick McManus, Piotr Sikora, Poul-Henning Kamp, Rick van Rein,
Kholodnov, Simon Pieters, Simon Schüppel, Todd Greer, Tommy Pauly, Roberto Polli, Semyon Kholodnov, Simon Pieters, Simon Schüppel, Todd
Vasiliy Faronov, Vladimir Lashchev, Wenbo Zhu, William A. Rowe Jr., Greer, Tommy Pauly, Vasiliy Faronov, Vladimir Lashchev, Wenbo Zhu,
Willy Tarreau, Xingwei Liu, and Yishuai Li. William A. Rowe Jr., Willy Tarreau, Xingwei Liu, and Yishuai Li.
See Section 10 of [RFC7230] for further acknowledgements from prior See Section 10 of [RFC7230] for further acknowledgements from prior
revisions. revisions.
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
 End of changes. 401 change blocks. 
1044 lines changed or deleted 1225 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/