draft-ietf-httpbis-semantics-17.txt   draft-ietf-httpbis-semantics-18.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: 27 January 2022 26 July 2021 Expires: 19 February 2022 18 August 2021
HTTP Semantics HTTP Semantics
draft-ietf-httpbis-semantics-17 draft-ietf-httpbis-semantics-18
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.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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.18. The changes in this draft are summarized in Appendix C.19.
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 27 January 2022. This Internet-Draft will expire on 19 February 2022.
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 49 skipping to change at page 2, line 49
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 . . . . . . . . . . . . . . . . . . 10 1.2. History and Evolution . . . . . . . . . . . . . . . . . . 10
1.3. Core Semantics . . . . . . . . . . . . . . . . . . . . . 11 1.3. Core Semantics . . . . . . . . . . . . . . . . . . . . . 11
1.4. Specifications Obsoleted by this Document . . . . . . . . 12 1.4. Specifications Obsoleted by this Document . . . . . . . . 11
2. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 12 2. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 12 2.1. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 12
2.2. Requirements Notation . . . . . . . . . . . . . . . . . . 13 2.2. Requirements Notation . . . . . . . . . . . . . . . . . . 13
2.3. Length Requirements . . . . . . . . . . . . . . . . . . . 14 2.3. Length Requirements . . . . . . . . . . . . . . . . . . . 14
2.4. Error Handling . . . . . . . . . . . . . . . . . . . . . 15 2.4. Error Handling . . . . . . . . . . . . . . . . . . . . . 15
2.5. Protocol Version . . . . . . . . . . . . . . . . . . . . 15 2.5. Protocol Version . . . . . . . . . . . . . . . . . . . . 15
3. Terminology and Core Concepts . . . . . . . . . . . . . . . . 16 3. Terminology and Core Concepts . . . . . . . . . . . . . . . . 16
3.1. Resources . . . . . . . . . . . . . . . . . . . . . . . . 16 3.1. Resources . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2. Representations . . . . . . . . . . . . . . . . . . . . . 17 3.2. Representations . . . . . . . . . . . . . . . . . . . . . 17
3.3. Connections, Clients and Servers . . . . . . . . . . . . 17 3.3. Connections, Clients and Servers . . . . . . . . . . . . 17
skipping to change at page 3, line 31 skipping to change at page 3, line 31
4.2.2. https URI Scheme . . . . . . . . . . . . . . . . . . 25 4.2.2. https URI Scheme . . . . . . . . . . . . . . . . . . 25
4.2.3. http(s) Normalization and Comparison . . . . . . . . 26 4.2.3. http(s) Normalization and Comparison . . . . . . . . 26
4.2.4. Deprecation of userinfo in http(s) URIs . . . . . . . 27 4.2.4. Deprecation of userinfo in http(s) URIs . . . . . . . 27
4.2.5. http(s) References with Fragment Identifiers . . . . 28 4.2.5. http(s) References with Fragment Identifiers . . . . 28
4.3. Authoritative Access . . . . . . . . . . . . . . . . . . 28 4.3. Authoritative Access . . . . . . . . . . . . . . . . . . 28
4.3.1. URI Origin . . . . . . . . . . . . . . . . . . . . . 28 4.3.1. URI Origin . . . . . . . . . . . . . . . . . . . . . 28
4.3.2. http origins . . . . . . . . . . . . . . . . . . . . 29 4.3.2. http origins . . . . . . . . . . . . . . . . . . . . 29
4.3.3. https origins . . . . . . . . . . . . . . . . . . . . 30 4.3.3. https origins . . . . . . . . . . . . . . . . . . . . 30
4.3.4. https certificate verification . . . . . . . . . . . 31 4.3.4. https certificate verification . . . . . . . . . . . 31
4.3.5. IP-ID reference identity . . . . . . . . . . . . . . 32 4.3.5. IP-ID reference identity . . . . . . . . . . . . . . 32
5. Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 5. Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.1. Field Names . . . . . . . . . . . . . . . . . . . . . . . 33 5.1. Field Names . . . . . . . . . . . . . . . . . . . . . . . 33
5.2. Field Lines and Combined Field Value . . . . . . . . . . 34 5.2. Field Lines and Combined Field Value . . . . . . . . . . 33
5.3. Field Order . . . . . . . . . . . . . . . . . . . . . . . 34 5.3. Field Order . . . . . . . . . . . . . . . . . . . . . . . 34
5.4. Field Limits . . . . . . . . . . . . . . . . . . . . . . 35 5.4. Field Limits . . . . . . . . . . . . . . . . . . . . . . 35
5.5. Field Values . . . . . . . . . . . . . . . . . . . . . . 35 5.5. Field Values . . . . . . . . . . . . . . . . . . . . . . 35
5.6. Common Rules for Defining Field Values . . . . . . . . . 37 5.6. Common Rules for Defining Field Values . . . . . . . . . 37
5.6.1. Lists (#rule ABNF Extension) . . . . . . . . . . . . 37 5.6.1. Lists (#rule ABNF Extension) . . . . . . . . . . . . 37
5.6.1.1. Sender Requirements . . . . . . . . . . . . . . . 38 5.6.1.1. Sender Requirements . . . . . . . . . . . . . . . 37
5.6.1.2. Recipient Requirements . . . . . . . . . . . . . 38 5.6.1.2. Recipient Requirements . . . . . . . . . . . . . 38
5.6.2. Tokens . . . . . . . . . . . . . . . . . . . . . . . 39 5.6.2. Tokens . . . . . . . . . . . . . . . . . . . . . . . 38
5.6.3. Whitespace . . . . . . . . . . . . . . . . . . . . . 39 5.6.3. Whitespace . . . . . . . . . . . . . . . . . . . . . 39
5.6.4. Quoted Strings . . . . . . . . . . . . . . . . . . . 40 5.6.4. Quoted Strings . . . . . . . . . . . . . . . . . . . 39
5.6.5. Comments . . . . . . . . . . . . . . . . . . . . . . 40 5.6.5. Comments . . . . . . . . . . . . . . . . . . . . . . 40
5.6.6. Parameters . . . . . . . . . . . . . . . . . . . . . 41 5.6.6. Parameters . . . . . . . . . . . . . . . . . . . . . 40
5.6.7. Date/Time Formats . . . . . . . . . . . . . . . . . . 41 5.6.7. Date/Time Formats . . . . . . . . . . . . . . . . . . 41
6. Message Abstraction . . . . . . . . . . . . . . . . . . . . . 43 6. Message Abstraction . . . . . . . . . . . . . . . . . . . . . 43
6.1. Framing and Completeness . . . . . . . . . . . . . . . . 44 6.1. Framing and Completeness . . . . . . . . . . . . . . . . 44
6.2. Control Data . . . . . . . . . . . . . . . . . . . . . . 45 6.2. Control Data . . . . . . . . . . . . . . . . . . . . . . 45
6.3. Header Fields . . . . . . . . . . . . . . . . . . . . . . 46 6.3. Header Fields . . . . . . . . . . . . . . . . . . . . . . 46
6.4. Content . . . . . . . . . . . . . . . . . . . . . . . . . 46 6.4. Content . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.4.1. Content Semantics . . . . . . . . . . . . . . . . . . 47 6.4.1. Content Semantics . . . . . . . . . . . . . . . . . . 46
6.4.2. Identifying Content . . . . . . . . . . . . . . . . . 48 6.4.2. Identifying Content . . . . . . . . . . . . . . . . . 47
6.5. Trailer Fields . . . . . . . . . . . . . . . . . . . . . 49 6.5. Trailer Fields . . . . . . . . . . . . . . . . . . . . . 49
6.5.1. Limitations on use of Trailers . . . . . . . . . . . 49 6.5.1. Limitations on use of Trailers . . . . . . . . . . . 49
6.5.2. Processing Trailer Fields . . . . . . . . . . . . . . 50 6.5.2. Processing Trailer Fields . . . . . . . . . . . . . . 50
7. Routing HTTP Messages . . . . . . . . . . . . . . . . . . . . 51 6.6. Message Metadata . . . . . . . . . . . . . . . . . . . . 50
7.1. Determining the Target Resource . . . . . . . . . . . . . 51 6.6.1. Date . . . . . . . . . . . . . . . . . . . . . . . . 51
7.2. Host and :authority . . . . . . . . . . . . . . . . . . . 52 6.6.2. Trailer . . . . . . . . . . . . . . . . . . . . . . . 52
7.3. Routing Inbound Requests . . . . . . . . . . . . . . . . 52 7. Routing HTTP Messages . . . . . . . . . . . . . . . . . . . . 52
7.3.1. To a Cache . . . . . . . . . . . . . . . . . . . . . 52 7.1. Determining the Target Resource . . . . . . . . . . . . . 52
7.3.2. To a Proxy . . . . . . . . . . . . . . . . . . . . . 53 7.2. Host and :authority . . . . . . . . . . . . . . . . . . . 53
7.3.3. To the Origin . . . . . . . . . . . . . . . . . . . . 53 7.3. Routing Inbound Requests . . . . . . . . . . . . . . . . 54
7.4. Rejecting Misdirected Requests . . . . . . . . . . . . . 53 7.3.1. To a Cache . . . . . . . . . . . . . . . . . . . . . 54
7.5. Response Correlation . . . . . . . . . . . . . . . . . . 54 7.3.2. To a Proxy . . . . . . . . . . . . . . . . . . . . . 54
7.6. Message Forwarding . . . . . . . . . . . . . . . . . . . 54 7.3.3. To the Origin . . . . . . . . . . . . . . . . . . . . 54
7.6.1. Connection . . . . . . . . . . . . . . . . . . . . . 55 7.4. Rejecting Misdirected Requests . . . . . . . . . . . . . 55
7.6.2. Max-Forwards . . . . . . . . . . . . . . . . . . . . 56 7.5. Response Correlation . . . . . . . . . . . . . . . . . . 55
7.6.3. Via . . . . . . . . . . . . . . . . . . . . . . . . . 57 7.6. Message Forwarding . . . . . . . . . . . . . . . . . . . 56
7.7. Message Transformations . . . . . . . . . . . . . . . . . 59 7.6.1. Connection . . . . . . . . . . . . . . . . . . . . . 56
7.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 60 7.6.2. Max-Forwards . . . . . . . . . . . . . . . . . . . . 58
8. Representation Data and Metadata . . . . . . . . . . . . . . 62 7.6.3. Via . . . . . . . . . . . . . . . . . . . . . . . . . 59
8.1. Representation Data . . . . . . . . . . . . . . . . . . . 62 7.7. Message Transformations . . . . . . . . . . . . . . . . . 60
8.2. Representation Metadata . . . . . . . . . . . . . . . . . 62 7.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 61
8.3. Content-Type . . . . . . . . . . . . . . . . . . . . . . 63 8. Representation Data and Metadata . . . . . . . . . . . . . . 64
8.3.1. Media Type . . . . . . . . . . . . . . . . . . . . . 64 8.1. Representation Data . . . . . . . . . . . . . . . . . . . 64
8.3.2. Charset . . . . . . . . . . . . . . . . . . . . . . . 64 8.2. Representation Metadata . . . . . . . . . . . . . . . . . 64
8.3.3. Multipart Types . . . . . . . . . . . . . . . . . . . 65 8.3. Content-Type . . . . . . . . . . . . . . . . . . . . . . 64
8.4. Content-Encoding . . . . . . . . . . . . . . . . . . . . 65 8.3.1. Media Type . . . . . . . . . . . . . . . . . . . . . 65
8.4.1. Content Codings . . . . . . . . . . . . . . . . . . . 66 8.3.2. Charset . . . . . . . . . . . . . . . . . . . . . . . 66
8.4.1.1. Compress Coding . . . . . . . . . . . . . . . . . 67 8.3.3. Multipart Types . . . . . . . . . . . . . . . . . . . 66
8.4.1.2. Deflate Coding . . . . . . . . . . . . . . . . . 67 8.4. Content-Encoding . . . . . . . . . . . . . . . . . . . . 67
8.4.1.3. Gzip Coding . . . . . . . . . . . . . . . . . . . 67 8.4.1. Content Codings . . . . . . . . . . . . . . . . . . . 68
8.5. Content-Language . . . . . . . . . . . . . . . . . . . . 67 8.4.1.1. Compress Coding . . . . . . . . . . . . . . . . . 68
8.5.1. Language Tags . . . . . . . . . . . . . . . . . . . . 68 8.4.1.2. Deflate Coding . . . . . . . . . . . . . . . . . 68
8.6. Content-Length . . . . . . . . . . . . . . . . . . . . . 69 8.4.1.3. Gzip Coding . . . . . . . . . . . . . . . . . . . 69
8.7. Content-Location . . . . . . . . . . . . . . . . . . . . 70 8.5. Content-Language . . . . . . . . . . . . . . . . . . . . 69
8.8. Validator Fields . . . . . . . . . . . . . . . . . . . . 72 8.5.1. Language Tags . . . . . . . . . . . . . . . . . . . . 70
8.8.1. Weak versus Strong . . . . . . . . . . . . . . . . . 73 8.6. Content-Length . . . . . . . . . . . . . . . . . . . . . 70
8.8.2. Last-Modified . . . . . . . . . . . . . . . . . . . . 74 8.7. Content-Location . . . . . . . . . . . . . . . . . . . . 72
8.8.2.1. Generation . . . . . . . . . . . . . . . . . . . 75 8.8. Validator Fields . . . . . . . . . . . . . . . . . . . . 74
8.8.2.2. Comparison . . . . . . . . . . . . . . . . . . . 75 8.8.1. Weak versus Strong . . . . . . . . . . . . . . . . . 74
8.8.3. ETag . . . . . . . . . . . . . . . . . . . . . . . . 76 8.8.2. Last-Modified . . . . . . . . . . . . . . . . . . . . 76
8.8.3.1. Generation . . . . . . . . . . . . . . . . . . . 77 8.8.2.1. Generation . . . . . . . . . . . . . . . . . . . 76
8.8.3.2. Comparison . . . . . . . . . . . . . . . . . . . 78 8.8.2.2. Comparison . . . . . . . . . . . . . . . . . . . 77
8.8.3. ETag . . . . . . . . . . . . . . . . . . . . . . . . 78
8.8.3.1. Generation . . . . . . . . . . . . . . . . . . . 79
8.8.3.2. Comparison . . . . . . . . . . . . . . . . . . . 80
8.8.3.3. Example: Entity-Tags Varying on Content-Negotiated 8.8.3.3. Example: Entity-Tags Varying on Content-Negotiated
Resources . . . . . . . . . . . . . . . . . . . . . 78 Resources . . . . . . . . . . . . . . . . . . . . . 80
8.8.4. When to Use Entity-Tags and Last-Modified Dates . . . 79 9. Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
9. Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 9.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 81
9.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 80 9.2. Common Method Properties . . . . . . . . . . . . . . . . 84
9.2. Common Method Properties . . . . . . . . . . . . . . . . 83 9.2.1. Safe Methods . . . . . . . . . . . . . . . . . . . . 84
9.2.1. Safe Methods . . . . . . . . . . . . . . . . . . . . 83 9.2.2. Idempotent Methods . . . . . . . . . . . . . . . . . 85
9.2.2. Idempotent Methods . . . . . . . . . . . . . . . . . 84 9.2.3. Methods and Caching . . . . . . . . . . . . . . . . . 86
9.2.3. Methods and Caching . . . . . . . . . . . . . . . . . 85 9.3. Method Definitions . . . . . . . . . . . . . . . . . . . 86
9.3. Method Definitions . . . . . . . . . . . . . . . . . . . 85 9.3.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 86
9.3.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 85 9.3.2. HEAD . . . . . . . . . . . . . . . . . . . . . . . . 87
9.3.2. HEAD . . . . . . . . . . . . . . . . . . . . . . . . 86 9.3.3. POST . . . . . . . . . . . . . . . . . . . . . . . . 88
9.3.3. POST . . . . . . . . . . . . . . . . . . . . . . . . 87 9.3.4. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 89
9.3.4. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 88 9.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . 92
9.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . 91 9.3.6. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 94
9.3.6. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 93 9.3.7. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 95
9.3.7. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 94 9.3.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . 96
9.3.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . 95 10. Message Context . . . . . . . . . . . . . . . . . . . . . . . 97
10. Message Context . . . . . . . . . . . . . . . . . . . . . . . 96 10.1. Request Context Fields . . . . . . . . . . . . . . . . . 97
10.1. Request Context Fields . . . . . . . . . . . . . . . . . 96 10.1.1. Expect . . . . . . . . . . . . . . . . . . . . . . . 97
10.1.1. Expect . . . . . . . . . . . . . . . . . . . . . . . 96 10.1.2. From . . . . . . . . . . . . . . . . . . . . . . . . 99
10.1.2. From . . . . . . . . . . . . . . . . . . . . . . . . 98 10.1.3. Referer . . . . . . . . . . . . . . . . . . . . . . 100
10.1.3. Referer . . . . . . . . . . . . . . . . . . . . . . 99 10.1.4. TE . . . . . . . . . . . . . . . . . . . . . . . . . 101
10.1.4. TE . . . . . . . . . . . . . . . . . . . . . . . . . 100 10.1.5. User-Agent . . . . . . . . . . . . . . . . . . . . . 102
10.1.5. Trailer . . . . . . . . . . . . . . . . . . . . . . 101 10.2. Response Context Fields . . . . . . . . . . . . . . . . 103
10.1.6. User-Agent . . . . . . . . . . . . . . . . . . . . . 101 10.2.1. Allow . . . . . . . . . . . . . . . . . . . . . . . 103
10.2. Response Context Fields . . . . . . . . . . . . . . . . 102 10.2.2. Location . . . . . . . . . . . . . . . . . . . . . . 104
10.2.1. Allow . . . . . . . . . . . . . . . . . . . . . . . 102 10.2.3. Retry-After . . . . . . . . . . . . . . . . . . . . 105
10.2.2. Date . . . . . . . . . . . . . . . . . . . . . . . . 103 10.2.4. Server . . . . . . . . . . . . . . . . . . . . . . . 106
10.2.3. Location . . . . . . . . . . . . . . . . . . . . . . 104
10.2.4. Retry-After . . . . . . . . . . . . . . . . . . . . 105
10.2.5. Server . . . . . . . . . . . . . . . . . . . . . . . 106
11. HTTP Authentication . . . . . . . . . . . . . . . . . . . . . 106 11. HTTP Authentication . . . . . . . . . . . . . . . . . . . . . 106
11.1. Authentication Scheme . . . . . . . . . . . . . . . . . 106 11.1. Authentication Scheme . . . . . . . . . . . . . . . . . 106
11.2. Authentication Parameters . . . . . . . . . . . . . . . 107 11.2. Authentication Parameters . . . . . . . . . . . . . . . 107
11.3. Challenge and Response . . . . . . . . . . . . . . . . . 107 11.3. Challenge and Response . . . . . . . . . . . . . . . . . 107
11.4. Credentials . . . . . . . . . . . . . . . . . . . . . . 108 11.4. Credentials . . . . . . . . . . . . . . . . . . . . . . 108
11.5. Establishing a Protection Space (Realm) . . . . . . . . 109 11.5. Establishing a Protection Space (Realm) . . . . . . . . 109
11.6. Authenticating Users to Origin Servers . . . . . . . . . 110 11.6. Authenticating Users to Origin Servers . . . . . . . . . 110
11.6.1. WWW-Authenticate . . . . . . . . . . . . . . . . . . 110 11.6.1. WWW-Authenticate . . . . . . . . . . . . . . . . . . 110
11.6.2. Authorization . . . . . . . . . . . . . . . . . . . 111 11.6.2. Authorization . . . . . . . . . . . . . . . . . . . 111
11.6.3. Authentication-Info . . . . . . . . . . . . . . . . 111 11.6.3. Authentication-Info . . . . . . . . . . . . . . . . 111
11.7. Authenticating Clients to Proxies . . . . . . . . . . . 112 11.7. Authenticating Clients to Proxies . . . . . . . . . . . 112
11.7.1. Proxy-Authenticate . . . . . . . . . . . . . . . . . 112 11.7.1. Proxy-Authenticate . . . . . . . . . . . . . . . . . 112
11.7.2. Proxy-Authorization . . . . . . . . . . . . . . . . 112 11.7.2. Proxy-Authorization . . . . . . . . . . . . . . . . 112
11.7.3. Proxy-Authentication-Info . . . . . . . . . . . . . 113 11.7.3. Proxy-Authentication-Info . . . . . . . . . . . . . 113
12. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 113 12. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 113
12.1. Proactive Negotiation . . . . . . . . . . . . . . . . . 114 12.1. Proactive Negotiation . . . . . . . . . . . . . . . . . 114
12.2. Reactive Negotiation . . . . . . . . . . . . . . . . . . 115 12.2. Reactive Negotiation . . . . . . . . . . . . . . . . . . 115
12.3. Request Content Negotiation . . . . . . . . . . . . . . 116 12.3. Request Content Negotiation . . . . . . . . . . . . . . 116
12.4. Content Negotiation Field Features . . . . . . . . . . . 116 12.4. Content Negotiation Field Features . . . . . . . . . . . 116
12.4.1. Absence . . . . . . . . . . . . . . . . . . . . . . 117 12.4.1. Absence . . . . . . . . . . . . . . . . . . . . . . 116
12.4.2. Quality Values . . . . . . . . . . . . . . . . . . . 117 12.4.2. Quality Values . . . . . . . . . . . . . . . . . . . 117
12.4.3. Wildcard Values . . . . . . . . . . . . . . . . . . 118 12.4.3. Wildcard Values . . . . . . . . . . . . . . . . . . 117
12.5. Content Negotiation Fields . . . . . . . . . . . . . . . 118 12.5. Content Negotiation Fields . . . . . . . . . . . . . . . 118
12.5.1. Accept . . . . . . . . . . . . . . . . . . . . . . . 118 12.5.1. Accept . . . . . . . . . . . . . . . . . . . . . . . 118
12.5.2. Accept-Charset . . . . . . . . . . . . . . . . . . . 120 12.5.2. Accept-Charset . . . . . . . . . . . . . . . . . . . 120
12.5.3. Accept-Encoding . . . . . . . . . . . . . . . . . . 121 12.5.3. Accept-Encoding . . . . . . . . . . . . . . . . . . 121
12.5.4. Accept-Language . . . . . . . . . . . . . . . . . . 123 12.5.4. Accept-Language . . . . . . . . . . . . . . . . . . 123
12.5.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . 124 12.5.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . 124
13. Conditional Requests . . . . . . . . . . . . . . . . . . . . 125 13. Conditional Requests . . . . . . . . . . . . . . . . . . . . 125
13.1. Preconditions . . . . . . . . . . . . . . . . . . . . . 126 13.1. Preconditions . . . . . . . . . . . . . . . . . . . . . 125
13.1.1. If-Match . . . . . . . . . . . . . . . . . . . . . . 126 13.1.1. If-Match . . . . . . . . . . . . . . . . . . . . . . 126
13.1.2. If-None-Match . . . . . . . . . . . . . . . . . . . 128 13.1.2. If-None-Match . . . . . . . . . . . . . . . . . . . 128
13.1.3. If-Modified-Since . . . . . . . . . . . . . . . . . 130 13.1.3. If-Modified-Since . . . . . . . . . . . . . . . . . 130
13.1.4. If-Unmodified-Since . . . . . . . . . . . . . . . . 131 13.1.4. If-Unmodified-Since . . . . . . . . . . . . . . . . 132
13.1.5. If-Range . . . . . . . . . . . . . . . . . . . . . . 133 13.1.5. If-Range . . . . . . . . . . . . . . . . . . . . . . 133
13.2. Evaluation of Preconditions . . . . . . . . . . . . . . 134 13.2. Evaluation of Preconditions . . . . . . . . . . . . . . 135
13.2.1. When to Evaluate . . . . . . . . . . . . . . . . . . 134 13.2.1. When to Evaluate . . . . . . . . . . . . . . . . . . 135
13.2.2. Precedence of Preconditions . . . . . . . . . . . . 135 13.2.2. Precedence of Preconditions . . . . . . . . . . . . 136
14. Range Requests . . . . . . . . . . . . . . . . . . . . . . . 137 14. Range Requests . . . . . . . . . . . . . . . . . . . . . . . 137
14.1. Range Units . . . . . . . . . . . . . . . . . . . . . . 137 14.1. Range Units . . . . . . . . . . . . . . . . . . . . . . 138
14.1.1. Range Specifiers . . . . . . . . . . . . . . . . . . 138 14.1.1. Range Specifiers . . . . . . . . . . . . . . . . . . 138
14.1.2. Byte Ranges . . . . . . . . . . . . . . . . . . . . 139 14.1.2. Byte Ranges . . . . . . . . . . . . . . . . . . . . 139
14.2. Range . . . . . . . . . . . . . . . . . . . . . . . . . 140 14.2. Range . . . . . . . . . . . . . . . . . . . . . . . . . 141
14.3. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 142 14.3. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 142
14.4. Content-Range . . . . . . . . . . . . . . . . . . . . . 143 14.4. Content-Range . . . . . . . . . . . . . . . . . . . . . 143
14.5. Partial PUT . . . . . . . . . . . . . . . . . . . . . . 145 14.5. Partial PUT . . . . . . . . . . . . . . . . . . . . . . 145
14.6. Media Type multipart/byteranges . . . . . . . . . . . . 145 14.6. Media Type multipart/byteranges . . . . . . . . . . . . 146
15. Status Codes . . . . . . . . . . . . . . . . . . . . . . . . 147 15. Status Codes . . . . . . . . . . . . . . . . . . . . . . . . 148
15.1. Overview of Status Codes . . . . . . . . . . . . . . . . 148 15.1. Overview of Status Codes . . . . . . . . . . . . . . . . 149
15.2. Informational 1xx . . . . . . . . . . . . . . . . . . . 149 15.2. Informational 1xx . . . . . . . . . . . . . . . . . . . 149
15.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 149 15.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 150
15.2.2. 101 Switching Protocols . . . . . . . . . . . . . . 149 15.2.2. 101 Switching Protocols . . . . . . . . . . . . . . 150
15.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . 150 15.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . 150
15.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 150 15.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 150
15.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . 151 15.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . 152
15.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . 151 15.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . 152
15.3.4. 203 Non-Authoritative Information . . . . . . . . . 151 15.3.4. 203 Non-Authoritative Information . . . . . . . . . 152
15.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . 152 15.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . 153
15.3.6. 205 Reset Content . . . . . . . . . . . . . . . . . 152 15.3.6. 205 Reset Content . . . . . . . . . . . . . . . . . 153
15.3.7. 206 Partial Content . . . . . . . . . . . . . . . . 153 15.3.7. 206 Partial Content . . . . . . . . . . . . . . . . 154
15.3.7.1. Single Part . . . . . . . . . . . . . . . . . . 154 15.3.7.1. Single Part . . . . . . . . . . . . . . . . . . 155
15.3.7.2. Multiple Parts . . . . . . . . . . . . . . . . . 154 15.3.7.2. Multiple Parts . . . . . . . . . . . . . . . . . 155
15.3.7.3. Combining Parts . . . . . . . . . . . . . . . . 156 15.3.7.3. Combining Parts . . . . . . . . . . . . . . . . 157
15.4. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 156 15.4. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 157
15.4.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 159 15.4.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 159
15.4.2. 301 Moved Permanently . . . . . . . . . . . . . . . 160 15.4.2. 301 Moved Permanently . . . . . . . . . . . . . . . 160
15.4.3. 302 Found . . . . . . . . . . . . . . . . . . . . . 160 15.4.3. 302 Found . . . . . . . . . . . . . . . . . . . . . 161
15.4.4. 303 See Other . . . . . . . . . . . . . . . . . . . 161 15.4.4. 303 See Other . . . . . . . . . . . . . . . . . . . 161
15.4.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 161 15.4.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 162
15.4.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 162 15.4.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 163
15.4.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . 162 15.4.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . 163
15.4.8. 307 Temporary Redirect . . . . . . . . . . . . . . . 162 15.4.8. 307 Temporary Redirect . . . . . . . . . . . . . . . 163
15.4.9. 308 Permanent Redirect . . . . . . . . . . . . . . . 163 15.4.9. 308 Permanent Redirect . . . . . . . . . . . . . . . 163
15.5. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 163 15.5. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 164
15.5.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 163 15.5.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 164
15.5.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 163 15.5.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 164
15.5.3. 402 Payment Required . . . . . . . . . . . . . . . . 164 15.5.3. 402 Payment Required . . . . . . . . . . . . . . . . 164
15.5.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 164 15.5.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 164
15.5.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 164 15.5.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 165
15.5.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 165 15.5.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 165
15.5.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 165 15.5.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 165
15.5.8. 407 Proxy Authentication Required . . . . . . . . . 165 15.5.8. 407 Proxy Authentication Required . . . . . . . . . 166
15.5.9. 408 Request Timeout . . . . . . . . . . . . . . . . 165 15.5.9. 408 Request Timeout . . . . . . . . . . . . . . . . 166
15.5.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . 166 15.5.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . 166
15.5.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 166 15.5.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 167
15.5.12. 411 Length Required . . . . . . . . . . . . . . . . 166 15.5.12. 411 Length Required . . . . . . . . . . . . . . . . 167
15.5.13. 412 Precondition Failed . . . . . . . . . . . . . . 167 15.5.13. 412 Precondition Failed . . . . . . . . . . . . . . 167
15.5.14. 413 Content Too Large . . . . . . . . . . . . . . . 167 15.5.14. 413 Content Too Large . . . . . . . . . . . . . . . 167
15.5.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . 167 15.5.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . 168
15.5.16. 415 Unsupported Media Type . . . . . . . . . . . . . 167 15.5.16. 415 Unsupported Media Type . . . . . . . . . . . . . 168
15.5.17. 416 Range Not Satisfiable . . . . . . . . . . . . . 168 15.5.17. 416 Range Not Satisfiable . . . . . . . . . . . . . 168
15.5.18. 417 Expectation Failed . . . . . . . . . . . . . . . 168 15.5.18. 417 Expectation Failed . . . . . . . . . . . . . . . 169
15.5.19. 418 (Unused) . . . . . . . . . . . . . . . . . . . . 169 15.5.19. 418 (Unused) . . . . . . . . . . . . . . . . . . . . 169
15.5.20. 421 Misdirected Request . . . . . . . . . . . . . . 169 15.5.20. 421 Misdirected Request . . . . . . . . . . . . . . 170
15.5.21. 422 Unprocessable Content . . . . . . . . . . . . . 169 15.5.21. 422 Unprocessable Content . . . . . . . . . . . . . 170
15.5.22. 426 Upgrade Required . . . . . . . . . . . . . . . . 169 15.5.22. 426 Upgrade Required . . . . . . . . . . . . . . . . 170
15.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 170 15.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 171
15.6.1. 500 Internal Server Error . . . . . . . . . . . . . 170 15.6.1. 500 Internal Server Error . . . . . . . . . . . . . 171
15.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . 170 15.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . 171
15.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 170 15.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 171
15.6.4. 503 Service Unavailable . . . . . . . . . . . . . . 171 15.6.4. 503 Service Unavailable . . . . . . . . . . . . . . 171
15.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 171 15.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 172
15.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . 171 15.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . 172
16. Extending HTTP . . . . . . . . . . . . . . . . . . . . . . . 171 16. Extending HTTP . . . . . . . . . . . . . . . . . . . . . . . 172
16.1. Method Extensibility . . . . . . . . . . . . . . . . . . 172 16.1. Method Extensibility . . . . . . . . . . . . . . . . . . 173
16.1.1. Method Registry . . . . . . . . . . . . . . . . . . 172 16.1.1. Method Registry . . . . . . . . . . . . . . . . . . 173
16.1.2. Considerations for New Methods . . . . . . . . . . . 172 16.1.2. Considerations for New Methods . . . . . . . . . . . 173
16.2. Status Code Extensibility . . . . . . . . . . . . . . . 173 16.2. Status Code Extensibility . . . . . . . . . . . . . . . 174
16.2.1. Status Code Registry . . . . . . . . . . . . . . . . 173 16.2.1. Status Code Registry . . . . . . . . . . . . . . . . 174
16.2.2. Considerations for New Status Codes . . . . . . . . 174 16.2.2. Considerations for New Status Codes . . . . . . . . 174
16.3. Field Extensibility . . . . . . . . . . . . . . . . . . 175 16.3. Field Extensibility . . . . . . . . . . . . . . . . . . 175
16.3.1. Field Name Registry . . . . . . . . . . . . . . . . 175 16.3.1. Field Name Registry . . . . . . . . . . . . . . . . 176
16.3.2. Considerations for New Fields . . . . . . . . . . . 176 16.3.2. Considerations for New Fields . . . . . . . . . . . 177
16.3.2.1. Considerations for New Field Names . . . . . . . 177 16.3.2.1. Considerations for New Field Names . . . . . . . 178
16.3.2.2. Considerations for New Field Values . . . . . . 178 16.3.2.2. Considerations for New Field Values . . . . . . 179
16.4. Authentication Scheme Extensibility . . . . . . . . . . 179
16.4.1. Authentication Scheme Registry . . . . . . . . . . . 179 16.4. Authentication Scheme Extensibility . . . . . . . . . . 180
16.4.2. Considerations for New Authentication Schemes . . . 179 16.4.1. Authentication Scheme Registry . . . . . . . . . . . 180
16.4.2. Considerations for New Authentication Schemes . . . 180
16.5. Range Unit Extensibility . . . . . . . . . . . . . . . . 181 16.5. Range Unit Extensibility . . . . . . . . . . . . . . . . 181
16.5.1. Range Unit Registry . . . . . . . . . . . . . . . . 181 16.5.1. Range Unit Registry . . . . . . . . . . . . . . . . 182
16.5.2. Considerations for New Range Units . . . . . . . . . 181 16.5.2. Considerations for New Range Units . . . . . . . . . 182
16.6. Content Coding Extensibility . . . . . . . . . . . . . . 181 16.6. Content Coding Extensibility . . . . . . . . . . . . . . 182
16.6.1. Content Coding Registry . . . . . . . . . . . . . . 181 16.6.1. Content Coding Registry . . . . . . . . . . . . . . 182
16.6.2. Considerations for New Content Codings . . . . . . . 182 16.6.2. Considerations for New Content Codings . . . . . . . 183
16.7. Upgrade Token Registry . . . . . . . . . . . . . . . . . 182 16.7. Upgrade Token Registry . . . . . . . . . . . . . . . . . 183
17. Security Considerations . . . . . . . . . . . . . . . . . . . 183 17. Security Considerations . . . . . . . . . . . . . . . . . . . 184
17.1. Establishing Authority . . . . . . . . . . . . . . . . . 183 17.1. Establishing Authority . . . . . . . . . . . . . . . . . 184
17.2. Risks of Intermediaries . . . . . . . . . . . . . . . . 184 17.2. Risks of Intermediaries . . . . . . . . . . . . . . . . 185
17.3. Attacks Based on File and Path Names . . . . . . . . . . 185 17.3. Attacks Based on File and Path Names . . . . . . . . . . 186
17.4. Attacks Based on Command, Code, or Query Injection . . . 185 17.4. Attacks Based on Command, Code, or Query Injection . . . 186
17.5. Attacks via Protocol Element Length . . . . . . . . . . 186 17.5. Attacks via Protocol Element Length . . . . . . . . . . 187
17.6. Attacks using Shared-dictionary Compression . . . . . . 187 17.6. Attacks using Shared-dictionary Compression . . . . . . 187
17.7. Disclosure of Personal Information . . . . . . . . . . . 187 17.7. Disclosure of Personal Information . . . . . . . . . . . 188
17.8. Privacy of Server Log Information . . . . . . . . . . . 187 17.8. Privacy of Server Log Information . . . . . . . . . . . 188
17.9. Disclosure of Sensitive Information in URIs . . . . . . 188 17.9. Disclosure of Sensitive Information in URIs . . . . . . 189
17.10. Application Handling of Field Names . . . . . . . . . . 188 17.10. Application Handling of Field Names . . . . . . . . . . 189
17.11. Disclosure of Fragment after Redirects . . . . . . . . . 189 17.11. Disclosure of Fragment after Redirects . . . . . . . . . 190
17.12. Disclosure of Product Information . . . . . . . . . . . 190 17.12. Disclosure of Product Information . . . . . . . . . . . 191
17.13. Browser Fingerprinting . . . . . . . . . . . . . . . . . 190 17.13. Browser Fingerprinting . . . . . . . . . . . . . . . . . 191
17.14. Validator Retention . . . . . . . . . . . . . . . . . . 191 17.14. Validator Retention . . . . . . . . . . . . . . . . . . 192
17.15. Denial-of-Service Attacks Using Range . . . . . . . . . 191 17.15. Denial-of-Service Attacks Using Range . . . . . . . . . 192
17.16. Authentication Considerations . . . . . . . . . . . . . 192 17.16. Authentication Considerations . . . . . . . . . . . . . 193
17.16.1. Confidentiality of Credentials . . . . . . . . . . 192 17.16.1. Confidentiality of Credentials . . . . . . . . . . 193
17.16.2. Credentials and Idle Clients . . . . . . . . . . . 192 17.16.2. Credentials and Idle Clients . . . . . . . . . . . 193
17.16.3. Protection Spaces . . . . . . . . . . . . . . . . . 193 17.16.3. Protection Spaces . . . . . . . . . . . . . . . . . 194
17.16.4. Additional Response Fields . . . . . . . . . . . . 193 17.16.4. Additional Response Fields . . . . . . . . . . . . 194
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 193 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 194
18.1. URI Scheme Registration . . . . . . . . . . . . . . . . 194 18.1. URI Scheme Registration . . . . . . . . . . . . . . . . 195
18.2. Method Registration . . . . . . . . . . . . . . . . . . 194 18.2. Method Registration . . . . . . . . . . . . . . . . . . 195
18.3. Status Code Registration . . . . . . . . . . . . . . . . 194 18.3. Status Code Registration . . . . . . . . . . . . . . . . 195
18.4. Field Name Registration . . . . . . . . . . . . . . . . 197 18.4. Field Name Registration . . . . . . . . . . . . . . . . 198
18.5. Authentication Scheme Registration . . . . . . . . . . . 199 18.5. Authentication Scheme Registration . . . . . . . . . . . 200
18.6. Content Coding Registration . . . . . . . . . . . . . . 200 18.6. Content Coding Registration . . . . . . . . . . . . . . 201
18.7. Range Unit Registration . . . . . . . . . . . . . . . . 200 18.7. Range Unit Registration . . . . . . . . . . . . . . . . 201
18.8. Media Type Registration . . . . . . . . . . . . . . . . 201 18.8. Media Type Registration . . . . . . . . . . . . . . . . 202
18.9. Port Registration . . . . . . . . . . . . . . . . . . . 201 18.9. Port Registration . . . . . . . . . . . . . . . . . . . 202
18.10. Upgrade Token Registration . . . . . . . . . . . . . . . 201 18.10. Upgrade Token Registration . . . . . . . . . . . . . . . 202
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 201 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 202
19.1. Normative References . . . . . . . . . . . . . . . . . . 201 19.1. Normative References . . . . . . . . . . . . . . . . . . 202
19.2. Informative References . . . . . . . . . . . . . . . . . 203 19.2. Informative References . . . . . . . . . . . . . . . . . 204
Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 210 Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 211
Appendix B. Changes from previous RFCs . . . . . . . . . . . . . 214 Appendix B. Changes from previous RFCs . . . . . . . . . . . . . 215
B.1. Changes from RFC 2818 . . . . . . . . . . . . . . . . . . 214 B.1. Changes from RFC 2818 . . . . . . . . . . . . . . . . . . 215
B.2. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 214 B.2. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 215
B.3. Changes from RFC 7231 . . . . . . . . . . . . . . . . . . 215 B.3. Changes from RFC 7231 . . . . . . . . . . . . . . . . . . 216
B.4. Changes from RFC 7232 . . . . . . . . . . . . . . . . . . 217 B.4. Changes from RFC 7232 . . . . . . . . . . . . . . . . . . 218
B.5. Changes from RFC 7233 . . . . . . . . . . . . . . . . . . 218 B.5. Changes from RFC 7233 . . . . . . . . . . . . . . . . . . 219
B.6. Changes from RFC 7235 . . . . . . . . . . . . . . . . . . 218 B.6. Changes from RFC 7235 . . . . . . . . . . . . . . . . . . 219
B.7. Changes from RFC 7538 . . . . . . . . . . . . . . . . . . 218 B.7. Changes from RFC 7538 . . . . . . . . . . . . . . . . . . 219
B.8. Changes from RFC 7615 . . . . . . . . . . . . . . . . . . 218 B.8. Changes from RFC 7615 . . . . . . . . . . . . . . . . . . 219
B.9. Changes from RFC 7694 . . . . . . . . . . . . . . . . . . 218 B.9. Changes from RFC 7694 . . . . . . . . . . . . . . . . . . 219
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 218 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 219
C.1. Between RFC723x and draft 00 . . . . . . . . . . . . . . 218 C.1. Between RFC723x and draft 00 . . . . . . . . . . . . . . 219
C.2. Since draft-ietf-httpbis-semantics-00 . . . . . . . . . . 219 C.2. Since draft-ietf-httpbis-semantics-00 . . . . . . . . . . 220
C.3. Since draft-ietf-httpbis-semantics-01 . . . . . . . . . . 219 C.3. Since draft-ietf-httpbis-semantics-01 . . . . . . . . . . 220
C.4. Since draft-ietf-httpbis-semantics-02 . . . . . . . . . . 221 C.4. Since draft-ietf-httpbis-semantics-02 . . . . . . . . . . 222
C.5. Since draft-ietf-httpbis-semantics-03 . . . . . . . . . . 222 C.5. Since draft-ietf-httpbis-semantics-03 . . . . . . . . . . 223
C.6. Since draft-ietf-httpbis-semantics-04 . . . . . . . . . . 222 C.6. Since draft-ietf-httpbis-semantics-04 . . . . . . . . . . 223
C.7. Since draft-ietf-httpbis-semantics-05 . . . . . . . . . . 223 C.7. Since draft-ietf-httpbis-semantics-05 . . . . . . . . . . 224
C.8. Since draft-ietf-httpbis-semantics-06 . . . . . . . . . . 224 C.8. Since draft-ietf-httpbis-semantics-06 . . . . . . . . . . 225
C.9. Since draft-ietf-httpbis-semantics-07 . . . . . . . . . . 226 C.9. Since draft-ietf-httpbis-semantics-07 . . . . . . . . . . 227
C.10. Since draft-ietf-httpbis-semantics-08 . . . . . . . . . . 227 C.10. Since draft-ietf-httpbis-semantics-08 . . . . . . . . . . 228
C.11. Since draft-ietf-httpbis-semantics-09 . . . . . . . . . . 228 C.11. Since draft-ietf-httpbis-semantics-09 . . . . . . . . . . 229
C.12. Since draft-ietf-httpbis-semantics-10 . . . . . . . . . . 228 C.12. Since draft-ietf-httpbis-semantics-10 . . . . . . . . . . 229
C.13. Since draft-ietf-httpbis-semantics-11 . . . . . . . . . . 230 C.13. Since draft-ietf-httpbis-semantics-11 . . . . . . . . . . 231
C.14. Since draft-ietf-httpbis-semantics-12 . . . . . . . . . . 230 C.14. Since draft-ietf-httpbis-semantics-12 . . . . . . . . . . 231
C.15. Since draft-ietf-httpbis-semantics-13 . . . . . . . . . . 232 C.15. Since draft-ietf-httpbis-semantics-13 . . . . . . . . . . 233
C.16. Since draft-ietf-httpbis-semantics-14 . . . . . . . . . . 233 C.16. Since draft-ietf-httpbis-semantics-14 . . . . . . . . . . 234
C.17. Since draft-ietf-httpbis-semantics-15 . . . . . . . . . . 235 C.17. Since draft-ietf-httpbis-semantics-15 . . . . . . . . . . 236
C.18. Since draft-ietf-httpbis-semantics-16 . . . . . . . . . . 236 C.18. Since draft-ietf-httpbis-semantics-16 . . . . . . . . . . 237
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 236 C.19. Since draft-ietf-httpbis-semantics-17 . . . . . . . . . . 237
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 239
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 248 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 251
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 29, line 43 skipping to change at page 29, line 43
If the host identifier is provided as an IP address, the origin If the host identifier is provided as an IP address, the origin
server is the listener (if any) on the indicated TCP port at that IP server is the listener (if any) on the indicated TCP port at that IP
address. If host is a registered name, the registered name is an address. If host is a registered name, the registered name is an
indirect identifier for use with a name resolution service, such as indirect identifier for use with a name resolution service, such as
DNS, to find an address for an appropriate origin server. DNS, to find an address for an appropriate origin server.
When an "http" URI is used within a context that calls for access to When an "http" URI is used within a context that calls for access to
the indicated resource, a client MAY attempt access by resolving the the indicated resource, a client MAY attempt access by resolving the
host identifier to an IP address, establishing a TCP connection to host identifier to an IP address, establishing a TCP connection to
that address on the indicated port, and sending an HTTP request that address on the indicated port, and sending over that connection
message to the server containing the URI's identifying data. an HTTP request message containing a request target that matches the
client's target URI (Section 7.1).
If the server responds to such a request with a non-interim HTTP If the server responds to such a request with a non-interim HTTP
response message, as described in Section 15, then that response is response message, as described in Section 15, then that response is
considered an authoritative answer to the client's request. considered an authoritative answer to the client's request.
Note, however, that the above is not the only means for obtaining an Note, however, that the above is not the only means for obtaining an
authoritative response, nor does it imply that an authoritative authoritative response, nor does it imply that an authoritative
response is always necessary (see [CACHING]). For example, the Alt- response is always necessary (see [CACHING]). For example, the Alt-
Svc header field [ALTSVC] allows an origin server to identify other Svc header field [ALTSVC] allows an origin server to identify other
services that are also authoritative for that origin. Access to services that are also authoritative for that origin. Access to
skipping to change at page 31, line 28 skipping to change at page 31, line 21
secured communication and thus cannot be trusted as definitive. secured communication and thus cannot be trusted as definitive.
Hence, the HTTP communication might take place over any channel that Hence, the HTTP communication might take place over any channel that
has been secured, as defined in Section 4.2.2, including protocols has been secured, as defined in Section 4.2.2, including protocols
that don't use TCP. that don't use TCP.
When an "https" URI is used within a context that calls for access to When an "https" URI is used within a context that calls for access to
the indicated resource, a client MAY attempt access by resolving the the indicated resource, a client MAY attempt access by resolving the
host identifier to an IP address, establishing a TCP connection to host identifier to an IP address, establishing a TCP connection to
that address on the indicated port, securing the connection end-to- that address on the indicated port, securing the connection end-to-
end by successfully initiating TLS over TCP with confidentiality and end by successfully initiating TLS over TCP with confidentiality and
integrity protection, and sending an HTTP request message over that integrity protection, and sending over that connection an HTTP
connection containing the URI's identifying data. request message containing a request target that matches the client's
target URI (Section 7.1).
If the server responds to such a request with a non-interim HTTP If the server responds to such a request with a non-interim HTTP
response message, as described in Section 15, then that response is response message, as described in Section 15, then that response is
considered an authoritative answer to the client's request. considered an authoritative answer to the client's request.
Note, however, that the above is not the only means for obtaining an Note, however, that the above is not the only means for obtaining an
authoritative response, nor does it imply that an authoritative authoritative response, nor does it imply that an authoritative
response is always necessary (see [CACHING]). response is always necessary (see [CACHING]).
4.3.4. https certificate verification 4.3.4. https certificate verification
skipping to change at page 33, line 20 skipping to change at page 33, line 9
HTTP uses _fields_ to provide data in the form of extensible key/ HTTP uses _fields_ to provide data in the form of extensible key/
value pairs with a registered key namespace. Fields are sent and value pairs with a registered key namespace. Fields are sent and
received within the header and trailer sections of messages received within the header and trailer sections of messages
(Section 6). (Section 6).
5.1. Field Names 5.1. Field Names
A field name labels the corresponding field value as having the A field name labels the corresponding field value as having the
semantics defined by that name. For example, the Date header field semantics defined by that name. For example, the Date header field
is defined in Section 10.2.2 as containing the origination timestamp is defined in Section 6.6.1 as containing the origination timestamp
for the message in which it appears. for the message in which it appears.
field-name = token field-name = token
Field names are case-insensitive and ought to be registered within Field names are case-insensitive and ought to be registered within
the "Hypertext Transfer Protocol (HTTP) Field Name Registry"; see the "Hypertext Transfer Protocol (HTTP) Field Name Registry"; see
Section 16.3.1. Section 16.3.1.
The interpretation of a field does not change between minor versions The interpretation of a field does not change between minor versions
of the same major HTTP version, though the default behavior of a of the same major HTTP version, though the default behavior of a
skipping to change at page 36, line 9 skipping to change at page 35, line 40
5.5. Field Values 5.5. Field Values
HTTP field values consist of a sequence of characters in a format HTTP field values consist of a sequence of characters in a format
defined by the field's grammar. Each field's grammar is usually defined by the field's grammar. Each field's grammar is usually
defined using ABNF ([RFC5234]). defined using ABNF ([RFC5234]).
field-value = *field-content field-value = *field-content
field-content = field-vchar field-content = field-vchar
[ 1*( SP / HTAB / field-vchar ) field-vchar ] [ 1*( SP / HTAB / field-vchar ) field-vchar ]
field-vchar = VCHAR / obs-text field-vchar = VCHAR / obs-text
obs-text = %x80-FF
A field value does not include leading or trailing whitespace. When A field value does not include leading or trailing whitespace. When
a specific version of HTTP allows such whitespace to appear in a a specific version of HTTP allows such whitespace to appear in a
message, a field parsing implementation MUST exclude such whitespace message, a field parsing implementation MUST exclude such whitespace
prior to evaluating the field value. prior to evaluating the field value.
Field values are usually constrained to the range of US-ASCII Field values are usually constrained to the range of US-ASCII
characters [USASCII]. Fields needing a greater range of characters characters [USASCII]. Fields needing a greater range of characters
can use an encoding, such as the one defined in [RFC8187]. can use an encoding, such as the one defined in [RFC8187].
Historically, HTTP allowed field content with text in the ISO-8859-1 Historically, HTTP allowed field content with text in the ISO-8859-1
charset [ISO-8859-1], supporting other charsets only through use of charset [ISO-8859-1], supporting other charsets only through use of
[RFC2047] encoding. Specifications for newly defined fields SHOULD [RFC2047] encoding. Specifications for newly defined fields SHOULD
limit their values to visible US-ASCII octets (VCHAR), SP, and HTAB. limit their values to visible US-ASCII octets (VCHAR), SP, and HTAB.
A recipient SHOULD treat other octets in field content (obs-text) as A recipient SHOULD treat other allowed octets in field content (i.e.,
opaque data. obs-text) as opaque data.
Field values containing CR or NUL characters are invalid and Field values containing CR, LF, or NUL characters are invalid and
dangerous, due to the varying ways that implementations might parse dangerous, due to the varying ways that implementations might parse
and interpret those characters; a recipient of CR or NUL within a and interpret those characters; a recipient of CR, LF, or NUL within
field value MUST either reject the message or replace each of those a field value MUST either reject the message or replace each of those
characters with SP before further processing or forwarding of that characters with SP before further processing or forwarding of that
message. Field values containing other CTL characters are also message. Field values containing other CTL characters are also
invalid; however, recipients MAY retain such characters for the sake invalid; however, recipients MAY retain such characters for the sake
of robustness if they only appear within safe field value contexts of robustness when they appear within a safe context (e.g., an
(e.g., opaque data). application-specific quoted string that will not be processed by any
downstream HTTP parser).
Fields that only anticipate a single member as the field value are Fields that only anticipate a single member as the field value are
referred to as _singleton fields_. referred to as _singleton fields_.
Fields that allow multiple members as the field value are referred to Fields that allow multiple members as the field value are referred to
as _list-based fields_. The list operator extension of Section 5.6.1 as _list-based fields_. The list operator extension of Section 5.6.1
is used as a common notation for defining field values that can is used as a common notation for defining field values that can
contain multiple members. contain multiple members.
Because commas (",") are used as the delimiter between members, they Because commas (",") are used as the delimiter between members, they
skipping to change at page 37, line 20 skipping to change at page 37, line 4
"http://without-a-comma.example.com/" "http://without-a-comma.example.com/"
Example-Dates: "Sat, 04 May 1996", "Wed, 14 Sep 2005" Example-Dates: "Sat, 04 May 1996", "Wed, 14 Sep 2005"
Note that double-quote delimiters are almost always used with the Note that double-quote delimiters are almost always used with the
quoted-string production (Section 5.6.4); using a different syntax quoted-string production (Section 5.6.4); using a different syntax
inside double-quotes will likely cause unnecessary confusion. inside double-quotes will likely cause unnecessary confusion.
Many fields (such as Content-Type, defined in Section 8.3) use a Many fields (such as Content-Type, defined in Section 8.3) use a
common syntax for parameters that allows both unquoted (token) and common syntax for parameters that allows both unquoted (token) and
quoted (quoted-string) syntax for a parameter value (Section 5.6.6). quoted (quoted-string) syntax for a parameter value (Section 5.6.6).
Use of common syntax allows recipients to reuse existing parser Use of common syntax allows recipients to reuse existing parser
components. When allowing both forms, the meaning of a parameter components. When allowing both forms, the meaning of a parameter
value ought to be the same whether it was received as a token or a value ought to be the same whether it was received as a token or a
quoted string. quoted string.
Historically, HTTP field values could be extended over multiple lines
by preceding each extra line with at least one space or horizontal
tab (obs-fold). This document assumes that any such obsolete line
folding has been removed prior to interpreting the field value (e.g.,
as described in Section 5.2 of [HTTP/1.1]).
| *Note:* For defining field value syntax, this specification | *Note:* For defining field value syntax, this specification
| uses an ABNF rule named after the field name to define the | uses an ABNF rule named after the field name to define the
| allowed grammar for that field's value (after said value has | allowed grammar for that field's value (after said value has
| been extracted from the underlying messaging syntax and | been extracted from the underlying messaging syntax and
| multiple instances combined into a list). | multiple instances combined into a list).
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)
skipping to change at page 38, line 8 skipping to change at page 37, line 32
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, defined in single comma (",") and optional whitespace (OWS, defined in
Section 5.6.3). 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 has to
lists that satisfy the following syntax: generate lists that satisfy the following syntax:
1#element => element *( OWS "," OWS element ) 1#element => element *( OWS "," OWS element )
and: and:
#element => [ 1#element ] #element => [ 1#element ]
and for n >= 1 and m > 1: and for n >= 1 and m > 1:
<n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element ) <n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element )
skipping to change at page 40, line 27 skipping to change at page 40, line 4
BWS = OWS BWS = OWS
; "bad" whitespace ; "bad" whitespace
5.6.4. Quoted Strings 5.6.4. Quoted Strings
A string of text is parsed as a single value if it is quoted using A string of text is parsed as a single value if it is quoted using
double-quote marks. double-quote marks.
quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
qdtext = HTAB / SP / %x21 / %x23-5B / %x5D-7E / obs-text qdtext = HTAB / SP / %x21 / %x23-5B / %x5D-7E / obs-text
obs-text = %x80-FF
The backslash octet ("\") can be used as a single-octet quoting The backslash octet ("\") can be used as a single-octet quoting
mechanism within quoted-string and comment constructs. Recipients mechanism within quoted-string and comment constructs. Recipients
that process the value of a quoted-string MUST handle a quoted-pair that process the value of a quoted-string MUST handle a quoted-pair
as if it were replaced by the octet following the backslash. as if it were replaced by the octet following the backslash.
quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text ) quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
A sender SHOULD NOT generate a quoted-pair in a quoted-string except A sender SHOULD NOT generate a quoted-pair in a quoted-string except
where necessary to quote DQUOTE and backslash octets occurring within where necessary to quote DQUOTE and backslash octets occurring within
skipping to change at page 42, line 9 skipping to change at page 41, line 33
A recipient that parses a timestamp value in an HTTP field MUST A recipient that parses a timestamp value in an HTTP field MUST
accept all three HTTP-date formats. When a sender generates a field accept all three HTTP-date formats. When a sender generates a field
that contains one or more timestamps defined as HTTP-date, the sender that contains one or more timestamps defined as HTTP-date, the sender
MUST generate those timestamps in the IMF-fixdate format. MUST generate those timestamps in the IMF-fixdate format.
An HTTP-date value represents time as an instance of Coordinated An HTTP-date value represents time as an instance of Coordinated
Universal Time (UTC). The first two formats indicate UTC by the Universal Time (UTC). The first two formats indicate UTC by the
three-letter abbreviation for Greenwich Mean Time, "GMT", a three-letter abbreviation for Greenwich Mean Time, "GMT", a
predecessor of the UTC name; values in the asctime format are assumed predecessor of the UTC name; values in the asctime format are assumed
to be in UTC. A sender that generates HTTP-date values from a local to be in UTC.
clock ought to use NTP ([RFC5905]) or some similar protocol to
synchronize its clock to UTC. A _clock_ is an implementation capable of providing a reasonable
approximation of the current instant in UTC. A clock implementation
ought to use NTP ([RFC5905]), or some similar protocol, to
synchronize with UTC.
Preferred format: Preferred format:
IMF-fixdate = day-name "," SP date1 SP time-of-day SP GMT IMF-fixdate = day-name "," SP date1 SP time-of-day SP GMT
; fixed length/zone/capitalization subset of the format ; fixed length/zone/capitalization subset of the format
; see Section 3.3 of [RFC5322] ; see Section 3.3 of [RFC5322]
day-name = %s"Mon" / %s"Tue" / %s"Wed" day-name = %s"Mon" / %s"Tue" / %s"Wed"
/ %s"Thu" / %s"Fri" / %s"Sat" / %s"Sun" / %s"Thu" / %s"Fri" / %s"Sat" / %s"Sun"
skipping to change at page 47, line 22 skipping to change at page 47, line 11
The purpose of content in a request is defined by the method The purpose of content in a request is defined by the method
semantics (Section 9). semantics (Section 9).
For example, a representation in the content of a PUT request For example, a representation in the content of a PUT request
(Section 9.3.4) represents the desired state of the target resource (Section 9.3.4) represents the desired state of the target resource
after the request is successfully applied, whereas a representation after the request is successfully applied, whereas a representation
in the content of a POST request (Section 9.3.3) represents in the content of a POST request (Section 9.3.3) represents
information to be processed by the target resource. information to be processed by the target resource.
In a response, the content's purpose is defined by both the request In a response, the content's purpose is defined by the request
method and the response status code (Section 15). For example, the method, response status code (Section 15), and response fields
content of a 200 (OK) response to GET (Section 9.3.1) represents the describing that content. For example, the content of a 200 (OK)
current state of the target resource, as observed at the time of the response to GET (Section 9.3.1) represents the current state of the
message origination date (Section 10.2.2), whereas the content of the target resource, as observed at the time of the message origination
same status code in a response to POST might represent either the date (Section 6.6.1), whereas the content of the same status code in
processing result or the new state of the target resource after a response to POST might represent either the processing result or
applying the processing. the new state of the target resource after applying the processing.
The content of a 206 (Partial Content) response to GET contains The content of a 206 (Partial Content) response to GET contains
either a single part of the selected representation or a multipart either a single part of the selected representation or a multipart
message body containing multiple parts of that representation, as message body containing multiple parts of that representation, as
described in Section 15.3.7. described in Section 15.3.7.
Response messages with an error status code usually contain content Response messages with an error status code usually contain content
that represents the error condition, such that the content describes that represents the error condition, such that the content describes
the error state and what steps are suggested for resolving it. the error state and what steps are suggested for resolving it.
skipping to change at page 48, line 40 skipping to change at page 48, line 27
specific identifier might be supplied within the content itself. specific identifier might be supplied within the content itself.
For a response message, the following rules are applied in order For a response message, the following rules are applied in order
until a match is found: until a match is found:
1. If the request method is HEAD or the response status code is 204 1. If the request method is HEAD or the response status code is 204
(No Content) or 304 (Not Modified), there is no content in the (No Content) or 304 (Not Modified), there is no content in the
response. response.
2. If the request method is GET and the response status code is 200 2. If the request method is GET and the response status code is 200
(OK), the content is a representation of the resource identified (OK), the content is a representation of the target resource
by the target URI (Section 7.1). (Section 7.1).
3. If the request method is GET and the response status code is 203 3. If the request method is GET and the response status code is 203
(Non-Authoritative Information), the content is a potentially (Non-Authoritative Information), the content is a potentially
modified or enhanced representation of the target resource as modified or enhanced representation of the target resource as
provided by an intermediary. provided by an intermediary.
4. If the request method is GET and the response status code is 206 4. If the request method is GET and the response status code is 206
(Partial Content), the content is one or more parts of a (Partial Content), the content is one or more parts of a
representation of the resource identified by the target URI representation of the target resource.
(Section 7.1).
5. If the response has a Content-Location header field and its field 5. If the response has a Content-Location header field and its field
value is a reference to the same URI as the target URI, the value is a reference to the same URI as the target URI, the
content is a representation of the target resource. content is a representation of the target resource.
6. If the response has a Content-Location header field and its field 6. If the response has a Content-Location header field and its field
value is a reference to a URI different from the target URI, then value is a reference to a URI different from the target URI, then
the sender asserts that the content is a representation of the the sender asserts that the content is a representation of the
resource identified by the Content-Location field value. resource identified by the Content-Location field value.
However, such an assertion cannot be trusted unless it can be However, such an assertion cannot be trusted unless it can be
skipping to change at page 50, line 27 skipping to change at page 50, line 21
mean that the client(s) will process any particular trailer field in mean that the client(s) will process any particular trailer field in
the response; only that the trailer section(s) will not be dropped by the response; only that the trailer section(s) will not be dropped by
any of the clients. any of the clients.
Because of the potential for trailer fields to be discarded in Because of the potential for trailer fields to be discarded in
transit, a server SHOULD NOT generate trailer fields that it believes transit, a server SHOULD NOT generate trailer fields that it believes
are necessary for the user agent to receive. are necessary for the user agent to receive.
6.5.2. Processing Trailer Fields 6.5.2. Processing Trailer Fields
The "Trailer" header field (Section 10.1.5) can be sent to indicate The "Trailer" header field (Section 6.6.2) can be sent to indicate
fields likely to be sent in the trailer section, which allows fields likely to be sent in the trailer section, which allows
recipients to prepare for their receipt before processing the recipients to prepare for their receipt before processing the
content. For example, this could be useful if a field name indicates content. For example, this could be useful if a field name indicates
that a dynamic checksum should be calculated as the content is that a dynamic checksum should be calculated as the content is
received and then immediately checked upon receipt of the trailer received and then immediately checked upon receipt of the trailer
field value. field value.
Like header fields, trailer fields with the same name are processed Like header fields, trailer fields with the same name are processed
in the order received; multiple trailer field lines with the same in the order received; multiple trailer field lines with the same
name have the equivalent semantics as appending the multiple values name have the equivalent semantics as appending the multiple values
as a list of members. Trailer fields that might be generated more as a list of members. Trailer fields that might be generated more
than once during a message MUST be defined as a list-based field even than once during a message MUST be defined as a list-based field even
if each member value is only processed once per field line received. if each member value is only processed once per field line received.
At the end of a message, a recipient MAY treat the set of received At the end of a message, a recipient MAY treat the set of received
trailer fields as a data structure of key/value pairs, similar to trailer fields as a data structure of key/value pairs, similar to
(but separate from) the header fields. Additional processing (but separate from) the header fields. Additional processing
expectations, if any, can be defined within the field specification expectations, if any, can be defined within the field specification
for a field intended for use in trailers. for a field intended for use in trailers.
6.6. Message Metadata
Fields that describe the message itself, such as when and how the
message has been generated, can appear in both requests and
responses.
6.6.1. Date
The "Date" header field represents the date and time at which the
message was originated, having the same semantics as the Origination
Date Field (orig-date) defined in Section 3.6.1 of [RFC5322]. The
field value is an HTTP-date, as defined in Section 5.6.7.
Date = HTTP-date
An example is
Date: Tue, 15 Nov 1994 08:12:31 GMT
A sender that generates a Date header field SHOULD generate its field
value as the best available approximation of the date and time of
message generation. In theory, the date ought to represent the
moment just before generating the message content. In practice, a
sender can generate the date value at any time during message
origination.
An origin server with a clock (as defined in Section 5.6.7) MUST
generate a Date header field in all 2xx (Successful), 3xx
(Redirection), and 4xx (Client Error) responses, and MAY generate a
Date header field in 1xx (Informational) and 5xx (Server Error)
responses.
An origin server without a clock MUST NOT generate a Date header
field.
A recipient with a clock that receives a response message without a
Date header field MUST record the time it was received and append a
corresponding Date header field to the message's header section if it
is cached or forwarded downstream.
A recipient with a clock that receives a response with an invalid
Date header field value MAY replace that value with the time that
response was received.
A user agent MAY send a Date header field in a request, though
generally will not do so unless it is believed to convey useful
information to the server. For example, custom applications of HTTP
might convey a Date if the server is expected to adjust its
interpretation of the user's request based on differences between the
user agent and server clocks.
6.6.2. Trailer
The "Trailer" header field provides a list of field names that the
sender anticipates sending as trailer fields within that message.
This allows a recipient to prepare for receipt of the indicated
metadata before it starts processing the content.
Trailer = #field-name
For example, a sender might indicate that a signature will be
computed as the content is being streamed and provide the final
signature as a trailer field. This allows a recipient to perform the
same check on the fly as it receives the content.
A sender that intends to generate one or more trailer fields in a
message SHOULD generate a Trailer header field in the header section
of that message to indicate which fields might be present in the
trailers.
If an intermediary discards the trailer section in transit, the
Trailer field could provide a hint of what metadata was lost, though
there is no guarantee that a sender of Trailer will always follow
through by sending the named fields.
7. Routing HTTP Messages 7. Routing HTTP Messages
HTTP request message routing is determined by each client based on HTTP request message routing is determined by each client based on
the target resource, the client's proxy configuration, and the target resource, the client's proxy configuration, and
establishment or reuse of an inbound connection. The corresponding establishment or reuse of an inbound connection. The corresponding
response routing follows the same connection chain back to the response routing follows the same connection chain back to the
client. client.
7.1. Determining the Target Resource 7.1. Determining the Target Resource
skipping to change at page 53, line 12 skipping to change at page 54, line 35
If the client has a cache [CACHING] and the request can be satisfied If the client has a cache [CACHING] and the request can be satisfied
by it, then the request is usually directed there first. by it, then the request is usually directed there first.
7.3.2. To a Proxy 7.3.2. To a Proxy
If the request is not satisfied by a cache, then a typical client If the request is not satisfied by a cache, then a typical client
will check its configuration to determine whether a proxy is to be will check its configuration to determine whether a proxy is to be
used to satisfy the request. Proxy configuration is implementation- used to satisfy the request. Proxy configuration is implementation-
dependent, but is often based on URI prefix matching, selective dependent, but is often based on URI prefix matching, selective
authority matching, or both, and the proxy itself is usually authority matching, or both, and the proxy itself is usually
identified by an "http" or "https" URI. If a proxy is applicable, identified by an "http" or "https" URI.
the client connects inbound by establishing (or reusing) a connection
to that proxy. If an "http" or "https" proxy is applicable, the client connects
inbound by establishing (or reusing) a connection to that proxy and
then sending it an HTTP request message containing a request target
that matches the client's target URI.
7.3.3. To the Origin 7.3.3. To the Origin
If no proxy is applicable, a typical client will invoke a handler If no proxy is applicable, a typical client will invoke a handler
routine, usually specific to the target URI's scheme, to connect routine (specific to the target URI's scheme) to obtain access to the
directly to an origin for the target resource. How that is identified resource. How that is accomplished is dependent on the
accomplished is dependent on the target URI scheme and defined by its target URI scheme and defined by its associated specification.
associated specification.
Section 4.3.2 defines how to obtain access to an "http" resource by
establishing (or reusing) an inbound connection to the identified
origin server and then sending it an HTTP request message containing
a request target that matches the client's target URI.
Section 4.3.3 defines how to obtain access to an "https" resource by
establishing (or reusing) an inbound secured connection to an origin
server that is authoritative for the identified origin and then
sending it an HTTP request message containing a request target that
matches the client's target URI.
7.4. Rejecting Misdirected Requests 7.4. Rejecting Misdirected Requests
Once a request is received by a server and parsed sufficiently to Once a request is received by a server and parsed sufficiently to
determine its target URI, the server decides whether to process the determine its target URI, the server decides whether to process the
request itself, forward the request to another server, redirect the request itself, forward the request to another server, redirect the
client to a different resource, respond with an error, or drop the client to a different resource, respond with an error, or drop the
connection. This decision can be influenced by anything about the connection. This decision can be influenced by anything about the
request or connection context, but is specifically directed at request or connection context, but is specifically directed at
whether the server has been configured to process requests for that whether the server has been configured to process requests for that
skipping to change at page 59, line 35 skipping to change at page 61, line 23
format transcoder, or a privacy filter. Such transformations are format transcoder, or a privacy filter. Such transformations are
presumed to be desired by whichever client (or client organization) presumed to be desired by whichever client (or client organization)
chose the proxy. chose the proxy.
If a proxy receives a target URI with a host name that is not a fully If a proxy receives a target URI with a host name that is not a fully
qualified domain name, it MAY add its own domain to the host name it qualified domain name, it MAY add its own domain to the host name it
received when forwarding the request. A proxy MUST NOT change the received when forwarding the request. A proxy MUST NOT change the
host name if the target URI contains a fully qualified domain name. host name if the target URI contains a fully qualified domain name.
A proxy MUST NOT modify the "absolute-path" and "query" parts of the A proxy MUST NOT modify the "absolute-path" and "query" parts of the
received target URI when forwarding it to the next inbound server, received target URI when forwarding it to the next inbound server
except as noted above to replace an empty path with "/" or "*". except as required by that forwarding protocol. For example, a proxy
forwarding a request to an origin server via HTTP/1.1 will replace an
empty path with "/" (Section 3.2.1 of [HTTP/1.1]) or "*"
(Section 3.2.4 of [HTTP/1.1]), depending on the request method.
A proxy MUST NOT transform the content (Section 6.4) of a message A proxy MUST NOT transform the content (Section 6.4) of a message
that contains a no-transform cache-control response directive that contains a no-transform cache-control response directive
(Section 5.2 of [CACHING]). Note that this does not include changes (Section 5.2 of [CACHING]). Note that this does not include changes
to the message body that do not affect the content, such as transfer to the message body that do not affect the content, such as transfer
codings (Section 7 of [HTTP/1.1]). codings (Section 7 of [HTTP/1.1]).
A proxy MAY transform the content of a message that does not contain A proxy MAY transform the content of a message that does not contain
a no-transform cache-control directive. A proxy that transforms the a no-transform cache-control directive. A proxy that transforms the
content of a 200 (OK) response can inform downstream recipients that content of a 200 (OK) response can inform downstream recipients that
skipping to change at page 63, line 34 skipping to change at page 65, line 17
Content-Type header field is not present, the recipient MAY either Content-Type header field is not present, the recipient MAY either
assume a media type of "application/octet-stream" ([RFC2046], assume a media type of "application/octet-stream" ([RFC2046],
Section 4.5.1) or examine the data to determine its type. Section 4.5.1) or examine the data to determine its type.
In practice, resource owners do not always properly configure their In practice, resource owners do not always properly configure their
origin server to provide the correct Content-Type for a given origin server to provide the correct Content-Type for a given
representation. Some user agents examine the content and, in certain representation. Some user agents examine the content and, in certain
cases, override the received type (for example, see [Sniffing]). cases, override the received type (for example, see [Sniffing]).
This "MIME sniffing" risks drawing incorrect conclusions about the This "MIME sniffing" risks drawing incorrect conclusions about the
data, which might expose the user to additional security risks (e.g., data, which might expose the user to additional security risks (e.g.,
"privilege escalation"). Furthermore, it is impossible to determine "privilege escalation"). Furthermore, distinct media types often
the sender's intended processing model by examining the data format: share a common data format, differing only in how the data is
many data formats match multiple media types that differ only in intended to be processed, which is impossible to distinguish by
processing semantics. Implementers are encouraged to provide a means inspecting the data alone. When sniffing is implemented,
to disable such sniffing. implementers are encouraged to provide a means for the user to
disable it.
Furthermore, although Content-Type is defined as a singleton field, Although Content-Type is defined as a singleton field, it is
it is sometimes incorrectly generated multiple times, resulting in a sometimes incorrectly generated multiple times, resulting in a
combined field value that appears to be a list. Recipients often combined field value that appears to be a list. Recipients often
attempt to handle this error by using the last syntactically valid attempt to handle this error by using the last syntactically valid
member of the list, but note that some implementations might have member of the list, leading to potential interoperability and
different error handling behaviors, leading to interoperability and/ security issues if different implementations have different error
or security issues. handling behaviors.
8.3.1. Media Type 8.3.1. Media Type
HTTP uses media types [RFC2046] in the Content-Type (Section 8.3) and HTTP uses media types [RFC2046] in the Content-Type (Section 8.3) and
Accept (Section 12.5.1) header fields in order to provide open and Accept (Section 12.5.1) header fields in order to provide open and
extensible data typing and type negotiation. Media types define both extensible data typing and type negotiation. Media types define both
a data format and various processing models: how to process that data a data format and various processing models: how to process that data
in accordance with the message context. in accordance with the message context.
media-type = type "/" subtype parameters media-type = type "/" subtype parameters
skipping to change at page 72, line 24 skipping to change at page 74, line 7
and the origin server accepts that PUT (without redirection), then and the origin server accepts that PUT (without redirection), then
the new state of that resource is expected to be consistent with the the new state of that resource is expected to be consistent with the
one representation supplied in that PUT; the Content-Location cannot one representation supplied in that PUT; the Content-Location cannot
be used as a form of reverse content selection identifier to update be used as a form of reverse content selection identifier to update
only one of the negotiated representations. If the user agent had only one of the negotiated representations. If the user agent had
wanted the latter semantics, it would have applied the PUT directly wanted the latter semantics, it would have applied the PUT directly
to the Content-Location URI. to the Content-Location URI.
8.8. Validator Fields 8.8. Validator Fields
Validator fields convey metadata about the selected representation Resource metadata is referred to as a _validator_ if it can be used
(Section 3.2). In responses to safe requests, validator fields within a precondition (Section 13.1) to make a conditional request
describe the selected representation chosen by the origin server (Section 13). Validator fields convey a current validator for the
while handling the response. Note that, depending on the status code selected representation (Section 3.2).
In responses to safe requests, validator fields describe the selected
representation chosen by the origin server while handling the
response. Note that, depending on the method and status code
semantics, the selected representation for a given response is not semantics, the selected representation for a given response is not
necessarily the same as the representation enclosed as response necessarily the same as the representation enclosed as response
content. content.
In a successful response to a state-changing request, validator In a successful response to a state-changing request, validator
fields describe the new representation that has replaced the prior fields describe the new representation that has replaced the prior
selected representation as a result of processing the request. selected representation as a result of processing the request.
For example, an ETag field in a 201 (Created) response communicates For example, an ETag field in a 201 (Created) response communicates
the entity-tag of the newly created resource's representation, so the entity-tag of the newly created resource's representation, so
that it can be used in later conditional requests to prevent the that the entity-tag can be used as a validator in later conditional
"lost update" problem (Section 13.1). requests to prevent the "lost update" problem.
This specification defines two forms of metadata that are commonly This specification defines two forms of metadata that are commonly
used to observe resource state and test for preconditions: used to observe resource state and test for preconditions:
modification dates (Section 8.8.2) and opaque entity tags modification dates (Section 8.8.2) and opaque entity tags
(Section 8.8.3). Additional metadata that reflects resource state (Section 8.8.3). Additional metadata that reflects resource state
has been defined by various extensions of HTTP, such as Web has been defined by various extensions of HTTP, such as Web
Distributed Authoring and Versioning [WEBDAV], that are beyond the Distributed Authoring and Versioning [WEBDAV], that are beyond the
scope of this specification. A resource metadata value is referred scope of this specification.
to as a _validator_ when it is used within a precondition.
8.8.1. Weak versus Strong 8.8.1. Weak versus Strong
Validators come in two flavors: strong or weak. Weak validators are Validators come in two flavors: strong or weak. Weak validators are
easy to generate but are far less useful for comparisons. Strong easy to generate but are far less useful for comparisons. Strong
validators are ideal for comparisons but can be very difficult (and validators are ideal for comparisons but can be very difficult (and
occasionally impossible) to generate efficiently. Rather than impose occasionally impossible) to generate efficiently. Rather than impose
that all forms of resource adhere to the same strength of validator, that all forms of resource adhere to the same strength of validator,
HTTP exposes the type of validator in use and imposes restrictions on HTTP exposes the type of validator in use and imposes restrictions on
when weak validators can be used as preconditions. when weak validators can be used as preconditions.
skipping to change at page 73, line 52 skipping to change at page 75, line 34
prior to the response header fields being sent and the digest does prior to the response header fields being sent and the digest does
not need to be recalculated every time a validation request is not need to be recalculated every time a validation request is
received. However, if a resource has distinct representations that received. However, if a resource has distinct representations that
differ only in their metadata, such as might occur with content differ only in their metadata, such as might occur with content
negotiation over media types that happen to share the same data negotiation over media types that happen to share the same data
format, then the origin server needs to incorporate additional format, then the origin server needs to incorporate additional
information in the validator to distinguish those representations. information in the validator to distinguish those representations.
In contrast, a _weak validator_ is representation metadata that might In contrast, a _weak validator_ is representation metadata that might
not change for every change to the representation data. This not change for every change to the representation data. This
weakness might be due to limitations in how the value is calculated, weakness might be due to limitations in how the value is calculated
such as clock resolution, an inability to ensure uniqueness for all (e.g., clock resolution), an inability to ensure uniqueness for all
possible representations of the resource, or a desire of the resource possible representations of the resource, or a desire of the resource
owner to group representations by some self-determined set of owner to group representations by some self-determined set of
equivalency rather than unique sequences of data. An origin server equivalency rather than unique sequences of data.
SHOULD change a weak entity-tag whenever it considers prior
representations to be unacceptable as a substitute for the current An origin server SHOULD change a weak entity-tag whenever it
representation. In other words, a weak entity-tag ought to change considers prior representations to be unacceptable as a substitute
whenever the origin server wants caches to invalidate old responses. for the current representation. In other words, a weak entity-tag
ought to change whenever the origin server wants caches to invalidate
old responses.
For example, the representation of a weather report that changes in For example, the representation of a weather report that changes in
content every second, based on dynamic measurements, might be grouped content every second, based on dynamic measurements, might be grouped
into sets of equivalent representations (from the origin server's into sets of equivalent representations (from the origin server's
perspective) with the same weak validator in order to allow cached perspective) with the same weak validator in order to allow cached
representations to be valid for a reasonable period of time (perhaps representations to be valid for a reasonable period of time (perhaps
adjusted dynamically based on server load or weather quality). adjusted dynamically based on server load or weather quality).
Likewise, a representation's modification time, if defined with only Likewise, a representation's modification time, if defined with only
one-second resolution, might be a weak validator if it is possible one-second resolution, might be a weak validator if it is possible
for the representation to be modified twice during a single second for the representation to be modified twice during a single second
and retrieved between those modifications. and retrieved between those modifications.
Likewise, a validator is weak if it is shared by two or more Likewise, a validator is weak if it is shared by two or more
representations of a given resource at the same time, unless those representations of a given resource at the same time, unless those
representations have identical representation data. For example, if representations have identical representation data. For example, if
the origin server sends the same validator for a representation with the origin server sends the same validator for a representation with
a gzip content coding applied as it does for a representation with no a gzip content coding applied as it does for a representation with no
skipping to change at page 75, line 28 skipping to change at page 77, line 18
determined for any given resource is an implementation detail beyond determined for any given resource is an implementation detail beyond
the scope of this specification. the scope of this specification.
An origin server SHOULD obtain the Last-Modified value of the An origin server SHOULD obtain the Last-Modified value of the
representation as close as possible to the time that it generates the representation as close as possible to the time that it generates the
Date field value for its response. This allows a recipient to make Date field value for its response. This allows a recipient to make
an accurate assessment of the representation's modification time, an accurate assessment of the representation's modification time,
especially if the representation changes near the time that the especially if the representation changes near the time that the
response is generated. response is generated.
An origin server with a clock MUST NOT send a Last-Modified date that An origin server with a clock (as defined in Section 5.6.7) MUST NOT
is later than the server's time of message origination (Date). If generate a Last-Modified date that is later than the server's time of
the last modification time is derived from implementation-specific message origination (Date, Section 6.6.1). If the last modification
metadata that evaluates to some time in the future, according to the time is derived from implementation-specific metadata that evaluates
origin server's clock, then the origin server MUST replace that value to some time in the future, according to the origin server's clock,
with the message origination date. This prevents a future then the origin server MUST replace that value with the message
modification date from having an adverse impact on cache validation. origination date. This prevents a future modification date from
having an adverse impact on cache validation.
An origin server without a clock MUST NOT assign Last-Modified values An origin server without a clock MUST NOT generate a Last-Modified
to a response unless these values were associated with the resource date for a response unless that date value was assigned to the
by some other system or user with a reliable clock. resource by some other system (presumably one with a clock).
8.8.2.2. Comparison 8.8.2.2. Comparison
A Last-Modified time, when used as a validator in a request, is A Last-Modified time, when used as a validator in a request, is
implicitly weak unless it is possible to deduce that it is strong, implicitly weak unless it is possible to deduce that it is strong,
using the following rules: using the following rules:
* The validator is being compared by an origin server to the actual * The validator is being compared by an origin server to the actual
current validator for the representation and, current validator for the representation and,
skipping to change at page 79, line 45 skipping to change at page 81, line 41
...binary data... ...binary data...
| *Note:* Content codings are a property of the representation | *Note:* Content codings are a property of the representation
| data, so a strong entity-tag for a content-encoded | data, so a strong entity-tag for a content-encoded
| representation has to be distinct from the entity tag of an | representation has to be distinct from the entity tag of an
| unencoded representation to prevent potential conflicts during | unencoded representation to prevent potential conflicts during
| cache updates and range requests. In contrast, transfer | cache updates and range requests. In contrast, transfer
| codings (Section 7 of [HTTP/1.1]) apply only during message | codings (Section 7 of [HTTP/1.1]) apply only during message
| transfer and do not result in distinct entity-tags. | transfer and do not result in distinct entity-tags.
8.8.4. When to Use Entity-Tags and Last-Modified Dates
In 200 (OK) responses to GET or HEAD, an origin server:
* SHOULD send an entity-tag validator unless it is not feasible to
generate one.
* MAY send a weak entity-tag instead of a strong entity-tag, if
performance considerations support the use of weak entity-tags, or
if it is unfeasible to send a strong entity-tag.
* SHOULD send a Last-Modified value if it is feasible to send one.
In other words, the preferred behavior for an origin server is to
send both a strong entity-tag and a Last-Modified value in successful
responses to a retrieval request.
A client:
* MUST send that entity-tag in any cache validation request (using
If-Match or If-None-Match) if an entity-tag has been provided by
the origin server.
* SHOULD send the Last-Modified value in non-subrange cache
validation requests (using If-Modified-Since) if only a Last-
Modified value has been provided by the origin server.
* MAY send the Last-Modified value in subrange cache validation
requests (using If-Unmodified-Since) if only a Last-Modified value
has been provided by an HTTP/1.0 origin server. The user agent
SHOULD provide a way to disable this, in case of difficulty.
* SHOULD send both validators in cache validation requests if both
an entity-tag and a Last-Modified value have been provided by the
origin server. This allows both HTTP/1.0 and HTTP/1.1 caches to
respond appropriately.
9. Methods 9. Methods
9.1. Overview 9.1. Overview
The request method token is the primary source of request semantics; The request method token is the primary source of request semantics;
it indicates the purpose for which the client has made this request it indicates the purpose for which the client has made this request
and what is expected by the client as a successful result. and what is expected by the client as a successful result.
The request method's semantics might be further specialized by the The request method's semantics might be further specialized by the
semantics of some header fields when present in a request if those semantics of some header fields when present in a request if those
skipping to change at page 88, line 18 skipping to change at page 89, line 18
appropriate status code depending on the result of processing the appropriate status code depending on the result of processing the
POST request; almost all of the status codes defined by this POST request; almost all of the status codes defined by this
specification could be received in a response to POST (the exceptions specification could be received in a response to POST (the exceptions
being 206 (Partial Content), 304 (Not Modified), and 416 (Range Not being 206 (Partial Content), 304 (Not Modified), and 416 (Range Not
Satisfiable)). Satisfiable)).
If one or more resources has been created on the origin server as a If one or more resources has been created on the origin server as a
result of successfully processing a POST request, the origin server result of successfully processing a POST request, the origin server
SHOULD send a 201 (Created) response containing a Location header SHOULD send a 201 (Created) response containing a Location header
field that provides an identifier for the primary resource created field that provides an identifier for the primary resource created
(Section 10.2.3) and a representation that describes the status of (Section 10.2.2) and a representation that describes the status of
the request while referring to the new resource(s). the request while referring to the new resource(s).
Responses to POST requests are only cacheable when they include Responses to POST requests are only cacheable when they include
explicit freshness information (see Section 4.2.1 of [CACHING]) and a explicit freshness information (see Section 4.2.1 of [CACHING]) and a
Content-Location header field that has the same value as the POST's Content-Location header field that has the same value as the POST's
target URI (Section 8.7). A cached POST response can be reused to target URI (Section 8.7). A cached POST response can be reused to
satisfy a later GET or HEAD request, but not a POST request, since satisfy a later GET or HEAD request, but not a POST request, since
POST is required to be written through to the origin server, because POST is required to be written through to the origin server, because
it is unsafe; see Section 4 of [CACHING]. it is unsafe; see Section 4 of [CACHING].
skipping to change at page 100, line 43 skipping to change at page 101, line 43
A TE field with a "trailers" member sent in a request indicates that A TE field with a "trailers" member sent in a request indicates that
the client will not discard trailer fields, as described in the client will not discard trailer fields, as described in
Section 6.5. Section 6.5.
TE is also used within HTTP/1.1 to advise servers about what transfer TE is also used within HTTP/1.1 to advise servers about what transfer
codings the client is able to accept in a response. As of codings the client is able to accept in a response. As of
publication, only HTTP/1.1 uses transfer codings (see Section 7 of publication, only HTTP/1.1 uses transfer codings (see Section 7 of
[HTTP/1.1]). [HTTP/1.1]).
The TE field value consists of a list of tokens, each allowing for The TE field value is a list of members, with each member (aside from
optional parameters (except for the special case "trailers"). "trailers") consisting of a transfer coding name token with an
optional weight indicating the client's relative preference for that
transfer coding (Section 12.4.2) and optional parameters for that
transfer coding.
TE = #t-codings TE = #t-codings
t-codings = "trailers" / ( transfer-coding [ weight ] ) t-codings = "trailers" / ( transfer-coding [ weight ] )
transfer-coding = token *( OWS ";" OWS transfer-parameter ) transfer-coding = token *( OWS ";" OWS transfer-parameter )
transfer-parameter = token BWS "=" BWS ( token / quoted-string ) transfer-parameter = token BWS "=" BWS ( token / quoted-string )
A sender of TE MUST also send a "TE" connection option within the A sender of TE MUST also send a "TE" connection option within the
Connection header field (Section 7.6.1) to inform intermediaries not Connection header field (Section 7.6.1) to inform intermediaries not
to forward this field. to forward this field.
10.1.5. Trailer 10.1.5. User-Agent
The "Trailer" header field provides a list of field names that the
sender anticipates sending as trailer fields within that message.
This allows a recipient to prepare for receipt of the indicated
metadata before it starts processing the content.
Trailer = #field-name
For example, a sender might indicate that a message integrity check
will be computed as the content is being streamed and provide the
final signature as a trailer field. This allows a recipient to
perform the same check on the fly as it receives the content.
Because the Trailer field is not removed by intermediaries, it can
also be used by downstream recipients to discover when a trailer
field has been removed from a message.
A sender that intends to generate one or more trailer fields in a
message SHOULD generate a Trailer header field in the header section
of that message to indicate which fields might be present in the
trailers.
10.1.6. User-Agent
The "User-Agent" header field contains information about the user The "User-Agent" header field contains information about the user
agent originating the request, which is often used by servers to help agent originating the request, which is often used by servers to help
identify the scope of reported interoperability problems, to work identify the scope of reported interoperability problems, to work
around or tailor responses to avoid particular user agent around or tailor responses to avoid particular user agent
limitations, and for analytics regarding browser or operating system limitations, and for analytics regarding browser or operating system
use. A user agent SHOULD send a User-Agent header field in each use. A user agent SHOULD send a User-Agent header field in each
request unless specifically configured not to do so. request unless specifically configured not to do so.
User-Agent = product *( RWS ( product / comment ) ) User-Agent = product *( RWS ( product / comment ) )
skipping to change at page 103, line 15 skipping to change at page 104, line 5
the time of each request. An origin server MUST generate an Allow the time of each request. An origin server MUST generate an Allow
header field in a 405 (Method Not Allowed) response and MAY do so in header field in a 405 (Method Not Allowed) response and MAY do so in
any other response. An empty Allow field value indicates that the any other response. An empty Allow field value indicates that the
resource allows no methods, which might occur in a 405 response if resource allows no methods, which might occur in a 405 response if
the resource has been temporarily disabled by configuration. the resource has been temporarily disabled by configuration.
A proxy MUST NOT modify the Allow header field - it does not need to A proxy MUST NOT modify the Allow header field - it does not need to
understand all of the indicated methods in order to handle them understand all of the indicated methods in order to handle them
according to the generic message handling rules. according to the generic message handling rules.
10.2.2. Date 10.2.2. Location
The "Date" header field represents the date and time at which the
message was originated, having the same semantics as the Origination
Date Field (orig-date) defined in Section 3.6.1 of [RFC5322]. The
field value is an HTTP-date, as defined in Section 5.6.7.
Date = HTTP-date
An example is
Date: Tue, 15 Nov 1994 08:12:31 GMT
A sender that generates a Date header field SHOULD generate its field
value as the best available approximation of the date and time of
message generation. In theory, the date ought to represent the
moment just before generating the message content. In practice, a
sender can generate the date value at any time during message
origination.
An origin server MUST NOT send a Date header field if it does not
have a clock capable of providing a reasonable approximation of the
current instant in Coordinated Universal Time. An origin server MAY
send a Date header field if the response is in the 1xx
(Informational) or 5xx (Server Error) class of status codes. An
origin server MUST send a Date header field in all other cases.
A recipient with a clock that receives a response message without a
Date header field MUST record the time it was received and append a
corresponding Date header field to the message's header section if it
is cached or forwarded downstream.
A recipient with a clock that receives a response with an invalid
Date header field value MAY replace that value with the time that
response was received.
A user agent MAY send a Date header field in a request, though
generally will not do so unless it is believed to convey useful
information to the server. For example, custom applications of HTTP
might convey a Date if the server is expected to adjust its
interpretation of the user's request based on differences between the
user agent and server clocks.
10.2.3. Location
The "Location" header field is used in some responses to refer to a The "Location" header field is used in some responses to refer to a
specific resource in relation to the response. The type of specific resource in relation to the response. The type of
relationship is defined by the combination of request method and relationship is defined by the combination of request method and
status code semantics. status code semantics.
Location = URI-reference Location = URI-reference
The field value consists of a single URI-reference. When it has the The field value consists of a single URI-reference. When it has the
form of a relative reference ([URI], Section 4.2), the final value is form of a relative reference ([URI], Section 4.2), the final value is
skipping to change at page 105, line 30 skipping to change at page 105, line 22
| along the path might combine those field lines into one value. | along the path might combine those field lines into one value.
| Recovery of a valid Location field value from that situation is | Recovery of a valid Location field value from that situation is
| difficult and not interoperable across implementations. | difficult and not interoperable across implementations.
| *Note:* The Content-Location header field (Section 8.7) differs | *Note:* The Content-Location header field (Section 8.7) differs
| from Location in that the Content-Location refers to the most | from Location in that the Content-Location refers to the most
| specific resource corresponding to the enclosed representation. | specific resource corresponding to the enclosed representation.
| It is therefore possible for a response to contain both the | It is therefore possible for a response to contain both the
| Location and Content-Location header fields. | Location and Content-Location header fields.
10.2.4. Retry-After 10.2.3. Retry-After
Servers send the "Retry-After" header field to indicate how long the Servers send the "Retry-After" header field to indicate how long the
user agent ought to wait before making a follow-up request. When user agent ought to wait before making a follow-up request. When
sent with a 503 (Service Unavailable) response, Retry-After indicates sent with a 503 (Service Unavailable) response, Retry-After indicates
how long the service is expected to be unavailable to the client. how long the service is expected to be unavailable to the client.
When sent with any 3xx (Redirection) response, Retry-After indicates When sent with any 3xx (Redirection) response, Retry-After indicates
the minimum time that the user agent is asked to wait before issuing the minimum time that the user agent is asked to wait before issuing
the redirected request. the redirected request.
The Retry-After field value can be either an HTTP-date or a number of The Retry-After field value can be either an HTTP-date or a number of
skipping to change at page 106, line 4 skipping to change at page 105, line 43
seconds to delay after receiving the response. seconds to delay after receiving the response.
Retry-After = HTTP-date / delay-seconds Retry-After = HTTP-date / delay-seconds
A delay-seconds value is a non-negative decimal integer, representing A delay-seconds value is a non-negative decimal integer, representing
time in seconds. time in seconds.
delay-seconds = 1*DIGIT delay-seconds = 1*DIGIT
Two examples of its use are Two examples of its use are
Retry-After: Fri, 31 Dec 1999 23:59:59 GMT Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120 Retry-After: 120
In the latter example, the delay is 2 minutes. In the latter example, the delay is 2 minutes.
10.2.5. Server 10.2.4. Server
The "Server" header field contains information about the software The "Server" header field contains information about the software
used by the origin server to handle the request, which is often used used by the origin server to handle the request, which is often used
by clients to help identify the scope of reported interoperability by clients to help identify the scope of reported interoperability
problems, to work around or tailor requests to avoid particular problems, to work around or tailor requests to avoid particular
server limitations, and for analytics regarding server or operating server limitations, and for analytics regarding server or operating
system use. An origin server MAY generate a Server header field in system use. An origin server MAY generate a Server header field in
its responses. its responses.
Server = product *( RWS ( product / comment ) ) Server = product *( RWS ( product / comment ) )
The Server header field value consists of one or more product The Server header field value consists of one or more product
identifiers, each followed by zero or more comments (Section 5.6.5), identifiers, each followed by zero or more comments (Section 5.6.5),
which together identify the origin server software and its which together identify the origin server software and its
significant subproducts. By convention, the product identifiers are significant subproducts. By convention, the product identifiers are
listed in decreasing order of their significance for identifying the listed in decreasing order of their significance for identifying the
origin server software. Each product identifier consists of a name origin server software. Each product identifier consists of a name
and optional version, as defined in Section 10.1.6. and optional version, as defined in Section 10.1.5.
Example: Example:
Server: CERN/3.0 libwww/2.17 Server: CERN/3.0 libwww/2.17
An origin server SHOULD NOT generate a Server header field containing An origin server SHOULD NOT generate a Server header field containing
needlessly fine-grained detail and SHOULD limit the addition of needlessly fine-grained detail and SHOULD limit the addition of
subproducts by third parties. Overly long and detailed Server field subproducts by third parties. Overly long and detailed Server field
values increase response latency and potentially reveal internal values increase response latency and potentially reveal internal
implementation details that might make it (slightly) easier for implementation details that might make it (slightly) easier for
skipping to change at page 113, line 36 skipping to change at page 113, line 36
chain. This is because only the client that chose a given proxy is chain. This is because only the client that chose a given proxy is
likely to have the credentials necessary for authentication. likely to have the credentials necessary for authentication.
However, when multiple proxies are used within the same However, when multiple proxies are used within the same
administrative domain, such as office and regional caching proxies administrative domain, such as office and regional caching proxies
within a large corporate network, it is common for credentials to be within a large corporate network, it is common for credentials to be
generated by the user agent and passed through the hierarchy until generated by the user agent and passed through the hierarchy until
consumed. Hence, in such a configuration, it will appear as if consumed. Hence, in such a configuration, it will appear as if
Proxy-Authentication-Info is being forwarded because each proxy will Proxy-Authentication-Info is being forwarded because each proxy will
send the same field value. send the same field value.
Proxy-Authentication-Info can be sent as a trailer field
(Section 6.5) when the authentication scheme explicitly allows this.
12. Content Negotiation 12. Content Negotiation
When responses convey content, whether indicating a success or an When responses convey content, whether indicating a success or an
error, the origin server often has different ways of representing error, the origin server often has different ways of representing
that information; for example, in different formats, languages, or that information; for example, in different formats, languages, or
encodings. Likewise, different users or user agents might have encodings. Likewise, different users or user agents might have
differing capabilities, characteristics, or preferences that could differing capabilities, characteristics, or preferences that could
influence which representation, among those available, would be best influence which representation, among those available, would be best
to deliver. For this reason, HTTP provides mechanisms for content to deliver. For this reason, HTTP provides mechanisms for content
negotiation. negotiation.
skipping to change at page 121, line 40 skipping to change at page 121, line 26
When sent by a server in a response, Accept-Encoding provides When sent by a server in a response, Accept-Encoding provides
information about what content codings are preferred in the content information about what content codings are preferred in the content
of a subsequent request to the same resource. of a subsequent request to the same resource.
An "identity" token is used as a synonym for "no encoding" in order An "identity" token is used as a synonym for "no encoding" in order
to communicate when no encoding is preferred. to communicate when no encoding is preferred.
Accept-Encoding = #( codings [ weight ] ) Accept-Encoding = #( codings [ weight ] )
codings = content-coding / "identity" / "*" codings = content-coding / "identity" / "*"
Each codings value MAY be given an associated quality value Each codings value MAY be given an associated quality value (weight)
representing the preference for that encoding, as defined in representing the preference for that encoding, as defined in
Section 12.4.2. The asterisk "*" symbol in an Accept-Encoding field Section 12.4.2. The asterisk "*" symbol in an Accept-Encoding field
matches any available content coding not explicitly listed in the matches any available content coding not explicitly listed in the
field. field.
For example, Examples:
Accept-Encoding: compress, gzip Accept-Encoding: compress, gzip
Accept-Encoding: Accept-Encoding:
Accept-Encoding: * Accept-Encoding: *
Accept-Encoding: compress;q=0.5, gzip;q=1.0 Accept-Encoding: compress;q=0.5, gzip;q=1.0
Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0 Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0
A server tests whether a content coding for a given representation is A server tests whether a content coding for a given representation is
acceptable using these rules: acceptable using these rules:
1. If no Accept-Encoding header field is in the request, any content 1. If no Accept-Encoding header field is in the request, any content
coding is considered acceptable by the user agent. coding is considered acceptable by the user agent.
2. If the representation has no content coding, then it is 2. If the representation has no content coding, then it is
acceptable by default unless specifically excluded by the Accept- acceptable by default unless specifically excluded by the Accept-
Encoding header field stating either "identity;q=0" or "*;q=0" Encoding header field stating either "identity;q=0" or "*;q=0"
without a more specific entry for "identity". without a more specific entry for "identity".
skipping to change at page 123, line 14 skipping to change at page 123, line 5
The most common use of Accept-Encoding is in responses with a 415 The most common use of Accept-Encoding is in responses with a 415
(Unsupported Media Type) status code, in response to optimistic use (Unsupported Media Type) status code, in response to optimistic use
of a content coding by clients. However, the header field can also of a content coding by clients. However, the header field can also
be used to indicate to clients that content codings are supported, to be used to indicate to clients that content codings are supported, to
optimize future interactions. For example, a resource might include optimize future interactions. For example, a resource might include
it in a 2xx (Successful) response when the request content was big it in a 2xx (Successful) response when the request content was big
enough to justify use of a compression coding but the client failed enough to justify use of a compression coding but the client failed
do so. do so.
| *Note:* Most HTTP/1.0 applications do not recognize or obey
| qvalues associated with content-codings. This means that
| qvalues might not work and are not permitted with x-gzip or
| x-compress.
12.5.4. Accept-Language 12.5.4. Accept-Language
The "Accept-Language" header field can be used by user agents to The "Accept-Language" header field can be used by user agents to
indicate the set of natural languages that are preferred in the indicate the set of natural languages that are preferred in the
response. Language tags are defined in Section 8.5.1. response. Language tags are defined in Section 8.5.1.
Accept-Language = #( language-range [ weight ] ) Accept-Language = #( language-range [ weight ] )
language-range = language-range =
<language-range, see [RFC4647], Section 2.1> <language-range, see [RFC4647], Section 2.1>
skipping to change at page 124, line 27 skipping to change at page 124, line 12
| setting a preference, since users are rarely familiar with the | setting a preference, since users are rarely familiar with the
| details of language matching as described above. For example, | details of language matching as described above. For example,
| users might assume that on selecting "en-gb", they will be | users might assume that on selecting "en-gb", they will be
| served any kind of English document if British English is not | served any kind of English document if British English is not
| available. A user agent might suggest, in such a case, to add | available. A user agent might suggest, in such a case, to add
| "en" to the list for better matching behavior. | "en" to the list for better matching behavior.
12.5.5. Vary 12.5.5. Vary
The "Vary" header field in a response describes what parts of a The "Vary" header field in a response describes what parts of a
request message, aside from the method and target URI, might request message, aside from the method and target URI, might have
influence the origin server's process for selecting and representing influenced the origin server's process for selecting the content of
this response. this response.
Vary = #( "*" / field-name ) Vary = #( "*" / field-name )
A Vary field value is a list of request field names, known as the A Vary field value is either the wildcard member "*" or a list of
selecting header fields, that might have a role in selecting the request field names, known as the selecting header fields, that might
representation for this response. Potential selecting header fields have had a role in selecting the representation for this response.
are not limited to those defined by this specification. Potential selecting header fields are not limited to fields defined
by this specification.
If the list contains "*", it signals that other aspects of the A list containing the member "*" signals that other aspects of the
request might play a role in selecting the response representation, request might have played a role in selecting the response
possibly including elements outside the message syntax (e.g., the representation, possibly including aspects outside the message syntax
client's network address). A recipient will not be able to determine (e.g., the client's network address). A recipient will not be able
whether this response is appropriate for a later request without to determine whether this response is appropriate for a later request
forwarding the request to the origin server. A proxy MUST NOT without forwarding the request to the origin server. A proxy MUST
generate "*" in a Vary field value. NOT generate "*" in a Vary field value.
For example, a response that contains For example, a response that contains
Vary: accept-encoding, accept-language Vary: accept-encoding, accept-language
indicates that the origin server might have used the request's indicates that the origin server might have used the request's
Accept-Encoding and Accept-Language header fields (or lack thereof) Accept-Encoding and Accept-Language header fields (or lack thereof)
as determining factors while choosing the content for this response. as determining factors while choosing the content for this response.
An origin server might send Vary with a list of header fields for two A Vary field containing a list of field names has two purposes:
purposes:
1. To inform cache recipients that they MUST NOT use this response 1. To inform cache recipients that they MUST NOT use this response
to satisfy a later request unless the later request has the same to satisfy a later request unless the later request has the same
values for the listed header fields as the original request values for the listed header fields as the original request
(Section 4.1 of [CACHING]). In other words, Vary expands the (Section 4.1 of [CACHING]) or reuse of the response has been
validated by the origin server. In other words, Vary expands the
cache key required to match a new request to the stored cache cache key required to match a new request to the stored cache
entry. entry.
2. To inform user agent recipients that this response is subject to 2. To inform user agent recipients that this response was subject to
content negotiation (Section 12) and that a different content negotiation (Section 12) and a different representation
representation might be sent in a subsequent request if might be sent in a subsequent request if other values are
additional parameters are provided in the listed header fields provided in the listed header fields (proactive negotiation).
(proactive negotiation).
An origin server SHOULD send a Vary header field when its algorithm An origin server SHOULD generate a Vary header field on a cacheable
for selecting a representation varies based on aspects of the request response when it wishes that response to be selectively reused for
message other than the method and target URI, unless the variance subsequent requests. Generally, that is the case when the response
cannot be crossed or the origin server has been deliberately content has been tailored to better fit the preferences expressed by
configured to prevent cache transparency. For example, there is no those selecting header fields, such as when an origin server has
need to send the Authorization field name in Vary because reuse selected the response's language based on the request's
across users is constrained by the field definition (Section 11.6.2). Accept-Language header field.
Likewise, an origin server might use Cache-Control response
directives (Section 5.2 of [CACHING]) to supplant Vary if it Vary might be elided when an origin server considers variance in
considers the variance less significant than the performance cost of content selection to be less significant than Vary's performance
Vary's impact on caching. impact on caching, particularly when reuse is already limited by
Cache-Control response directives (Section 5.2 of [CACHING]).
There is no need to send the Authorization field name in Vary because
reuse of that response for a different user is prohibited by the
field definition (Section 11.6.2). Likewise, if the response content
has been selected or influenced by network region but the origin
server wants the cached response to be reused even if recipients move
from one region to another, then there is no need for the origin
server to indicate such variance in Vary.
13. Conditional Requests 13. Conditional Requests
A conditional request is an HTTP request with one or more request A conditional request is an HTTP request with one or more request
header fields that indicate a precondition to be tested before header fields that indicate a precondition to be tested before
applying the request method to the target resource. Section 13.2 applying the request method to the target resource. Section 13.2
defines when to evaluate preconditions and their order of precedence defines when to evaluate preconditions and their order of precedence
when more than one precondition is present. when more than one precondition is present.
Conditional GET requests are the most efficient mechanism for HTTP Conditional GET requests are the most efficient mechanism for HTTP
skipping to change at page 127, line 21 skipping to change at page 127, line 12
Examples: Examples:
If-Match: "xyzzy" If-Match: "xyzzy"
If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-Match: * If-Match: *
If-Match is most often used with state-changing methods (e.g., POST, If-Match is most often used with state-changing methods (e.g., POST,
PUT, DELETE) to prevent accidental overwrites when multiple user PUT, DELETE) to prevent accidental overwrites when multiple user
agents might be acting in parallel on the same resource (i.e., to agents might be acting in parallel on the same resource (i.e., to
prevent the "lost update" problem). It can also be used with any prevent the "lost update" problem). In general, it can be used with
method to abort a request if the selected representation does not any method that involves the selection or modification of a
match one that the client has already stored (or partially stored) representation to abort the request if the selected representation's
from a prior request. current entity-tag is not a member within the If-Match field value.
An origin server that receives an If-Match header field MUST evaluate When an origin server receives a request that selects a
the condition as per Section 13.2 prior to performing the method. representation and that request includes an If-Match header field,
the origin server MUST evaluate the If-Match condition as per
Section 13.2 prior to performing the method.
To evaluate a received If-Match header field: To evaluate a received If-Match header field:
1. If the field value is "*", the condition is true if the origin 1. If the field value is "*", the condition is true if the origin
server has a current representation for the target resource. server has a current representation for the target resource.
2. If the field value is a list of entity-tags, the condition is 2. If the field value is a list of entity-tags, the condition is
true if any of the listed tags match the entity-tag of the true if any of the listed tags match the entity-tag of the
selected representation. selected representation.
3. Otherwise, the condition is false. 3. Otherwise, the condition is false.
An origin server MUST NOT perform the requested method if a received An origin server that evaluates an If-Match condition MUST NOT
If-Match condition evaluates to false. Instead, the origin server perform the requested method if the condition evaluates to false.
MAY indicate that the conditional request failed by responding with a Instead, the origin server MAY indicate that the conditional request
412 (Precondition Failed) status code. Alternatively, if the request failed by responding with a 412 (Precondition Failed) status code.
is a state-changing operation that appears to have already been Alternatively, if the request is a state-changing operation that
applied to the selected representation, the origin server MAY respond appears to have already been applied to the selected representation,
with a 2xx (Successful) status code (i.e., the change requested by the origin server MAY respond with a 2xx (Successful) status code
the user agent has already succeeded, but the user agent might not be (i.e., the change requested by the user agent has already succeeded,
aware of it, perhaps because the prior response was lost or an but the user agent might not be aware of it, perhaps because the
equivalent change was made by some other user agent). prior response was lost or an equivalent change was made by some
other user agent).
Allowing an origin server to send a success response when a change Allowing an origin server to send a success response when a change
request appears to have already been applied is more efficient for request appears to have already been applied is more efficient for
many authoring use cases, but comes with some risk if multiple user many authoring use cases, but comes with some risk if multiple user
agents are making change requests that are very similar but not agents are making change requests that are very similar but not
cooperative. For example, multiple user agents writing to a common cooperative. For example, multiple user agents writing to a common
resource as a semaphore (e.g., a non-atomic increment) are likely to resource as a semaphore (e.g., a non-atomic increment) are likely to
collide and potentially lose important state transitions. For those collide and potentially lose important state transitions. For those
kinds of resources, an origin server is better off being stringent in kinds of resources, an origin server is better off being stringent in
sending 412 for every failed precondition on an unsafe method. In sending 412 for every failed precondition on an unsafe method. In
other cases, excluding the ETag field from a success response might other cases, excluding the ETag field from a success response might
encourage the user agent to perform a GET as its next request to encourage the user agent to perform a GET as its next request to
eliminate confusion about the resource's current state. eliminate confusion about the resource's current state.
The If-Match header field can be ignored by caches and intermediaries A client MAY send an If-Match header field in a GET request to
because it is not applicable to a stored response. indicate that it would prefer a 412 (Precondition Failed) response if
the selected representation does not match. However, this is only
useful in range requests (Section 14), for completing a previously
received partial representation, when there is no desire for a new
representation. If-Range (Section 13.1.5) is better suited for range
requests when the client prefers to receive a new representation.
A cache or intermediary MAY ignore If-Match because its
interoperability features are only necessary for an origin server.
Note that an If-Match header field with a list value containing "*" Note that an If-Match header field with a list value containing "*"
and other values (including other instances of "*") is syntactically and other values (including other instances of "*") is syntactically
invalid (therefore not allowed to be generated) and furthermore is invalid (therefore not allowed to be generated) and furthermore is
unlikely to be interoperable. unlikely to be interoperable.
13.1.2. If-None-Match 13.1.2. If-None-Match
The "If-None-Match" header field makes the request method conditional The "If-None-Match" header field makes the request method conditional
on a recipient cache or origin server either not having any current on a recipient cache or origin server either not having any current
skipping to change at page 129, line 17 skipping to change at page 129, line 17
responses matches the selected representation. responses matches the selected representation.
If-None-Match can also be used with a value of "*" to prevent an If-None-Match can also be used with a value of "*" to prevent an
unsafe request method (e.g., PUT) from inadvertently modifying an unsafe request method (e.g., PUT) from inadvertently modifying an
existing representation of the target resource when the client existing representation of the target resource when the client
believes that the resource does not have a current representation believes that the resource does not have a current representation
(Section 9.2.1). This is a variation on the "lost update" problem (Section 9.2.1). This is a variation on the "lost update" problem
that might arise if more than one client attempts to create an that might arise if more than one client attempts to create an
initial representation for the target resource. initial representation for the target resource.
An origin server that receives an If-None-Match header field MUST When an origin server receives a request that selects a
evaluate the condition as per Section 13.2 prior to performing the representation and that request includes an If-None-Match header
method. field, the origin server MUST evaluate the If-None-Match condition as
per Section 13.2 prior to performing the method.
To evaluate a received If-None-Match header field: To evaluate a received If-None-Match header field:
1. If the field value is "*", the condition is false if the origin 1. If the field value is "*", the condition is false if the origin
server has a current representation for the target resource. server has a current representation for the target resource.
2. If the field value is a list of entity-tags, the condition is 2. If the field value is a list of entity-tags, the condition is
false if one of the listed tags matches the entity-tag of the false if one of the listed tags matches the entity-tag of the
selected representation. selected representation.
3. Otherwise, the condition is true. 3. Otherwise, the condition is true.
An origin server MUST NOT perform the requested method if a received An origin server that evaluates an If-None-Match condition MUST NOT
If-None-Match condition evaluates to false; instead, the origin perform the requested method if the condition evaluates to false;
server MUST respond with either a) the 304 (Not Modified) status code instead, the origin server MUST respond with either a) the 304 (Not
if the request method is GET or HEAD or b) the 412 (Precondition Modified) status code if the request method is GET or HEAD or b) the
Failed) status code for all other request methods. 412 (Precondition Failed) status code for all other request methods.
Requirements on cache handling of a received If-None-Match header Requirements on cache handling of a received If-None-Match header
field are defined in Section 4.3.2 of [CACHING]. field are defined in Section 4.3.2 of [CACHING].
Note that an If-None-Match header field with a list value containing Note that an If-None-Match header field with a list value containing
"*" and other values (including other instances of "*") is "*" and other values (including other instances of "*") is
syntactically invalid (therefore not allowed to be generated) and syntactically invalid (therefore not allowed to be generated) and
furthermore is unlikely to be interoperable. furthermore is unlikely to be interoperable.
13.1.3. If-Modified-Since 13.1.3. If-Modified-Since
skipping to change at page 130, line 31 skipping to change at page 130, line 31
considered to be a more accurate replacement for the condition in If- considered to be a more accurate replacement for the condition in If-
Modified-Since, and the two are only combined for the sake of Modified-Since, and the two are only combined for the sake of
interoperating with older intermediaries that might not implement interoperating with older intermediaries that might not implement
If-None-Match. If-None-Match.
A recipient MUST ignore the If-Modified-Since header field if the A recipient MUST ignore the If-Modified-Since header field if the
received field value is not a valid HTTP-date, the field value has received field value is not a valid HTTP-date, the field value has
more than one member, or if the request method is neither GET nor more than one member, or if the request method is neither GET nor
HEAD. HEAD.
A recipient MUST ignore the If-Modified-Since header field if the
resource does not have a modification date available.
A recipient MUST interpret an If-Modified-Since field value's A recipient MUST interpret an If-Modified-Since field value's
timestamp in terms of the origin server's clock. timestamp in terms of the origin server's clock.
If-Modified-Since is typically used for two distinct purposes: 1) to If-Modified-Since is typically used for two distinct purposes: 1) to
allow efficient updates of a cached representation that does not have allow efficient updates of a cached representation that does not have
an entity-tag and 2) to limit the scope of a web traversal to an entity-tag and 2) to limit the scope of a web traversal to
resources that have recently changed. resources that have recently changed.
When used for cache updates, a cache will typically use the value of When used for cache updates, a cache will typically use the value of
the cached message's Last-Modified header field to generate the field the cached message's Last-Modified header field to generate the field
value of If-Modified-Since. This behavior is most interoperable for value of If-Modified-Since. This behavior is most interoperable for
cases where clocks are poorly synchronized or when the server has cases where clocks are poorly synchronized or when the server has
chosen to only honor exact timestamp matches (due to a problem with chosen to only honor exact timestamp matches (due to a problem with
Last-Modified dates that appear to go "back in time" when the origin Last-Modified dates that appear to go "back in time" when the origin
server's clock is corrected or a representation is restored from an server's clock is corrected or a representation is restored from an
archived backup). However, caches occasionally generate the field archived backup). However, caches occasionally generate the field
value based on other data, such as the Date header field of the value based on other data, such as the Date header field of the
cached message or the local clock time that the message was received, cached message or the clock time at which the message was received,
particularly when the cached message does not contain a Last-Modified particularly when the cached message does not contain a Last-Modified
header field. header field.
When used for limiting the scope of retrieval to a recent time When used for limiting the scope of retrieval to a recent time
window, a user agent will generate an If-Modified-Since field value window, a user agent will generate an If-Modified-Since field value
based on either its own local clock or a Date header field received based on either its own clock or a Date header field received from
from the server in a prior response. Origin servers that choose an the server in a prior response. Origin servers that choose an exact
exact timestamp match based on the selected representation's timestamp match based on the selected representation's Last-Modified
Last-Modified header field will not be able to help the user agent header field will not be able to help the user agent limit its data
limit its data transfers to only those changed during the specified transfers to only those changed during the specified window.
window.
An origin server that receives an If-Modified-Since header field When an origin server receives a request that selects a
SHOULD evaluate the condition as per Section 13.2 prior to performing representation and that request includes an If-Modified-Since header
the method. field without an If-None-Match header field, the origin server SHOULD
evaluate the If-Modified-Since condition as per Section 13.2 prior to
performing the method.
To evaluate a received If-Modified-Since header field: To evaluate a received If-Modified-Since header field:
1. If the selected representation's last modification date is 1. If the selected representation's last modification date is
earlier or equal to the date provided in the field value, the earlier or equal to the date provided in the field value, the
condition is false. condition is false.
2. Otherwise, the condition is true. 2. Otherwise, the condition is true.
An origin server SHOULD NOT perform the requested method if a An origin server that evaluates an If-Modified-Since condition SHOULD
received If-Modified-Since condition evaluates to false; instead, the NOT perform the requested method if the condition evaluates to false;
origin server SHOULD generate a 304 (Not Modified) response, instead, the origin server SHOULD generate a 304 (Not Modified)
including only those metadata that are useful for identifying or response, including only those metadata that are useful for
updating a previously cached response. identifying or updating a previously cached response.
Requirements on cache handling of a received If-Modified-Since header Requirements on cache handling of a received If-Modified-Since header
field are defined in Section 4.3.2 of [CACHING]. field are defined in Section 4.3.2 of [CACHING].
13.1.4. If-Unmodified-Since 13.1.4. If-Unmodified-Since
The "If-Unmodified-Since" header field makes the request method The "If-Unmodified-Since" header field makes the request method
conditional on the selected representation's last modification date conditional on the selected representation's last modification date
being earlier than or equal to the date provided in the field value. being earlier than or equal to the date provided in the field value.
This field accomplishes the same purpose as If-Match for cases where This field accomplishes the same purpose as If-Match for cases where
skipping to change at page 132, line 14 skipping to change at page 132, line 29
A recipient MUST ignore If-Unmodified-Since if the request contains A recipient MUST ignore If-Unmodified-Since if the request contains
an If-Match header field; the condition in If-Match is considered to an If-Match header field; the condition in If-Match is considered to
be a more accurate replacement for the condition in If-Unmodified- be a more accurate replacement for the condition in If-Unmodified-
Since, and the two are only combined for the sake of interoperating Since, and the two are only combined for the sake of interoperating
with older intermediaries that might not implement If-Match. with older intermediaries that might not implement If-Match.
A recipient MUST ignore the If-Unmodified-Since header field if the A recipient MUST ignore the If-Unmodified-Since header field if the
received field value is not a valid HTTP-date (including when the received field value is not a valid HTTP-date (including when the
field value appears to be a list of dates). field value appears to be a list of dates).
A recipient MUST ignore the If-Unmodified-Since header field if the
resource does not have a modification date available.
A recipient MUST interpret an If-Unmodified-Since field value's A recipient MUST interpret an If-Unmodified-Since field value's
timestamp in terms of the origin server's clock. timestamp in terms of the origin server's clock.
If-Unmodified-Since is most often used with state-changing methods If-Unmodified-Since is most often used with state-changing methods
(e.g., POST, PUT, DELETE) to prevent accidental overwrites when (e.g., POST, PUT, DELETE) to prevent accidental overwrites when
multiple user agents might be acting in parallel on a resource that multiple user agents might be acting in parallel on a resource that
does not supply entity-tags with its representations (i.e., to does not supply entity-tags with its representations (i.e., to
prevent the "lost update" problem). It can also be used with any prevent the "lost update" problem). In general, it can be used with
method to abort a request if the selected representation does not any method that involves the selection or modification of a
match one that the client already stored (or partially stored) from a representation to abort the request if the selected representation's
prior request. last modification date has changed since the date provided in the If-
Unmodified-Since field value.
An origin server that receives an If-Unmodified-Since header field When an origin server receives a request that selects a
without an If-Match header field MUST evaluate the condition as per representation and that request includes an If-Unmodified-Since
Section 13.2 prior to performing the method. header field without an If-Match header field, the origin server MUST
evaluate the If-Unmodified-Since condition as per Section 13.2 prior
to performing the method.
To evaluate a received If-Unmodified-Since header field: To evaluate a received If-Unmodified-Since header field:
1. If the selected representation's last modification date is 1. If the selected representation's last modification date is
earlier than or equal to the date provided in the field value, earlier than or equal to the date provided in the field value,
the condition is true. the condition is true.
2. Otherwise, the condition is false. 2. Otherwise, the condition is false.
An origin server MUST NOT perform the requested method if an If- An origin server that evaluates an If-Unmodified-Since condition MUST
Unmodified-Since condition evaluates to false. Instead, the origin NOT perform the requested method if the condition evaluates to false.
server MAY indicate that the conditional request failed by responding Instead, the origin server MAY indicate that the conditional request
with a 412 (Precondition Failed) status code. Alternatively, if the failed by responding with a 412 (Precondition Failed) status code.
request is a state-changing operation that appears to have already Alternatively, if the request is a state-changing operation that
been applied to the selected representation, the origin server MAY appears to have already been applied to the selected representation,
respond with a 2xx (Successful) status code (i.e., the change the origin server MAY respond with a 2xx (Successful) status code
requested by the user agent has already succeeded, but the user agent (i.e., the change requested by the user agent has already succeeded,
might not be aware of it, perhaps because the prior response was lost but the user agent might not be aware of it, perhaps because the
or an equivalent change was made by some other user agent). prior response was lost or an equivalent change was made by some
other user agent).
Allowing an origin server to send a success response when a change Allowing an origin server to send a success response when a change
request appears to have already been applied is more efficient for request appears to have already been applied is more efficient for
many authoring use cases, but comes with some risk if multiple user many authoring use cases, but comes with some risk if multiple user
agents are making change requests that are very similar but not agents are making change requests that are very similar but not
cooperative. In those cases, an origin server is better off being cooperative. In those cases, an origin server is better off being
stringent in sending 412 for every failed precondition on an unsafe stringent in sending 412 for every failed precondition on an unsafe
method. method.
The If-Unmodified-Since header field can be ignored by caches and A client MAY send an If-Unmodified-Since header field in a GET
intermediaries because it is not applicable to a stored response. request to indicate that it would prefer a 412 (Precondition Failed)
response if the selected representation has been modified. However,
this is only useful in range requests (Section 14), for completing a
previously received partial representation, when there is no desire
for a new representation. If-Range (Section 13.1.5) is better suited
for range requests when the client prefers to receive a new
representation.
A cache or intermediary MAY ignore If-Unmodified-Since because its
interoperability features are only necessary for an origin server.
13.1.5. If-Range 13.1.5. If-Range
The "If-Range" header field provides a special conditional request The "If-Range" header field provides a special conditional request
mechanism that is similar to the If-Match and If-Unmodified-Since mechanism that is similar to the If-Match and If-Unmodified-Since
header fields but that instructs the recipient to ignore the Range header fields but that instructs the recipient to ignore the Range
header field if the validator doesn't match, resulting in transfer of header field if the validator doesn't match, resulting in transfer of
the new selected representation instead of a 412 (Precondition the new selected representation instead of a 412 (Precondition
Failed) response. Failed) response.
skipping to change at page 136, line 35 skipping to change at page 137, line 16
If-Modified-Since is present, evaluate the If-Modified-Since If-Modified-Since is present, evaluate the If-Modified-Since
precondition: precondition:
* if true, continue to step 5 * if true, continue to step 5
* if false, respond 304 (Not Modified) * if false, respond 304 (Not Modified)
5. When the method is GET and both Range and If-Range are present, 5. When the method is GET and both Range and If-Range are present,
evaluate the If-Range precondition: evaluate the If-Range precondition:
* if the validator matches and the Range specification is * if true and the Range is applicable to the selected
applicable to the selected representation, respond 206 representation, respond 206 (Partial Content)
(Partial Content)
* otherwise, ignore the Range header field and respond 200 (OK)
6. Otherwise, 6. Otherwise,
* all conditions are met, so perform the requested action and * perform the requested method and respond according to its
respond according to its success or failure. success or failure.
Any extension to HTTP that defines additional conditional request Any extension to HTTP that defines additional conditional request
header fields ought to define the order for evaluating such fields in header fields ought to define the order for evaluating such fields in
relation to those defined in this document and other conditionals relation to those defined in this document and other conditionals
that might be found in practice. that might be found in practice.
14. Range Requests 14. Range Requests
Clients often encounter interrupted data transfers as a result of Clients often encounter interrupted data transfers as a result of
canceled requests or dropped connections. When a client has stored a canceled requests or dropped connections. When a client has stored a
skipping to change at page 151, line 9 skipping to change at page 151, line 40
request indicates a preference for no content upon success, the request indicates a preference for no content upon success, the
origin server ought to send a _204 (No Content)_ response instead. origin server ought to send a _204 (No Content)_ response instead.
For CONNECT, there is no content because the successful result is a For CONNECT, there is no content because the successful result is a
tunnel, which begins immediately after the 200 response header tunnel, which begins immediately after the 200 response header
section. section.
A 200 response is heuristically cacheable; i.e., unless otherwise A 200 response is heuristically cacheable; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [CACHING]). Section 4.2.2 of [CACHING]).
In 200 responses to GET or HEAD, an origin server SHOULD send any
available validator fields (Section 8.8) for the selected
representation, with both a strong entity-tag and a Last-Modified
date being preferred.
In 200 responses to state-changing methods, any validator fields
(Section 8.8) sent in the response convey the current validators for
the new representation formed as a result of successfully applying
the request semantics. Note that the PUT method (Section 9.3.4) has
additional requirements that might preclude sending such validators.
15.3.2. 201 Created 15.3.2. 201 Created
The _201 (Created)_ status code indicates that the request has been The _201 (Created)_ status code indicates that the request has been
fulfilled and has resulted in one or more new resources being fulfilled and has resulted in one or more new resources being
created. The primary resource created by the request is identified created. The primary resource created by the request is identified
by either a Location header field in the response or, if no Location by either a Location header field in the response or, if no Location
header field is received, by the target URI. header field is received, by the target URI.
The 201 response content typically describes and links to the The 201 response content typically describes and links to the
resource(s) created. See Section 8.8 for a discussion of the meaning resource(s) created. Any validator fields (Section 8.8) sent in the
and purpose of validator fields, such as ETag and Last-Modified, in a response convey the current validators for a new representation
201 response. created by the request. Note that the PUT method (Section 9.3.4) has
additional requirements that might preclude sending such validators.
15.3.3. 202 Accepted 15.3.3. 202 Accepted
The _202 (Accepted)_ status code indicates that the request has been The _202 (Accepted)_ status code indicates that the request has been
accepted for processing, but the processing has not been completed. accepted for processing, but the processing has not been completed.
The request might or might not eventually be acted upon, as it might The request might or might not eventually be acted upon, as it might
be disallowed when processing actually takes place. There is no be disallowed when processing actually takes place. There is no
facility in HTTP for re-sending a status code from an asynchronous facility in HTTP for re-sending a status code from an asynchronous
operation. operation.
skipping to change at page 156, line 34 skipping to change at page 157, line 34
combined response header fields consist of the most recent 200 combined response header fields consist of the most recent 200
response's header fields. If all of the matching stored responses response's header fields. If all of the matching stored responses
are 206 responses, then the stored response with the most recent are 206 responses, then the stored response with the most recent
header fields is used as the source of header fields for the combined header fields is used as the source of header fields for the combined
response, except that the client MUST use other header fields response, except that the client MUST use other header fields
provided in the new response, aside from Content-Range, to replace provided in the new response, aside from Content-Range, to replace
all instances of the corresponding header fields in the stored all instances of the corresponding header fields in the stored
response. response.
The combined response content consists of the union of partial The combined response content consists of the union of partial
content ranges in the new response and each of the selected content ranges within the new response and all of the matching stored
responses. If the union consists of the entire range of the responses. If the union consists of the entire range of the
representation, then the client MUST process the combined response as representation, then the client MUST process the combined response as
if it were a complete 200 (OK) response, including a Content-Length if it were a complete 200 (OK) response, including a Content-Length
header field that reflects the complete length. Otherwise, the header field that reflects the complete length. Otherwise, the
client MUST process the set of continuous ranges as one of the client MUST process the set of continuous ranges as one of the
following: an incomplete 200 (OK) response if the combined response following: an incomplete 200 (OK) response if the combined response
is a prefix of the representation, a single 206 (Partial Content) is a prefix of the representation, a single 206 (Partial Content)
response containing multipart/byteranges content, or multiple 206 response containing multipart/byteranges content, or multiple 206
(Partial Content) responses, each with one continuous range that is (Partial Content) responses, each with one continuous range that is
indicated by a Content-Range header field. indicated by a Content-Range header field.
skipping to change at page 157, line 21 skipping to change at page 158, line 21
of representing this resource, as in the 300 (Multiple Choices) of representing this resource, as in the 300 (Multiple Choices)
status code. status code.
3. Redirection to a different resource, identified by the Location 3. Redirection to a different resource, identified by the Location
header field, that can represent an indirect response to the header field, that can represent an indirect response to the
request, as in the 303 (See Other) status code. request, as in the 303 (See Other) status code.
4. Redirection to a previously stored result, as in the 304 (Not 4. Redirection to a previously stored result, as in the 304 (Not
Modified) status code. Modified) status code.
If a Location header field (Section 10.2.3) is provided, the user | *Note:* In HTTP/1.0, the status codes 301 (Moved Permanently)
| and 302 (Found) were originally defined as method-preserving
| ([HTTP/1.0], Section 9.3) to match their implementation at
| CERN; 303 (See Other) was defined for a redirection that
| changed its method to GET. However, early user agents split on
| whether to redirect POST requests as POST (according to then-
| current specification) or as GET (the safer alternative when
| redirected to a different site). Prevailing practice
| eventually converged on changing the method to GET. 307
| (Temporary Redirect) and 308 (Permanent Redirect) [RFC7538]
| were later added to unambiguously indicate method-preserving
| redirects, and 301/302 have been adjusted to allow a POST
| request to be redirected as GET.
If a Location header field (Section 10.2.2) is provided, the user
agent MAY automatically redirect its request to the URI referenced by agent MAY automatically redirect its request to the URI referenced by
the Location field value, even if the specific status code is not the Location field value, even if the specific status code is not
understood. Automatic redirection needs to be done with care for understood. Automatic redirection needs to be done with care for
methods not known to be safe, as defined in Section 9.2.1, since the methods not known to be safe, as defined in Section 9.2.1, since the
user might not wish to redirect an unsafe request. user might not wish to redirect an unsafe request.
When automatically following a redirected request, the user agent When automatically following a redirected request, the user agent
SHOULD resend the original request message with the following SHOULD resend the original request message with the following
modifications: modifications:
skipping to change at page 158, line 20 skipping to change at page 159, line 32
request because they were added by the calling context) where request because they were added by the calling context) where
there are security implications; this includes but is not limited there are security implications; this includes but is not limited
to Authorization and Cookie. to Authorization and Cookie.
4. Change the request method according to the redirecting status 4. Change the request method according to the redirecting status
code's semantics, if applicable. code's semantics, if applicable.
5. If the request method has been changed to GET or HEAD, remove 5. If the request method has been changed to GET or HEAD, remove
content-specific header fields, including (but not limited to) content-specific header fields, including (but not limited to)
Content-Encoding, Content-Language, Content-Location, Content-Encoding, Content-Language, Content-Location,
Content-Type, Content-Length, Digest, ETag, Last-Modified. Content-Type, Content-Length, Digest, Last-Modified.
| *Note:* In HTTP/1.0, the status codes 301 (Moved Permanently)
| and 302 (Found) were defined for the first type of redirect
| ([HTTP/1.0], Section 9.3). Early user agents split on whether
| the method applied to the redirect target would be the same as
| the original request or would be rewritten as GET. Although
| HTTP originally defined the former semantics for 301 and 302
| (to match its original implementation at CERN), and defined 303
| (See Other) to match the latter semantics, prevailing practice
| gradually converged on the latter semantics for 301 and 302 as
| well. The first revision of HTTP/1.1 added 307 (Temporary
| Redirect) to indicate the former semantics of 302 without being
| impacted by divergent practice. For the same reason, 308
| (Permanent Redirect) was later on added in [RFC7538] to match
| 301. Over 10 years later, most user agents still do method
| rewriting for 301 and 302; therefore, [RFC7231] made that
| behavior conformant when the original request is POST.
A client SHOULD detect and intervene in cyclical redirections (i.e., A client SHOULD detect and intervene in cyclical redirections (i.e.,
"infinite" redirection loops). "infinite" redirection loops).
| *Note:* An earlier version of this specification recommended a | *Note:* An earlier version of this specification recommended a
| maximum of five redirections ([RFC2068], Section 10.3). | maximum of five redirections ([RFC2068], Section 10.3).
| Content developers need to be aware that some clients might | Content developers need to be aware that some clients might
| implement such a fixed limitation. | implement such a fixed limitation.
15.4.1. 300 Multiple Choices 15.4.1. 300 Multiple Choices
skipping to change at page 161, line 19 skipping to change at page 161, line 46
URI in the Location header field, which is intended to provide an URI in the Location header field, which is intended to provide an
indirect response to the original request. A user agent can perform indirect response to the original request. A user agent can perform
a retrieval request targeting that URI (a GET or HEAD request if a retrieval request targeting that URI (a GET or HEAD request if
using HTTP), which might also be redirected, and present the eventual using HTTP), which might also be redirected, and present the eventual
result as an answer to the original request. Note that the new URI result as an answer to the original request. Note that the new URI
in the Location header field is not considered equivalent to the in the Location header field is not considered equivalent to the
target URI. target URI.
This status code is applicable to any HTTP method. It is primarily This status code is applicable to any HTTP method. It is primarily
used to allow the output of a POST action to redirect the user agent used to allow the output of a POST action to redirect the user agent
to a selected resource, since doing so provides the information to a different resource, since doing so provides the information
corresponding to the POST response in a form that can be separately corresponding to the POST response as a resource that can be
identified, bookmarked, and cached, independent of the original separately identified, bookmarked, and cached.
request.
A 303 response to a GET request indicates that the origin server does A 303 response to a GET request indicates that the origin server does
not have a representation of the target resource that can be not have a representation of the target resource that can be
transferred by the server over HTTP. However, the Location field transferred by the server over HTTP. However, the Location field
value refers to a resource that is descriptive of the target value refers to a resource that is descriptive of the target
resource, such that making a retrieval request on that other resource resource, such that making a retrieval request on that other resource
might result in a representation that is useful to recipients without might result in a representation that is useful to recipients without
implying that it represents the original target resource. Note that implying that it represents the original target resource. Note that
answers to the questions of what can be represented, what answers to the questions of what can be represented, what
representations are adequate, and what might be a useful description representations are adequate, and what might be a useful description
skipping to change at page 171, line 11 skipping to change at page 171, line 46
The _502 (Bad Gateway)_ status code indicates that the server, while The _502 (Bad Gateway)_ status code indicates that the server, while
acting as a gateway or proxy, received an invalid response from an acting as a gateway or proxy, received an invalid response from an
inbound server it accessed while attempting to fulfill the request. inbound server it accessed while attempting to fulfill the request.
15.6.4. 503 Service Unavailable 15.6.4. 503 Service Unavailable
The _503 (Service Unavailable)_ status code indicates that the server The _503 (Service Unavailable)_ status code indicates that the server
is currently unable to handle the request due to a temporary overload is currently unable to handle the request due to a temporary overload
or scheduled maintenance, which will likely be alleviated after some or scheduled maintenance, which will likely be alleviated after some
delay. The server MAY send a Retry-After header field delay. The server MAY send a Retry-After header field
(Section 10.2.4) to suggest an appropriate amount of time for the (Section 10.2.3) to suggest an appropriate amount of time for the
client to wait before retrying the request. client to wait before retrying the request.
| *Note:* The existence of the 503 status code does not imply | *Note:* The existence of the 503 status code does not imply
| that a server has to use it when becoming overloaded. Some | that a server has to use it when becoming overloaded. Some
| servers might simply refuse the connection. | servers might simply refuse the connection.
15.6.5. 504 Gateway Timeout 15.6.5. 504 Gateway Timeout
The _504 (Gateway Timeout)_ status code indicates that the server, The _504 (Gateway Timeout)_ status code indicates that the server,
while acting as a gateway or proxy, did not receive a timely response while acting as a gateway or proxy, did not receive a timely response
skipping to change at page 175, line 49 skipping to change at page 176, line 40
The "Hypertext Transfer Protocol (HTTP) Field Name Registry" is The "Hypertext Transfer Protocol (HTTP) Field Name Registry" is
located at <https://www.iana.org/assignments/http-fields/>. located at <https://www.iana.org/assignments/http-fields/>.
Registration requests can be made by following the instructions Registration requests can be made by following the instructions
located there or by sending an email to the "ietf-http-wg@w3.org" located there or by sending an email to the "ietf-http-wg@w3.org"
mailing list. mailing list.
Field names are registered on the advice of a Designated Expert Field names are registered on the advice of a Designated Expert
(appointed by the IESG or their delegate). Fields with the status (appointed by the IESG or their delegate). Fields with the status
'permanent' are Specification Required ([RFC8126], Section 4.6). 'permanent' are Specification Required ([RFC8126], Section 4.6).
Registration requests consist of at least the following information: Registration requests consist of the following information:
Field name: Field name:
The requested field name. It MUST conform to the field-name The requested field name. It MUST conform to the field-name
syntax defined in Section 5.1, and SHOULD be restricted to just syntax defined in Section 5.1, and SHOULD be restricted to just
letters, digits, and hyphen ('-') characters, with the first letters, digits, and hyphen ('-') characters, with the first
character being a letter. character being a letter.
Status: Status:
"permanent" or "provisional". "permanent" or "provisional".
Specification document(s): Specification document(s):
Reference to the document that specifies the field, preferably Reference to the document that specifies the field, preferably
including a URI that can be used to retrieve a copy of the including a URI that can be used to retrieve a copy of the
document. An indication of the relevant section(s) can also be document. Optional but encouraged for provisional registrations.
included, but is not required. An indication of the relevant section(s) can also be included, but
is not required.
And, optionally: And, optionally:
Comments: Additional information, such as about reserved entries. Comments: Additional information, such as about reserved entries.
The Expert(s) can define additional fields to be collected in the The Expert(s) can define additional fields to be collected in the
registry, in consultation with the community. registry, in consultation with the community.
Standards-defined names have a status of "permanent". Other names Standards-defined names have a status of "permanent". Other names
can also be registered as permanent, if the Expert(s) find that they can also be registered as permanent, if the Expert(s) find that they
skipping to change at page 189, line 48 skipping to change at page 190, line 48
being passed with a different prefix to distinguish it from other being passed with a different prefix to distinguish it from other
fields. fields.
17.11. Disclosure of Fragment after Redirects 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.2), 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.12. 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.5), Via (Section 7.6.3), and Server
(Section 10.2.5) header fields often reveal information about the (Section 10.2.4) 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.
skipping to change at page 198, line 24 skipping to change at page 199, line 24
| Content-Language | standard | 8.5 | | | Content-Language | standard | 8.5 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| Content-Length | standard | 8.6 | | | Content-Length | standard | 8.6 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| Content-Location | standard | 8.7 | | | Content-Location | standard | 8.7 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| Content-Range | standard | 14.4 | | | Content-Range | standard | 14.4 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| Content-Type | standard | 8.3 | | | Content-Type | standard | 8.3 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| Date | standard | 10.2.2 | | | Date | standard | 6.6.1 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| ETag | standard | 8.8.3 | | | ETag | standard | 8.8.3 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| Expect | standard | 10.1.1 | | | Expect | standard | 10.1.1 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| From | standard | 10.1.2 | | | From | standard | 10.1.2 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| Host | standard | 7.2 | | | Host | standard | 7.2 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| If-Match | standard | 13.1.1 | | | If-Match | standard | 13.1.1 | |
skipping to change at page 198, line 46 skipping to change at page 199, line 46
| If-Modified-Since | standard | 13.1.3 | | | If-Modified-Since | standard | 13.1.3 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| If-None-Match | standard | 13.1.2 | | | If-None-Match | standard | 13.1.2 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| If-Range | standard | 13.1.5 | | | If-Range | standard | 13.1.5 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| If-Unmodified-Since | standard | 13.1.4 | | | If-Unmodified-Since | standard | 13.1.4 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| Last-Modified | standard | 8.8.2 | | | Last-Modified | standard | 8.8.2 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| Location | standard | 10.2.3 | | | Location | standard | 10.2.2 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| Max-Forwards | standard | 7.6.2 | | | Max-Forwards | standard | 7.6.2 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| Proxy-Authenticate | standard | 11.7.1 | | | Proxy-Authenticate | standard | 11.7.1 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| Proxy-Authentication-Info | standard | 11.7.3 | | | Proxy-Authentication-Info | standard | 11.7.3 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| Proxy-Authorization | standard | 11.7.2 | | | Proxy-Authorization | standard | 11.7.2 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| Range | standard | 14.2 | | | Range | standard | 14.2 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| Referer | standard | 10.1.3 | | | Referer | standard | 10.1.3 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| Retry-After | standard | 10.2.4 | | | Retry-After | standard | 10.2.3 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| Server | standard | 10.2.5 | | | Server | standard | 10.2.4 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| TE | standard | 10.1.4 | | | TE | standard | 10.1.4 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| Trailer | standard | 10.1.5 | | | Trailer | standard | 6.6.2 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| Upgrade | standard | 7.8 | | | Upgrade | standard | 7.8 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| User-Agent | standard | 10.1.6 | | | User-Agent | standard | 10.1.5 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| Vary | standard | 12.5.5 | | | Vary | standard | 12.5.5 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| Via | standard | 7.6.3 | | | Via | standard | 7.6.3 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| WWW-Authenticate | standard | 11.6.1 | | | WWW-Authenticate | standard | 11.6.1 | |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
| * | standard | 12.5.5 | (reserved) | | * | standard | 12.5.5 | (reserved) |
+---------------------------+------------+--------+------------+ +---------------------------+------------+--------+------------+
skipping to change at page 201, line 46 skipping to change at page 202, 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-17, 26 July 2021, draft-ietf-httpbis-cache-18, 18 August 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis- <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
cache-17>. cache-18>.
[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>.
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification
version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996, version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996,
<https://www.rfc-editor.org/info/rfc1951>. <https://www.rfc-editor.org/info/rfc1951>.
skipping to change at page 202, line 48 skipping to change at page 203, line 48
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[RFC5322] Resnick, P., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008,
<https://www.rfc-editor.org/info/rfc5322>.
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,
September 2009, <https://www.rfc-editor.org/info/rfc5646>. September 2009, <https://www.rfc-editor.org/info/rfc5646>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <https://www.rfc-editor.org/info/rfc6125>. 2011, <https://www.rfc-editor.org/info/rfc6125>.
skipping to change at page 205, line 12 skipping to change at page 206, line 16
HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015,
<https://www.rfc-editor.org/info/rfc7541>. <https://www.rfc-editor.org/info/rfc7541>.
[HTTP/1.0] Berners-Lee, T., Fielding, R.T., and H.F. Nielsen, [HTTP/1.0] Berners-Lee, T., Fielding, R.T., and H.F. Nielsen,
"Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945,
DOI 10.17487/RFC1945, May 1996, DOI 10.17487/RFC1945, May 1996,
<https://www.rfc-editor.org/info/rfc1945>. <https://www.rfc-editor.org/info/rfc1945>.
[HTTP/1.1] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [HTTP/1.1] 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-17, 26 July 2021, ietf-httpbis-messaging-18, 18 August 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis- <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
messaging-17>. messaging-18>.
[HTTP/2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext [HTTP/2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540, Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015, DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/info/rfc7540>. <https://www.rfc-editor.org/info/rfc7540>.
[HTTP/3] Bishop, M., "Hypertext Transfer Protocol Version 3 [HTTP/3] Bishop, M., "Hypertext Transfer Protocol Version 3
(HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf-
quic-http-34, 2 February 2021, quic-http-34, 2 February 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-quic- <https://datatracker.ietf.org/doc/html/draft-ietf-quic-
skipping to change at page 207, line 33 skipping to change at page 208, line 37
[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>.
[RFC5322] Resnick, P., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008,
<https://www.rfc-editor.org/info/rfc5322>.
[RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP", [RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP",
RFC 5789, DOI 10.17487/RFC5789, March 2010, RFC 5789, DOI 10.17487/RFC5789, March 2010,
<https://www.rfc-editor.org/info/rfc5789>. <https://www.rfc-editor.org/info/rfc5789>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>. <https://www.rfc-editor.org/info/rfc5905>.
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
skipping to change at page 229, line 47 skipping to change at page 230, line 47
* In Section 5.5, introduce the terms "singleton field" and "list- * In Section 5.5, introduce the terms "singleton field" and "list-
based field" (also - in various places - discuss what to do when a based field" (also - in various places - discuss what to do when a
singleton field is received as a list) singleton field is received as a list)
(<https://github.com/httpwg/http-core/issues/193>) (<https://github.com/httpwg/http-core/issues/193>)
* In Section 10.1.1, change the ABNF back to be a list of * In Section 10.1.1, change the ABNF back to be a list of
expectations, as defined in RFC 2616 (<https://github.com/httpwg/ expectations, as defined in RFC 2616 (<https://github.com/httpwg/
http-core/issues/203>) http-core/issues/203>)
* In Section 10.1.5 (Trailer), Section 7.6.3 (Via), Section 7.8 * In Section 6.6.2 (Trailer), Section 7.6.3 (Via), Section 7.8
(Upgrade), Section 7.6.1 (Connection), Section 8.4 (Upgrade), Section 7.6.1 (Connection), Section 8.4
(Content-Encoding), Section 8.5 (Content-Language), Section 10.1.1 (Content-Encoding), Section 8.5 (Content-Language), Section 10.1.1
(Expect), Section 13.1.1 (If-Match), Section 13.1.2 (Expect), Section 13.1.1 (If-Match), Section 13.1.2
(If-None-Match), Section 12.5.2 (Accept-Charset), Section 12.5.4 (If-None-Match), Section 12.5.2 (Accept-Charset), Section 12.5.4
(Accept-Language), Section 12.5.5 (Vary), Section 11.6.1 (Accept-Language), Section 12.5.5 (Vary), Section 11.6.1
(WWW-Authenticate), and Section 11.7.1 (Proxy-Authenticate), (WWW-Authenticate), and Section 11.7.1 (Proxy-Authenticate),
adjust ABNF to allow empty lists (<https://github.com/httpwg/http- adjust ABNF to allow empty lists (<https://github.com/httpwg/http-
core/issues/210>) core/issues/210>)
* In Section 9.3.1 and Section 17.9, provide a more nuanced * In Section 9.3.1 and Section 17.9, provide a more nuanced
skipping to change at page 233, line 23 skipping to change at page 234, line 23
for new methods (<https://github.com/httpwg/http-core/issues/636>) for new methods (<https://github.com/httpwg/http-core/issues/636>)
* Changed to using "content" instead of "payload" or "payload data" * Changed to using "content" instead of "payload" or "payload data"
to avoid confusion with the payload of version-specific messaging to avoid confusion with the payload of version-specific messaging
frames (<https://github.com/httpwg/http-core/issues/654>) frames (<https://github.com/httpwg/http-core/issues/654>)
* In Section 13.1.3, Section 13.1.4, and Section 13.1.5, specify * In Section 13.1.3, Section 13.1.4, and Section 13.1.5, specify
evaluation in a way similar to other conditional header fields evaluation in a way similar to other conditional header fields
(<https://github.com/httpwg/http-core/issues/665>) (<https://github.com/httpwg/http-core/issues/665>)
* In Section 10.2.2, specify that recipients can replace an invalid * In Section 6.6.1, specify that recipients can replace an invalid
Date header field value with the time received Date header field value with the time received
(<https://github.com/httpwg/http-core/issues/669>) (<https://github.com/httpwg/http-core/issues/669>)
C.16. Since draft-ietf-httpbis-semantics-14 C.16. Since draft-ietf-httpbis-semantics-14
* In Section 5.5, relax prohibition of characters in field values to * In Section 5.5, relax prohibition of characters in field values to
CR and NUL (<https://github.com/httpwg/http-core/issues/683>) CR and NUL (<https://github.com/httpwg/http-core/issues/683>)
* In Section 15, clarify that status code values outside the range * In Section 15, clarify that status code values outside the range
100..599 are invalid, and recommend error handling 100..599 are invalid, and recommend error handling
skipping to change at page 235, line 26 skipping to change at page 236, line 26
after the 101 response (<https://github.com/httpwg/http-core/ after the 101 response (<https://github.com/httpwg/http-core/
issues/776>) issues/776>)
* In Section 9.3.6, state that data received after the headers of a * In Section 9.3.6, state that data received after the headers of a
CONNECT message is version-specific (<https://github.com/httpwg/ CONNECT message is version-specific (<https://github.com/httpwg/
http-core/issues/780>) http-core/issues/780>)
* In Section 4.2.3, clarify how normalization works, and align with * In Section 4.2.3, clarify how normalization works, and align with
RF3986 (<https://github.com/httpwg/http-core/issues/788>) RF3986 (<https://github.com/httpwg/http-core/issues/788>)
* In Section 10.1.5, note that the Trailer field can be used to * In Section 6.6.2, 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 [HTTP/1.1] * Throughout, remove unneeded normative references to [HTTP/1.1]
(<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 C.17. Since draft-ietf-httpbis-semantics-15
skipping to change at page 236, line 45 skipping to change at page 237, line 45
* In Section 7.4, check all target URIs for scheme semantic * In Section 7.4, check all target URIs for scheme semantic
mismatches (<https://github.com/httpwg/http-core/issues/896>) mismatches (<https://github.com/httpwg/http-core/issues/896>)
* In Section 9.3.1, Section 9.3.2, and Section 9.3.5, clarify * In Section 9.3.1, Section 9.3.2, and Section 9.3.5, clarify
(again) that sending content in a request for a method that does (again) that sending content in a request for a method that does
not define such content will not interoperate without prior not define such content will not interoperate without prior
agreement, even if it is parsed correctly, and cannot be relied agreement, even if it is parsed correctly, and cannot be relied
upon by an origin server unless they control the entire request upon by an origin server unless they control the entire request
chain (<https://github.com/httpwg/http-core/issues/904>) chain (<https://github.com/httpwg/http-core/issues/904>)
C.19. Since draft-ietf-httpbis-semantics-17
* Move ABNF for obs-text into Section 5.5
(<https://github.com/httpwg/http-core/issues/914>)
* In Section 6.4.1, note that response metadata can be relevant as
well (<https://github.com/httpwg/http-core/issues/914>)
* In Section 6.6.2, use the term "signature" througout and lower
expectations on what Trailer indicates without a trailer section
(<https://github.com/httpwg/http-core/issues/914>)
* In Section 8.3, cleanup mime sniffing discussion
(<https://github.com/httpwg/http-core/issues/914>)
* In Section 10.1.4, add a forward reference to "weight"
(<https://github.com/httpwg/http-core/issues/914>)
* In Section 12.5.3, clarify that the examples contains multiple
values; also remove obsolete HTTP/1.0 note about qvalues
(<https://github.com/httpwg/http-core/issues/914>)
* In Section 15.4, remove incorrect mention of Etag as request field
(<https://github.com/httpwg/http-core/issues/914>)
* Move text about obs-fold in message/http to [HTTP/1.1]; also note
that LF is forbidden in field values just as CR and NUL
(<https://github.com/httpwg/http-core/issues/923>)
* In Section 7.7, properly refer to text that has moved to
[HTTP/1.1] (<https://github.com/httpwg/http-core/issues/930>)
* Rewrite description of validators and move cache-related aspects
into [CACHING] (<https://github.com/httpwg/http-core/issues/933>)
* In Section 12.5.5, rephrase description to be more explanatory
(<https://github.com/httpwg/http-core/issues/938>)
* In Section 13.2.2, clarify that a false If-Range means ignore the
Range (<https://github.com/httpwg/http-core/issues/940>)
* In Section 13.1.3 and Section 13.1.4, restore text about missing
modification date (<https://github.com/httpwg/http-core/
issues/942>)
* In Section 5.6.1.1, avoid duplicate normative requirement
(<https://github.com/httpwg/http-core/issues/943>)
* In Section 8.8.2.1, reference 'Date' more visibly
(<https://github.com/httpwg/http-core/issues/945>)
* In Section 11.7.3, state that Proxy-Authentication-Info can be
used as trailer (<https://github.com/httpwg/http-core/issues/946>)
* In Section 15.4, slightly clarify history of redirect status codes
(<https://github.com/httpwg/http-core/issues/947>)
* In Section 16.3.1, fix requirements for provisional registrations
(<https://github.com/httpwg/http-core/issues/950>)
* In Section 4.3, explicitly refer to how this spec defines access
to http or https resources (<https://github.com/httpwg/http-core/
issues/951>)
* In Section 6.6.1, make clock a defined term and use that
definition throughout the spec (<https://github.com/httpwg/http-
core/issues/953>)
* In Section 13.1, make preconditions consistent on when they are
required to be evaluated (<https://github.com/httpwg/http-core/
issues/954>)
* Throughout, disambiguate "selected representation" and "selected
response" (now "chosen response") (<https://github.com/httpwg/
http-core/issues/958>)
Acknowledgements Acknowledgements
Aside from the current editors, the following individuals deserve Aside from the current editors, the following individuals deserve
special recognition for their contributions to early aspects of HTTP special recognition for their contributions to early aspects of HTTP
and its core specifications: Marc Andreessen, Tim Berners-Lee, Robert and its core specifications: Marc Andreessen, Tim Berners-Lee, Robert
Cailliau, Daniel W. Connolly, Bob Denny, John Franks, Jim Gettys, Cailliau, Daniel W. Connolly, Bob Denny, John Franks, Jim Gettys,
Jean-François Groff, Phillip M. Hallam-Baker, Koen Holtman, Jeffery Jean-François Groff, Phillip M. Hallam-Baker, Koen Holtman, Jeffery
L. Hostetler, Shel Kaphan, Dave Kristol, Yves Lafon, Scott L. Hostetler, Shel Kaphan, Dave Kristol, Yves Lafon, Scott
D. Lawrence, Paul J. Leach, Håkon W. Lie, Ari Luotonen, Larry D. Lawrence, Paul J. Leach, Håkon W. Lie, Ari Luotonen, Larry
Masinter, Rob McCool, Jeffrey C. Mogul, Lou Montulli, David Morris, Masinter, Rob McCool, Jeffrey C. Mogul, Lou Montulli, David Morris,
skipping to change at page 239, line 47 skipping to change at page 242, line 27
Content-Encoding header field Section 8.4 Content-Encoding header field Section 8.4
Content-Language header field Section 8.5 Content-Language header field Section 8.5
Content-Length header field Section 8.6 Content-Length header field Section 8.6
Content-Location header field Section 8.7 Content-Location header field Section 8.7
Content-MD5 header field Section 18.4, Paragraph 9 Content-MD5 header field Section 18.4, Paragraph 9
Content-Range header field Section 14.4; Section 14.5 Content-Range header field Section 14.4; Section 14.5
Content-Type header field Section 8.3 Content-Type header field Section 8.3
cache Section 3.8 cache Section 3.8
cacheable Section 3.8, Paragraph 4 cacheable Section 3.8, Paragraph 4
client Section 3.3 client Section 3.3
clock Section 5.6.7
complete Section 6.1 complete Section 6.1
compress (Coding Format) Section 8.4.1.1 compress (Coding Format) Section 8.4.1.1
compress (content coding) Section 8.4.1 compress (content coding) Section 8.4.1
conditional request Section 13 conditional request Section 13
connection Section 3.3 connection Section 3.3
content Section 6.4 content Section 6.4
content coding Section 8.4.1 content coding Section 8.4.1
content negotiation Section 1.3, Paragraph 4 content negotiation Section 1.3, Paragraph 4
control data Section 6.2 control data Section 6.2
D D
DELETE method Section 9.3.5 DELETE method Section 9.3.5
Date header field Section 10.2.2 Date header field Section 6.6.1
Delimiters Section 5.6.2, Paragraph 3 Delimiters Section 5.6.2, Paragraph 3
deflate (Coding Format) Section 8.4.1.2 deflate (Coding Format) Section 8.4.1.2
deflate (content coding) Section 8.4.1 deflate (content coding) Section 8.4.1
downstream Section 3.7, Paragraph 4 downstream Section 3.7, Paragraph 4
E E
ETag field Section 8.8.3 ETag field Section 8.8.3
Expect header field Section 10.1.1 Expect header field Section 10.1.1
effective request URI Section 7.1, Paragraph 8.1 effective request URI Section 7.1, Paragraph 8.1
skipping to change at page 240, line 44 skipping to change at page 243, line 25
Authentication-Info Section 11.6.3 Authentication-Info Section 11.6.3
Authorization Section 11.6.2 Authorization Section 11.6.2
Connection Section 7.6.1 Connection Section 7.6.1
Content-Encoding Section 8.4 Content-Encoding Section 8.4
Content-Language Section 8.5 Content-Language Section 8.5
Content-Length Section 8.6 Content-Length Section 8.6
Content-Location Section 8.7 Content-Location Section 8.7
Content-MD5 Section 18.4, Paragraph 9 Content-MD5 Section 18.4, Paragraph 9
Content-Range Section 14.4; Section 14.5 Content-Range Section 14.4; Section 14.5
Content-Type Section 8.3 Content-Type Section 8.3
Date Section 10.2.2 Date Section 6.6.1
ETag Section 8.8.3 ETag Section 8.8.3
Expect Section 10.1.1 Expect Section 10.1.1
From Section 10.1.2 From Section 10.1.2
Host Section 7.2 Host Section 7.2
If-Match Section 13.1.1 If-Match Section 13.1.1
If-Modified-Since Section 13.1.3 If-Modified-Since Section 13.1.3
If-None-Match Section 13.1.2 If-None-Match Section 13.1.2
If-Range Section 13.1.5 If-Range Section 13.1.5
If-Unmodified-Since Section 13.1.4 If-Unmodified-Since Section 13.1.4
Last-Modified Section 8.8.2 Last-Modified Section 8.8.2
Location Section 10.2.3 Location Section 10.2.2
Max-Forwards Section 7.6.2 Max-Forwards Section 7.6.2
Proxy-Authenticate Section 11.7.1 Proxy-Authenticate Section 11.7.1
Proxy-Authentication-Info Section 11.7.3 Proxy-Authentication-Info Section 11.7.3
Proxy-Authorization Section 11.7.2 Proxy-Authorization Section 11.7.2
Range Section 14.2 Range Section 14.2
Referer Section 10.1.3 Referer Section 10.1.3
Retry-After Section 10.2.4 Retry-After Section 10.2.3
Server Section 10.2.5 Server Section 10.2.4
TE Section 10.1.4 TE Section 10.1.4
Trailer Section 10.1.5 Trailer Section 6.6.2
Upgrade Section 7.8 Upgrade Section 7.8
User-Agent Section 10.1.6 User-Agent Section 10.1.5
Vary Section 12.5.5 Vary Section 12.5.5
Via Section 7.6.3 Via Section 7.6.3
WWW-Authenticate Section 11.6.1 WWW-Authenticate Section 11.6.1
Fragment Identifiers Section 4.2.5 Fragment Identifiers Section 4.2.5
From header field Section 10.1.2 From header field Section 10.1.2
field Section 5; Section 6.3 field Section 5; Section 6.3
field line Section 5.2, Paragraph 1 field line Section 5.2, Paragraph 1
field line value Section 5.2, Paragraph 1 field line value Section 5.2, Paragraph 1
field name Section 5.2, Paragraph 1 field name Section 5.2, Paragraph 1
field value Section 5.2, Paragraph 2 field value Section 5.2, Paragraph 2
skipping to change at page 242, line 9 skipping to change at page 244, line 37
CTL Section 2.1 CTL Section 2.1
Connection Section 7.6.1 Connection Section 7.6.1
Content-Encoding Section 8.4 Content-Encoding Section 8.4
Content-Language Section 8.5 Content-Language Section 8.5
Content-Length Section 8.6 Content-Length Section 8.6
Content-Location Section 8.7 Content-Location Section 8.7
Content-Range Section 14.4 Content-Range Section 14.4
Content-Type Section 8.3 Content-Type Section 8.3
DIGIT Section 2.1 DIGIT Section 2.1
DQUOTE Section 2.1 DQUOTE Section 2.1
Date Section 10.2.2 Date Section 6.6.1
ETag Section 8.8.3 ETag Section 8.8.3
Expect Section 10.1.1 Expect Section 10.1.1
From Section 10.1.2 From Section 10.1.2
GMT Section 5.6.7 GMT Section 5.6.7
HEXDIG Section 2.1 HEXDIG Section 2.1
HTAB Section 2.1 HTAB Section 2.1
HTTP-date Section 5.6.7 HTTP-date Section 5.6.7
Host Section 7.2 Host Section 7.2
IMF-fixdate Section 5.6.7 IMF-fixdate Section 5.6.7
If-Match Section 13.1.1 If-Match Section 13.1.1
If-Modified-Since Section 13.1.3 If-Modified-Since Section 13.1.3
If-None-Match Section 13.1.2 If-None-Match Section 13.1.2
If-Range Section 13.1.5 If-Range Section 13.1.5
If-Unmodified-Since Section 13.1.4 If-Unmodified-Since Section 13.1.4
LF Section 2.1 LF Section 2.1
Last-Modified Section 8.8.2 Last-Modified Section 8.8.2
Location Section 10.2.3 Location Section 10.2.2
Max-Forwards Section 7.6.2 Max-Forwards Section 7.6.2
OCTET Section 2.1 OCTET Section 2.1
OWS Section 5.6.3 OWS Section 5.6.3
Proxy-Authenticate Section 11.7.1 Proxy-Authenticate Section 11.7.1
Proxy-Authentication-Info Section 11.7.3 Proxy-Authentication-Info Section 11.7.3
Proxy-Authorization Section 11.7.2 Proxy-Authorization Section 11.7.2
RWS Section 5.6.3 RWS Section 5.6.3
Range Section 14.2 Range Section 14.2
Referer Section 10.1.3 Referer Section 10.1.3
Retry-After Section 10.2.4 Retry-After Section 10.2.3
SP Section 2.1 SP Section 2.1
Server Section 10.2.5 Server Section 10.2.4
TE Section 10.1.4 TE Section 10.1.4
Trailer Section 10.1.5 Trailer Section 6.6.2
URI-reference Section 4.1 URI-reference Section 4.1
Upgrade Section 7.8 Upgrade Section 7.8
User-Agent Section 10.1.6 User-Agent Section 10.1.5
VCHAR Section 2.1 VCHAR Section 2.1
Vary Section 12.5.5 Vary Section 12.5.5
Via Section 7.6.3 Via Section 7.6.3
WWW-Authenticate Section 11.6.1 WWW-Authenticate Section 11.6.1
absolute-URI Section 4.1 absolute-URI Section 4.1
absolute-path Section 4.1 absolute-path Section 4.1
acceptable-ranges Section 14.3 acceptable-ranges Section 14.3
asctime-date Section 5.6.7 asctime-date Section 5.6.7
auth-param Section 11.2 auth-param Section 11.2
auth-scheme Section 11.1 auth-scheme Section 11.1
skipping to change at page 243, line 19 skipping to change at page 245, line 47
comment Section 5.6.5 comment Section 5.6.5
complete-length Section 14.4 complete-length Section 14.4
connection-option Section 7.6.1 connection-option Section 7.6.1
content-coding Section 8.4.1 content-coding Section 8.4.1
credentials Section 11.4 credentials Section 11.4
ctext Section 5.6.5 ctext Section 5.6.5
date1 Section 5.6.7 date1 Section 5.6.7
day Section 5.6.7 day Section 5.6.7
day-name Section 5.6.7 day-name Section 5.6.7
day-name-l Section 5.6.7 day-name-l Section 5.6.7
delay-seconds Section 10.2.4 delay-seconds Section 10.2.3
entity-tag Section 8.8.3 entity-tag Section 8.8.3
etagc Section 8.8.3 etagc Section 8.8.3
field-content Section 5.5 field-content Section 5.5
field-name Section 5.1; Section 10.1.5 field-name Section 5.1; Section 6.6.2
field-value Section 5.5 field-value Section 5.5
field-vchar Section 5.5 field-vchar Section 5.5
first-pos Section 14.1.1; Section 14.4 first-pos Section 14.1.1; Section 14.4
hour Section 5.6.7 hour Section 5.6.7
http-URI Section 4.2.1 http-URI Section 4.2.1
https-URI Section 4.2.2 https-URI Section 4.2.2
incl-range Section 14.4 incl-range Section 14.4
int-range Section 14.1.1 int-range Section 14.1.1
language-range Section 12.5.4 language-range Section 12.5.4
language-tag Section 8.5.1 language-tag Section 8.5.1
last-pos Section 14.1.1; Section 14.4 last-pos Section 14.1.1; Section 14.4
media-range Section 12.5.1 media-range Section 12.5.1
media-type Section 8.3.1 media-type Section 8.3.1
method Section 9.1 method Section 9.1
minute Section 5.6.7 minute Section 5.6.7
month Section 5.6.7 month Section 5.6.7
obs-date Section 5.6.7 obs-date Section 5.6.7
obs-text Section 5.6.4 obs-text Section 5.5
opaque-tag Section 8.8.3 opaque-tag Section 8.8.3
other-range Section 14.1.1 other-range Section 14.1.1
parameter Section 5.6.6 parameter Section 5.6.6
parameter-name Section 5.6.6 parameter-name Section 5.6.6
parameter-value Section 5.6.6 parameter-value Section 5.6.6
parameters Section 5.6.6 parameters Section 5.6.6
partial-URI Section 4.1 partial-URI Section 4.1
port Section 4.1 port Section 4.1
product Section 10.1.6 product Section 10.1.5
product-version Section 10.1.6 product-version Section 10.1.5
protocol-name Section 7.6.3 protocol-name Section 7.6.3
protocol-version Section 7.6.3 protocol-version Section 7.6.3
pseudonym Section 7.6.3 pseudonym Section 7.6.3
qdtext Section 5.6.4 qdtext Section 5.6.4
query Section 4.1 query Section 4.1
quoted-pair Section 5.6.4 quoted-pair Section 5.6.4
quoted-string Section 5.6.4 quoted-string Section 5.6.4
qvalue Section 12.4.2 qvalue Section 12.4.2
range-resp Section 14.4 range-resp Section 14.4
range-set Section 14.1.1 range-set Section 14.1.1
skipping to change at page 245, line 14 skipping to change at page 247, line 42
Authentication-Info Section 11.6.3 Authentication-Info Section 11.6.3
Authorization Section 11.6.2 Authorization Section 11.6.2
Connection Section 7.6.1 Connection Section 7.6.1
Content-Encoding Section 8.4 Content-Encoding Section 8.4
Content-Language Section 8.5 Content-Language Section 8.5
Content-Length Section 8.6 Content-Length Section 8.6
Content-Location Section 8.7 Content-Location Section 8.7
Content-MD5 Section 18.4, Paragraph 9 Content-MD5 Section 18.4, Paragraph 9
Content-Range Section 14.4; Section 14.5 Content-Range Section 14.4; Section 14.5
Content-Type Section 8.3 Content-Type Section 8.3
Date Section 10.2.2 Date Section 6.6.1
ETag Section 8.8.3 ETag Section 8.8.3
Expect Section 10.1.1 Expect Section 10.1.1
From Section 10.1.2 From Section 10.1.2
Host Section 7.2 Host Section 7.2
If-Match Section 13.1.1 If-Match Section 13.1.1
If-Modified-Since Section 13.1.3 If-Modified-Since Section 13.1.3
If-None-Match Section 13.1.2 If-None-Match Section 13.1.2
If-Range Section 13.1.5 If-Range Section 13.1.5
If-Unmodified-Since Section 13.1.4 If-Unmodified-Since Section 13.1.4
Last-Modified Section 8.8.2 Last-Modified Section 8.8.2
Location Section 10.2.3 Location Section 10.2.2
Max-Forwards Section 7.6.2 Max-Forwards Section 7.6.2
Proxy-Authenticate Section 11.7.1 Proxy-Authenticate Section 11.7.1
Proxy-Authentication-Info Section 11.7.3 Proxy-Authentication-Info Section 11.7.3
Proxy-Authorization Section 11.7.2 Proxy-Authorization Section 11.7.2
Range Section 14.2 Range Section 14.2
Referer Section 10.1.3 Referer Section 10.1.3
Retry-After Section 10.2.4 Retry-After Section 10.2.3
Server Section 10.2.5 Server Section 10.2.4
TE Section 10.1.4 TE Section 10.1.4
Trailer Section 10.1.5 Trailer Section 6.6.2
Upgrade Section 7.8 Upgrade Section 7.8
User-Agent Section 10.1.6 User-Agent Section 10.1.5
Vary Section 12.5.5 Vary Section 12.5.5
Via Section 7.6.3 Via Section 7.6.3
WWW-Authenticate Section 11.6.1 WWW-Authenticate Section 11.6.1
Host header field Section 7.2 Host header field Section 7.2
header section Section 6.3 header section Section 6.3
http URI scheme Section 4.2.1 http URI scheme Section 4.2.1
https URI scheme Section 4.2.2 https URI scheme Section 4.2.2
I I
skipping to change at page 246, line 14 skipping to change at page 248, line 42
If-Unmodified-Since header field Section 13.1.4 If-Unmodified-Since header field Section 13.1.4
idempotent Section 9.2.2 idempotent Section 9.2.2
inbound Section 3.7, Paragraph 4 inbound Section 3.7, Paragraph 4
incomplete Section 6.1 incomplete Section 6.1
interception proxy Section 3.7, Paragraph 10 interception proxy Section 3.7, Paragraph 10
intermediary Section 3.7 intermediary Section 3.7
L L
Last-Modified header field Section 8.8.2 Last-Modified header field Section 8.8.2
Location header field Section 10.2.3 Location header field Section 10.2.2
list-based field Section 5.5, Paragraph 7 list-based field Section 5.5, Paragraph 7
M M
Max-Forwards header field Section 7.6.2 Max-Forwards header field Section 7.6.2
Media Type Media Type
multipart/byteranges Section 14.6 multipart/byteranges Section 14.6
multipart/x-byteranges Section 14.6, Paragraph 4, Item 3 multipart/x-byteranges Section 14.6, Paragraph 4, Item 3
Method Method
* Section 18.2, Paragraph 3 * Section 18.2, Paragraph 3
skipping to change at page 247, line 21 skipping to change at page 249, line 49
Proxy-Authentication-Info header field Section 11.7.3 Proxy-Authentication-Info header field Section 11.7.3
Proxy-Authorization header field Section 11.7.2 Proxy-Authorization header field Section 11.7.2
phishing Section 17.1 phishing Section 17.1
proxy Section 3.7, Paragraph 5 proxy Section 3.7, Paragraph 5
R R
Range header field Section 14.2 Range header field Section 14.2
Realm Section 11.5 Realm Section 11.5
Referer header field Section 10.1.3 Referer header field Section 10.1.3
Retry-After header field Section 10.2.4 Retry-After header field Section 10.2.3
recipient Section 3.4 recipient Section 3.4
representation Section 3.2 representation Section 3.2
request Section 3.4 request Section 3.4
request target Section 7.1 request target Section 7.1
resource Section 3.1; Section 4 resource Section 3.1; Section 4
response Section 3.4 response Section 3.4
reverse proxy Section 3.7, Paragraph 6 reverse proxy Section 3.7, Paragraph 6
S S
Server header field Section 10.2.5 Server header field Section 10.2.4
Status Code Section 15 Status Code Section 15
Status Codes Status Codes
Final Section 15, Paragraph 7 Final Section 15, Paragraph 7
Informational Section 15, Paragraph 7 Informational Section 15, Paragraph 7
Interim Section 15, Paragraph 7 Interim Section 15, Paragraph 7
Status Codes Classes Status Codes Classes
1xx Informational Section 15.2 1xx Informational Section 15.2
2xx Successful Section 15.3 2xx Successful Section 15.3
3xx Redirection Section 15.4 3xx Redirection Section 15.4
4xx Client Error Section 15.5 4xx Client Error Section 15.5
skipping to change at page 248, line 11 skipping to change at page 250, line 40
server Section 3.3 server Section 3.3
singleton field Section 5.5, Paragraph 6 singleton field Section 5.5, Paragraph 6
spider Section 3.5 spider Section 3.5
T T
TE header field Section 10.1.4 TE header field Section 10.1.4
TRACE method Section 9.3.8 TRACE method Section 9.3.8
Trailer Fields Trailer Fields
ETag Section 8.8.3 ETag Section 8.8.3
Trailer header field Section 10.1.5 Trailer header field Section 6.6.2
target URI Section 7.1 target URI Section 7.1
target resource Section 7.1 target resource Section 7.1
trailer fields Section 6.5 trailer fields Section 6.5
trailer section Section 6.5 trailer section Section 6.5
trailers Section 6.5 trailers Section 6.5
transforming proxy Section 7.7 transforming proxy Section 7.7
transparent proxy Section 3.7, Paragraph 10 transparent proxy Section 3.7, Paragraph 10
tunnel Section 3.7, Paragraph 8 tunnel Section 3.7, Paragraph 8
U U
URI Section 4 URI Section 4
origin Section 4.3.1 origin Section 4.3.1
URI reference Section 4.1 URI reference Section 4.1
URI scheme URI scheme
http Section 4.2.1 http Section 4.2.1
https Section 4.2.2 https Section 4.2.2
Upgrade header field Section 7.8 Upgrade header field Section 7.8
User-Agent header field Section 10.1.6 User-Agent header field Section 10.1.5
upstream Section 3.7, Paragraph 4 upstream Section 3.7, Paragraph 4
user agent Section 3.5 user agent Section 3.5
V V
Vary header field Section 12.5.5 Vary header field Section 12.5.5
Via header field Section 7.6.3 Via header field Section 7.6.3
validator Section 8.8 validator Section 8.8
strong Section 8.8.1 strong Section 8.8.1
weak Section 8.8.1 weak Section 8.8.1
 End of changes. 162 change blocks. 
594 lines changed or deleted 723 lines changed or added

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