draft-ietf-httpbis-semantics-15.txt   draft-ietf-httpbis-semantics-16.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: 1 October 2021 30 March 2021 Expires: 28 November 2021 27 May 2021
HTTP Semantics HTTP Semantics
draft-ietf-httpbis-semantics-15 draft-ietf-httpbis-semantics-16
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 describes the overall architecture of HTTP, systems. This document describes the overall architecture of HTTP,
establishes common terminology, and defines aspects of the protocol establishes common terminology, and defines aspects of the protocol
that are shared by all versions. In this definition are core that are shared by all versions. In this definition are core
protocol elements, extensibility mechanisms, and the "http" and 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 updates RFC 3864 and obsoletes RFC 2818, RFC 7231, RFC
7235, RFC 7538, RFC 7615, RFC 7694, and portions of RFC 7230. 7232, RFC 7233, RFC 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.16. The changes in this draft are summarized in Appendix C.17.
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 1 October 2021. This Internet-Draft will expire on 28 November 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 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
skipping to change at page 2, line 42 skipping to change at page 2, line 47
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 . . . . . . . . . . . . . . . . . . . . . 11
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 . . . . . . . . . . . . . . . . . . . . . 12 2.1. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 12
2.2. Requirements Notation . . . . . . . . . . . . . . . . . . 12 2.2. Requirements Notation . . . . . . . . . . . . . . . . . . 13
2.3. Length Requirements . . . . . . . . . . . . . . . . . . . 13 2.3. Length Requirements . . . . . . . . . . . . . . . . . . . 14
2.4. Error Handling . . . . . . . . . . . . . . . . . . . . . 14 2.4. Error Handling . . . . . . . . . . . . . . . . . . . . . 15
2.5. Protocol Version . . . . . . . . . . . . . . . . . . . . 15 2.5. Protocol Version . . . . . . . . . . . . . . . . . . . . 15
3. Terminology and Core Concepts . . . . . . . . . . . . . . . . 15 3. Terminology and Core Concepts . . . . . . . . . . . . . . . . 16
3.1. Resources . . . . . . . . . . . . . . . . . . . . . . . . 16 3.1. Resources . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2. Representations . . . . . . . . . . . . . . . . . . . . . 16 3.2. Representations . . . . . . . . . . . . . . . . . . . . . 17
3.3. Connections, Clients and Servers . . . . . . . . . . . . 17 3.3. Connections, Clients and Servers . . . . . . . . . . . . 17
3.4. Messages . . . . . . . . . . . . . . . . . . . . . . . . 17 3.4. Messages . . . . . . . . . . . . . . . . . . . . . . . . 18
3.5. User Agents . . . . . . . . . . . . . . . . . . . . . . . 18 3.5. User Agents . . . . . . . . . . . . . . . . . . . . . . . 18
3.6. Origin Server . . . . . . . . . . . . . . . . . . . . . . 19 3.6. Origin Server . . . . . . . . . . . . . . . . . . . . . . 19
3.7. Intermediaries . . . . . . . . . . . . . . . . . . . . . 19 3.7. Intermediaries . . . . . . . . . . . . . . . . . . . . . 20
3.8. Caches . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.8. Caches . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.9. Example Message Exchange . . . . . . . . . . . . . . . . 22 3.9. Example Message Exchange . . . . . . . . . . . . . . . . 22
4. Identifiers in HTTP . . . . . . . . . . . . . . . . . . . . . 22 4. Identifiers in HTTP . . . . . . . . . . . . . . . . . . . . . 23
4.1. URI References . . . . . . . . . . . . . . . . . . . . . 22 4.1. URI References . . . . . . . . . . . . . . . . . . . . . 23
4.2. HTTP-Related URI Schemes . . . . . . . . . . . . . . . . 23 4.2. HTTP-Related URI Schemes . . . . . . . . . . . . . . . . 24
4.2.1. http URI Scheme . . . . . . . . . . . . . . . . . . . 24 4.2.1. http URI Scheme . . . . . . . . . . . . . . . . . . . 25
4.2.2. https URI Scheme . . . . . . . . . . . . . . . . . . 25 4.2.2. https URI Scheme . . . . . . . . . . . . . . . . . . 25
4.2.3. http(s) Normalization and Comparison . . . . . . . . 25 4.2.3. http(s) Normalization and Comparison . . . . . . . . 26
4.2.4. Deprecation of userinfo in http(s) URIs . . . . . . . 26 4.2.4. Deprecation of userinfo in http(s) URIs . . . . . . . 27
4.2.5. http(s) References with Fragment Identifiers . . . . 27 4.2.5. http(s) References with Fragment Identifiers . . . . 27
4.3. Authoritative Access . . . . . . . . . . . . . . . . . . 27 4.3. Authoritative Access . . . . . . . . . . . . . . . . . . 28
4.3.1. URI Origin . . . . . . . . . . . . . . . . . . . . . 27 4.3.1. URI Origin . . . . . . . . . . . . . . . . . . . . . 28
4.3.2. http origins . . . . . . . . . . . . . . . . . . . . 28 4.3.2. http origins . . . . . . . . . . . . . . . . . . . . 29
4.3.3. https origins . . . . . . . . . . . . . . . . . . . . 29 4.3.3. https origins . . . . . . . . . . . . . . . . . . . . 30
4.3.4. https certificate verification . . . . . . . . . . . 30 4.3.4. https certificate verification . . . . . . . . . . . 31
4.3.5. IP-ID reference identity . . . . . . . . . . . . . . 31 4.3.5. IP-ID reference identity . . . . . . . . . . . . . . 32
5. Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 5. Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.1. Field Names . . . . . . . . . . . . . . . . . . . . . . . 32 5.1. Field Names . . . . . . . . . . . . . . . . . . . . . . . 32
5.2. Field Lines and Combined Field Value . . . . . . . . . . 32 5.2. Field Lines and Combined Field Value . . . . . . . . . . 33
5.3. Field Order . . . . . . . . . . . . . . . . . . . . . . . 33 5.3. Field Order . . . . . . . . . . . . . . . . . . . . . . . 34
5.4. Field Limits . . . . . . . . . . . . . . . . . . . . . . 34 5.4. Field Limits . . . . . . . . . . . . . . . . . . . . . . 35
5.5. Field Values . . . . . . . . . . . . . . . . . . . . . . 34 5.5. Field Values . . . . . . . . . . . . . . . . . . . . . . 35
5.6. Common Rules for Defining Field Values . . . . . . . . . 36 5.6. Common Rules for Defining Field Values . . . . . . . . . 37
5.6.1. Lists (#rule ABNF Extension) . . . . . . . . . . . . 36 5.6.1. Lists (#rule ABNF Extension) . . . . . . . . . . . . 37
5.6.2. Tokens . . . . . . . . . . . . . . . . . . . . . . . 37 5.6.1.1. Sender Requirements . . . . . . . . . . . . . . . 37
5.6.3. Whitespace . . . . . . . . . . . . . . . . . . . . . 38 5.6.1.2. Recipient Requirements . . . . . . . . . . . . . 38
5.6.2. Tokens . . . . . . . . . . . . . . . . . . . . . . . 38
5.6.3. Whitespace . . . . . . . . . . . . . . . . . . . . . 39
5.6.4. Quoted Strings . . . . . . . . . . . . . . . . . . . 39 5.6.4. Quoted Strings . . . . . . . . . . . . . . . . . . . 39
5.6.5. Comments . . . . . . . . . . . . . . . . . . . . . . 39 5.6.5. Comments . . . . . . . . . . . . . . . . . . . . . . 40
5.6.6. Parameters . . . . . . . . . . . . . . . . . . . . . 39 5.6.6. Parameters . . . . . . . . . . . . . . . . . . . . . 40
5.6.7. Date/Time Formats . . . . . . . . . . . . . . . . . . 40 5.6.7. Date/Time Formats . . . . . . . . . . . . . . . . . . 41
6. Message Abstraction . . . . . . . . . . . . . . . . . . . . . 42 6. Message Abstraction . . . . . . . . . . . . . . . . . . . . . 43
6.1. Framing and Completeness . . . . . . . . . . . . . . . . 43 6.1. Framing and Completeness . . . . . . . . . . . . . . . . 44
6.2. Control Data . . . . . . . . . . . . . . . . . . . . . . 44 6.2. Control Data . . . . . . . . . . . . . . . . . . . . . . 45
6.3. Header Fields . . . . . . . . . . . . . . . . . . . . . . 45 6.3. Header Fields . . . . . . . . . . . . . . . . . . . . . . 46
6.4. Content . . . . . . . . . . . . . . . . . . . . . . . . . 45 6.4. Content . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.4.1. Content Semantics . . . . . . . . . . . . . . . . . . 45 6.4.1. Content Semantics . . . . . . . . . . . . . . . . . . 46
6.4.2. Identifying Content . . . . . . . . . . . . . . . . . 46 6.4.2. Identifying Content . . . . . . . . . . . . . . . . . 47
6.5. Trailer Fields . . . . . . . . . . . . . . . . . . . . . 47 6.5. Trailer Fields . . . . . . . . . . . . . . . . . . . . . 48
6.5.1. Limitations on use of Trailers . . . . . . . . . . . 48 6.5.1. Limitations on use of Trailers . . . . . . . . . . . 49
6.5.2. Processing Trailer Fields . . . . . . . . . . . . . . 49 6.5.2. Processing Trailer Fields . . . . . . . . . . . . . . 50
7. Routing HTTP Messages . . . . . . . . . . . . . . . . . . . . 49 7. Routing HTTP Messages . . . . . . . . . . . . . . . . . . . . 50
7.1. Determining the Target Resource . . . . . . . . . . . . . 49 7.1. Determining the Target Resource . . . . . . . . . . . . . 50
7.2. Host and :authority . . . . . . . . . . . . . . . . . . . 50 7.2. Host and :authority . . . . . . . . . . . . . . . . . . . 51
7.3. Routing Inbound Requests . . . . . . . . . . . . . . . . 51 7.3. Routing Inbound Requests . . . . . . . . . . . . . . . . 52
7.3.1. To a Cache . . . . . . . . . . . . . . . . . . . . . 51 7.3.1. To a Cache . . . . . . . . . . . . . . . . . . . . . 52
7.3.2. To a Proxy . . . . . . . . . . . . . . . . . . . . . 51 7.3.2. To a Proxy . . . . . . . . . . . . . . . . . . . . . 52
7.3.3. To the Origin . . . . . . . . . . . . . . . . . . . . 51 7.3.3. To the Origin . . . . . . . . . . . . . . . . . . . . 52
7.4. Rejecting Misdirected Requests . . . . . . . . . . . . . 52 7.4. Rejecting Misdirected Requests . . . . . . . . . . . . . 53
7.5. Response Correlation . . . . . . . . . . . . . . . . . . 52 7.5. Response Correlation . . . . . . . . . . . . . . . . . . 53
7.6. Message Forwarding . . . . . . . . . . . . . . . . . . . 53 7.6. Message Forwarding . . . . . . . . . . . . . . . . . . . 54
7.6.1. Connection . . . . . . . . . . . . . . . . . . . . . 53 7.6.1. Connection . . . . . . . . . . . . . . . . . . . . . 54
7.6.2. Max-Forwards . . . . . . . . . . . . . . . . . . . . 55 7.6.2. Max-Forwards . . . . . . . . . . . . . . . . . . . . 56
7.6.3. Via . . . . . . . . . . . . . . . . . . . . . . . . . 56 7.6.3. Via . . . . . . . . . . . . . . . . . . . . . . . . . 57
7.7. Message Transformations . . . . . . . . . . . . . . . . . 57 7.7. Message Transformations . . . . . . . . . . . . . . . . . 58
7.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 58 7.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 59
8. Representation Data and Metadata . . . . . . . . . . . . . . 61 8. Representation Data and Metadata . . . . . . . . . . . . . . 62
8.1. Representation Data . . . . . . . . . . . . . . . . . . . 61 8.1. Representation Data . . . . . . . . . . . . . . . . . . . 62
8.2. Representation Metadata . . . . . . . . . . . . . . . . . 61 8.2. Representation Metadata . . . . . . . . . . . . . . . . . 62
8.3. Content-Type . . . . . . . . . . . . . . . . . . . . . . 61 8.3. Content-Type . . . . . . . . . . . . . . . . . . . . . . 62
8.3.1. Media Type . . . . . . . . . . . . . . . . . . . . . 62 8.3.1. Media Type . . . . . . . . . . . . . . . . . . . . . 63
8.3.2. Charset . . . . . . . . . . . . . . . . . . . . . . . 63 8.3.2. Charset . . . . . . . . . . . . . . . . . . . . . . . 64
8.3.3. Multipart Types . . . . . . . . . . . . . . . . . . . 63 8.3.3. Multipart Types . . . . . . . . . . . . . . . . . . . 64
8.4. Content-Encoding . . . . . . . . . . . . . . . . . . . . 64 8.4. Content-Encoding . . . . . . . . . . . . . . . . . . . . 65
8.4.1. Content Codings . . . . . . . . . . . . . . . . . . . 65 8.4.1. Content Codings . . . . . . . . . . . . . . . . . . . 66
8.5. Content-Language . . . . . . . . . . . . . . . . . . . . 66 8.4.1.1. Compress Coding . . . . . . . . . . . . . . . . . 66
8.5.1. Language Tags . . . . . . . . . . . . . . . . . . . . 67 8.4.1.2. Deflate Coding . . . . . . . . . . . . . . . . . 66
8.6. Content-Length . . . . . . . . . . . . . . . . . . . . . 67 8.4.1.3. Gzip Coding . . . . . . . . . . . . . . . . . . . 67
8.7. Content-Location . . . . . . . . . . . . . . . . . . . . 69 8.5. Content-Language . . . . . . . . . . . . . . . . . . . . 67
8.8. Validator Fields . . . . . . . . . . . . . . . . . . . . 71 8.5.1. Language Tags . . . . . . . . . . . . . . . . . . . . 68
8.8.1. Weak versus Strong . . . . . . . . . . . . . . . . . 71 8.6. Content-Length . . . . . . . . . . . . . . . . . . . . . 68
8.8.2. Last-Modified . . . . . . . . . . . . . . . . . . . . 73 8.7. Content-Location . . . . . . . . . . . . . . . . . . . . 70
8.8.3. ETag . . . . . . . . . . . . . . . . . . . . . . . . 75 8.8. Validator Fields . . . . . . . . . . . . . . . . . . . . 72
8.8.4. When to Use Entity-Tags and Last-Modified Dates . . . 78 8.8.1. Weak versus Strong . . . . . . . . . . . . . . . . . 72
9. Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 8.8.2. Last-Modified . . . . . . . . . . . . . . . . . . . . 74
9.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 79 8.8.2.1. Generation . . . . . . . . . . . . . . . . . . . 74
9.2. Common Method Properties . . . . . . . . . . . . . . . . 81 8.8.2.2. Comparison . . . . . . . . . . . . . . . . . . . 75
9.2.1. Safe Methods . . . . . . . . . . . . . . . . . . . . 81 8.8.3. ETag . . . . . . . . . . . . . . . . . . . . . . . . 76
9.2.2. Idempotent Methods . . . . . . . . . . . . . . . . . 82 8.8.3.1. Generation . . . . . . . . . . . . . . . . . . . 77
9.2.3. Methods and Caching . . . . . . . . . . . . . . . . . 83 8.8.3.2. Comparison . . . . . . . . . . . . . . . . . . . 77
9.3. Method Definitions . . . . . . . . . . . . . . . . . . . 83 8.8.3.3. Example: Entity-Tags Varying on Content-Negotiated
9.3.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 83 Resources . . . . . . . . . . . . . . . . . . . . . 78
9.3.2. HEAD . . . . . . . . . . . . . . . . . . . . . . . . 84 8.8.4. When to Use Entity-Tags and Last-Modified Dates . . . 79
9.3.3. POST . . . . . . . . . . . . . . . . . . . . . . . . 85 9. Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
9.3.4. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 86 9.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 80
9.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . 89 9.2. Common Method Properties . . . . . . . . . . . . . . . . 82
9.3.6. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 90 9.2.1. Safe Methods . . . . . . . . . . . . . . . . . . . . 82
9.3.7. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 91 9.2.2. Idempotent Methods . . . . . . . . . . . . . . . . . 83
9.3.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . 92 9.2.3. Methods and Caching . . . . . . . . . . . . . . . . . 84
10. Message Context . . . . . . . . . . . . . . . . . . . . . . . 93 9.3. Method Definitions . . . . . . . . . . . . . . . . . . . 84
10.1. Request Context Fields . . . . . . . . . . . . . . . . . 93 9.3.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 84
10.1.1. Expect . . . . . . . . . . . . . . . . . . . . . . . 93 9.3.2. HEAD . . . . . . . . . . . . . . . . . . . . . . . . 85
10.1.2. From . . . . . . . . . . . . . . . . . . . . . . . . 95 9.3.3. POST . . . . . . . . . . . . . . . . . . . . . . . . 86
10.1.3. Referer . . . . . . . . . . . . . . . . . . . . . . 96 9.3.4. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 87
10.1.4. TE . . . . . . . . . . . . . . . . . . . . . . . . . 97 9.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . 90
10.1.5. Trailer . . . . . . . . . . . . . . . . . . . . . . 98 9.3.6. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 91
10.1.6. User-Agent . . . . . . . . . . . . . . . . . . . . . 98 9.3.7. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 92
10.2. Response Context Fields . . . . . . . . . . . . . . . . 99 9.3.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . 93
10.2.1. Allow . . . . . . . . . . . . . . . . . . . . . . . 100 10. Message Context . . . . . . . . . . . . . . . . . . . . . . . 94
10.2.2. Date . . . . . . . . . . . . . . . . . . . . . . . . 100 10.1. Request Context Fields . . . . . . . . . . . . . . . . . 94
10.2.3. Location . . . . . . . . . . . . . . . . . . . . . . 101 10.1.1. Expect . . . . . . . . . . . . . . . . . . . . . . . 94
10.2.4. Retry-After . . . . . . . . . . . . . . . . . . . . 103 10.1.2. From . . . . . . . . . . . . . . . . . . . . . . . . 96
10.2.5. Server . . . . . . . . . . . . . . . . . . . . . . . 103 10.1.3. Referer . . . . . . . . . . . . . . . . . . . . . . 97
11. HTTP Authentication . . . . . . . . . . . . . . . . . . . . . 104 10.1.4. TE . . . . . . . . . . . . . . . . . . . . . . . . . 98
11.1. Authentication Scheme . . . . . . . . . . . . . . . . . 104 10.1.5. Trailer . . . . . . . . . . . . . . . . . . . . . . 99
11.2. Authentication Parameters . . . . . . . . . . . . . . . 104 10.1.6. User-Agent . . . . . . . . . . . . . . . . . . . . . 99
11.3. Challenge and Response . . . . . . . . . . . . . . . . . 105 10.2. Response Context Fields . . . . . . . . . . . . . . . . 100
11.4. Credentials . . . . . . . . . . . . . . . . . . . . . . 106 10.2.1. Allow . . . . . . . . . . . . . . . . . . . . . . . 101
11.5. Establishing a Protection Space (Realm) . . . . . . . . 106 10.2.2. Date . . . . . . . . . . . . . . . . . . . . . . . . 101
11.6. Authenticating Users to Origin Servers . . . . . . . . . 107 10.2.3. Location . . . . . . . . . . . . . . . . . . . . . . 102
11.6.1. WWW-Authenticate . . . . . . . . . . . . . . . . . . 107 10.2.4. Retry-After . . . . . . . . . . . . . . . . . . . . 104
11.6.2. Authorization . . . . . . . . . . . . . . . . . . . 108 10.2.5. Server . . . . . . . . . . . . . . . . . . . . . . . 104
11.6.3. Authentication-Info . . . . . . . . . . . . . . . . 109 11. HTTP Authentication . . . . . . . . . . . . . . . . . . . . . 105
11.7. Authenticating Clients to Proxies . . . . . . . . . . . 109 11.1. Authentication Scheme . . . . . . . . . . . . . . . . . 105
11.7.1. Proxy-Authenticate . . . . . . . . . . . . . . . . . 109 11.2. Authentication Parameters . . . . . . . . . . . . . . . 105
11.7.2. Proxy-Authorization . . . . . . . . . . . . . . . . 110 11.3. Challenge and Response . . . . . . . . . . . . . . . . . 106
11.7.3. Proxy-Authentication-Info . . . . . . . . . . . . . 110 11.4. Credentials . . . . . . . . . . . . . . . . . . . . . . 107
12. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 111 11.5. Establishing a Protection Space (Realm) . . . . . . . . 107
12.1. Proactive Negotiation . . . . . . . . . . . . . . . . . 112 11.6. Authenticating Users to Origin Servers . . . . . . . . . 108
12.2. Reactive Negotiation . . . . . . . . . . . . . . . . . . 113 11.6.1. WWW-Authenticate . . . . . . . . . . . . . . . . . . 108
12.3. Request Content Negotiation . . . . . . . . . . . . . . 114 11.6.2. Authorization . . . . . . . . . . . . . . . . . . . 109
12.4. Content Negotiation Field Features . . . . . . . . . . . 114 11.6.3. Authentication-Info . . . . . . . . . . . . . . . . 110
12.4.1. Absence . . . . . . . . . . . . . . . . . . . . . . 114 11.7. Authenticating Clients to Proxies . . . . . . . . . . . 110
12.4.2. Quality Values . . . . . . . . . . . . . . . . . . . 114 11.7.1. Proxy-Authenticate . . . . . . . . . . . . . . . . . 110
12.4.3. Wildcard Values . . . . . . . . . . . . . . . . . . 115 11.7.2. Proxy-Authorization . . . . . . . . . . . . . . . . 111
12.5. Content Negotiation Fields . . . . . . . . . . . . . . . 115 11.7.3. Proxy-Authentication-Info . . . . . . . . . . . . . 111
12.5.1. Accept . . . . . . . . . . . . . . . . . . . . . . . 115 12. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 112
12.5.2. Accept-Charset . . . . . . . . . . . . . . . . . . . 118 12.1. Proactive Negotiation . . . . . . . . . . . . . . . . . 113
12.5.3. Accept-Encoding . . . . . . . . . . . . . . . . . . 118 12.2. Reactive Negotiation . . . . . . . . . . . . . . . . . . 114
12.5.4. Accept-Language . . . . . . . . . . . . . . . . . . 120 12.3. Request Content Negotiation . . . . . . . . . . . . . . 115
12.5.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . 121 12.4. Content Negotiation Field Features . . . . . . . . . . . 115
13. Conditional Requests . . . . . . . . . . . . . . . . . . . . 123 12.4.1. Absence . . . . . . . . . . . . . . . . . . . . . . 115
13.1. Preconditions . . . . . . . . . . . . . . . . . . . . . 123 12.4.2. Quality Values . . . . . . . . . . . . . . . . . . . 115
13.1.1. If-Match . . . . . . . . . . . . . . . . . . . . . . 124 12.4.3. Wildcard Values . . . . . . . . . . . . . . . . . . 116
13.1.2. If-None-Match . . . . . . . . . . . . . . . . . . . 125 12.5. Content Negotiation Fields . . . . . . . . . . . . . . . 116
13.1.3. If-Modified-Since . . . . . . . . . . . . . . . . . 127 12.5.1. Accept . . . . . . . . . . . . . . . . . . . . . . . 116
13.1.4. If-Unmodified-Since . . . . . . . . . . . . . . . . 129 12.5.2. Accept-Charset . . . . . . . . . . . . . . . . . . . 119
13.1.5. If-Range . . . . . . . . . . . . . . . . . . . . . . 130 12.5.3. Accept-Encoding . . . . . . . . . . . . . . . . . . 119
13.2. Evaluation of Preconditions . . . . . . . . . . . . . . 131 12.5.4. Accept-Language . . . . . . . . . . . . . . . . . . 121
13.2.1. When to Evaluate . . . . . . . . . . . . . . . . . . 132 12.5.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . 122
13.2.2. Precedence of Preconditions . . . . . . . . . . . . 132 13. Conditional Requests . . . . . . . . . . . . . . . . . . . . 124
14. Range Requests . . . . . . . . . . . . . . . . . . . . . . . 134 13.1. Preconditions . . . . . . . . . . . . . . . . . . . . . 124
14.1. Range Units . . . . . . . . . . . . . . . . . . . . . . 134 13.1.1. If-Match . . . . . . . . . . . . . . . . . . . . . . 125
14.1.1. Range Specifiers . . . . . . . . . . . . . . . . . . 135 13.1.2. If-None-Match . . . . . . . . . . . . . . . . . . . 126
14.1.2. Byte Ranges . . . . . . . . . . . . . . . . . . . . 136 13.1.3. If-Modified-Since . . . . . . . . . . . . . . . . . 128
14.2. Range . . . . . . . . . . . . . . . . . . . . . . . . . 137 13.1.4. If-Unmodified-Since . . . . . . . . . . . . . . . . 130
14.3. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 139 13.1.5. If-Range . . . . . . . . . . . . . . . . . . . . . . 131
14.4. Content-Range . . . . . . . . . . . . . . . . . . . . . 139 13.2. Evaluation of Preconditions . . . . . . . . . . . . . . 132
14.5. Partial PUT . . . . . . . . . . . . . . . . . . . . . . 141 13.2.1. When to Evaluate . . . . . . . . . . . . . . . . . . 133
14.6. Media Type multipart/byteranges . . . . . . . . . . . . 142 13.2.2. Precedence of Preconditions . . . . . . . . . . . . 133
15. Status Codes . . . . . . . . . . . . . . . . . . . . . . . . 144 14. Range Requests . . . . . . . . . . . . . . . . . . . . . . . 135
15.1. Overview of Status Codes . . . . . . . . . . . . . . . . 145 14.1. Range Units . . . . . . . . . . . . . . . . . . . . . . 135
15.2. Informational 1xx . . . . . . . . . . . . . . . . . . . 145 14.1.1. Range Specifiers . . . . . . . . . . . . . . . . . . 136
15.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 146 14.1.2. Byte Ranges . . . . . . . . . . . . . . . . . . . . 137
15.2.2. 101 Switching Protocols . . . . . . . . . . . . . . 146 14.2. Range . . . . . . . . . . . . . . . . . . . . . . . . . 138
15.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . 146 14.3. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 140
15.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 147 14.4. Content-Range . . . . . . . . . . . . . . . . . . . . . 140
15.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . 147 14.5. Partial PUT . . . . . . . . . . . . . . . . . . . . . . 142
15.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . 148 14.6. Media Type multipart/byteranges . . . . . . . . . . . . 143
15.3.4. 203 Non-Authoritative Information . . . . . . . . . 148 15. Status Codes . . . . . . . . . . . . . . . . . . . . . . . . 145
15.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . 148 15.1. Overview of Status Codes . . . . . . . . . . . . . . . . 146
15.3.6. 205 Reset Content . . . . . . . . . . . . . . . . . 149 15.2. Informational 1xx . . . . . . . . . . . . . . . . . . . 146
15.3.7. 206 Partial Content . . . . . . . . . . . . . . . . 149 15.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 147
15.4. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 153 15.2.2. 101 Switching Protocols . . . . . . . . . . . . . . 147
15.4.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 155 15.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . 147
15.4.2. 301 Moved Permanently . . . . . . . . . . . . . . . 156 15.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 148
15.4.3. 302 Found . . . . . . . . . . . . . . . . . . . . . 156 15.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . 148
15.4.4. 303 See Other . . . . . . . . . . . . . . . . . . . 157 15.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . 149
15.4.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 158 15.3.4. 203 Non-Authoritative Information . . . . . . . . . 149
15.4.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 158 15.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . 149
15.4.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . 158 15.3.6. 205 Reset Content . . . . . . . . . . . . . . . . . 150
15.4.8. 307 Temporary Redirect . . . . . . . . . . . . . . . 159 15.3.7. 206 Partial Content . . . . . . . . . . . . . . . . 150
15.4.9. 308 Permanent Redirect . . . . . . . . . . . . . . . 159 15.3.7.1. Single Part . . . . . . . . . . . . . . . . . . 151
15.5. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 159 15.3.7.2. Multiple Parts . . . . . . . . . . . . . . . . . 152
15.5.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 160 15.3.7.3. Combining Parts . . . . . . . . . . . . . . . . 153
15.5.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 160 15.4. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 154
15.5.3. 402 Payment Required . . . . . . . . . . . . . . . . 160 15.4.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 156
15.5.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 160 15.4.2. 301 Moved Permanently . . . . . . . . . . . . . . . 157
15.5.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 161 15.4.3. 302 Found . . . . . . . . . . . . . . . . . . . . . 157
15.5.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 161 15.4.4. 303 See Other . . . . . . . . . . . . . . . . . . . 158
15.5.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 161 15.4.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 159
15.5.8. 407 Proxy Authentication Required . . . . . . . . . 162 15.4.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 159
15.5.9. 408 Request Timeout . . . . . . . . . . . . . . . . 162 15.4.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . 159
15.5.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . 162 15.4.8. 307 Temporary Redirect . . . . . . . . . . . . . . . 160
15.5.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 162 15.4.9. 308 Permanent Redirect . . . . . . . . . . . . . . . 160
15.5.12. 411 Length Required . . . . . . . . . . . . . . . . 163 15.5. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 160
15.5.13. 412 Precondition Failed . . . . . . . . . . . . . . 163 15.5.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 161
15.5.14. 413 Content Too Large . . . . . . . . . . . . . . . 163 15.5.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 161
15.5.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . 164 15.5.3. 402 Payment Required . . . . . . . . . . . . . . . . 161
15.5.16. 415 Unsupported Media Type . . . . . . . . . . . . . 164 15.5.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 161
15.5.17. 416 Range Not Satisfiable . . . . . . . . . . . . . 164 15.5.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 162
15.5.18. 417 Expectation Failed . . . . . . . . . . . . . . . 165 15.5.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 162
15.5.19. 418 (Unused) . . . . . . . . . . . . . . . . . . . . 165 15.5.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 162
15.5.20. 421 Misdirected Request . . . . . . . . . . . . . . 166 15.5.8. 407 Proxy Authentication Required . . . . . . . . . 163
15.5.21. 422 Unprocessable Content . . . . . . . . . . . . . 166 15.5.9. 408 Request Timeout . . . . . . . . . . . . . . . . 163
15.5.22. 426 Upgrade Required . . . . . . . . . . . . . . . . 166 15.5.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . 163
15.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 167 15.5.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 163
15.6.1. 500 Internal Server Error . . . . . . . . . . . . . 167 15.5.12. 411 Length Required . . . . . . . . . . . . . . . . 164
15.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . 167 15.5.13. 412 Precondition Failed . . . . . . . . . . . . . . 164
15.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 167 15.5.14. 413 Content Too Large . . . . . . . . . . . . . . . 164
15.6.4. 503 Service Unavailable . . . . . . . . . . . . . . 167 15.5.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . 165
15.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 168 15.5.16. 415 Unsupported Media Type . . . . . . . . . . . . . 165
15.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . 168 15.5.17. 416 Range Not Satisfiable . . . . . . . . . . . . . 165
16. Extending HTTP . . . . . . . . . . . . . . . . . . . . . . . 168 15.5.18. 417 Expectation Failed . . . . . . . . . . . . . . . 166
16.1. Method Extensibility . . . . . . . . . . . . . . . . . . 169 15.5.19. 418 (Unused) . . . . . . . . . . . . . . . . . . . . 166
16.1.1. Method Registry . . . . . . . . . . . . . . . . . . 169 15.5.20. 421 Misdirected Request . . . . . . . . . . . . . . 167
16.1.2. Considerations for New Methods . . . . . . . . . . . 169 15.5.21. 422 Unprocessable Content . . . . . . . . . . . . . 167
16.2. Status Code Extensibility . . . . . . . . . . . . . . . 170 15.5.22. 426 Upgrade Required . . . . . . . . . . . . . . . . 167
16.2.1. Status Code Registry . . . . . . . . . . . . . . . . 170 15.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 168
16.2.2. Considerations for New Status Codes . . . . . . . . 170 15.6.1. 500 Internal Server Error . . . . . . . . . . . . . 168
16.3. Field Extensibility . . . . . . . . . . . . . . . . . . 171 15.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . 168
16.3.1. Field Name Registry . . . . . . . . . . . . . . . . 172 15.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 168
16.3.2. Considerations for New Fields . . . . . . . . . . . 173 15.6.4. 503 Service Unavailable . . . . . . . . . . . . . . 168
16.4. Authentication Scheme Extensibility . . . . . . . . . . 175 15.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 169
16.4.1. Authentication Scheme Registry . . . . . . . . . . . 176 15.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . 169
16.4.2. Considerations for New Authentication Schemes . . . 176 16. Extending HTTP . . . . . . . . . . . . . . . . . . . . . . . 169
16.5. Range Unit Extensibility . . . . . . . . . . . . . . . . 177 16.1. Method Extensibility . . . . . . . . . . . . . . . . . . 170
16.5.1. Range Unit Registry . . . . . . . . . . . . . . . . 178 16.1.1. Method Registry . . . . . . . . . . . . . . . . . . 170
16.5.2. Considerations for New Range Units . . . . . . . . . 178 16.1.2. Considerations for New Methods . . . . . . . . . . . 170
16.6. Content Coding Extensibility . . . . . . . . . . . . . . 178 16.2. Status Code Extensibility . . . . . . . . . . . . . . . 171
16.6.1. Content Coding Registry . . . . . . . . . . . . . . 178 16.2.1. Status Code Registry . . . . . . . . . . . . . . . . 171
16.6.2. Considerations for New Content Codings . . . . . . . 179 16.2.2. Considerations for New Status Codes . . . . . . . . 171
16.7. Upgrade Token Registry . . . . . . . . . . . . . . . . . 179 16.3. Field Extensibility . . . . . . . . . . . . . . . . . . 172
17. Security Considerations . . . . . . . . . . . . . . . . . . . 180 16.3.1. Field Name Registry . . . . . . . . . . . . . . . . 173
17.1. Establishing Authority . . . . . . . . . . . . . . . . . 180 16.3.2. Considerations for New Fields . . . . . . . . . . . 174
17.2. Risks of Intermediaries . . . . . . . . . . . . . . . . 181 16.3.2.1. Considerations for New Field Names . . . . . . . 175
17.3. Attacks Based on File and Path Names . . . . . . . . . . 182 16.3.2.2. Considerations for New Field Values . . . . . . 176
17.4. Attacks Based on Command, Code, or Query Injection . . . 182 16.4. Authentication Scheme Extensibility . . . . . . . . . . 176
17.5. Attacks via Protocol Element Length . . . . . . . . . . 183 16.4.1. Authentication Scheme Registry . . . . . . . . . . . 177
17.6. Attacks using Shared-dictionary Compression . . . . . . 183 16.4.2. Considerations for New Authentication Schemes . . . 177
17.7. Disclosure of Personal Information . . . . . . . . . . . 184 16.5. Range Unit Extensibility . . . . . . . . . . . . . . . . 178
17.8. Privacy of Server Log Information . . . . . . . . . . . 184 16.5.1. Range Unit Registry . . . . . . . . . . . . . . . . 179
17.9. Disclosure of Sensitive Information in URIs . . . . . . 185 16.5.2. Considerations for New Range Units . . . . . . . . . 179
17.10. Disclosure of Fragment after Redirects . . . . . . . . . 185 16.6. Content Coding Extensibility . . . . . . . . . . . . . . 179
17.11. Disclosure of Product Information . . . . . . . . . . . 186 16.6.1. Content Coding Registry . . . . . . . . . . . . . . 179
17.12. Browser Fingerprinting . . . . . . . . . . . . . . . . . 186 16.6.2. Considerations for New Content Codings . . . . . . . 180
17.13. Validator Retention . . . . . . . . . . . . . . . . . . 187 16.7. Upgrade Token Registry . . . . . . . . . . . . . . . . . 180
17.14. Denial-of-Service Attacks Using Range . . . . . . . . . 187 17. Security Considerations . . . . . . . . . . . . . . . . . . . 181
17.15. Authentication Considerations . . . . . . . . . . . . . 188 17.1. Establishing Authority . . . . . . . . . . . . . . . . . 181
17.15.1. Confidentiality of Credentials . . . . . . . . . . 188 17.2. Risks of Intermediaries . . . . . . . . . . . . . . . . 182
17.15.2. Credentials and Idle Clients . . . . . . . . . . . 188 17.3. Attacks Based on File and Path Names . . . . . . . . . . 183
17.15.3. Protection Spaces . . . . . . . . . . . . . . . . . 189 17.4. Attacks Based on Command, Code, or Query Injection . . . 183
17.15.4. Additional Response Fields . . . . . . . . . . . . 189 17.5. Attacks via Protocol Element Length . . . . . . . . . . 184
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 189 17.6. Attacks using Shared-dictionary Compression . . . . . . 184
18.1. URI Scheme Registration . . . . . . . . . . . . . . . . 190 17.7. Disclosure of Personal Information . . . . . . . . . . . 185
18.2. Method Registration . . . . . . . . . . . . . . . . . . 190 17.8. Privacy of Server Log Information . . . . . . . . . . . 185
18.3. Status Code Registration . . . . . . . . . . . . . . . . 190 17.9. Disclosure of Sensitive Information in URIs . . . . . . 186
18.4. Field Name Registration . . . . . . . . . . . . . . . . 193 17.10. Application Handling of Field Names . . . . . . . . . . 186
18.5. Authentication Scheme Registration . . . . . . . . . . . 195 17.11. Disclosure of Fragment after Redirects . . . . . . . . . 187
18.6. Content Coding Registration . . . . . . . . . . . . . . 196 17.12. Disclosure of Product Information . . . . . . . . . . . 188
18.7. Range Unit Registration . . . . . . . . . . . . . . . . 196 17.13. Browser Fingerprinting . . . . . . . . . . . . . . . . . 188
18.8. Media Type Registration . . . . . . . . . . . . . . . . 197 17.14. Validator Retention . . . . . . . . . . . . . . . . . . 189
18.9. Port Registration . . . . . . . . . . . . . . . . . . . 197 17.15. Denial-of-Service Attacks Using Range . . . . . . . . . 189
18.10. Upgrade Token Registration . . . . . . . . . . . . . . . 197 17.16. Authentication Considerations . . . . . . . . . . . . . 190
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 197 17.16.1. Confidentiality of Credentials . . . . . . . . . . 190
19.1. Normative References . . . . . . . . . . . . . . . . . . 197 17.16.2. Credentials and Idle Clients . . . . . . . . . . . 190
19.2. Informative References . . . . . . . . . . . . . . . . . 199 17.16.3. Protection Spaces . . . . . . . . . . . . . . . . . 191
Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 205 17.16.4. Additional Response Fields . . . . . . . . . . . . 191
Appendix B. Changes from previous RFCs . . . . . . . . . . . . . 210 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 191
B.1. Changes from RFC 2818 . . . . . . . . . . . . . . . . . . 210 18.1. URI Scheme Registration . . . . . . . . . . . . . . . . 192
B.2. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 210 18.2. Method Registration . . . . . . . . . . . . . . . . . . 192
B.3. Changes from RFC 7231 . . . . . . . . . . . . . . . . . . 211 18.3. Status Code Registration . . . . . . . . . . . . . . . . 192
B.4. Changes from RFC 7232 . . . . . . . . . . . . . . . . . . 213 18.4. Field Name Registration . . . . . . . . . . . . . . . . 195
B.5. Changes from RFC 7233 . . . . . . . . . . . . . . . . . . 213 18.5. Authentication Scheme Registration . . . . . . . . . . . 197
B.6. Changes from RFC 7235 . . . . . . . . . . . . . . . . . . 214 18.6. Content Coding Registration . . . . . . . . . . . . . . 198
B.7. Changes from RFC 7538 . . . . . . . . . . . . . . . . . . 214 18.7. Range Unit Registration . . . . . . . . . . . . . . . . 198
B.8. Changes from RFC 7615 . . . . . . . . . . . . . . . . . . 214 18.8. Media Type Registration . . . . . . . . . . . . . . . . 199
B.9. Changes from RFC 7694 . . . . . . . . . . . . . . . . . . 214 18.9. Port Registration . . . . . . . . . . . . . . . . . . . 199
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 214 18.10. Upgrade Token Registration . . . . . . . . . . . . . . . 199
C.1. Between RFC723x and draft 00 . . . . . . . . . . . . . . 214 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 199
C.2. Since draft-ietf-httpbis-semantics-00 . . . . . . . . . . 215 19.1. Normative References . . . . . . . . . . . . . . . . . . 199
C.3. Since draft-ietf-httpbis-semantics-01 . . . . . . . . . . 215 19.2. Informative References . . . . . . . . . . . . . . . . . 201
C.4. Since draft-ietf-httpbis-semantics-02 . . . . . . . . . . 216 Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 208
C.5. Since draft-ietf-httpbis-semantics-03 . . . . . . . . . . 217 Appendix B. Changes from previous RFCs . . . . . . . . . . . . . 212
C.6. Since draft-ietf-httpbis-semantics-04 . . . . . . . . . . 218 B.1. Changes from RFC 2818 . . . . . . . . . . . . . . . . . . 212
C.7. Since draft-ietf-httpbis-semantics-05 . . . . . . . . . . 219 B.2. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 213
C.8. Since draft-ietf-httpbis-semantics-06 . . . . . . . . . . 220 B.3. Changes from RFC 7231 . . . . . . . . . . . . . . . . . . 213
C.9. Since draft-ietf-httpbis-semantics-07 . . . . . . . . . . 221 B.4. Changes from RFC 7232 . . . . . . . . . . . . . . . . . . 215
C.10. Since draft-ietf-httpbis-semantics-08 . . . . . . . . . . 223 B.5. Changes from RFC 7233 . . . . . . . . . . . . . . . . . . 216
C.11. Since draft-ietf-httpbis-semantics-09 . . . . . . . . . . 224 B.6. Changes from RFC 7235 . . . . . . . . . . . . . . . . . . 216
C.12. Since draft-ietf-httpbis-semantics-10 . . . . . . . . . . 224 B.7. Changes from RFC 7538 . . . . . . . . . . . . . . . . . . 216
C.13. Since draft-ietf-httpbis-semantics-11 . . . . . . . . . . 226 B.8. Changes from RFC 7615 . . . . . . . . . . . . . . . . . . 216
C.14. Since draft-ietf-httpbis-semantics-12 . . . . . . . . . . 226 B.9. Changes from RFC 7694 . . . . . . . . . . . . . . . . . . 216
C.15. Since draft-ietf-httpbis-semantics-13 . . . . . . . . . . 228 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 216
C.16. Since draft-ietf-httpbis-semantics-14 . . . . . . . . . . 229 C.1. Between RFC723x and draft 00 . . . . . . . . . . . . . . 216
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 231 C.2. Since draft-ietf-httpbis-semantics-00 . . . . . . . . . . 217
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 232 C.3. Since draft-ietf-httpbis-semantics-01 . . . . . . . . . . 217
C.4. Since draft-ietf-httpbis-semantics-02 . . . . . . . . . . 219
C.5. Since draft-ietf-httpbis-semantics-03 . . . . . . . . . . 220
C.6. Since draft-ietf-httpbis-semantics-04 . . . . . . . . . . 220
C.7. Since draft-ietf-httpbis-semantics-05 . . . . . . . . . . 221
C.8. Since draft-ietf-httpbis-semantics-06 . . . . . . . . . . 222
C.9. Since draft-ietf-httpbis-semantics-07 . . . . . . . . . . 224
C.10. Since draft-ietf-httpbis-semantics-08 . . . . . . . . . . 225
C.11. Since draft-ietf-httpbis-semantics-09 . . . . . . . . . . 226
C.12. Since draft-ietf-httpbis-semantics-10 . . . . . . . . . . 226
C.13. Since draft-ietf-httpbis-semantics-11 . . . . . . . . . . 228
C.14. Since draft-ietf-httpbis-semantics-12 . . . . . . . . . . 228
C.15. Since draft-ietf-httpbis-semantics-13 . . . . . . . . . . 230
C.16. Since draft-ietf-httpbis-semantics-14 . . . . . . . . . . 231
C.17. Since draft-ietf-httpbis-semantics-15 . . . . . . . . . . 233
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 234
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 246
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 33, line 9 skipping to change at page 33, line 35
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 with Field sections are composed of any number of _field lines_, each with
a _field name_ (see Section 5.1) identifying the field, and a _field a _field name_ (see Section 5.1) identifying the field, and a _field
line value_ that conveys data for that instance of the field. line value_ that conveys data for that instance of the 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 line _field value_ for that field consists of the corresponding field line
value. When a field name is repeated within a section, its combined value. When a field name is repeated within a section, its combined
field value consists of the list of corresponding field line values field value consists of the list of corresponding field line values
within that section, concatenated in order, with each non-empty field within that section, concatenated in order, with each field line
line value separated by a comma. 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".
5.3. Field Order 5.3. Field Order
A recipient MAY combine multiple field lines within a field section A recipient MAY combine multiple field lines within a field section
that have the same field name into one field line, without changing that have the same field name into one field line, without changing
the semantics of the message, by appending each subsequent field line the semantics of the message, by appending each subsequent field line
value to the initial field line value in order, separated by a comma value to the initial field line value in order, separated by a comma
and OWS (optional whitespace). For consistency, use comma SP. (",") and optional whitespace (OWS, defined in Section 5.6.3). For
consistency, use comma SP.
The order in which field lines with the same name are received is The order in which field lines with the same name are received is
therefore significant to the interpretation of the field value; a therefore significant to the interpretation of the field value; a
proxy MUST NOT change the order of these field line values when proxy MUST NOT change the order of these field line values when
forwarding a message. forwarding a message.
This means that, aside from the well-known exception noted below, a This means that, aside from the well-known exception noted below, a
sender MUST NOT generate multiple field lines with the same name in a sender MUST NOT generate multiple field lines with the same name in a
message (whether in the headers or trailers), or append a field line message (whether in the headers or trailers), or append a field line
when a field line of the same name already exists in the message, when a field line of the same name already exists in the message,
skipping to change at page 36, line 38 skipping to change at page 37, line 27
5.6. Common Rules for Defining Field Values 5.6. Common Rules for Defining Field Values
5.6.1. Lists (#rule ABNF Extension) 5.6.1. Lists (#rule ABNF Extension)
A #rule extension to the ABNF rules of [RFC5234] is used to improve A #rule extension to the ABNF rules of [RFC5234] is used to improve
readability in the definitions of some list-based field values. readability in the definitions of some list-based field values.
A construct "#" is defined, similar to "*", for defining comma- A construct "#" is defined, similar to "*", for defining comma-
delimited lists of elements. The full form is "<n>#<m>element" delimited lists of elements. The full form is "<n>#<m>element"
indicating at least <n> and at most <m> elements, each separated by a indicating at least <n> and at most <m> elements, each separated by a
single comma (",") and optional whitespace (OWS). single comma (",") and optional whitespace (OWS, defined in
Section 5.6.3).
5.6.1.1. Sender Requirements 5.6.1.1. Sender Requirements
In any production that uses the list construct, a sender MUST NOT In any production that uses the list construct, a sender MUST NOT
generate empty list elements. In other words, a sender MUST generate generate empty list elements. In other words, a sender MUST generate
lists that satisfy the following syntax: lists that satisfy the following syntax:
1#element => element *( OWS "," OWS element ) 1#element => element *( OWS "," OWS element )
and: and:
skipping to change at page 85, line 5 skipping to change at page 86, line 5
determined only while generating the content. 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 content 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 content within a HEAD request message has no defined semantics; A client SHOULD NOT generate content in a HEAD request. Content
sending content in a HEAD request might cause some existing received in a HEAD request has no defined semantics, cannot alter the
implementations to reject the request. meaning or target of the request, and might lead some implementations
to reject the request and close the connection because of its
potential as a request smuggling attack (Section 11.2 of
[Messaging]).
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
The POST method requests that the target resource process the The POST method requests that the target resource process the
skipping to change at page 106, line 16 skipping to change at page 107, line 16
Both the Authorization field value and the Proxy-Authorization field Both the Authorization field value and the Proxy-Authorization field
value contain the client's credentials for the realm of the resource value contain the client's credentials for the realm of the resource
being requested, based upon a challenge received in a response being requested, based upon a challenge received in a response
(possibly at some point in the past). When creating their values, (possibly at some point in the past). When creating their values,
the user agent ought to do so by selecting the challenge with what it the user agent ought to do so by selecting the challenge with what it
considers to be the most secure auth-scheme that it understands, considers to be the most secure auth-scheme that it understands,
obtaining credentials from the user as appropriate. Transmission of obtaining credentials from the user as appropriate. Transmission of
credentials within header field values implies significant security credentials within header field values implies significant security
considerations regarding the confidentiality of the underlying considerations regarding the confidentiality of the underlying
connection, as described in Section 17.15.1. connection, as described in Section 17.16.1.
credentials = auth-scheme [ 1*SP ( token68 / #auth-param ) ] credentials = auth-scheme [ 1*SP ( token68 / #auth-param ) ]
Upon receipt of a request for a protected resource that omits Upon receipt of a request for a protected resource that omits
credentials, contains invalid credentials (e.g., a bad password) or credentials, contains invalid credentials (e.g., a bad password) or
partial credentials (e.g., when the authentication scheme requires partial credentials (e.g., when the authentication scheme requires
more than one round trip), an origin server SHOULD send a 401 more than one round trip), an origin server SHOULD send a 401
(Unauthorized) response that contains a WWW-Authenticate header field (Unauthorized) response that contains a WWW-Authenticate header field
with at least one (possibly new) challenge applicable to the with at least one (possibly new) challenge applicable to the
requested resource. requested resource.
skipping to change at page 114, line 38 skipping to change at page 115, line 38
none of the available representations for the response can be none of the available representations for the response can be
considered acceptable according to it, the origin server can either considered acceptable according to it, the origin server can either
honor the header field by sending a 406 (Not Acceptable) response or honor the header field by sending a 406 (Not Acceptable) response or
disregard the header field by treating the response as if it is not disregard the header field by treating the response as if it is not
subject to content negotiation for that request header field. This subject to content negotiation for that request header field. This
does not imply, however, that the client will be able to use the does not imply, however, that the client will be able to use the
representation. representation.
| *Note:* Sending these header fields makes it easier for a | *Note:* Sending these header fields makes it easier for a
| server to identify an individual by virtue of the user agent's | server to identify an individual by virtue of the user agent's
| request characteristics (Section 17.12). | request characteristics (Section 17.13).
12.4.2. Quality Values 12.4.2. Quality Values
The content negotiation fields defined by this specification use a The content negotiation fields defined by this specification use a
common parameter, named "q" (case-insensitive), to assign a relative common parameter, named "q" (case-insensitive), to assign a relative
"weight" to the preference for that associated kind of content. This "weight" to the preference for that associated kind of content. This
weight is referred to as a "quality value" (or "qvalue") because the weight is referred to as a "quality value" (or "qvalue") because the
same parameter name is often used within server configurations to same parameter name is often used within server configurations to
assign a weight to the relative quality of the various assign a weight to the relative quality of the various
representations that can be selected for a resource. representations that can be selected for a resource.
skipping to change at page 118, line 35 skipping to change at page 119, line 35
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.13). 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.4.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.
skipping to change at page 121, line 24 skipping to change at page 122, line 24
found in Section 2.3 of [RFC4647]. found in Section 2.3 of [RFC4647].
For matching, Section 3 of [RFC4647] defines several matching For matching, Section 3 of [RFC4647] defines several matching
schemes. Implementations can offer the most appropriate matching schemes. Implementations can offer the most appropriate matching
scheme for their requirements. The "Basic Filtering" scheme scheme for their requirements. The "Basic Filtering" scheme
([RFC4647], Section 3.3.1) is identical to the matching scheme that ([RFC4647], Section 3.3.1) is identical to the matching scheme that
was previously defined for HTTP in Section 14.4 of [RFC2616]. was previously defined for HTTP in Section 14.4 of [RFC2616].
It might be contrary to the privacy expectations of the user to send It might be contrary to the privacy expectations of the user to send
an Accept-Language header field with the complete linguistic an Accept-Language header field with the complete linguistic
preferences of the user in every request (Section 17.12). preferences of the user in every request (Section 17.13).
Since intelligibility is highly dependent on the individual user, Since intelligibility is highly dependent on the individual user,
user agents need to allow user control over the linguistic preference user agents need to allow user control over the linguistic preference
(either through configuration of the user agent itself or by (either through configuration of the user agent itself or by
defaulting to a user controllable system setting). A user agent that defaulting to a user controllable system setting). A user agent that
does not provide such control to the user MUST NOT send an Accept- does not provide such control to the user MUST NOT send an Accept-
Language header field. Language header field.
| *Note:* User agents ought to provide guidance to users when | *Note:* User agents ought to provide guidance to users when
| setting a preference, since users are rarely familiar with the | setting a preference, since users are rarely familiar with the
skipping to change at page 138, line 18 skipping to change at page 139, line 18
range handling is defined. range handling is defined.
An origin server MUST ignore a Range header field that contains a An origin server MUST ignore a Range header field that contains a
range unit it does not understand. A proxy MAY discard a Range range unit it does not understand. A proxy MAY discard a Range
header field that contains a range unit it does not understand. header field that contains a range unit it does not understand.
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.15). 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 content (i.e., the selected when the selected representation has no content (i.e., the 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
skipping to change at page 174, line 49 skipping to change at page 175, line 49
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 that use (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. For example, the
underscore ("_") character can be problematic when passed through
non-HTTP gateway interfaces (see Section 17.10).
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.2.2. Considerations for New Field Values 16.3.2.2. Considerations for New Field Values
skipping to change at page 177, line 45 skipping to change at page 178, line 45
Therefore, new authentication schemes that choose not to carry Therefore, new authentication schemes that choose not to carry
credentials in the Authorization header field (e.g., using a newly credentials in the Authorization header field (e.g., using a newly
defined header field) will need to explicitly disallow caching, by defined header field) will need to explicitly disallow caching, by
mandating the use of Cache-Control response directives (e.g., mandating the use of Cache-Control response directives (e.g.,
"private"). "private").
* Schemes using Authentication-Info, Proxy-Authentication-Info, or * Schemes using Authentication-Info, Proxy-Authentication-Info, or
any other authentication related response header field need to any other authentication related response header field need to
consider and document the related security considerations (see consider and document the related security considerations (see
Section 17.15.4). Section 17.16.4).
16.5. Range Unit Extensibility 16.5. Range Unit Extensibility
16.5.1. Range Unit Registry 16.5.1. Range Unit Registry
The "HTTP Range Unit Registry" defines the namespace for the range The "HTTP Range Unit Registry" defines the namespace for the range
unit names and refers to their corresponding specifications. It is unit names and refers to their corresponding specifications. It is
maintained at <https://www.iana.org/assignments/http-parameters>. maintained at <https://www.iana.org/assignments/http-parameters>.
Registration of an HTTP Range Unit MUST include the following fields: Registration of an HTTP Range Unit MUST include the following fields:
skipping to change at page 185, line 38 skipping to change at page 186, line 38
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
information about the user's immediate browsing history and any information about the user's immediate browsing history and any
personal information that might be found in the referring resource's personal information that might be found in the referring resource's
URI. Limitations on the Referer header field are described in URI. Limitations on the Referer header field are described in
Section 10.1.3 to address some of its security considerations. Section 10.1.3 to address some of its security considerations.
17.10. Disclosure of Fragment after Redirects 17.10. Application Handling of Field Names
Servers often use non-HTTP gateway interfaces and frameworks to
process a received request and produce content for the response. For
historical reasons, such interfaces often pass received field names
as external variable names, using a name mapping suitable for
environment variables.
For example, the Common Gateway Interface (CGI) mapping of protocol-
specific meta-variables, defined by Section 4.1.18 of [RFC3875], is
applied to received header fields that do not correspond to one of
CGI's standard variables; the mapping consists of prepending "HTTP_"
to each name and changing all instances of hyphen ("-") to underscore
("_"). This same mapping has been inherited by many other
application frameworks in order to simplify moving applications from
one platform to the next.
In CGI, a received Content-Length field would be passed as the meta-
variable "CONTENT_LENGTH" with a string value matching the received
field's value. In contrast, a received "Content_Length" header field
would be passed as the protocol-specific meta-variable
"HTTP_CONTENT_LENGTH", which might lead to some confusion if an
application mistakenly reads the protocol-specific meta-variable
instead of the default one. (This historical practice is why
Section 16.3.2.1 discourages the creation of new field names that
contain an underscore.)
Unfortunately, mapping field names to different interface names can
lead to security vulnerabilities if the mapping is incomplete or
ambiguous. For example, if an attacker were to send a field named
"Transfer_Encoding", a naive interface might map that to the same
variable name as the "Transfer-Encoding" field, resulting in a
potential request smuggling vulnerability (Section 11.2 of
[Messaging]).
To mitigate the associated risks, implementations that perform such
mappings are advised to make the mapping unambiguous and complete for
the full range of potential octets received as a name (including
those that are discouraged or forbidden by the HTTP grammar). For
example, a field with an unusual name character might result in the
request being blocked, the specific field being removed, or the name
being passed with a different prefix to distinguish it from other
fields.
17.11. Disclosure of Fragment after Redirects
Although fragment identifiers used within URI references are not sent Although fragment identifiers used within URI references are not sent
in requests, implementers ought to be aware that they will be visible in requests, implementers ought to be aware that they will be visible
to the user agent and any extensions or scripts running as a result to the user agent and any extensions or scripts running as a result
of the response. In particular, when a redirect occurs and the of the response. In particular, when a redirect occurs and the
original request's fragment identifier is inherited by the new original request's fragment identifier is inherited by the new
reference in Location (Section 10.2.3), this might have the effect of reference in Location (Section 10.2.3), this might have the effect of
disclosing one site's fragment to another site. If the first site disclosing one site's fragment to another site. If the first site
uses personal information in fragments, it ought to ensure that uses personal information in fragments, it ought to ensure that
redirects to other sites include a (possibly empty) fragment redirects to other sites include a (possibly empty) fragment
component in order to block that inheritance. component in order to block that inheritance.
17.11. Disclosure of Product Information 17.12. Disclosure of Product Information
The User-Agent (Section 10.1.6), Via (Section 7.6.3), and Server The User-Agent (Section 10.1.6), Via (Section 7.6.3), and Server
(Section 10.2.5) header fields often reveal information about the (Section 10.2.5) header fields often reveal information about the
respective sender's software systems. In theory, this can make it respective sender's software systems. In theory, this can make it
easier for an attacker to exploit known security holes; in practice, easier for an attacker to exploit known security holes; in practice,
attackers tend to try all potential holes regardless of the apparent attackers tend to try all potential holes regardless of the apparent
software versions being used. software versions being used.
Proxies that serve as a portal through a network firewall ought to Proxies that serve as a portal through a network firewall ought to
take special precautions regarding the transfer of header information take special precautions regarding the transfer of header information
that might identify hosts behind the firewall. The Via header field that might identify hosts behind the firewall. The Via header field
allows intermediaries to replace sensitive machine names with allows intermediaries to replace sensitive machine names with
pseudonyms. pseudonyms.
17.12. Browser Fingerprinting 17.13. Browser Fingerprinting
Browser fingerprinting is a set of techniques for identifying a Browser fingerprinting is a set of techniques for identifying a
specific user agent over time through its unique set of specific user agent over time through its unique set of
characteristics. These characteristics might include information characteristics. These characteristics might include information
related to its TCP behavior, feature capabilities, and scripting related to its TCP behavior, feature capabilities, and scripting
environment, though of particular interest here is the set of unique environment, though of particular interest here is the set of unique
characteristics that might be communicated via HTTP. Fingerprinting characteristics that might be communicated via HTTP. Fingerprinting
is considered a privacy concern because it enables tracking of a user is considered a privacy concern because it enables tracking of a user
agent's behavior over time ([Bujlow]) without the corresponding agent's behavior over time ([Bujlow]) without the corresponding
controls that the user might have over other forms of data collection controls that the user might have over other forms of data collection
skipping to change at page 187, line 23 skipping to change at page 189, line 23
indicates language negotiation might be useful. indicates language negotiation might be useful.
In environments where proxies are used to enhance privacy, user In environments where proxies are used to enhance privacy, user
agents ought to be conservative in sending proactive negotiation agents ought to be conservative in sending proactive negotiation
header fields. General-purpose user agents that provide a high header fields. General-purpose user agents that provide a high
degree of header field configurability ought to inform users about degree of header field configurability ought to inform users about
the loss of privacy that might result if too much detail is provided. the loss of privacy that might result if too much detail is provided.
As an extreme privacy measure, proxies could filter the proactive As an extreme privacy measure, proxies could filter the proactive
negotiation header fields in relayed requests. negotiation header fields in relayed requests.
17.13. Validator Retention 17.14. Validator Retention
The validators defined by this specification are not intended to The validators defined by this specification are not intended to
ensure the validity of a representation, guard against malicious ensure the validity of a representation, guard against malicious
changes, or detect on-path attacks. At best, they enable more changes, or detect on-path attacks. At best, they enable more
efficient cache updates and optimistic concurrent writes when all efficient cache updates and optimistic concurrent writes when all
participants are behaving nicely. At worst, the conditions will fail participants are behaving nicely. At worst, the conditions will fail
and the client will receive a response that is no more harmful than and the client will receive a response that is no more harmful than
an HTTP exchange without conditional requests. an HTTP exchange without conditional requests.
An entity-tag can be abused in ways that create privacy risks. For An entity-tag can be abused in ways that create privacy risks. For
skipping to change at page 187, line 45 skipping to change at page 189, line 45
entity-tag that is unique to the user or user agent, send it in a entity-tag that is unique to the user or user agent, send it in a
cacheable response with a long freshness time, and then read that cacheable response with a long freshness time, and then read that
entity-tag in later conditional requests as a means of re-identifying entity-tag in later conditional requests as a means of re-identifying
that user or user agent. Such an identifying tag would become a that user or user agent. Such an identifying tag would become a
persistent identifier for as long as the user agent retained the persistent identifier for as long as the user agent retained the
original cache entry. User agents that cache representations ought original cache entry. User agents that cache representations ought
to ensure that the cache is cleared or replaced whenever the user to ensure that the cache is cleared or replaced whenever the user
performs privacy-maintaining actions, such as clearing stored cookies performs privacy-maintaining actions, such as clearing stored cookies
or changing to a private browsing mode. or changing to a private browsing mode.
17.14. Denial-of-Service Attacks Using Range 17.15. Denial-of-Service Attacks Using Range
Unconstrained multiple range requests are susceptible to denial-of- Unconstrained multiple range requests are susceptible to denial-of-
service attacks because the effort required to request many service attacks because the effort required to request many
overlapping ranges of the same data is tiny compared to the time, overlapping ranges of the same data is tiny compared to the time,
memory, and bandwidth consumed by attempting to serve the requested memory, and bandwidth consumed by attempting to serve the requested
data in many parts. Servers ought to ignore, coalesce, or reject data in many parts. Servers ought to ignore, coalesce, or reject
egregious range requests, such as requests for more than two egregious range requests, such as requests for more than two
overlapping ranges or for many small ranges in a single set, overlapping ranges or for many small ranges in a single set,
particularly when the ranges are requested out of order for no particularly when the ranges are requested out of order for no
apparent reason. Multipart range requests are not designed to apparent reason. Multipart range requests are not designed to
support random access. support random access.
17.15. Authentication Considerations 17.16. Authentication Considerations
Everything about the topic of HTTP authentication is a security Everything about the topic of HTTP authentication is a security
consideration, so the list of considerations below is not exhaustive. consideration, so the list of considerations below is not exhaustive.
Furthermore, it is limited to security considerations regarding the Furthermore, it is limited to security considerations regarding the
authentication framework, in general, rather than discussing all of authentication framework, in general, rather than discussing all of
the potential considerations for specific authentication schemes the potential considerations for specific authentication schemes
(which ought to be documented in the specifications that define those (which ought to be documented in the specifications that define those
schemes). Various organizations maintain topical information and schemes). Various organizations maintain topical information and
links to current research on Web application security (e.g., links to current research on Web application security (e.g.,
[OWASP]), including common pitfalls for implementing and using the [OWASP]), including common pitfalls for implementing and using the
authentication schemes found in practice. authentication schemes found in practice.
17.15.1. Confidentiality of Credentials 17.16.1. Confidentiality of Credentials
The HTTP authentication framework does not define a single mechanism The HTTP authentication framework does not define a single mechanism
for maintaining the confidentiality of credentials; instead, each for maintaining the confidentiality of credentials; instead, each
authentication scheme defines how the credentials are encoded prior authentication scheme defines how the credentials are encoded prior
to transmission. While this provides flexibility for the development to transmission. While this provides flexibility for the development
of future authentication schemes, it is inadequate for the protection of future authentication schemes, it is inadequate for the protection
of existing schemes that provide no confidentiality on their own, or of existing schemes that provide no confidentiality on their own, or
that do not sufficiently protect against replay attacks. that do not sufficiently protect against replay attacks.
Furthermore, if the server expects credentials that are specific to Furthermore, if the server expects credentials that are specific to
each individual user, the exchange of those credentials will have the each individual user, the exchange of those credentials will have the
effect of identifying that user even if the content within effect of identifying that user even if the content within
credentials remains confidential. credentials remains confidential.
HTTP depends on the security properties of the underlying transport- HTTP depends on the security properties of the underlying transport-
or session-level connection to provide confidential transmission of or session-level connection to provide confidential transmission of
fields. Services that depend on individual user authentication fields. Services that depend on individual user authentication
require a secured connection prior to exchanging credentials require a secured connection prior to exchanging credentials
(Section 4.2.2). (Section 4.2.2).
17.15.2. Credentials and Idle Clients 17.16.2. Credentials and Idle Clients
Existing HTTP clients and user agents typically retain authentication Existing HTTP clients and user agents typically retain authentication
information indefinitely. HTTP does not provide a mechanism for the information indefinitely. HTTP does not provide a mechanism for the
origin server to direct clients to discard these cached credentials, origin server to direct clients to discard these cached credentials,
since the protocol has no awareness of how credentials are obtained since the protocol has no awareness of how credentials are obtained
or managed by the user agent. The mechanisms for expiring or or managed by the user agent. The mechanisms for expiring or
revoking credentials can be specified as part of an authentication revoking credentials can be specified as part of an authentication
scheme definition. scheme definition.
Circumstances under which credential caching can interfere with the Circumstances under which credential caching can interfere with the
skipping to change at page 189, line 21 skipping to change at page 191, line 21
* Applications that include a session termination indication (such * Applications that include a session termination indication (such
as a "logout" or "commit" button on a page) after which the server as a "logout" or "commit" button on a page) after which the server
side of the application "knows" that there is no further reason side of the application "knows" that there is no further reason
for the client to retain the credentials. for the client to retain the credentials.
User agents that cache credentials are encouraged to provide a User agents that cache credentials are encouraged to provide a
readily accessible mechanism for discarding cached credentials under readily accessible mechanism for discarding cached credentials under
user control. user control.
17.15.3. Protection Spaces 17.16.3. Protection Spaces
Authentication schemes that solely rely on the "realm" mechanism for Authentication schemes that solely rely on the "realm" mechanism for
establishing a protection space will expose credentials to all establishing a protection space will expose credentials to all
resources on an origin server. Clients that have successfully made resources on an origin server. Clients that have successfully made
authenticated requests with a resource can use the same authenticated requests with a resource can use the same
authentication credentials for other resources on the same origin authentication credentials for other resources on the same origin
server. This makes it possible for a different resource to harvest server. This makes it possible for a different resource to harvest
authentication credentials for other resources. authentication credentials for other resources.
This is of particular concern when an origin server hosts resources This is of particular concern when an origin server hosts resources
for multiple parties under the same origin (Section 11.5). Possible for multiple parties under the same origin (Section 11.5). Possible
mitigation strategies include restricting direct access to mitigation strategies include restricting direct access to
authentication credentials (i.e., not making the content of the authentication credentials (i.e., not making the content of the
Authorization request header field available), and separating Authorization request header field available), and separating
protection spaces by using a different host name (or port number) for protection spaces by using a different host name (or port number) for
each party. each party.
17.15.4. Additional Response Fields 17.16.4. Additional Response Fields
Adding information to responses that are sent over an unencrypted Adding information to responses that are sent over an unencrypted
channel can affect security and privacy. The presence of the channel can affect security and privacy. The presence of the
Authentication-Info and Proxy-Authentication-Info header fields alone Authentication-Info and Proxy-Authentication-Info header fields alone
indicates that HTTP authentication is in use. Additional information indicates that HTTP authentication is in use. Additional information
could be exposed by the contents of the authentication-scheme could be exposed by the contents of the authentication-scheme
specific parameters; this will have to be considered in the specific parameters; this will have to be considered in the
definitions of these schemes. definitions of these schemes.
18. IANA Considerations 18. IANA Considerations
skipping to change at page 197, line 46 skipping to change at page 199, line 46
+------+-------------------+-------------------------+------+ +------+-------------------+-------------------------+------+
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-15, 30 March 2021, draft-ietf-httpbis-cache-16, 27 May 2021,
<https://tools.ietf.org/html/draft-ietf-httpbis-cache-15>. <https://tools.ietf.org/html/draft-ietf-httpbis-cache-16>.
[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 201, line 8 skipping to change at page 203, line 8
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>.
[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-15, 30 March 2021, ietf-httpbis-messaging-16, 27 May 2021,
<https://tools.ietf.org/html/draft-ietf-httpbis-messaging- <https://tools.ietf.org/html/draft-ietf-httpbis-messaging-
15>. 16>.
[OWASP] van der Stock, A., Ed., "A Guide to Building Secure Web [OWASP] van der Stock, A., Ed., "A Guide to Building Secure Web
Applications and Web Services", The Open Web Application Applications and Web Services", The Open Web Application
Security Project (OWASP) 2.0.1, 27 July 2005, Security Project (OWASP) 2.0.1, 27 July 2005,
<https://www.owasp.org/>. <https://www.owasp.org/>.
[REST] Fielding, R.T., "Architectural Styles and the Design of [REST] Fielding, R.T., "Architectural Styles and the Design of
Network-based Software Architectures", Network-based Software Architectures",
Doctoral Dissertation, University of California, Irvine, Doctoral Dissertation, University of California, Irvine,
September 2000, September 2000,
skipping to change at page 202, line 48 skipping to change at page 204, line 48
[RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web [RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web
Replication and Caching Taxonomy", RFC 3040, Replication and Caching Taxonomy", RFC 3040,
DOI 10.17487/RFC3040, January 2001, DOI 10.17487/RFC3040, January 2001,
<https://www.rfc-editor.org/info/rfc3040>. <https://www.rfc-editor.org/info/rfc3040>.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864, Procedures for Message Header Fields", BCP 90, RFC 3864,
DOI 10.17487/RFC3864, September 2004, DOI 10.17487/RFC3864, September 2004,
<https://www.rfc-editor.org/info/rfc3864>. <https://www.rfc-editor.org/info/rfc3864>.
[RFC3875] Robinson, D. and K. Coar, "The Common Gateway Interface
(CGI) Version 1.1", RFC 3875, DOI 10.17487/RFC3875,
October 2004, <https://www.rfc-editor.org/info/rfc3875>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005, RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/info/rfc4033>. <https://www.rfc-editor.org/info/rfc4033>.
[RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based
Kerberos and NTLM HTTP Authentication in Microsoft Kerberos and NTLM HTTP Authentication in Microsoft
Windows", RFC 4559, DOI 10.17487/RFC4559, June 2006, Windows", RFC 4559, DOI 10.17487/RFC4559, June 2006,
<https://www.rfc-editor.org/info/rfc4559>. <https://www.rfc-editor.org/info/rfc4559>.
skipping to change at page 204, line 15 skipping to change at page 206, line 20
[RFC7232] Fielding, R., Ed. and J. F. Reschke, Ed., "Hypertext [RFC7232] Fielding, R., Ed. and J. F. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Conditional Requests", Transfer Protocol (HTTP/1.1): Conditional Requests",
RFC 7232, DOI 10.17487/RFC7232, June 2014, RFC 7232, DOI 10.17487/RFC7232, June 2014,
<https://www.rfc-editor.org/info/rfc7232>. <https://www.rfc-editor.org/info/rfc7232>.
[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. F. Reschke, Ed., [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. F. Reschke, Ed.,
"Hypertext Transfer Protocol (HTTP/1.1): Range Requests", "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
RFC 7233, DOI 10.17487/RFC7233, June 2014, RFC 7233, DOI 10.17487/RFC7233, June 2014,
<https://www.rfc-editor.org/info/rfc7233>. <https://www.rfc-editor.org/info/rfc7233>.
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. F. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP): Caching",
RFC 7234, DOI 10.17487/RFC7234, June 2014,
<https://www.rfc-editor.org/info/rfc7234>.
[RFC7235] Fielding, R., Ed. and J. F. Reschke, Ed., "Hypertext [RFC7235] Fielding, R., Ed. and J. F. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, Transfer Protocol (HTTP/1.1): Authentication", RFC 7235,
DOI 10.17487/RFC7235, June 2014, DOI 10.17487/RFC7235, June 2014,
<https://www.rfc-editor.org/info/rfc7235>. <https://www.rfc-editor.org/info/rfc7235>.
[RFC7538] Reschke, J. F., "The Hypertext Transfer Protocol Status [RFC7538] Reschke, J. F., "The Hypertext Transfer Protocol Status
Code 308 (Permanent Redirect)", RFC 7538, Code 308 (Permanent Redirect)", RFC 7538,
DOI 10.17487/RFC7538, April 2015, DOI 10.17487/RFC7538, April 2015,
<https://www.rfc-editor.org/info/rfc7538>. <https://www.rfc-editor.org/info/rfc7538>.
skipping to change at page 212, line 25 skipping to change at page 214, line 32
"content", to better align with its usage elsewhere (e.g., in field "content", to better align with its usage elsewhere (e.g., in field
names) and to avoid confusion with frame payloads in HTTP/2 and names) and to avoid confusion with frame payloads in HTTP/2 and
HTTP/3. (Section 6.4) HTTP/3. (Section 6.4)
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, HEAD, and DELETE are not
interoperable. (Section 9.3.1, Section 9.3.5) interoperable. (Section 9.3.1, Section 9.3.2, Section 9.3.5)
Allowed use of the Content-Range header field (Section 14.4) as a Allowed use of the Content-Range header field (Section 14.4) as a
request modifier on PUT. (Section 9.3.4) request modifier on PUT. (Section 9.3.4)
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)
Removed normative requirement to use the "message/http" media type in Removed normative requirement to use the "message/http" media type in
TRACE responses. (Section 9.3.8) TRACE responses. (Section 9.3.8)
skipping to change at page 220, line 49 skipping to change at page 223, line 24
insensitive, and encourage registration insensitive, and encourage registration
(<https://github.com/httpwg/http-core/issues/179>) (<https://github.com/httpwg/http-core/issues/179>)
* In Section 8.4.1, explicitly call out content codings as case- * 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>)
* In Section 5.1, explicitly call out field names as case- * 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>)
* In Section 17.12, cite [Bujlow] (<https://github.com/httpwg/http- * In Section 17.13, cite [Bujlow] (<https://github.com/httpwg/http-
core/issues/185>) core/issues/185>)
* In Section 15, formally define "final" and "interim" status codes * 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>)
* In Section 9.3.5, caution against a request content more strongly * 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>)
* In Section 8.8.3, note that Etag can be used in trailers * 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>)
skipping to change at page 226, line 23 skipping to change at page 228, line 42
* The entire document has been reorganized, with no changes to * The entire document has been reorganized, with no changes to
content except editorial for the reorganization content except editorial for the reorganization
(<https://github.com/httpwg/http-core/issues/368>) (<https://github.com/httpwg/http-core/issues/368>)
* Move IANA Upgrade Token Registry instructions from [Messaging] * Move IANA Upgrade Token Registry instructions from [Messaging]
(<https://github.com/httpwg/http-core/issues/450>) (<https://github.com/httpwg/http-core/issues/450>)
C.14. Since draft-ietf-httpbis-semantics-12 C.14. Since draft-ietf-httpbis-semantics-12
* In Appendix "Acknowledgments" (Appendix D), added acks for the * In Appendix "Acknowledgments" (Appendix "Acknowledgments"), added
work since 2014 (<https://github.com/httpwg/http-core/issues/442>) acks for the work since 2014 (<https://github.com/httpwg/http-
core/issues/442>)
* In Section 15.3.7, specifically require that a client check the * In Section 15.3.7, specifically require that a client check the
206 response header fields to determine what ranges are enclosed, 206 response header fields to determine what ranges are enclosed,
since it cannot assume they exactly match those requested since it cannot assume they exactly match those requested
(<https://github.com/httpwg/http-core/issues/445>) (<https://github.com/httpwg/http-core/issues/445>)
* In Section 16.3, explain why new fields need to be backwards- * In Section 16.3, explain why new fields need to be backwards-
compatible (<https://github.com/httpwg/http-core/issues/448>) compatible (<https://github.com/httpwg/http-core/issues/448>)
* In Section 5.3, constrain field combination to be within a section * In Section 5.3, constrain field combination to be within a section
skipping to change at page 228, line 14 skipping to change at page 230, line 35
* In Section 15.5.9, rephrase prose about connection re-use * In Section 15.5.9, rephrase prose about connection re-use
(<https://github.com/httpwg/http-core/issues/579>) (<https://github.com/httpwg/http-core/issues/579>)
* In Section 14.2, potentially allow Range handling on methods other * In Section 14.2, potentially allow Range handling on methods other
than GET (<https://github.com/httpwg/http-core/issues/581>) than GET (<https://github.com/httpwg/http-core/issues/581>)
* In Section 18.3, remove redundant text about status code 418 * 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>)
* In Section 17.15.1, rewrite requirement to refer to "secured * In Section 17.16.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>)
* Make reference to [RFC8446] normative (<https://github.com/httpwg/ * 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 C.15. Since draft-ietf-httpbis-semantics-13
* In Section 12.5.1, remove the unused "accept parameters" * In Section 12.5.1, remove the unused "accept parameters"
(<https://github.com/httpwg/http-core/issues/568>) (<https://github.com/httpwg/http-core/issues/568>)
skipping to change at page 231, line 15 skipping to change at page 233, line 36
* In Section 10.1.5, note that the Trailer field can be used to * In Section 10.1.5, note that the Trailer field can be used to
discover deleted trailers (<https://github.com/httpwg/http-core/ discover deleted trailers (<https://github.com/httpwg/http-core/
issues/793>) issues/793>)
* Throughout, remove unneeded normative references to [Messaging] * Throughout, remove unneeded normative references to [Messaging]
(<https://github.com/httpwg/http-core/issues/795>) (<https://github.com/httpwg/http-core/issues/795>)
* In Section 10.1.4, explicitly require listing in Connection * In Section 10.1.4, explicitly require listing in Connection
(<https://github.com/httpwg/http-core/issues/809>) (<https://github.com/httpwg/http-core/issues/809>)
C.17. Since draft-ietf-httpbis-semantics-15
* For [HTTP3], add an RFC Editor note to rename to "RFCnnn" before
publication (<https://github.com/httpwg/http-core/issues/815>)
* In Section 9.3.2, align prose about content in HEAD requests with
description of GET (<https://github.com/httpwg/http-core/
issues/826>)
* In Section 5.3, remove the restriction to non-empty field line
values (<https://github.com/httpwg/http-core/issues/836>)
* Add forward references to definition of OWS
(<https://github.com/httpwg/http-core/issues/841>)
* In Section 17.10, add a security consideration regarding
application handling of field names (<https://github.com/httpwg/
http-core/issues/843>)
Acknowledgments Acknowledgments
This edition of the HTTP specification builds on the many Aside from the current editors, the following individuals deserve
contributions that went into RFC 1945, RFC 2068, RFC 2145, RFC 2616, special recognition for their contributions to early aspects of HTTP
and RFC 2818, including substantial contributions made by the current and its core specifications: Marc Andreessen, Tim Berners-Lee, Robert
and previous editors of HTTP: Tim Berners-Lee, Jean-François Groff, Cailliau, Daniel W. Connolly, Bob Denny, John Franks, Jim Gettys,
Ari Luotonen, Henrik Frystyk Nielsen, Jim Gettys, Jeffrey C. Mogul, Jean-François Groff, Phillip M. Hallam-Baker, Koen Holtman, Jeffery
Larry Masinter, Paul J. Leach, Eric Rescorla, and Yves Lafon. L. Hostetler, Shel Kaphan, Dave Kristol, Yves Lafon, Scott
D. Lawrence, Paul J. Leach, Håkon W. Lie, Ari Luotonen, Larry
Masinter, Rob McCool, Jeffrey C. Mogul, Lou Montulli, David Morris,
Henrik Frystyk Nielsen, Dave Raggett, Eric Rescorla, Tony Sanders,
Lawrence C. Stewart, Marc VanHeyningen, and Steve Zilles.
In addition, this document has reincorporated the HTTP Authentication This edition builds on the many contributions that went into past
Framework, previously defined in RFC 7235 and RFC 2617. We thank specifications of HTTP, including RFC 1945, RFC 2068, RFC 2145, RFC
John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott 2616, RFC 2617, RFC 2818, RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC
D. Lawrence, Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart 7234, and RFC 7235. The acknowledgements within those documents
for their work on that specification. See Section 6 of [RFC2617] for still apply.
further acknowledgements.
Since 2014, the following contributors have helped improve the HTTP Since 2014, the following contributors have helped improve this
specification by reporting bugs, asking smart questions, drafting or specification by reporting bugs, asking smart questions, drafting or
reviewing text, and evaluating open issues: reviewing text, and evaluating open issues:
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, James Peach, Jeffrey Florian Best, Igor Lubashev, James Callahan, James Peach, Jeffrey
Yasskin, Kalin Gyokov, Kannan Goundan, 奥 一穂 (Kazuho Oku), Ken Yasskin, Kalin Gyokov, Kannan Goundan, 奥 一穂 (Kazuho Oku), Ken
Murchison, Krzysztof Maczyński, Lucas Pardue, Martin Dürst, Martin Murchison, Krzysztof Maczyński, Lucas Pardue, Martin Dürst, Martin
Thomson, Martynas Jusevičius, Matt Menke, Matthias Pigulla, Michael Thomson, Martynas Jusevičius, Matt Menke, Matthias Pigulla, Michael
Osipov, Mike Bishop, Mike Pennisi, Mike Taylor, Mike West, Nathaniel Osipov, Mike Bishop, Mike Pennisi, Mike Taylor, Mike West, Nathaniel
J. Smith, Nicholas Hurley, Nikita Piskunov, Patrick McManus, Piotr J. Smith, Nicholas Hurley, Nikita Piskunov, Patrick McManus, Piotr
Sikora, Poul-Henning Kamp, Rick van Rein, Roberto Polli, Semyon Sikora, Poul-Henning Kamp, Rick van Rein, Roberto Polli, Samuel
Kholodnov, Simon Pieters, Simon Schüppel, Todd Greer, Tommy Pauly, Williams, 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 Index
revisions.
1 2 3 4 5 A B C D E F G H I L M N O P R S T U V W X
1
100 Continue (status code) Section 15.2.1
100-continue (expect value) Section 10.1.1
101 Switching Protocols (status code) Section 15.2.2
1xx Informational (status code class) Section 15.2
2
200 OK (status code) Section 15.3.1
201 Created (status code) Section 15.3.2
202 Accepted (status code) Section 15.3.3
203 Non-Authoritative Information (status code) Section 15.3.4
204 No Content (status code) Section 15.3.5
205 Reset Content (status code) Section 15.3.6
206 Partial Content (status code) Section 15.3.7
2xx Successful (status code class) Section 15.3
3
300 Multiple Choices (status code) Section 15.4.1
301 Moved Permanently (status code) Section 15.4.2
302 Found (status code) Section 15.4.3
303 See Other (status code) Section 15.4.4
304 Not Modified (status code) Section 15.4.5
305 Use Proxy (status code) Section 15.4.6
306 (Unused) (status code) Section 15.4.7
307 Temporary Redirect (status code) Section 15.4.8
308 Permanent Redirect (status code) Section 15.4.9
3xx Redirection (status code class) Section 15.4
4
400 Bad Request (status code) Section 15.5.1
401 Unauthorized (status code) Section 15.5.2
402 Payment Required (status code) Section 15.5.3
403 Forbidden (status code) Section 15.5.4
404 Not Found (status code) Section 15.5.5
405 Method Not Allowed (status code) Section 15.5.6
406 Not Acceptable (status code) Section 15.5.7
407 Proxy Authentication Required (status code) Section 15.5.8
408 Request Timeout (status code) Section 15.5.9
409 Conflict (status code) Section 15.5.10
410 Gone (status code) Section 15.5.11
411 Length Required (status code) Section 15.5.12
412 Precondition Failed (status code) Section 15.5.13
413 Content Too Large (status code) Section 15.5.14
414 URI Too Long (status code) Section 15.5.15
415 Unsupported Media Type (status code) Section 15.5.16
416 Range Not Satisfiable (status code) Section 15.5.17
417 Expectation Failed (status code) Section 15.5.18
418 (Unused) (status code) Section 15.5.19
421 Misdirected Request (status code) Section 15.5.20
422 Unprocessable Content (status code) Section 15.5.21
426 Upgrade Required (status code) Section 15.5.22
4xx Client Error (status code class) Section 15.5
5
500 Internal Server Error (status code) Section 15.6.1
501 Not Implemented (status code) Section 15.6.2
502 Bad Gateway (status code) Section 15.6.3
503 Service Unavailable (status code) Section 15.6.4
504 Gateway Timeout (status code) Section 15.6.5
505 HTTP Version Not Supported (status code) Section 15.6.6
5xx Server Error (status code class) Section 15.6
A
Accept header field Section 12.5.1
Accept-Charset header field Section 12.5.2
Accept-Encoding header field Section 12.5.3
Accept-Language header field Section 12.5.4
Accept-Ranges header field Section 14.3
Allow header field Section 10.2.1
Authentication-Info header field Section 11.6.3
Authorization header field Section 11.6.2
accelerator Section 3.7, Paragraph 6
authoritative response Section 17.1
B
browser Section 3.5
C
CONNECT method Section 9.3.6
Connection header field Section 7.6.1
Content-Encoding header field Section 8.4
Content-Language header field Section 8.5
Content-Length header field Section 8.6
Content-Location header field Section 8.7
Content-MD5 header field Section 18.4, Paragraph 9
Content-Range header field Section 14.4; Section 14.5
Content-Type header field Section 8.3
cache Section 3.8
cacheable Section 3.8, Paragraph 4
client Section 3.3
complete Section 6.1
compress (Coding Format) Section 8.4.1.1
compress (content coding) Section 8.4.1
conditional request Section 13
connection Section 3.3
content Section 6.4
content coding Section 8.4.1
content negotiation Section 1.3, Paragraph 4
control data Section 6.2
D
DELETE method Section 9.3.5
Date header field Section 10.2.2
Delimiters Section 5.6.2, Paragraph 3
deflate (Coding Format) Section 8.4.1.2
deflate (content coding) Section 8.4.1
downstream Section 3.7, Paragraph 4
E
ETag field Section 8.8.3
Expect header field Section 10.1.1
effective request URI Section 7.1, Paragraph 8.1
F
Fields
* Section 18.4, Paragraph 8
Accept Section 12.5.1
Accept-Charset Section 12.5.2
Accept-Encoding Section 12.5.3
Accept-Language Section 12.5.4
Accept-Ranges Section 14.3
Allow Section 10.2.1
Authentication-Info Section 11.6.3
Authorization Section 11.6.2
Connection Section 7.6.1
Content-Encoding Section 8.4
Content-Language Section 8.5
Content-Length Section 8.6
Content-Location Section 8.7
Content-MD5 Section 18.4, Paragraph 9
Content-Range Section 14.4; Section 14.5
Content-Type Section 8.3
Date Section 10.2.2
ETag Section 8.8.3
Expect Section 10.1.1
From Section 10.1.2
Host Section 7.2
If-Match Section 13.1.1
If-Modified-Since Section 13.1.3
If-None-Match Section 13.1.2
If-Range Section 13.1.5
If-Unmodified-Since Section 13.1.4
Last-Modified Section 8.8.2
Location Section 10.2.3
Max-Forwards Section 7.6.2
Proxy-Authenticate Section 11.7.1
Proxy-Authentication-Info Section 11.7.3
Proxy-Authorization Section 11.7.2
Range Section 14.2
Referer Section 10.1.3
Retry-After Section 10.2.4
Server Section 10.2.5
TE Section 10.1.4
Trailer Section 10.1.5
Upgrade Section 7.8
User-Agent Section 10.1.6
Vary Section 12.5.5
Via Section 7.6.3
WWW-Authenticate Section 11.6.1
Fragment Identifiers Section 4.2.5
From header field Section 10.1.2
field Section 5; Section 6.3
field line Section 5.2, Paragraph 1
field line value Section 5.2, Paragraph 1
field name Section 5.2, Paragraph 1
field value Section 5.2, Paragraph 2
G
GET method Section 9.3.1
Grammar
ALPHA Section 2.1
Accept Section 12.5.1
Accept-Charset Section 12.5.2
Accept-Encoding Section 12.5.3
Accept-Language Section 12.5.4
Accept-Ranges Section 14.3
Allow Section 10.2.1
Authentication-Info Section 11.6.3
Authorization Section 11.6.2
BWS Section 5.6.3
CR Section 2.1
CRLF Section 2.1
CTL Section 2.1
Connection Section 7.6.1
Content-Encoding Section 8.4
Content-Language Section 8.5
Content-Length Section 8.6
Content-Location Section 8.7
Content-Range Section 14.4
Content-Type Section 8.3
DIGIT Section 2.1
DQUOTE Section 2.1
Date Section 10.2.2
ETag Section 8.8.3
Expect Section 10.1.1
From Section 10.1.2
GMT Section 5.6.7
HEXDIG Section 2.1
HTAB Section 2.1
HTTP-date Section 5.6.7
Host Section 7.2
IMF-fixdate Section 5.6.7
If-Match Section 13.1.1
If-Modified-Since Section 13.1.3
If-None-Match Section 13.1.2
If-Range Section 13.1.5
If-Unmodified-Since Section 13.1.4
LF Section 2.1
Last-Modified Section 8.8.2
Location Section 10.2.3
Max-Forwards Section 7.6.2
OCTET Section 2.1
OWS Section 5.6.3
Proxy-Authenticate Section 11.7.1
Proxy-Authentication-Info Section 11.7.3
Proxy-Authorization Section 11.7.2
RWS Section 5.6.3
Range Section 14.2
Referer Section 10.1.3
Retry-After Section 10.2.4
SP Section 2.1
Server Section 10.2.5
TE Section 10.1.4
Trailer Section 10.1.5
URI-reference Section 4.1
Upgrade Section 7.8
User-Agent Section 10.1.6
VCHAR Section 2.1
Vary Section 12.5.5
Via Section 7.6.3
WWW-Authenticate Section 11.6.1
absolute-URI Section 4.1
absolute-path Section 4.1
acceptable-ranges Section 14.3
asctime-date Section 5.6.7
auth-param Section 11.2
auth-scheme Section 11.1
authority Section 4.1
challenge Section 11.3
codings Section 12.5.3
comment Section 5.6.5
complete-length Section 14.4
connection-option Section 7.6.1
content-coding Section 8.4.1
credentials Section 11.4
ctext Section 5.6.5
date1 Section 5.6.7
day Section 5.6.7
day-name Section 5.6.7
day-name-l Section 5.6.7
delay-seconds Section 10.2.4
entity-tag Section 8.8.3
etagc Section 8.8.3
field-content Section 5.5
field-name Section 5.1; Section 10.1.5
field-value Section 5.5
field-vchar Section 5.5
first-pos Section 14.1.1; Section 14.4
hour Section 5.6.7
http-URI Section 4.2.1
https-URI Section 4.2.2
incl-range Section 14.4
int-range Section 14.1.1
language-range Section 12.5.4
language-tag Section 8.5.1
last-pos Section 14.1.1; Section 14.4
media-range Section 12.5.1
media-type Section 8.3.1
method Section 9.1
minute Section 5.6.7
month Section 5.6.7
obs-date Section 5.6.7
obs-text Section 5.6.4
opaque-tag Section 8.8.3
other-range Section 14.1.1
parameter Section 5.6.6
parameter-name Section 5.6.6
parameter-value Section 5.6.6
parameters Section 5.6.6
partial-URI Section 4.1
port Section 4.1
product Section 10.1.6
product-version Section 10.1.6
protocol-name Section 7.6.3
protocol-version Section 7.6.3
pseudonym Section 7.6.3
qdtext Section 5.6.4
query Section 4.1
quoted-pair Section 5.6.4
quoted-string Section 5.6.4
qvalue Section 12.4.2
range-resp Section 14.4
range-set Section 14.1.1
range-spec Section 14.1.1
range-unit Section 14.1
ranges-specifier Section 14.1.1
received-by Section 7.6.3
received-protocol Section 7.6.3
rfc850-date Section 5.6.7
second Section 5.6.7
segment Section 4.1
subtype Section 8.3.1
suffix-length Section 14.1.1
suffix-range Section 14.1.1
t-codings Section 10.1.4
tchar Section 5.6.2
time-of-day Section 5.6.7
token Section 5.6.2
token68 Section 11.2
transfer-coding Section 10.1.4
transfer-parameter Section 10.1.4
type Section 8.3.1
unsatisfied-range Section 14.4
uri-host Section 4.1
weak Section 8.8.3
weight Section 12.4.2
year Section 5.6.7
gateway Section 3.7, Paragraph 6
gzip (Coding Format) Section 8.4.1.3
gzip (content coding) Section 8.4.1
H
HEAD method Section 9.3.2
Header Fields
Accept Section 12.5.1
Accept-Charset Section 12.5.2
Accept-Encoding Section 12.5.3
Accept-Language Section 12.5.4
Accept-Ranges Section 14.3
Allow Section 10.2.1
Authentication-Info Section 11.6.3
Authorization Section 11.6.2
Connection Section 7.6.1
Content-Encoding Section 8.4
Content-Language Section 8.5
Content-Length Section 8.6
Content-Location Section 8.7
Content-MD5 Section 18.4, Paragraph 9
Content-Range Section 14.4; Section 14.5
Content-Type Section 8.3
Date Section 10.2.2
ETag Section 8.8.3
Expect Section 10.1.1
From Section 10.1.2
Host Section 7.2
If-Match Section 13.1.1
If-Modified-Since Section 13.1.3
If-None-Match Section 13.1.2
If-Range Section 13.1.5
If-Unmodified-Since Section 13.1.4
Last-Modified Section 8.8.2
Location Section 10.2.3
Max-Forwards Section 7.6.2
Proxy-Authenticate Section 11.7.1
Proxy-Authentication-Info Section 11.7.3
Proxy-Authorization Section 11.7.2
Range Section 14.2
Referer Section 10.1.3
Retry-After Section 10.2.4
Server Section 10.2.5
TE Section 10.1.4
Trailer Section 10.1.5
Upgrade Section 7.8
User-Agent Section 10.1.6
Vary Section 12.5.5
Via Section 7.6.3
WWW-Authenticate Section 11.6.1
Host header field Section 7.2
header section Section 6.3
http URI scheme Section 4.2.1
https URI scheme Section 4.2.2
I
If-Match header field Section 13.1.1
If-Modified-Since header field Section 13.1.3
If-None-Match header field Section 13.1.2
If-Range header field Section 13.1.5
If-Unmodified-Since header field Section 13.1.4
idempotent Section 9.2.2
inbound Section 3.7, Paragraph 4
incomplete Section 6.1
interception proxy Section 3.7, Paragraph 10
intermediary Section 3.7
L
Last-Modified header field Section 8.8.2
Location header field Section 10.2.3
list-based field Section 5.5, Paragraph 7
M
Max-Forwards header field Section 7.6.2
Media Type
multipart/byteranges Section 14.6
multipart/x-byteranges Section 14.6, Paragraph 4, Item 3
Method
* Section 18.2, Paragraph 3
CONNECT Section 9.3.6
DELETE Section 9.3.5
GET Section 9.3.1
HEAD Section 9.3.2
OPTIONS Section 9.3.7
POST Section 9.3.3
PUT Section 9.3.4
TRACE Section 9.3.8
message Section 3.4; Section 6
message abstraction Section 6
messages Section 3.4
metadata Section 8.8
multipart/byteranges Media Type Section 14.6
multipart/x-byteranges Media Type Section 14.6, Paragraph 4,
Item 3
N
non-transforming proxy Section 7.7
O
OPTIONS method Section 9.3.7
Origin Section 11.5
origin Section 4.3.1
origin server Section 3.6
outbound Section 3.7, Paragraph 4
P
POST method Section 9.3.3
PUT method Section 9.3.4
Protection Space Section 11.5
Proxy-Authenticate header field Section 11.7.1
Proxy-Authentication-Info header field Section 11.7.3
Proxy-Authorization header field Section 11.7.2
phishing Section 17.1
proxy Section 3.7, Paragraph 5
R
Range header field Section 14.2
Realm Section 11.5
Referer header field Section 10.1.3
Retry-After header field Section 10.2.4
recipient Section 3.4
representation Section 3.2
request Section 3.4
request target Section 7.1
resource Section 3.1; Section 4
response Section 3.4
reverse proxy Section 3.7, Paragraph 6
S
Server header field Section 10.2.5
Status Code Section 15
Status Codes
Final Section 15, Paragraph 7
Informational Section 15, Paragraph 7
Interim Section 15, Paragraph 7
Status Codes Classes
1xx Informational Section 15.2
2xx Successful Section 15.3
3xx Redirection Section 15.4
4xx Client Error Section 15.5
5xx Server Error Section 15.6
safe Section 9.2.1
secured Section 4.2.2
selected representation Section 3.2, Paragraph 4; Section 8.8;
Section 13.1
self-descriptive Section 6
sender Section 3.4
server Section 3.3
singleton field Section 5.5, Paragraph 6
spider Section 3.5
T
TE header field Section 10.1.4
TRACE method Section 9.3.8
Trailer Fields
ETag Section 8.8.3
Trailer header field Section 10.1.5
target URI Section 7.1
target resource Section 7.1
trailer fields Section 6.5
trailer section Section 6.5
trailers Section 6.5
transforming proxy Section 7.7
transparent proxy Section 3.7, Paragraph 10
tunnel Section 3.7, Paragraph 8
U
URI Section 4
origin Section 4.3.1
URI reference Section 4.1
URI scheme
http Section 4.2.1
https Section 4.2.2
Upgrade header field Section 7.8
User-Agent header field Section 10.1.6
upstream Section 3.7, Paragraph 4
user agent Section 3.5
V
Vary header field Section 12.5.5
Via header field Section 7.6.3
validator Section 8.8
strong Section 8.8.1
weak Section 8.8.1
W
WWW-Authenticate header field Section 11.6.1
X
x-compress (content coding) Section 8.4.1
x-gzip (content coding) Section 8.4.1
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
United States of America United States of America
Email: fielding@gbiv.com Email: fielding@gbiv.com
 End of changes. 53 change blocks. 
349 lines changed or deleted 987 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/