draft-ietf-httpbis-semantics-06.txt   draft-ietf-httpbis-semantics-07.txt 
HTTP Working Group R. Fielding, Ed. HTTP Working Group R. Fielding, Ed.
Internet-Draft Adobe Internet-Draft Adobe
Obsoletes: M. Nottingham, Ed. Obsoletes: M. Nottingham, Ed.
2818,7230,7231,7232,7233,7235 Fastly 2818,7230,7231,7232,7233,7235 Fastly
,7538,7615 (if approved) J. Reschke, Ed. ,7538,7615 (if approved) J. Reschke, Ed.
Intended status: Standards Track greenbytes Intended status: Standards Track greenbytes
Expires: May 7, 2020 November 4, 2019 Expires: September 8, 2020 March 7, 2020
HTTP Semantics HTTP Semantics
draft-ietf-httpbis-semantics-06 draft-ietf-httpbis-semantics-07
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is a stateless application- The Hypertext Transfer Protocol (HTTP) is a stateless application-
level protocol for distributed, collaborative, hypertext information level protocol for distributed, collaborative, hypertext information
systems. This document defines the semantics of HTTP: its systems. This document defines the semantics of HTTP: its
architecture, terminology, the "http" and "https" Uniform Resource architecture, terminology, the "http" and "https" Uniform Resource
Identifier (URI) schemes, core request methods, request header Identifier (URI) schemes, core request methods, request header
fields, response status codes, response header fields, and content fields, response status codes, response header fields, and content
negotiation. negotiation.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 J.7. The changes in this draft are summarized in Appendix C.8.
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 May 7, 2020. This Internet-Draft will expire on September 8, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 41 skipping to change at page 2, line 41
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 9 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 9
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 9 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 10
2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 10 1.2.1. Whitespace . . . . . . . . . . . . . . . . . . . . . 10
2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 10 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2. Intermediaries . . . . . . . . . . . . . . . . . . . . . 12 2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 11
2.3. Caches . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.2. Intermediaries . . . . . . . . . . . . . . . . . . . . . 13
2.4. Uniform Resource Identifiers . . . . . . . . . . . . . . 15 2.3. Caches . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.5. Resources . . . . . . . . . . . . . . . . . . . . . . . . 16 2.4. Uniform Resource Identifiers . . . . . . . . . . . . . . 16
2.5.1. http URI Scheme . . . . . . . . . . . . . . . . . . . 16 2.5. Resources . . . . . . . . . . . . . . . . . . . . . . . . 17
2.5.1. http URI Scheme . . . . . . . . . . . . . . . . . . . 17
2.5.2. https URI Scheme . . . . . . . . . . . . . . . . . . 18 2.5.2. https URI Scheme . . . . . . . . . . . . . . . . . . 18
2.5.3. Fragment Identifiers on http(s) URI References . . . 20 2.5.3. http and https URI Normalization and Comparison . . . 19
2.5.4. http and https URI Normalization and Comparison . . . 20 2.5.4. Deprecated userinfo . . . . . . . . . . . . . . . . . 19
3. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.5.5. Fragment Identifiers on http(s) URI References . . . 20
3.1. Implementation Diversity . . . . . . . . . . . . . . . . 21 3. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.1. Implementation Diversity . . . . . . . . . . . . . . . . 20
3.2. Role-based Requirements . . . . . . . . . . . . . . . . . 21 3.2. Role-based Requirements . . . . . . . . . . . . . . . . . 21
3.3. Parsing Elements . . . . . . . . . . . . . . . . . . . . 22 3.3. Parsing Elements . . . . . . . . . . . . . . . . . . . . 21
3.4. Error Handling . . . . . . . . . . . . . . . . . . . . . 23 3.4. Error Handling . . . . . . . . . . . . . . . . . . . . . 22
3.5. Protocol Versioning . . . . . . . . . . . . . . . . . . . 23 3.5. Protocol Versioning . . . . . . . . . . . . . . . . . . . 22
4. Header Fields . . . . . . . . . . . . . . . . . . . . . . . . 24 4. Header and Trailer Fields . . . . . . . . . . . . . . . . . . 24
4.1. Header Field Names . . . . . . . . . . . . . . . . . . . 24 4.1. Field Ordering and Combination . . . . . . . . . . . . . 25
4.1.1. Header Field Name Registry . . . . . . . . . . . . . 27 4.2. Field Limits . . . . . . . . . . . . . . . . . . . . . . 26
4.1.2. Header Field Extensibility . . . . . . . . . . . . . 28 4.3. Field Names . . . . . . . . . . . . . . . . . . . . . . . 26
4.2. Header Field Values . . . . . . . . . . . . . . . . . . . 28 4.3.1. Field Extensibility . . . . . . . . . . . . . . . . . 27
4.2.1. Header Field Order . . . . . . . . . . . . . . . . . 29 4.3.2. Field Name Registry . . . . . . . . . . . . . . . . . 27
4.2.2. Header Field Limits . . . . . . . . . . . . . . . . . 30 4.4. Field Values . . . . . . . . . . . . . . . . . . . . . . 28
4.2.3. Header Field Value Components . . . . . . . . . . . . 30 4.4.1. Common Field Value Components . . . . . . . . . . . . 30
4.3. Trailer Fields . . . . . . . . . . . . . . . . . . . . . 32 4.5. ABNF List Extension: #rule . . . . . . . . . . . . . . . 31
4.3.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 32 4.5.1. Sender Requirements . . . . . . . . . . . . . . . . . 31
4.3.2. Limitations . . . . . . . . . . . . . . . . . . . . . 32 4.5.2. Recipient Requirements . . . . . . . . . . . . . . . 32
4.3.3. Trailer . . . . . . . . . . . . . . . . . . . . . . . 33 4.6. Trailer Fields . . . . . . . . . . . . . . . . . . . . . 32
4.4. Considerations for New Header Fields . . . . . . . . . . 33 4.6.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 33
5. Message Routing . . . . . . . . . . . . . . . . . . . . . . . 35 4.6.2. Limitations . . . . . . . . . . . . . . . . . . . . . 33
5.1. Identifying a Target Resource . . . . . . . . . . . . . . 35 4.6.3. Trailer . . . . . . . . . . . . . . . . . . . . . . . 34
5.2. Routing Inbound . . . . . . . . . . . . . . . . . . . . . 36 4.7. Considerations for New HTTP Fields . . . . . . . . . . . 34
5.3. Effective Request URI . . . . . . . . . . . . . . . . . . 36 4.8. Fields Defined In This Document . . . . . . . . . . . . . 35
5.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . 37 5. Message Routing . . . . . . . . . . . . . . . . . . . . . . . 37
5.5. Message Forwarding . . . . . . . . . . . . . . . . . . . 38 5.1. Identifying a Target Resource . . . . . . . . . . . . . . 37
5.5.1. Via . . . . . . . . . . . . . . . . . . . . . . . . . 39 5.2. Determining Origin . . . . . . . . . . . . . . . . . . . 37
5.5.2. Transformations . . . . . . . . . . . . . . . . . . . 40 5.3. Routing Inbound . . . . . . . . . . . . . . . . . . . . . 38
6. Representations . . . . . . . . . . . . . . . . . . . . . . . 41 5.4. Direct Authoritative Access . . . . . . . . . . . . . . . 38
6.1. Representation Data . . . . . . . . . . . . . . . . . . . 42 5.4.1. http origins . . . . . . . . . . . . . . . . . . . . 38
6.1.1. Media Type . . . . . . . . . . . . . . . . . . . . . 42 5.4.2. https origins . . . . . . . . . . . . . . . . . . . . 39
6.1.2. Content Codings . . . . . . . . . . . . . . . . . . . 44 5.4.3. Initiating HTTP Over TLS . . . . . . . . . . . . . . 41
6.1.3. Language Tags . . . . . . . . . . . . . . . . . . . . 46 5.5. Effective Request URI . . . . . . . . . . . . . . . . . . 43
6.1.4. Range Units . . . . . . . . . . . . . . . . . . . . . 47 5.6. Host . . . . . . . . . . . . . . . . . . . . . . . . . . 43
6.2. Representation Metadata . . . . . . . . . . . . . . . . . 51 5.7. Message Forwarding . . . . . . . . . . . . . . . . . . . 44
6.2.1. Content-Type . . . . . . . . . . . . . . . . . . . . 51 5.7.1. Via . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.2.2. Content-Encoding . . . . . . . . . . . . . . . . . . 52 5.7.2. Transformations . . . . . . . . . . . . . . . . . . . 47
6.2.3. Content-Language . . . . . . . . . . . . . . . . . . 53 6. Representations . . . . . . . . . . . . . . . . . . . . . . . 48
6.2.4. Content-Length . . . . . . . . . . . . . . . . . . . 54 6.1. Representation Data . . . . . . . . . . . . . . . . . . . 48
6.2.5. Content-Location . . . . . . . . . . . . . . . . . . 55 6.1.1. Media Type . . . . . . . . . . . . . . . . . . . . . 49
6.3. Payload . . . . . . . . . . . . . . . . . . . . . . . . . 57 6.1.2. Content Codings . . . . . . . . . . . . . . . . . . . 51
6.3.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 57 6.1.3. Language Tags . . . . . . . . . . . . . . . . . . . . 53
6.3.2. Identification . . . . . . . . . . . . . . . . . . . 58 6.1.4. Range Units . . . . . . . . . . . . . . . . . . . . . 54
6.3.3. Payload Body . . . . . . . . . . . . . . . . . . . . 59 6.2. Representation Metadata . . . . . . . . . . . . . . . . . 58
6.3.4. Content-Range . . . . . . . . . . . . . . . . . . . . 59 6.2.1. Content-Type . . . . . . . . . . . . . . . . . . . . 58
6.3.5. Media Type multipart/byteranges . . . . . . . . . . . 61 6.2.2. Content-Encoding . . . . . . . . . . . . . . . . . . 59
6.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 63 6.2.3. Content-Language . . . . . . . . . . . . . . . . . . 60
6.4.1. Proactive Negotiation . . . . . . . . . . . . . . . . 64 6.2.4. Content-Length . . . . . . . . . . . . . . . . . . . 61
6.4.2. Reactive Negotiation . . . . . . . . . . . . . . . . 65 6.2.5. Content-Location . . . . . . . . . . . . . . . . . . 62
7. Request Methods . . . . . . . . . . . . . . . . . . . . . . . 66 6.3. Payload . . . . . . . . . . . . . . . . . . . . . . . . . 64
7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 66 6.3.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 64
7.2. Common Method Properties . . . . . . . . . . . . . . . . 67 6.3.2. Identification . . . . . . . . . . . . . . . . . . . 65
7.2.1. Safe Methods . . . . . . . . . . . . . . . . . . . . 68 6.3.3. Payload Body . . . . . . . . . . . . . . . . . . . . 66
7.2.2. Idempotent Methods . . . . . . . . . . . . . . . . . 69 6.3.4. Content-Range . . . . . . . . . . . . . . . . . . . . 66
7.2.3. Methods and Caching . . . . . . . . . . . . . . . . . 70 6.3.5. Media Type multipart/byteranges . . . . . . . . . . . 68
7.3. Method Definitions . . . . . . . . . . . . . . . . . . . 70 6.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 70
7.3.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 70 6.4.1. Proactive Negotiation . . . . . . . . . . . . . . . . 71
7.3.2. HEAD . . . . . . . . . . . . . . . . . . . . . . . . 71 6.4.2. Reactive Negotiation . . . . . . . . . . . . . . . . 72
7.3.3. POST . . . . . . . . . . . . . . . . . . . . . . . . 72 7. Request Methods . . . . . . . . . . . . . . . . . . . . . . . 73
7.3.4. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 73 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 73
7.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . 75 7.2. Common Method Properties . . . . . . . . . . . . . . . . 74
7.3.6. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 76 7.2.1. Safe Methods . . . . . . . . . . . . . . . . . . . . 75
7.3.7. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 78 7.2.2. Idempotent Methods . . . . . . . . . . . . . . . . . 76
7.3.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . 79 7.2.3. Methods and Caching . . . . . . . . . . . . . . . . . 77
7.4. Method Extensibility . . . . . . . . . . . . . . . . . . 79 7.3. Method Definitions . . . . . . . . . . . . . . . . . . . 77
7.4.1. Method Registry . . . . . . . . . . . . . . . . . . . 79 7.3.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 77
7.4.2. Considerations for New Methods . . . . . . . . . . . 80 7.3.2. HEAD . . . . . . . . . . . . . . . . . . . . . . . . 78
8. Request Header Fields . . . . . . . . . . . . . . . . . . . . 80 7.3.3. POST . . . . . . . . . . . . . . . . . . . . . . . . 79
8.1. Controls . . . . . . . . . . . . . . . . . . . . . . . . 81 7.3.4. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 80
8.1.1. Expect . . . . . . . . . . . . . . . . . . . . . . . 81 7.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . 82
8.1.2. Max-Forwards . . . . . . . . . . . . . . . . . . . . 83 7.3.6. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 83
8.2. Preconditions . . . . . . . . . . . . . . . . . . . . . . 84 7.3.7. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 85
8.2.1. Evaluation . . . . . . . . . . . . . . . . . . . . . 85 7.3.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . 86
8.2.2. Precedence . . . . . . . . . . . . . . . . . . . . . 86 7.4. Method Extensibility . . . . . . . . . . . . . . . . . . 86
8.2.3. If-Match . . . . . . . . . . . . . . . . . . . . . . 88 7.4.1. Method Registry . . . . . . . . . . . . . . . . . . . 86
8.2.4. If-None-Match . . . . . . . . . . . . . . . . . . . . 89 7.4.2. Considerations for New Methods . . . . . . . . . . . 87
8.2.5. If-Modified-Since . . . . . . . . . . . . . . . . . . 90 8. Request Header Fields . . . . . . . . . . . . . . . . . . . . 87
8.2.6. If-Unmodified-Since . . . . . . . . . . . . . . . . . 91 8.1. Controls . . . . . . . . . . . . . . . . . . . . . . . . 88
8.2.7. If-Range . . . . . . . . . . . . . . . . . . . . . . 93 8.1.1. Expect . . . . . . . . . . . . . . . . . . . . . . . 88
8.3. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 94 8.1.2. Max-Forwards . . . . . . . . . . . . . . . . . . . . 90
8.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 95 8.2. Preconditions . . . . . . . . . . . . . . . . . . . . . . 91
8.4.1. Quality Values . . . . . . . . . . . . . . . . . . . 96 8.2.1. Evaluation . . . . . . . . . . . . . . . . . . . . . 92
8.4.2. Accept . . . . . . . . . . . . . . . . . . . . . . . 97 8.2.2. Precedence . . . . . . . . . . . . . . . . . . . . . 93
8.4.3. Accept-Charset . . . . . . . . . . . . . . . . . . . 99 8.2.3. If-Match . . . . . . . . . . . . . . . . . . . . . . 95
8.4.4. Accept-Encoding . . . . . . . . . . . . . . . . . . . 100 8.2.4. If-None-Match . . . . . . . . . . . . . . . . . . . . 96
8.4.5. Accept-Language . . . . . . . . . . . . . . . . . . . 101 8.2.5. If-Modified-Since . . . . . . . . . . . . . . . . . . 97
8.5. Authentication Credentials . . . . . . . . . . . . . . . 102 8.2.6. If-Unmodified-Since . . . . . . . . . . . . . . . . . 98
8.5.1. Challenge and Response . . . . . . . . . . . . . . . 102 8.2.7. If-Range . . . . . . . . . . . . . . . . . . . . . . 100
8.5.2. Protection Space (Realm) . . . . . . . . . . . . . . 104 8.3. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 101
8.5.3. Authorization . . . . . . . . . . . . . . . . . . . . 105 8.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 102
8.5.4. Proxy-Authorization . . . . . . . . . . . . . . . . . 105 8.4.1. Quality Values . . . . . . . . . . . . . . . . . . . 103
8.5.5. Authentication Scheme Extensibility . . . . . . . . . 106 8.4.2. Accept . . . . . . . . . . . . . . . . . . . . . . . 104
8.6. Request Context . . . . . . . . . . . . . . . . . . . . . 108 8.4.3. Accept-Charset . . . . . . . . . . . . . . . . . . . 106
8.6.1. From . . . . . . . . . . . . . . . . . . . . . . . . 108 8.4.4. Accept-Encoding . . . . . . . . . . . . . . . . . . . 107
8.6.2. Referer . . . . . . . . . . . . . . . . . . . . . . . 109 8.4.5. Accept-Language . . . . . . . . . . . . . . . . . . . 108
8.6.3. User-Agent . . . . . . . . . . . . . . . . . . . . . 110 8.5. Authentication Credentials . . . . . . . . . . . . . . . 109
8.5.1. Challenge and Response . . . . . . . . . . . . . . . 109
9. Response Status Codes . . . . . . . . . . . . . . . . . . . . 111 8.5.2. Protection Space (Realm) . . . . . . . . . . . . . . 111
9.1. Overview of Status Codes . . . . . . . . . . . . . . . . 112 8.5.3. Authorization . . . . . . . . . . . . . . . . . . . . 112
9.2. Informational 1xx . . . . . . . . . . . . . . . . . . . . 113 8.5.4. Proxy-Authorization . . . . . . . . . . . . . . . . . 112
9.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 114 8.5.5. Authentication Scheme Extensibility . . . . . . . . . 113
9.2.2. 101 Switching Protocols . . . . . . . . . . . . . . . 114 8.6. Request Context . . . . . . . . . . . . . . . . . . . . . 115
9.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . 114 8.6.1. From . . . . . . . . . . . . . . . . . . . . . . . . 115
9.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 114 8.6.2. Referer . . . . . . . . . . . . . . . . . . . . . . . 116
9.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 115 8.6.3. User-Agent . . . . . . . . . . . . . . . . . . . . . 117
9.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . 115 9. Response Status Codes . . . . . . . . . . . . . . . . . . . . 118
9.3.4. 203 Non-Authoritative Information . . . . . . . . . . 116 9.1. Overview of Status Codes . . . . . . . . . . . . . . . . 119
9.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . 116 9.2. Informational 1xx . . . . . . . . . . . . . . . . . . . . 120
9.3.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 117 9.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 121
9.3.7. 206 Partial Content . . . . . . . . . . . . . . . . . 117 9.2.2. 101 Switching Protocols . . . . . . . . . . . . . . . 121
9.4. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 120 9.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . 121
9.4.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 122 9.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 121
9.4.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 123 9.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 122
9.4.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 123 9.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . 122
9.4.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 124 9.3.4. 203 Non-Authoritative Information . . . . . . . . . . 123
9.4.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 124 9.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . 123
9.4.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 125 9.3.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 124
9.4.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . 125 9.3.7. 206 Partial Content . . . . . . . . . . . . . . . . . 124
9.4.8. 307 Temporary Redirect . . . . . . . . . . . . . . . 125 9.4. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 127
9.4.9. 308 Permanent Redirect . . . . . . . . . . . . . . . 126 9.4.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 129
9.5. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 126 9.4.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 130
9.5.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 126 9.4.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 130
9.5.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 126 9.4.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 131
9.5.3. 402 Payment Required . . . . . . . . . . . . . . . . 127 9.4.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 131
9.5.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 127 9.4.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 132
9.5.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 127 9.4.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . 132
9.5.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 128 9.4.8. 307 Temporary Redirect . . . . . . . . . . . . . . . 132
9.5.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 128 9.4.9. 308 Permanent Redirect . . . . . . . . . . . . . . . 133
9.5.8. 407 Proxy Authentication Required . . . . . . . . . . 128 9.5. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 133
9.5.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 128 9.5.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 133
9.5.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . 129 9.5.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 133
9.5.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 129 9.5.3. 402 Payment Required . . . . . . . . . . . . . . . . 134
9.5.12. 411 Length Required . . . . . . . . . . . . . . . . . 129 9.5.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 134
9.5.13. 412 Precondition Failed . . . . . . . . . . . . . . . 130 9.5.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 134
9.5.14. 413 Payload Too Large . . . . . . . . . . . . . . . . 130 9.5.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 135
9.5.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . 130 9.5.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 135
9.5.16. 415 Unsupported Media Type . . . . . . . . . . . . . 130 9.5.8. 407 Proxy Authentication Required . . . . . . . . . . 135
9.5.17. 416 Range Not Satisfiable . . . . . . . . . . . . . . 131 9.5.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 135
9.5.18. 417 Expectation Failed . . . . . . . . . . . . . . . 131 9.5.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . 136
9.5.19. 418 (Unused) . . . . . . . . . . . . . . . . . . . . 131 9.5.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 136
9.5.20. 422 Unprocessable Payload . . . . . . . . . . . . . . 132 9.5.12. 411 Length Required . . . . . . . . . . . . . . . . . 136
9.5.21. 426 Upgrade Required . . . . . . . . . . . . . . . . 132 9.5.13. 412 Precondition Failed . . . . . . . . . . . . . . . 137
9.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 132 9.5.14. 413 Payload Too Large . . . . . . . . . . . . . . . . 137
9.6.1. 500 Internal Server Error . . . . . . . . . . . . . . 133 9.5.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . 137
9.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 133 9.5.16. 415 Unsupported Media Type . . . . . . . . . . . . . 137
9.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 133 9.5.17. 416 Range Not Satisfiable . . . . . . . . . . . . . . 138
9.6.4. 503 Service Unavailable . . . . . . . . . . . . . . . 133 9.5.18. 417 Expectation Failed . . . . . . . . . . . . . . . 138
9.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 133 9.5.19. 418 (Unused) . . . . . . . . . . . . . . . . . . . . 138
9.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . 133 9.5.20. 422 Unprocessable Payload . . . . . . . . . . . . . . 139
9.7. Status Code Extensibility . . . . . . . . . . . . . . . . 134 9.5.21. 426 Upgrade Required . . . . . . . . . . . . . . . . 139
9.7.1. Status Code Registry . . . . . . . . . . . . . . . . 134 9.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 139
9.7.2. Considerations for New Status Codes . . . . . . . . . 134 9.6.1. 500 Internal Server Error . . . . . . . . . . . . . . 140
10. Response Header Fields . . . . . . . . . . . . . . . . . . . 135 9.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 140
10.1. Control Data . . . . . . . . . . . . . . . . . . . . . . 135 9.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 140
10.1.1. Origination Date . . . . . . . . . . . . . . . . . . 136 9.6.4. 503 Service Unavailable . . . . . . . . . . . . . . . 140
10.1.2. Location . . . . . . . . . . . . . . . . . . . . . . 139 9.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 140
10.1.3. Retry-After . . . . . . . . . . . . . . . . . . . . 140 9.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . 140
10.1.4. Vary . . . . . . . . . . . . . . . . . . . . . . . . 141 9.7. Status Code Extensibility . . . . . . . . . . . . . . . . 141
10.2. Validators . . . . . . . . . . . . . . . . . . . . . . . 142 9.7.1. Status Code Registry . . . . . . . . . . . . . . . . 141
10.2.1. Weak versus Strong . . . . . . . . . . . . . . . . . 143 9.7.2. Considerations for New Status Codes . . . . . . . . . 141
10.2.2. Last-Modified . . . . . . . . . . . . . . . . . . . 144 10. Response Header Fields . . . . . . . . . . . . . . . . . . . 142
10.2.3. ETag . . . . . . . . . . . . . . . . . . . . . . . . 146 10.1. Control Data . . . . . . . . . . . . . . . . . . . . . . 142
10.2.4. When to Use Entity-Tags and Last-Modified Dates . . 150 10.1.1. Origination Date . . . . . . . . . . . . . . . . . . 143
10.3. Authentication Challenges . . . . . . . . . . . . . . . 150 10.1.2. Location . . . . . . . . . . . . . . . . . . . . . . 146
10.3.1. WWW-Authenticate . . . . . . . . . . . . . . . . . . 151 10.1.3. Retry-After . . . . . . . . . . . . . . . . . . . . 147
10.3.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . 152 10.1.4. Vary . . . . . . . . . . . . . . . . . . . . . . . . 147
10.3.3. Authentication-Info . . . . . . . . . . . . . . . . 152 10.2. Validators . . . . . . . . . . . . . . . . . . . . . . . 149
10.3.4. Proxy-Authentication-Info . . . . . . . . . . . . . 153 10.2.1. Weak versus Strong . . . . . . . . . . . . . . . . . 150
10.4. Response Context . . . . . . . . . . . . . . . . . . . . 154 10.2.2. Last-Modified . . . . . . . . . . . . . . . . . . . 151
10.4.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . 154 10.2.3. ETag . . . . . . . . . . . . . . . . . . . . . . . . 153
10.4.2. Allow . . . . . . . . . . . . . . . . . . . . . . . 154 10.2.4. When to Use Entity-Tags and Last-Modified Dates . . 157
10.4.3. Server . . . . . . . . . . . . . . . . . . . . . . . 155 10.3. Authentication Challenges . . . . . . . . . . . . . . . 157
11. Generic Syntax . . . . . . . . . . . . . . . . . . . . . . . 156 10.3.1. WWW-Authenticate . . . . . . . . . . . . . . . . . . 158
11.1. Whitespace . . . . . . . . . . . . . . . . . . . . . . . 156 10.3.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . 159
12. ABNF List Extension: #rule . . . . . . . . . . . . . . . . . 156 10.3.3. Authentication-Info . . . . . . . . . . . . . . . . 159
12.1. Sender Requirements . . . . . . . . . . . . . . . . . . 156 10.3.4. Proxy-Authentication-Info . . . . . . . . . . . . . 160
12.2. Recipient Requirements . . . . . . . . . . . . . . . . . 157 10.4. Response Context . . . . . . . . . . . . . . . . . . . . 161
13. Security Considerations . . . . . . . . . . . . . . . . . . . 158 10.4.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . 161
13.1. Establishing Authority . . . . . . . . . . . . . . . . . 158 10.4.2. Allow . . . . . . . . . . . . . . . . . . . . . . . 161
13.2. Risks of Intermediaries . . . . . . . . . . . . . . . . 159 10.4.3. Server . . . . . . . . . . . . . . . . . . . . . . . 162
13.3. Attacks Based on File and Path Names . . . . . . . . . . 160 11. Security Considerations . . . . . . . . . . . . . . . . . . . 163
13.4. Attacks Based on Command, Code, or Query Injection . . . 160 11.1. Establishing Authority . . . . . . . . . . . . . . . . . 163
13.5. Attacks via Protocol Element Length . . . . . . . . . . 161 11.2. Risks of Intermediaries . . . . . . . . . . . . . . . . 164
13.6. Disclosure of Personal Information . . . . . . . . . . . 161 11.3. Attacks Based on File and Path Names . . . . . . . . . . 165
13.7. Privacy of Server Log Information . . . . . . . . . . . 161 11.4. Attacks Based on Command, Code, or Query Injection . . . 165
13.8. Disclosure of Sensitive Information in URIs . . . . . . 162 11.5. Attacks via Protocol Element Length . . . . . . . . . . 166
13.9. Disclosure of Fragment after Redirects . . . . . . . . . 162 11.6. Disclosure of Personal Information . . . . . . . . . . . 166
13.10. Disclosure of Product Information . . . . . . . . . . . 163 11.7. Privacy of Server Log Information . . . . . . . . . . . 166
13.11. Browser Fingerprinting . . . . . . . . . . . . . . . . . 163 11.8. Disclosure of Sensitive Information in URIs . . . . . . 167
13.12. Validator Retention . . . . . . . . . . . . . . . . . . 164 11.9. Disclosure of Fragment after Redirects . . . . . . . . . 167
13.13. Denial-of-Service Attacks Using Range . . . . . . . . . 165 11.10. Disclosure of Product Information . . . . . . . . . . . 168
13.14. Authentication Considerations . . . . . . . . . . . . . 165 11.11. Browser Fingerprinting . . . . . . . . . . . . . . . . . 168
13.14.1. Confidentiality of Credentials . . . . . . . . . . 165 11.12. Validator Retention . . . . . . . . . . . . . . . . . . 169
13.14.2. Credentials and Idle Clients . . . . . . . . . . . 166 11.13. Denial-of-Service Attacks Using Range . . . . . . . . . 170
13.14.3. Protection Spaces . . . . . . . . . . . . . . . . . 166 11.14. Authentication Considerations . . . . . . . . . . . . . 170
13.14.4. Additional Response Header Fields . . . . . . . . . 167 11.14.1. Confidentiality of Credentials . . . . . . . . . . 170
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 167 11.14.2. Credentials and Idle Clients . . . . . . . . . . . 171
14.1. URI Scheme Registration . . . . . . . . . . . . . . . . 167 11.14.3. Protection Spaces . . . . . . . . . . . . . . . . . 171
14.2. Method Registration . . . . . . . . . . . . . . . . . . 167 11.14.4. Additional Response Fields . . . . . . . . . . . . 172
14.3. Status Code Registration . . . . . . . . . . . . . . . . 167 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 172
14.4. Header Field Registration . . . . . . . . . . . . . . . 168 12.1. URI Scheme Registration . . . . . . . . . . . . . . . . 172
14.5. Authentication Scheme Registration . . . . . . . . . . . 168 12.2. Method Registration . . . . . . . . . . . . . . . . . . 172
14.6. Content Coding Registration . . . . . . . . . . . . . . 168 12.3. Status Code Registration . . . . . . . . . . . . . . . . 172
14.7. Range Unit Registration . . . . . . . . . . . . . . . . 169 12.4. HTTP Field Name Registration . . . . . . . . . . . . . . 173
14.8. Media Type Registration . . . . . . . . . . . . . . . . 169 12.5. Authentication Scheme Registration . . . . . . . . . . . 173
14.9. Port Registration . . . . . . . . . . . . . . . . . . . 169 12.6. Content Coding Registration . . . . . . . . . . . . . . 173
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 169 12.7. Range Unit Registration . . . . . . . . . . . . . . . . 174
15.1. Normative References . . . . . . . . . . . . . . . . . . 169 12.8. Media Type Registration . . . . . . . . . . . . . . . . 174
15.2. Informative References . . . . . . . . . . . . . . . . . 171 12.9. Port Registration . . . . . . . . . . . . . . . . . . . 174
Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 177 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 174
Appendix B. Changes from RFC 7230 . . . . . . . . . . . . . . . 181 13.1. Normative References . . . . . . . . . . . . . . . . . . 174
Appendix C. Changes from RFC 2818 . . . . . . . . . . . . . . . 182 13.2. Informative References . . . . . . . . . . . . . . . . . 176
Appendix D. Changes from RFC 7231 . . . . . . . . . . . . . . . 182 Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 182
Appendix E. Changes from RFC 7232 . . . . . . . . . . . . . . . 182 Appendix B. Changes from previous RFCs . . . . . . . . . . . . . 186
Appendix F. Changes from RFC 7233 . . . . . . . . . . . . . . . 182 B.1. Changes from RFC 2818 . . . . . . . . . . . . . . . . . . 186
Appendix G. Changes from RFC 7235 . . . . . . . . . . . . . . . 182 B.2. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 186
Appendix H. Changes from RFC 7538 . . . . . . . . . . . . . . . 183 B.3. Changes from RFC 7231 . . . . . . . . . . . . . . . . . . 187
Appendix I. Changes from RFC 7615 . . . . . . . . . . . . . . . 183 B.4. Changes from RFC 7232 . . . . . . . . . . . . . . . . . . 188
Appendix J. Change Log . . . . . . . . . . . . . . . . . . . . . 183 B.5. Changes from RFC 7233 . . . . . . . . . . . . . . . . . . 188
J.1. Between RFC723x and draft 00 . . . . . . . . . . . . . . 183 B.6. Changes from RFC 7235 . . . . . . . . . . . . . . . . . . 188
J.2. Since draft-ietf-httpbis-semantics-00 . . . . . . . . . . 183 B.7. Changes from RFC 7538 . . . . . . . . . . . . . . . . . . 188
J.3. Since draft-ietf-httpbis-semantics-01 . . . . . . . . . . 184 B.8. Changes from RFC 7615 . . . . . . . . . . . . . . . . . . 188
J.4. Since draft-ietf-httpbis-semantics-02 . . . . . . . . . . 185 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 188
J.5. Since draft-ietf-httpbis-semantics-03 . . . . . . . . . . 186 C.1. Between RFC723x and draft 00 . . . . . . . . . . . . . . 188
J.6. Since draft-ietf-httpbis-semantics-04 . . . . . . . . . . 187 C.2. Since draft-ietf-httpbis-semantics-00 . . . . . . . . . . 189
J.7. Since draft-ietf-httpbis-semantics-05 . . . . . . . . . . 187 C.3. Since draft-ietf-httpbis-semantics-01 . . . . . . . . . . 189
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 C.4. Since draft-ietf-httpbis-semantics-02 . . . . . . . . . . 191
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 196 C.5. Since draft-ietf-httpbis-semantics-03 . . . . . . . . . . 192
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 197 C.6. Since draft-ietf-httpbis-semantics-04 . . . . . . . . . . 192
C.7. Since draft-ietf-httpbis-semantics-05 . . . . . . . . . . 193
C.8. Since draft-ietf-httpbis-semantics-06 . . . . . . . . . . 194
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 205
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 206
1. Introduction 1. Introduction
The Hypertext Transfer Protocol (HTTP) is a stateless application- The Hypertext Transfer Protocol (HTTP) is a stateless application-
level request/response protocol that uses extensible semantics and level request/response protocol that uses extensible semantics and
self-descriptive messages for flexible interaction with network-based self-descriptive messages for flexible interaction with network-based
hypertext information systems. HTTP is defined by a series of hypertext information systems. HTTP is defined by a series of
documents that collectively form the HTTP/1.1 specification: documents that collectively form the HTTP/1.1 specification:
o "HTTP Semantics" (this document) o "HTTP Semantics" (this document)
skipping to change at page 9, line 18 skipping to change at page 9, line 30
a payload is intended to be interpreted by a recipient, the request a payload is intended to be interpreted by a recipient, the request
header fields that might influence content selection, and the various header fields that might influence content selection, and the various
selection algorithms that are collectively referred to as "content selection algorithms that are collectively referred to as "content
negotiation" (Section 6.4). negotiation" (Section 6.4).
This document defines HTTP range requests, partial responses, and the This document defines HTTP range requests, partial responses, and the
multipart/byteranges media type. multipart/byteranges media type.
This document obsoletes the portions of RFC 7230 that are independent This document obsoletes the portions of RFC 7230 that are independent
of the HTTP/1.1 messaging syntax and connection management, with the of the HTTP/1.1 messaging syntax and connection management, with the
changes being summarized in Appendix B. The other parts of RFC 7230 changes being summarized in Appendix B.2. The other parts of RFC
are obsoleted by "HTTP/1.1 Messaging" [Messaging]. This document 7230 are obsoleted by "HTTP/1.1 Messaging" [Messaging]. This
also obsoletes RFC 2818 (see Appendix C), RFC 7231 (see Appendix D), document also obsoletes RFC 2818 (see Appendix B.1), RFC 7231 (see
RFC 7232 (see Appendix E), RFC 7233 (see Appendix F), RFC 7235 (see Appendix B.3), RFC 7232 (see Appendix B.4), RFC 7233 (see
Appendix G), RFC 7538 (see Appendix H), and RFC 7615 (see Appendix B.5), RFC 7235 (see Appendix B.6), RFC 7538 (see
Appendix I). Appendix B.7), and RFC 7615 (see Appendix B.8).
1.1. Requirements Notation 1.1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Conformance criteria and considerations regarding error handling are Conformance criteria and considerations regarding error handling are
defined in Section 3. defined in Section 3.
1.2. Syntax Notation 1.2. Syntax Notation
This specification uses the Augmented Backus-Naur Form (ABNF) This specification uses the Augmented Backus-Naur Form (ABNF)
notation of [RFC5234], extended with the notation for case- notation of [RFC5234], extended with the notation for case-
sensitivity in strings defined in [RFC7405]. sensitivity in strings defined in [RFC7405].
It also uses a list extension, defined in Section 12, that allows for It also uses a list extension, defined in Section 4.5, that allows
compact definition of comma-separated lists using a '#' operator for compact definition of comma-separated lists using a '#' operator
(similar to how the '*' operator indicates repetition). Appendix A (similar to how the '*' operator indicates repetition). Appendix A
shows the collected grammar with all list operators expanded to shows the collected grammar with all list operators expanded to
standard ABNF notation. standard ABNF notation.
As a convention, ABNF rule names prefixed with "obs-" denote As a convention, ABNF rule names prefixed with "obs-" denote
"obsolete" grammar rules that appear for historical reasons. "obsolete" grammar rules that appear for historical reasons.
The following core rules are included by reference, as defined in The following core rules are included by reference, as defined in
Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return),
CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double
quote), HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF quote), HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF
(line feed), OCTET (any 8-bit sequence of data), SP (space), and (line feed), OCTET (any 8-bit sequence of data), SP (space), and
VCHAR (any visible US-ASCII character). VCHAR (any visible US-ASCII character).
Section 4.2.3 defines some generic syntactic components for header Section 4.4.1 defines some generic syntactic components for field
field values. values.
The rules below are defined in [Messaging]: The rules below are defined in [Messaging]:
obs-fold = <obs-fold, see [Messaging], Section 5.2> obs-fold = <obs-fold, see [Messaging], Section 5.2>
protocol-name = <protocol-name, see [Messaging], Section 9.9> protocol-name = <protocol-name, see [Messaging], Section 9.9>
protocol-version = <protocol-version, see [Messaging], Section 9.9> protocol-version = <protocol-version, see [Messaging], Section 9.9>
request-target = <request-target, see [Messaging], Section 3.2> request-target = <request-target, see [Messaging], Section 3.2>
This specification uses the terms "character", "character encoding This specification uses the terms "character", "character encoding
scheme", "charset", and "protocol element" as they are defined in scheme", "charset", and "protocol element" as they are defined in
[RFC6365]. [RFC6365].
1.2.1. Whitespace
This specification uses three rules to denote the use of linear
whitespace: OWS (optional whitespace), RWS (required whitespace), and
BWS ("bad" whitespace).
The OWS rule is used where zero or more linear whitespace octets
might appear. For protocol elements where optional whitespace is
preferred to improve readability, a sender SHOULD generate the
optional whitespace as a single SP; otherwise, a sender SHOULD NOT
generate optional whitespace except as needed to white out invalid or
unwanted protocol elements during in-place message filtering.
The RWS rule is used when at least one linear whitespace octet is
required to separate field tokens. A sender SHOULD generate RWS as a
single SP.
OWS and RWS have the same semantics as a single SP. Any content
known to be defined as OWS or RWS MAY be replaced with a single SP
before interpreting it or forwarding the message downstream.
The BWS rule is used where the grammar allows optional whitespace
only for historical reasons. A sender MUST NOT generate BWS in
messages. A recipient MUST parse for such bad whitespace and remove
it before interpreting the protocol element.
BWS has no semantics. Any content known to be defined as BWS MAY be
removed before interpreting it or forwarding the message downstream.
OWS = *( SP / HTAB )
; optional whitespace
RWS = 1*( SP / HTAB )
; required whitespace
BWS = OWS
; "bad" whitespace
2. Architecture 2. Architecture
HTTP was created for the World Wide Web (WWW) architecture and has HTTP was created for the World Wide Web (WWW) architecture and has
evolved over time to support the scalability needs of a worldwide evolved over time to support the scalability needs of a worldwide
hypertext system. Much of that architecture is reflected in the hypertext system. Much of that architecture is reflected in the
terminology and syntax productions used to define HTTP. terminology and syntax productions used to define HTTP.
2.1. Client/Server Messaging 2.1. Client/Server Messaging
HTTP is a stateless request/response protocol that operates by HTTP is a stateless request/response protocol that operates by
skipping to change at page 11, line 22 skipping to change at page 12, line 24
connection (===) between the user agent (UA) and the origin server connection (===) between the user agent (UA) and the origin server
(O). (O).
request > request >
UA ======================================= O UA ======================================= O
< response < response
Each major version of HTTP defines its own syntax for the inclusion Each major version of HTTP defines its own syntax for the inclusion
of information in messages. Nevertheless, a common abstraction is of information in messages. Nevertheless, a common abstraction is
that a message includes some form of envelope/framing, a potential that a message includes some form of envelope/framing, a potential
set of named header fields up front (a header section), a potential set of named fields up front (a header section), a potential body,
body, and a potential set of named trailer fields. and a potential following set of named fields (a trailer section).
A client sends an HTTP request to a server in the form of a request A client sends an HTTP request to a server in the form of a request
message, beginning with a method (Section 7) and URI, followed by message, beginning with a method (Section 7) and URI, followed by
header fields containing request modifiers, client information, and header fields containing request modifiers, client information, and
representation metadata (Section 4), and finally a payload body (if representation metadata (Section 4), and finally a payload body (if
any, Section 6.3.3). any, Section 6.3.3).
A server responds to a client's request by sending one or more HTTP A server responds to a client's request by sending one or more HTTP
response messages, each beginning with a success or error code response messages, each beginning with a success or error code
(Section 9), possibly followed by header fields containing server (Section 9), possibly followed by header fields containing server
information, resource metadata, and representation metadata information, resource metadata, and representation metadata
(Section 4), and finally a payload body (if any, Section 6.3.3). (Section 4), and finally a payload body (if any, Section 6.3.3).
A connection might be used for multiple request/response exchanges. A connection might be used for multiple request/response exchanges.
The mechanism used to correlate between request and response messages The mechanism used to correlate between request and response messages
is version dependent; some versions of HTTP use implicit ordering of is version dependent; some versions of HTTP use implicit ordering of
messages, while others use an explicit identifier. messages, while others use an explicit identifier.
Responses (both final and non-final) can be sent at any time after a Responses (both final and interim) can be sent at any time after a
request is received, even if it is not yet complete. However, request is received, even if it is not yet complete. However,
clients (including intermediaries) might abandon a request if the clients (including intermediaries) might abandon a request if the
response is not forthcoming within a reasonable period of time. response is not forthcoming within a reasonable period of time.
The following example illustrates a typical message exchange for a The following example illustrates a typical message exchange for a
GET request (Section 7.3.1) on the URI "http://www.example.com/ GET request (Section 7.3.1) on the URI "http://www.example.com/
hello.txt": hello.txt":
Client request: Client request:
skipping to change at page 13, line 20 skipping to change at page 14, line 23
client, usually via local configuration rules, to receive requests client, usually via local configuration rules, to receive requests
for some type(s) of absolute URI and attempt to satisfy those for some type(s) of absolute URI and attempt to satisfy those
requests via translation through the HTTP interface. Some requests via translation through the HTTP interface. Some
translations are minimal, such as for proxy requests for "http" URIs, translations are minimal, such as for proxy requests for "http" URIs,
whereas other requests might require translation to and from entirely whereas other requests might require translation to and from entirely
different application-level protocols. Proxies are often used to different application-level protocols. Proxies are often used to
group an organization's HTTP requests through a common intermediary group an organization's HTTP requests through a common intermediary
for the sake of security, annotation services, or shared caching. for the sake of security, annotation services, or shared caching.
Some proxies are designed to apply transformations to selected Some proxies are designed to apply transformations to selected
messages or payloads while they are being forwarded, as described in messages or payloads while they are being forwarded, as described in
Section 5.5.2. Section 5.7.2.
A "gateway" (a.k.a. "reverse proxy") is an intermediary that acts as A "gateway" (a.k.a. "reverse proxy") is an intermediary that acts as
an origin server for the outbound connection but translates received an origin server for the outbound connection but translates received
requests and forwards them inbound to another server or servers. requests and forwards them inbound to another server or servers.
Gateways are often used to encapsulate legacy or untrusted Gateways are often used to encapsulate legacy or untrusted
information services, to improve server performance through information services, to improve server performance through
"accelerator" caching, and to enable partitioning or load balancing "accelerator" caching, and to enable partitioning or load balancing
of HTTP services across multiple machines. of HTTP services across multiple machines.
All HTTP requirements applicable to an origin server also apply to All HTTP requirements applicable to an origin server also apply to
skipping to change at page 15, line 49 skipping to change at page 16, line 51
query = <query, see [RFC3986], Section 3.4> query = <query, see [RFC3986], Section 3.4>
absolute-path = 1*( "/" segment ) absolute-path = 1*( "/" segment )
partial-URI = relative-part [ "?" query ] partial-URI = relative-part [ "?" query ]
Each protocol element in HTTP that allows a URI reference will Each protocol element in HTTP that allows a URI reference will
indicate in its ABNF production whether the element allows any form indicate in its ABNF production whether the element allows any form
of reference (URI-reference), only a URI in absolute form (absolute- of reference (URI-reference), only a URI in absolute form (absolute-
URI), only the path and optional query components, or some URI), only the path and optional query components, or some
combination of the above. Unless otherwise indicated, URI references combination of the above. Unless otherwise indicated, URI references
are parsed relative to the effective request URI (Section 5.3). are parsed relative to the effective request URI (Section 5.5).
It is RECOMMENDED that all senders and recipients support, at a It is RECOMMENDED that all senders and recipients support, at a
minimum, URIs with lengths of 8000 octets in protocol elements. Note minimum, URIs with lengths of 8000 octets in protocol elements. Note
that this implies some structures and on-wire representations (for that this implies some structures and on-wire representations (for
example, the request line in HTTP/1.1) will necessarily be larger in example, the request line in HTTP/1.1) will necessarily be larger in
some cases. some cases.
2.5. Resources 2.5. Resources
The target of an HTTP request is called a "resource". HTTP does not The target of an HTTP request is called a "resource". HTTP does not
skipping to change at page 16, line 38 skipping to change at page 17, line 38
might target any URI scheme, the following schemes are inherent to might target any URI scheme, the following schemes are inherent to
HTTP servers: HTTP servers:
+------------+------------------------------------+---------------+ +------------+------------------------------------+---------------+
| URI Scheme | Description | Reference | | URI Scheme | Description | Reference |
+------------+------------------------------------+---------------+ +------------+------------------------------------+---------------+
| http | Hypertext Transfer Protocol | Section 2.5.1 | | http | Hypertext Transfer Protocol | Section 2.5.1 |
| https | Hypertext Transfer Protocol Secure | Section 2.5.2 | | https | Hypertext Transfer Protocol Secure | Section 2.5.2 |
+------------+------------------------------------+---------------+ +------------+------------------------------------+---------------+
Note that the presence of an "http" or "https" URI does not imply
that there is always an HTTP server at the identified origin
listening for connections. Anyone can mint a URI, whether or not a
server exists and whether or not that server currently maps that
identifier to a resource. The delegated nature of registered names
and IP addresses creates a federated namespace whether or not an HTTP
server is present.
2.5.1. http URI Scheme 2.5.1. http URI Scheme
The "http" URI scheme is hereby defined for the purpose of minting The "http" URI scheme is hereby defined for minting identifiers
identifiers according to their association with the hierarchical within the hierarchical namespace governed by a potential HTTP origin
namespace governed by a potential HTTP origin server listening for server listening for TCP ([RFC0793]) connections on a given port.
TCP ([RFC0793]) connections on a given port.
http-URI = "http:" "//" authority path-abempty [ "?" query ] http-URI = "http" "://" authority path-abempty [ "?" query ]
The origin server for an "http" URI is identified by the authority The origin server for an "http" URI is identified by the authority
component, which includes a host identifier and optional TCP port component, which includes a host identifier and optional port number
([RFC3986], Section 3.2.2). The hierarchical path component and ([RFC3986], Section 3.2.2). If the port subcomponent is empty or not
optional query component serve as an identifier for a potential given, TCP port 80 (the reserved port for WWW services) is the
target resource within that origin server's name space. default. The origin determines who has the right to respond
authoritatively to requests that target the identified resource, as
defined in Section 5.4.1.
A sender MUST NOT generate an "http" URI with an empty host A sender MUST NOT generate an "http" URI with an empty host
identifier. A recipient that processes such a URI reference MUST identifier. A recipient that processes such a URI reference MUST
reject it as invalid. reject it as invalid.
If the host identifier is provided as an IP address, the origin The hierarchical path component and optional query component identify
server is the listener (if any) on the indicated TCP port at that IP the target resource within that origin server's name space.
address. If host is a registered name, the registered name is an
indirect identifier for use with a name resolution service, such as
DNS, to find an address for that origin server. If the port
subcomponent is empty or not given, TCP port 80 (the reserved port
for WWW services) is the default.
Note that the presence of a URI with a given authority component does
not imply that there is always an HTTP server listening for
connections on that host and port. Anyone can mint a URI. What the
authority component determines is who has the right to respond
authoritatively to requests that target the identified resource. The
delegated nature of registered names and IP addresses creates a
federated namespace, based on control over the indicated host and
port, whether or not an HTTP server is present. See Section 13.1 for
security considerations related to establishing authority.
When an "http" URI is used within a context that calls for access to
the indicated resource, a client MAY attempt access by resolving the
host to an IP address, establishing a TCP connection to that address
on the indicated port, and sending an HTTP request message (Section 2
of [Messaging]) containing the URI's identifying data to the server.
If the server responds to that request with a non-interim HTTP
response message, as described in Section 9, then that response is
considered an authoritative answer to the client's request.
Although HTTP is independent of the transport protocol, the "http"
scheme is specific to TCP-based services because the name delegation
process depends on TCP for establishing authority. An HTTP service
based on some other underlying connection protocol would presumably
be identified using a different URI scheme, just as the "https"
scheme (below) is used for resources that require an end-to-end
secured connection. Other protocols might also be used to provide
access to "http" identified resources -- it is only the authoritative
interface that is specific to TCP.
The URI generic syntax for authority also includes a deprecated
userinfo subcomponent ([RFC3986], Section 3.2.1) for including user
authentication information in the URI. Some implementations make use
of the userinfo component for internal configuration of
authentication information, such as within command invocation
options, configuration files, or bookmark lists, even though such
usage might expose a user identifier or password. A sender MUST NOT
generate the userinfo subcomponent (and its "@" delimiter) when an
"http" URI reference is generated within a message as a request
target or header field value. Before making use of an "http" URI
reference received from an untrusted source, a recipient SHOULD parse
for userinfo and treat its presence as an error; it is likely being
used to obscure the authority for the sake of phishing attacks.
2.5.2. https URI Scheme 2.5.2. https URI Scheme
The "https" URI scheme is hereby defined for the purpose of minting The "https" URI scheme is hereby defined for minting identifiers
identifiers according to their association with the hierarchical within the hierarchical namespace governed by a potential origin
namespace governed by a potential HTTP origin server listening to a server listening for TCP connections on a given port and capable of
given TCP port for TLS-secured connections ([RFC8446]). establishing a TLS ([RFC8446]) connection that has been secured for
HTTP communication. In this context, "secured" specifically means
that the server has been authenticated as acting on behalf of the
identified authority and all HTTP communication with that server has
been protected for confidentiality and integrity through the use of
strong encryption.
All of the requirements listed above for the "http" scheme are also https-URI = "https" "://" authority path-abempty [ "?" query ]
requirements for the "https" scheme, except that TCP port 443 is the
default if the port subcomponent is empty or not given, and the user
agent MUST ensure that its connection to the origin server is secured
through the use of strong encryption, end-to-end, prior to sending
the first HTTP request.
https-URI = "https:" "//" authority path-abempty [ "?" query ] The origin server for an "https" URI is identified by the authority
component, which includes a host identifier and optional port number
([RFC3986], Section 3.2.2). If the port subcomponent is empty or not
given, TCP port 443 (the reserved port for HTTP over TLS) is the
default. The origin determines who has the right to respond
authoritatively to requests that target the identified resource, as
defined in Section 5.4.2.
Note that the "https" URI scheme depends on both TLS and TCP for A sender MUST NOT generate an "https" URI with an empty host
establishing authority. Resources made available via the "https" identifier. A recipient that processes such a URI reference MUST
scheme have no shared identity with the "http" scheme even if their reject it as invalid.
resource identifiers indicate the same authority (the same host
listening to the same TCP port). They are distinct namespaces and
are considered to be distinct origin servers. However, an extension
to HTTP that is defined to apply to entire host domains, such as the
Cookie protocol [RFC6265], can allow information set by one service
to impact communication with other services within a matching group
of host domains.
2.5.2.1. Initiating HTTP Over TLS The hierarchical path component and optional query component identify
the target resource within that origin server's name space.
Conceptually, HTTP/TLS is very simple. Simply use HTTP over TLS A client MUST ensure that its HTTP requests for an "https" resource
precisely as you would use HTTP over TCP. are secured, prior to being communicated, and that it only accepts
secured responses to those requests.
The agent acting as the HTTP client should also act as the TLS Resources made available via the "https" scheme have no shared
client. It should initiate a connection to the server on the identity with the "http" scheme. They are distinct origins with
appropriate port and then send the TLS ClientHello to begin the TLS separate namespaces. However, an extension to HTTP that is defined
handshake. When the TLS handshake has finished. The client may then to apply to all origins with the same host, such as the Cookie
initiate the first HTTP request. All HTTP data MUST be sent as TLS protocol [RFC6265], can allow information set by one service to
"application data". Normal HTTP behavior, including retained impact communication with other services within a matching group of
connections should be followed. host domains.
2.5.2.2. Identifying HTTPS Servers 2.5.3. http and https URI Normalization and Comparison
In general, HTTP/TLS requests are generated by dereferencing a URI. Since the "http" and "https" schemes conform to the URI generic
As a consequence, the hostname for the server is known to the client. syntax, such URIs are normalized and compared according to the
If the hostname is available, the client MUST check it against the algorithm defined in Section 6 of [RFC3986], using the defaults
server's identity as presented in the server's Certificate message, described above for each scheme.
in order to prevent man-in-the-middle attacks.
If the client has external information as to the expected identity of If the port is equal to the default port for a scheme, the normal
the server, the hostname check MAY be omitted. (For instance, a form is to omit the port subcomponent. When not being used in
client may be connecting to a machine whose address and hostname are absolute form as the request target of an OPTIONS request, an empty
dynamic but the client knows the certificate that the server will path component is equivalent to an absolute path of "/", so the
present.) In such cases, it is important to narrow the scope of normal form is to provide a path of "/" instead. The scheme and host
acceptable certificates as much as possible in order to prevent man are case-insensitive and normally provided in lowercase; all other
in the middle attacks. In special cases, it may be appropriate for components are compared in a case-sensitive manner. Characters other
the client to simply ignore the server's identity, but it must be than those in the "reserved" set are equivalent to their percent-
understood that this leaves the connection open to active attack. encoded octets: the normal form is to not encode them (see Sections
2.1 and 2.2 of [RFC3986]).
If a subjectAltName extension of type dNSName is present, that MUST For example, the following three URIs are equivalent:
be used as the identity. Otherwise, the (most specific) Common Name
field in the Subject field of the certificate MUST be used. Although
the use of the Common Name is existing practice, it is deprecated and
Certification Authorities are encouraged to use the dNSName instead.
Matching is performed using the matching rules specified by http://example.com:80/~smith/home.html
[RFC5280]. If more than one identity of a given type is present in http://EXAMPLE.com/%7Esmith/home.html
the certificate (e.g., more than one dNSName name, a match in any one http://EXAMPLE.com:/%7esmith/home.html
of the set is considered acceptable.) Names may contain the wildcard
character * which is considered to match any single domain name
component or component fragment. E.g., *.a.com matches foo.a.com but
not bar.foo.a.com. f*.com matches foo.com but not bar.com.
In some cases, the URI is specified as an IP address rather than a 2.5.4. Deprecated userinfo
hostname. In this case, the iPAddress subjectAltName must be present
in the certificate and must exactly match the IP in the URI.
If the hostname does not match the identity in the certificate, user The URI generic syntax for authority also includes a userinfo
oriented clients MUST either notify the user (clients MAY give the subcomponent ([RFC3986], Section 3.2.1) for including user
user the opportunity to continue with the connection in any case) or authentication information in the URI. In that subcomponent, the use
terminate the connection with a bad certificate error. Automated of the format "user:password" is deprecated.
clients MUST log the error to an appropriate audit log (if available)
and SHOULD terminate the connection (with a bad certificate error).
Automated clients MAY provide a configuration setting that disables
this check, but MUST provide a setting which enables it.
Note that in many cases the URI itself comes from an untrusted Some implementations make use of the userinfo component for internal
source. The above-described check provides no protection against configuration of authentication information, such as within command
attacks where this source is compromised. For example, if the URI invocation options, configuration files, or bookmark lists, even
was obtained by clicking on an HTML page which was itself obtained though such usage might expose a user identifier or password.
without using HTTP/TLS, a man in the middle could have replaced the
URI. In order to prevent this form of attack, users should carefully
examine the certificate presented by the server to determine if it
meets their expectations.
2.5.2.3. Identifying HTTPS Clients A sender MUST NOT generate the userinfo subcomponent (and its "@"
delimiter) when an "http" or "https" URI reference is generated
within a message as a request target or field value.
Typically, the server has no external knowledge of what the client's Before making use of an "http" or "https" URI reference received from
identity ought to be and so checks (other than that the client has a an untrusted source, a recipient SHOULD parse for userinfo and treat
certificate chain rooted in an appropriate CA) are not possible. If its presence as an error; it is likely being used to obscure the
a server has such knowledge (typically from some source external to authority for the sake of phishing attacks.
HTTP or TLS) it SHOULD check the identity as described above.
2.5.3. Fragment Identifiers on http(s) URI References 2.5.5. Fragment Identifiers on http(s) URI References
Fragment identifiers allow for indirect identification of a secondary Fragment identifiers allow for indirect identification of a secondary
resource, independent of the URI scheme, as defined in Section 3.5 of resource, independent of the URI scheme, as defined in Section 3.5 of
[RFC3986]. Some protocol elements that refer to a URI allow [RFC3986]. Some protocol elements that refer to a URI allow
inclusion of a fragment, while others do not. They are distinguished inclusion of a fragment, while others do not. They are distinguished
by use of the ABNF rule for elements where fragment is allowed; by use of the ABNF rule for elements where fragment is allowed;
otherwise, a specific rule that excludes fragments is used (see otherwise, a specific rule that excludes fragments is used (see
Section 5.1). Section 5.1).
Note: the fragment identifier component is not part of the actual Note: the fragment identifier component is not part of the actual
scheme definition for a URI scheme (see Section 4.3 of [RFC3986]), scheme definition for a URI scheme (see Section 4.3 of [RFC3986]),
thus does not appear in the ABNF definitions for the "http" and thus does not appear in the ABNF definitions for the "http" and
"https" URI schemes above. "https" URI schemes above.
2.5.4. http and https URI Normalization and Comparison
Since the "http" and "https" schemes conform to the URI generic
syntax, such URIs are normalized and compared according to the
algorithm defined in Section 6 of [RFC3986], using the defaults
described above for each scheme.
If the port is equal to the default port for a scheme, the normal
form is to omit the port subcomponent. When not being used in
absolute form as the request target of an OPTIONS request, an empty
path component is equivalent to an absolute path of "/", so the
normal form is to provide a path of "/" instead. The scheme and host
are case-insensitive and normally provided in lowercase; all other
components are compared in a case-sensitive manner. Characters other
than those in the "reserved" set are equivalent to their percent-
encoded octets: the normal form is to not encode them (see Sections
2.1 and 2.2 of [RFC3986]).
For example, the following three URIs are equivalent:
http://example.com:80/~smith/home.html
http://EXAMPLE.com/%7Esmith/home.html
http://EXAMPLE.com:/%7esmith/home.html
3. Conformance 3. Conformance
3.1. Implementation Diversity 3.1. Implementation Diversity
When considering the design of HTTP, it is easy to fall into a trap When considering the design of HTTP, it is easy to fall into a trap
of thinking that all user agents are general-purpose browsers and all of thinking that all user agents are general-purpose browsers and all
origin servers are large public websites. That is not the case in origin servers are large public websites. That is not the case in
practice. Common HTTP user agents include household appliances, practice. Common HTTP user agents include household appliances,
stereos, scales, firmware update scripts, command-line programs, stereos, scales, firmware update scripts, command-line programs,
mobile apps, and communication devices in a multitude of shapes and mobile apps, and communication devices in a multitude of shapes and
skipping to change at page 22, line 30 skipping to change at page 21, line 46
allowed to be generated by participants in other roles (i.e., a role allowed to be generated by participants in other roles (i.e., a role
that the sender does not have for that message). that the sender does not have for that message).
3.3. Parsing Elements 3.3. Parsing Elements
When a received protocol element is parsed, the recipient MUST be When a received protocol element is parsed, the recipient MUST be
able to parse any value of reasonable length that is applicable to able to parse any value of reasonable length that is applicable to
the recipient's role and that matches the grammar defined by the the recipient's role and that matches the grammar defined by the
corresponding ABNF rules. Note, however, that some received protocol corresponding ABNF rules. Note, however, that some received protocol
elements might not be parsed. For example, an intermediary elements might not be parsed. For example, an intermediary
forwarding a message might parse a header-field into generic field- forwarding a message might parse a field into generic field name and
name and field-value components, but then forward the header field field value components, but then forward the field without further
without further parsing inside the field-value. parsing inside the field value.
HTTP does not have specific length limitations for many of its HTTP does not have specific length limitations for many of its
protocol elements because the lengths that might be appropriate will protocol elements because the lengths that might be appropriate will
vary widely, depending on the deployment context and purpose of the vary widely, depending on the deployment context and purpose of the
implementation. Hence, interoperability between senders and implementation. Hence, interoperability between senders and
recipients depends on shared expectations regarding what is a recipients depends on shared expectations regarding what is a
reasonable length for each protocol element. Furthermore, what is reasonable length for each protocol element. Furthermore, what is
commonly understood to be a reasonable length for some protocol commonly understood to be a reasonable length for some protocol
elements has changed over the course of the past two decades of HTTP elements has changed over the course of the past two decades of HTTP
use and is expected to continue changing in the future. use and is expected to continue changing in the future.
skipping to change at page 24, line 41 skipping to change at page 24, line 7
message with a higher minor version, when sent to a recipient that message with a higher minor version, when sent to a recipient that
has not yet indicated support for that higher version, is has not yet indicated support for that higher version, is
sufficiently backwards-compatible to be safely processed by any sufficiently backwards-compatible to be safely processed by any
implementation of the same major version. implementation of the same major version.
When a major version of HTTP does not define any minor versions, the When a major version of HTTP does not define any minor versions, the
minor version "0" is implied and is used when referring to that minor version "0" is implied and is used when referring to that
protocol within a protocol element that requires sending a minor protocol within a protocol element that requires sending a minor
version. version.
4. Header Fields 4. Header and Trailer Fields
This section defines the abstraction for message fields as field-name HTTP messages use key/value pairs to convey data about the message,
and field-value pairs. its payload, the target resource, or the connection (i.e., control
data). They are called "HTTP fields" or just "fields".
4.1. Header Field Names Every message can have two separate areas that such fields can occur
within; the "header field section" (or just "header section")
preceding the message body and containing "header fields" (or just
"headers", colloquially) and the "trailer field section" (or just
"trailer section") after the message body containing "trailer fields"
(or just "trailers" colloquially). Header fields are more common;
see Section 4.6 for discussion of the applicability and limitations
of trailer fields.
Header fields are key:value pairs that can be used to communicate Both sections are composed of any number of "field lines", each with
data about the message, its payload, the target resource, or the a "field name" (see Section 4.3) identifying the field, and a "field
connection (i.e., control data). line value" that conveys data for the field.
The requirements for header field names are defined in [BCP90]. Each field name present in a section has a corresponding "field
value" for that section, composed from all field line values with
that given field name in that section, concatenated together and
separated with commas. See Section 4.1 for further discussion of the
semantics of field ordering and combination in messages, and
Section 4.4 for more discussion of field values.
The field-name token labels the corresponding field-value as having For example, this section:
the semantics defined by that header field. For example, the Date
header field is defined in Section 10.1.1.2 as containing the Example-Field: Foo, Bar
origination timestamp for the message in which it appears. Example-Field: Baz
contains two field lines, both with the field name "Example-Field".
The first field line has a field line value of "Foo, Bar", while the
second field line value is "Baz". The field value for "Example-
Field" is a list with three members: "Foo", "Bar", and "Baz".
The interpretation of a field does not change between minor versions
of the same major HTTP version, though the default behavior of a
recipient in the absence of such a field can change. Unless
specified otherwise, fields are defined for all versions of HTTP. In
particular, the Host and Connection fields ought to be implemented by
all HTTP/1.x implementations whether or not they advertise
conformance with HTTP/1.1.
New fields can be introduced without changing the protocol version if
their defined semantics allow them to be safely ignored by recipients
that do not recognize them; see Section 4.3.1.
4.1. Field Ordering and Combination
The order in which field lines with differing names are received in a
message is not significant. However, it is good practice to send
header fields that contain control data first, such as Host on
requests and Date on responses, so that implementations can decide
when not to handle a message as early as possible. A server MUST NOT
apply a request to the target resource until the entire request
header section is received, since later header field lines might
include conditionals, authentication credentials, or deliberately
misleading duplicate header fields that would impact request
processing.
A recipient MAY combine multiple field lines with the same field name
into one field line, without changing the semantics of the message,
by appending each subsequent field line value to the initial field
line value in order, separated by a comma and optional whitespace.
For consistency, use comma SP.
The order in which field lines with the same name are received is
therefore significant to the interpretation of the field value; a
proxy MUST NOT change the order of these field line values when
forwarding a message.
This means that, aside from the well-known exception noted below, a
sender MUST NOT generate multiple field lines with the same name in a
message (whether in the headers or trailers), or append a field line
when a field line of the same name already exists in the message,
unless that field's definition allows multiple field line values to
be recombined as a comma-separated list [i.e., at least one
alternative of the field's definition allows a comma-separated list,
such as an ABNF rule of #(values) defined in Section 4.5].
Note: In practice, the "Set-Cookie" header field ([RFC6265]) often
appears in a response message across multiple field and does not
use the list syntax, violating the above requirements on multiple
field lines with the same field name. Since it cannot be combined
into a single field value, recipients ought to handle "Set-Cookie"
as a special case while processing fields. (See Appendix A.2.3 of
[Kri2001] for details.)
4.2. Field Limits
HTTP does not place a predefined limit on the length of each field
line, field value, or on the length of the header or trailer section
as a whole, as described in Section 3. Various ad hoc limitations on
individual lengths are found in practice, often depending on the
specific field's semantics.
A server that receives a request header field line, field value, or
set of fields larger than it wishes to process MUST respond with an
appropriate 4xx (Client Error) status code. Ignoring such header
fields would increase the server's vulnerability to request smuggling
attacks (Section 11.2 of [Messaging]).
A client MAY discard or truncate received field lines that are larger
than the client wishes to process if the field semantics are such
that the dropped value(s) can be safely ignored without changing the
message framing or response semantics.
4.3. Field Names
The field-name token labels the corresponding field value as having
the semantics defined by that field. For example, the Date header
field is defined in Section 10.1.1.2 as containing the origination
timestamp for the message in which it appears.
field-name = token field-name = token
The interpretation of a header field does not change between minor Field names are case-insensitive and ought to be registered within
versions of the same major HTTP version, though the default behavior the "Hypertext Transfer Protocol (HTTP) Field Name Registry"; see
of a recipient in the absence of such a field can change. Unless Section 4.3.2.
specified otherwise, header fields are defined for all versions of
HTTP. In particular, the Host and Connection header fields ought to
be implemented by all HTTP/1.x implementations whether or not they
advertise conformance with HTTP/1.1.
New header fields can be introduced without changing the protocol Authors of specifications defining new fields are advised to choose a
version if their defined semantics allow them to be safely ignored by short but descriptive field name. Short names avoid needless data
recipients that do not recognize them. Header field extensibility is transmission; descriptive names avoid confusion and "squatting" on
discussed in Section 4.1.2. names that might have broader uses.
The following field names are defined by this document: To that end, limited-use fields (such as a header confined to a
single application or use case) are encouraged to use a name that
includes its name (or an abbreviation) as a prefix; for example, if
the Foo Application needs a Description field, it might use "Foo-
Desc"; "Description" is too generic, and "Foo-Description" is
needlessly long.
+---------------------------+------------+-------------------+ While the field-name syntax is defined to allow any token character,
| Header Field Name | Status | Reference | in practice some implementations place limits on the characters they
+---------------------------+------------+-------------------+ accept in field-names. To be interoperable, new field names SHOULD
| Accept | standard | Section 8.4.2 | constrain themselves to alphanumeric characters, "-", and ".", and
| Accept-Charset | deprecated | Section 8.4.3 | SHOULD begin with an alphanumeric character.
| Accept-Encoding | standard | Section 8.4.4 |
| Accept-Language | standard | Section 8.4.5 |
| Accept-Ranges | standard | Section 10.4.1 |
| Allow | standard | Section 10.4.2 |
| Authentication-Info | standard | Section 10.3.3 |
| Authorization | standard | Section 8.5.3 |
| Content-Encoding | standard | Section 6.2.2 |
| Content-Language | standard | Section 6.2.3 |
| Content-Length | standard | Section 6.2.4 |
| Content-Location | standard | Section 6.2.5 |
| Content-Range | standard | Section 6.3.4 |
| Content-Type | standard | Section 6.2.1 |
| Date | standard | Section 10.1.1.2 |
| ETag | standard | Section 10.2.3 |
| Expect | standard | Section 8.1.1 |
| From | standard | Section 8.6.1 |
| Host | standard | Section 5.4 |
| If-Match | standard | Section 8.2.3 |
| If-Modified-Since | standard | Section 8.2.5 |
| If-None-Match | standard | Section 8.2.4 |
| If-Range | standard | Section 8.2.7 |
| If-Unmodified-Since | standard | Section 8.2.6 |
| Last-Modified | standard | Section 10.2.2 |
| Location | standard | Section 10.1.2 |
| Max-Forwards | standard | Section 8.1.2 |
| Proxy-Authenticate | standard | Section 10.3.2 |
| Proxy-Authentication-Info | standard | Section 10.3.4 |
| Proxy-Authorization | standard | Section 8.5.4 |
| Range | standard | Section 8.3 |
| Referer | standard | Section 8.6.2 |
| Retry-After | standard | Section 10.1.3 |
| Server | standard | Section 10.4.3 |
| Trailer | standard | Section 4.3.3 |
| User-Agent | standard | Section 8.6.3 |
| Vary | standard | Section 10.1.4 |
| Via | standard | Section 5.5.1 |
| WWW-Authenticate | standard | Section 10.3.1 |
+---------------------------+------------+-------------------+
Table 1 Field names ought not be prefixed with "X-"; see [BCP178] for further
information.
4.1.1. Header Field Name Registry Other prefixes are sometimes used in HTTP field names; for example,
"Accept-" is used in many content negotiation headers. These
prefixes are only an aid to recognizing the purpose of a field, and
do not trigger automatic processing.
The "Hypertext Transfer Protocol (HTTP) Header Field Registry" 4.3.1. Field Extensibility
defines the namespace for HTTP header field names.
Any party can request registration of a HTTP header field. See There is no limit on the introduction of new field names, each
Section 4.4 for considerations to take into account when creating a presumably defining new semantics.
new HTTP header field.
The "HTTP Header Field Name" registry is located at New fields can be defined such that, when they are understood by a
"https://www.iana.org/assignments/http-headers/". Registration recipient, they might override or enhance the interpretation of
requests can be made by following the instructions located there or previously defined fields, define preconditions on request
by sending an email to the "ietf-http-wg@ietf.org" mailing list. evaluation, or refine the meaning of responses.
Header field names are registered on the advice of a Designated A proxy MUST forward unrecognized header fields unless the field name
Expert (appointed by the IESG or their delegate). Header fields with is listed in the Connection header field (Section 9.1 of [Messaging])
the status 'permanent' are Specification Required (using terminology or the proxy is specifically configured to block, or otherwise
from [RFC8126]). transform, such fields. Other recipients SHOULD ignore unrecognized
header and trailer fields. These requirements allow HTTP's
functionality to be enhanced without requiring prior update of
deployed intermediaries.
4.3.2. Field Name Registry
The "Hypertext Transfer Protocol (HTTP) Field Name Registry" defines
the namespace for HTTP field names.
Any party can request registration of a HTTP field. See Section 4.7
for considerations to take into account when creating a new HTTP
field.
The "Hypertext Transfer Protocol (HTTP) Field Name Registry" is
located at "https://www.iana.org/assignments/http-fields/".
Registration requests can be made by following the instructions
located there or by sending an email to the "ietf-http-wg@ietf.org"
mailing list.
Field names are registered on the advice of a Designated Expert
(appointed by the IESG or their delegate). Fields with the status
'permanent' are Specification Required (using terminology from
[RFC8126]).
Registration requests consist of at least the following information: Registration requests consist of at least the following information:
o Header field name: The requested field name. It MUST conform to o Field name: The requested field name. It MUST conform to the
the field-name syntax defined in Section 4.1, and SHOULD be field-name syntax defined in Section 4.3, and SHOULD be restricted
restricted to just letters, digits, hyphen ('-') and underscore to just letters, digits, hyphen ('-') and underscore ('_')
('_') characters, with the first character being a letter. characters, with the first character being a letter.
o Status: "permanent" or "provisional" o Status: "permanent" or "provisional"
o Specification document(s): Reference to the document that o Specification document(s): Reference to the document that
specifies the header field, preferably including a URI that can be specifies the field, preferably including a URI that can be used
used to retrieve a copy of the document. An indication of the to retrieve a copy of the document. An indication of the relevant
relevant section(s) can also be included, but is not required. section(s) can also be included, but is not required.
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
are in use, in consultation with the community. Other names should are in use, in consultation with the community. Other names should
be registered as "provisional". be registered as "provisional".
Provisional entries can be removed by the Expert(s) if -- in Provisional entries can be removed by the Expert(s) if -- in
consultation with the community -- the Expert(s) find that they are consultation with the community -- the Expert(s) find that they are
not in use. The Experts can change a provisional entry's status to not in use. The Experts can change a provisional entry's status to
permanent at any time. permanent at any time.
Note that names can be registered by third parties (including the Note that names can be registered by third parties (including the
Expert(s)), if the Expert(s) determines that an unregistered name is Expert(s)), if the Expert(s) determines that an unregistered name is
widely deployed and not likely to be registered in a timely manner widely deployed and not likely to be registered in a timely manner
otherwise. otherwise.
4.1.2. Header Field Extensibility 4.4. Field Values
Header fields are fully extensible: there is no limit on the
introduction of new field names, each presumably defining new
semantics, nor on the number of header fields used in a given
message. Existing fields are defined in each part of this
specification and in many other specifications outside this document
set.
New header fields can be defined such that, when they are understood
by a recipient, they might override or enhance the interpretation of
previously defined header fields, define preconditions on request
evaluation, or refine the meaning of responses.
A proxy MUST forward unrecognized header fields unless the field-name
is listed in the Connection header field (Section 9.1 of [Messaging])
or the proxy is specifically configured to block, or otherwise
transform, such fields. Other recipients SHOULD ignore unrecognized
header fields. These requirements allow HTTP's functionality to be
enhanced without requiring prior update of deployed intermediaries.
All defined header fields ought to be registered with IANA in the
"HTTP Header Field Name" registry.
4.2. Header Field Values
This specification does not use ABNF rules to define each "Field- HTTP field values typically have their syntax defined using ABNF
Name: Field Value" pair, as was done in earlier editions. Instead, ([RFC5234]), using the extension defined in Section 4.5 as necessary,
this specification uses ABNF rules that are named according to each and are usually constrained to the range of US-ASCII characters.
registered field name, wherein the rule defines the valid grammar for Fields needing a greater range of characters can use an encoding such
that field's corresponding field values (i.e., after the field-value as the one defined in [RFC8187].
has been extracted by a generic field parser).
field-value = *( field-content / obs-fold ) field-value = *( field-content / obs-fold )
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
Historically, HTTP header field values could be extended over Historically, HTTP allowed field content with text in the ISO-8859-1
multiple lines by preceding each extra line with at least one space charset [ISO-8859-1], supporting other charsets only through use of
or horizontal tab (obs-fold). [[CREF1: This document assumes that [RFC2047] encoding. In practice, most HTTP field values use only a
any such obs-fold has been replaced with one or more SP octets prior subset of the US-ASCII charset [USASCII]. Newly defined fields
to interpreting the field value, as described in Section 5.2 of SHOULD limit their values to US-ASCII octets. A recipient SHOULD
[Messaging].]] treat other octets in field content (obs-text) as opaque data.
Historically, HTTP has allowed field content with text in the
ISO-8859-1 charset [ISO-8859-1], supporting other charsets only
through use of [RFC2047] encoding. In practice, most HTTP header
field values use only a subset of the US-ASCII charset [USASCII].
Newly defined header fields SHOULD limit their field values to
US-ASCII octets. A recipient SHOULD treat other octets in field
content (obs-text) as opaque data.
4.2.1. Header Field Order
The order in which header fields with differing field names are Leading and trailing whitespace in raw field values is removed upon
received is not significant. However, it is good practice to send field parsing (Section 5.1 of [Messaging]). Field definitions where
header fields that contain control data first, such as Host on leading or trailing whitespace in values is significant will have to
requests and Date on responses, so that implementations can decide use a container syntax such as quoted-string (Section 4.4.1.2).
when not to handle a message as early as possible. A server MUST NOT
apply a request to the target resource until the entire request
header section is received, since later header fields might include
conditionals, authentication credentials, or deliberately misleading
duplicate header fields that would impact request processing.
Aside from the well-known exception noted below, a sender MUST NOT Because commas (",") are used as a generic delimiter between members
generate multiple header fields with the same field name in a of a list-based field value, they need to be treated with care if
message, or append a header field when a field of the same name they are allowed as data within those members. Typically, list
already exists in the message, unless that field's definition allows members that might contain a comma are enclosed in a quoted-string.
multiple field values to be recombined as a comma-separated list
[i.e., at least one alternative of the field's definition allows a
comma-separated list, such as an ABNF rule of #(values)].
A recipient MAY combine multiple header fields with the same field For example, a textual date and a URI (either of which might contain
name into one "field-name: field-value" pair, without changing the a comma) could be safely carried in list-based field values like
semantics of the message, by appending each subsequent field value to these:
the combined field value in order, separated by a comma. The order
in which header fields with the same field name are received is
therefore significant to the interpretation of the combined field
value; a proxy MUST NOT change the order of these field values when
forwarding a message.
Note: In practice, the "Set-Cookie" header field ([RFC6265]) often Example-URI-Field: "http://example.com/a.html,foo",
appears multiple times in a response message and does not use the "http://without-a-comma.example.com/"
list syntax, violating the above requirements on multiple header Example-Date-Field: "Sat, 04 May 1996", "Wed, 14 Sep 2005"
fields with the same name. Since it cannot be combined into a
single field-value, recipients ought to handle "Set-Cookie" as a
special case while processing header fields. (See Appendix A.2.3
of [Kri2001] for details.)
4.2.2. Header Field Limits Note that double-quote delimiters almost always are used with the
quoted-string production; using a different syntax inside double-
quotes will likely cause unnecessary confusion.
HTTP does not place a predefined limit on the length of each header Many fields (such as Content-Type, defined in Section 6.2.1) use a
field or on the length of the header section as a whole, as described common syntax for parameters that allows both unquoted (token) and
in Section 3. Various ad hoc limitations on individual header field quoted (quoted-string) syntax for a parameter value
length are found in practice, often depending on the specific field (Section 4.4.1.4). Use of common syntax allows recipients to reuse
semantics. existing parser 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 quoted string.
A server that receives a request header field, or set of fields, Historically, HTTP field values could be extended over multiple lines
larger than it wishes to process MUST respond with an appropriate 4xx by preceding each extra line with at least one space or horizontal
(Client Error) status code. Ignoring such header fields would tab (obs-fold). [[CREF1: This document assumes that any such obs-
increase the server's vulnerability to request smuggling attacks fold has been replaced with one or more SP octets prior to
(Section 11.2 of [Messaging]). interpreting the field value, as described in Section 5.2 of
[Messaging].]]
A client MAY discard or truncate received header fields that are This specification does not use ABNF rules to define each "Field
larger than the client wishes to process if the field semantics are Name: Field Value" pair, as was done in earlier editions.
such that the dropped value(s) can be safely ignored without changing Instead, this specification uses ABNF rules that are named
the message framing or response semantics. according to each registered field name, wherein the rule defines
the valid grammar for that field's corresponding field values
(i.e., after the field value has been extracted by a generic field
parser).
4.2.3. Header Field Value Components 4.4.1. Common Field Value Components
Many HTTP header field values are defined using common syntax Many HTTP field values are defined using common syntax components,
components, separated by whitespace or specific delimiting separated by whitespace or specific delimiting characters.
characters. Delimiters are chosen from the set of US-ASCII visual Delimiters are chosen from the set of US-ASCII visual characters not
characters not allowed in a token (DQUOTE and "(),/:;<=>?@[\]{}"). allowed in a token (DQUOTE and "(),/:;<=>?@[\]{}").
4.2.3.1. Tokens 4.4.1.1. Tokens
Tokens are short textual identifiers that do not include whitespace Tokens are short textual identifiers that do not include whitespace
or delimiters. or delimiters.
token = 1*tchar token = 1*tchar
tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*"
/ "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
/ DIGIT / ALPHA / DIGIT / ALPHA
; any VCHAR, except delimiters ; any VCHAR, except delimiters
4.2.3.2. Quoted Strings 4.4.1.2. 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 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
skipping to change at page 31, line 18 skipping to change at page 30, line 46
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
that string. A sender SHOULD NOT generate a quoted-pair in a comment that string. A sender SHOULD NOT generate a quoted-pair in a comment
except where necessary to quote parentheses ["(" and ")"] and except where necessary to quote parentheses ["(" and ")"] and
backslash octets occurring within that comment. backslash octets occurring within that comment.
4.2.3.3. Comments 4.4.1.3. Comments
Comments can be included in some HTTP header fields by surrounding Comments can be included in some HTTP fields by surrounding the
the comment text with parentheses. Comments are only allowed in comment text with parentheses. Comments are only allowed in fields
fields containing "comment" as part of their field value definition. containing "comment" as part of their field value definition.
comment = "(" *( ctext / quoted-pair / comment ) ")" comment = "(" *( ctext / quoted-pair / comment ) ")"
ctext = HTAB / SP / %x21-27 / %x2A-5B / %x5D-7E / obs-text ctext = HTAB / SP / %x21-27 / %x2A-5B / %x5D-7E / obs-text
4.2.3.4. Parameters 4.4.1.4. Parameters
A parameter is a name=value pair that is often defined within header A parameter is a name=value pair that is often defined within field
field values as a common syntax for appending auxiliary information values as a common syntax for appending auxiliary information to an
to an item. Each parameter is usually delimited by an immediately item. Each parameter is usually delimited by an immediately
preceding semicolon. preceding semicolon.
parameter = parameter-name "=" parameter-value parameter = parameter-name "=" parameter-value
parameter-name = token parameter-name = token
parameter-value = ( token / quoted-string ) parameter-value = ( token / quoted-string )
Parameter names are case-insensitive. Parameter values might or Parameter names are case-insensitive. Parameter values might or
might not be case-sensitive, depending on the semantics of the might not be case-sensitive, depending on the semantics of the
parameter name. Examples of parameters and some equivalent forms can parameter name. Examples of parameters and some equivalent forms can
be seen in media types (Section 6.1.1) and the Accept header field be seen in media types (Section 6.1.1) and the Accept header field
(Section 8.4.2). (Section 8.4.2).
A parameter value that matches the token production can be A parameter value that matches the token production can be
transmitted either as a token or within a quoted-string. The quoted transmitted either as a token or within a quoted-string. The quoted
and unquoted values are equivalent. and unquoted values are equivalent.
Note: Parameters do not allow whitespace (not even "bad" Note: Parameters do not allow whitespace (not even "bad"
whitespace) around the "=" character. whitespace) around the "=" character.
4.3. Trailer Fields 4.5. ABNF List Extension: #rule
4.3.1. Purpose A #rule extension to the ABNF rules of [RFC5234] is used to improve
readability in the definitions of some list-based field values.
A construct "#" is defined, similar to "*", for defining comma-
delimited lists of elements. The full form is "<n>#<m>element"
indicating at least <n> and at most <m> elements, each separated by a
single comma (",") and optional whitespace (OWS).
4.5.1. Sender Requirements
In any production that uses the list construct, a sender MUST NOT
generate empty list elements. In other words, a sender MUST generate
lists that satisfy the following syntax:
1#element => element *( OWS "," OWS element )
and:
#element => [ 1#element ]
and for n >= 1 and m > 1:
<n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element )
4.5.2. Recipient Requirements
Empty elements do not contribute to the count of elements present. A
recipient MUST parse and ignore a reasonable number of empty list
elements: enough to handle common mistakes by senders that merge
values, but not so much that they could be used as a denial-of-
service mechanism. In other words, a recipient MUST accept lists
that satisfy the following syntax:
#element => [ element ] *( OWS "," OWS [ element ] )
Note that because of the potential presence of empty list elements,
the RFC 5234 ABNF cannot enforce the cardinality of list elements,
and consequently all cases are mapped is if there was no cardinality
specified.
For example, given these ABNF productions:
example-list = 1#example-list-elmt
example-list-elmt = token ; see Section 4.4.1.1
Then the following are valid values for example-list (not including
the double quotes, which are present for delimitation only):
"foo,bar"
"foo ,bar,"
"foo , ,bar,charlie"
In contrast, the following values would be invalid, since at least
one non-empty element is required by the example-list production:
""
","
", ,"
Appendix A shows the collected ABNF for recipients after the list
constructs have been expanded.
4.6. Trailer Fields
4.6.1. Purpose
In some HTTP versions, additional metadata can be sent after the In some HTTP versions, additional metadata can be sent after the
initial header section has been completed (during or after initial header section has been completed (during or after
transmission of the payload body), such as a message integrity check, transmission of the payload body), such as a message integrity check,
digital signature, or post-processing status. For example, the digital signature, or post-processing status. For example, the
chunked coding in HTTP/1.1 allows a trailer section after the payload chunked coding in HTTP/1.1 allows a trailer section after the payload
body (Section 7.1.2 of [Messaging]) which can contain trailer fields: body (Section 7.1.2 of [Messaging]) which can contain trailer fields:
field names and values that share the same syntax and namespace as field names and values that share the same syntax and namespace as
header fields but are received after the header section. header fields but that are received after the header section.
Trailer fields ought to be processed and stored separately from the Trailer fields ought to be processed and stored separately from the
fields in the header section to avoid contradicting message semantics fields in the header section to avoid contradicting message semantics
known at the time the header section was complete. The presence or known at the time the header section was complete. The presence or
absence of certain header fields might impact choices made for the absence of certain header fields might impact choices made for the
routing or processing of the message as a whole before the trailers routing or processing of the message as a whole before the trailers
are received; those choices cannot be unmade by the later discovery are received; those choices cannot be unmade by the later discovery
of trailer fields. of trailer fields.
4.3.2. Limitations 4.6.2. Limitations
Many header fields cannot be processed outside the header section Many fields cannot be processed outside the header section because
because their evaluation is necessary prior to receiving the message their evaluation is necessary prior to receiving the message body,
body, such as fields that describe message framing, routing, such as those that describe message framing, routing, authentication,
authentication, request modifiers, response controls, or payload request modifiers, response controls, or payload format. A sender
format. A sender MUST NOT generate a trailer field unless the sender MUST NOT generate a trailer field unless the sender knows the
knows the corresponding header field name's definition permits the corresponding header field name's definition permits the field to be
field to be sent in trailers. sent in trailers.
Trailer fields can be difficult to process by intermediaries that Trailer fields can be difficult to process by intermediaries that
forward messages from one protocol version to another. If the entire forward messages from one protocol version to another. If the entire
message can be buffered in transit, some intermediaries could merge message can be buffered in transit, some intermediaries could merge
trailer fields into the header section (as appropriate) before it is trailer fields into the header section (as appropriate) before it is
forwarded. However, in most cases, the trailers are simply forwarded. However, in most cases, the trailers are simply
discarded. A recipient MUST NOT merge a trailer field into a header discarded. A recipient MUST NOT merge a trailer field into a header
section unless the recipient understands the corresponding header section unless the recipient understands the corresponding header
field definition and that definition explicitly permits and defines field definition and that definition explicitly permits and defines
how trailer field values can be safely merged. how trailer field values can be safely merged.
A client can send a TE header field indicating "trailers" is A client can send a TE header field indicating "trailers" is
acceptable, as described in Section 7.4 of [Messaging], to inform the acceptable, as described in Section 7.4 of [Messaging], to inform the
server that it will not discard trailer fields. server that it will not discard trailer fields.
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.
4.3.3. Trailer 4.6.3. Trailer
The "Trailer" header field provides a list of field names that the The "Trailer" header field provides a list of field names that the
sender anticipates sending as trailer fields within that message. sender anticipates sending as trailer fields within that message.
This allows a recipient to prepare for receipt of the indicated This allows a recipient to prepare for receipt of the indicated
metadata before it starts processing the body. metadata before it starts processing the body.
Trailer = 1#field-name Trailer = 1#field-name
For example, a sender might indicate that a message integrity check For example, a sender might indicate that a message integrity check
will be computed as the payload is being streamed and provide the will be computed as the payload is being streamed and provide the
final signature as a trailer field. This allows a recipient to final signature as a trailer field. This allows a recipient to
perform the same check on the fly as the payload data is received. perform the same check on the fly as the payload data is received.
A sender that intends to generate one or more trailer fields in a A sender that intends to generate one or more trailer fields in a
message SHOULD generate a Trailer header field in the header section message SHOULD generate a Trailer header field in the header section
of that message to indicate which fields might be present in the of that message to indicate which fields might be present in the
trailers. trailers.
4.4. Considerations for New Header Fields 4.7. Considerations for New HTTP Fields
Authors of specifications defining new fields are advised to choose a
short but descriptive field name. Short names avoid needless data
transmission; descriptive names avoid confusion and "squatting" on
names that might have broader uses.
To that end, limited-use fields (such as a header confined to a
single application or use case) are encouraged to use a name that
includes its name (or an abbreviation) as a prefix; for example, if
the Foo Application needs a Description field, it might use "Foo-
Desc"; "Description" is too generic, and "Foo-Description" is
needlessly long.
Header field names ought not be prefixed with "X-"; see [BCP178] for
further information.
Other prefixes are sometimes used in HTTP header field names; for
example, "Accept-" is used in many content negotiation headers.
These prefixes are only an aid to recognizing the purpose of a header
field, and do not trigger automatic processing.
Header field values typically have their syntax defined using ABNF
([RFC5234]), using the extension defined in Section 12 as necessary,
and are usually constrained to the range of US-ASCII characters.
Header fields needing a greater range of characters can use an
encoding such as the one defined in [RFC8187].
Leading and trailing whitespace in raw field values is removed upon
field parsing (Section 5.1 of [Messaging]). Field definitions where
leading or trailing whitespace in values is significant will have to
use a container syntax such as quoted-string (Section 4.2.3.2).
Because commas (",") are used as a generic delimiter between field-
values, they need to be treated with care if they are allowed in the
field-value. Typically, components that might contain a comma are
protected with double-quotes using the quoted-string ABNF production.
For example, a textual date and a URI (either of which might contain
a comma) could be safely carried in field-values like these:
Example-URI-Field: "http://example.com/a.html,foo",
"http://without-a-comma.example.com/"
Example-Date-Field: "Sat, 04 May 1996", "Wed, 14 Sep 2005"
Note that double-quote delimiters almost always are used with the
quoted-string production; using a different syntax inside double-
quotes will likely cause unnecessary confusion.
Many header fields (such as Content-Type, defined in Section 6.2.1) See Section 4.3 for a general requirements for field names, and
use a common syntax for parameters that allows both unquoted (token) Section 4.4 for a discussion of field values.
and quoted (quoted-string) syntax for a parameter value
(Section 4.2.3.4). Use of common syntax allows recipients to reuse
existing parser 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 quoted string.
Authors of specifications defining new header fields are advised to Authors of specifications defining new fields are advised to consider
consider documenting: documenting:
o Whether the field is a single value or whether it can be a list o Whether the field is a single value or whether it can be a list
(delimited by commas; see Section 4.2). (delimited by commas; see Section 4.4).
If it does not use the list syntax, document how to treat messages If it is not a list, document how to treat messages where the
where the field occurs multiple times (a sensible default would be field occurs multiple times (a sensible default would be to ignore
to ignore the field, but this might not always be the right the field, but this might not always be the right choice).
choice).
Note that intermediaries and software libraries might combine Note that intermediaries and software libraries might combine
multiple header field instances into a single one, despite the multiple field instances into a single one, despite the field's
field's definition not allowing the list syntax. A robust format definition not allowing the list syntax. A robust format enables
enables recipients to discover these situations (good example: recipients to discover these situations (good example: "Content-
"Content-Type", as the comma can only appear inside quoted Type", as the comma can only appear inside quoted strings; bad
strings; bad example: "Location", as a comma can occur inside a example: "Location", as a comma can occur inside a URI).
URI).
o Under what conditions the header field can be used; e.g., only in o Under what conditions the field can be used; e.g., only in
responses or requests, in all messages, only on responses to a responses or requests, in all messages, only on responses to a
particular request method, etc. particular request method, etc.
o Whether the field should be stored by origin servers that o Whether the field should be stored by origin servers that
understand it upon a PUT request. understand it upon a PUT request.
o Whether the field semantics are further refined by the context, o Whether the field semantics are further refined by the context,
such as by existing request methods or status codes. such as by existing request methods or status codes.
o Whether it is appropriate to list the field-name in the Connection o Whether it is appropriate to list the field name in the Connection
header field (i.e., if the header field is to be hop-by-hop; see header field (i.e., if the field is to be hop-by-hop; see
Section 9.1 of [Messaging]). Section 9.1 of [Messaging]).
o Under what conditions intermediaries are allowed to insert, o Under what conditions intermediaries are allowed to insert,
delete, or modify the field's value. delete, or modify the field's value.
o Whether it is appropriate to list the field-name in a Vary o Whether it is appropriate to list the field name in a Vary
response header field (e.g., when the request header field is used response header field (e.g., when the request header field is used
by an origin server's content selection algorithm; see by an origin server's content selection algorithm; see
Section 10.1.4). Section 10.1.4).
o Whether the header field is useful or allowable in trailers (see o Whether the field is allowable in trailers (see Section 4.6).
Section 7.1 of [Messaging]).
o Whether the header field ought to be preserved across redirects. o Whether the field ought to be preserved across redirects.
o Whether it introduces any additional security considerations, such o Whether it introduces any additional security considerations, such
as disclosure of privacy-related data. as disclosure of privacy-related data.
4.8. Fields Defined In This Document
The following fields are defined by this document:
+---------------------------+------------+-------------------+
| Field Name | Status | Reference |
+---------------------------+------------+-------------------+
| Accept | standard | Section 8.4.2 |
| Accept-Charset | deprecated | Section 8.4.3 |
| Accept-Encoding | standard | Section 8.4.4 |
| Accept-Language | standard | Section 8.4.5 |
| Accept-Ranges | standard | Section 10.4.1 |
| Allow | standard | Section 10.4.2 |
| Authentication-Info | standard | Section 10.3.3 |
| Authorization | standard | Section 8.5.3 |
| Content-Encoding | standard | Section 6.2.2 |
| Content-Language | standard | Section 6.2.3 |
| Content-Length | standard | Section 6.2.4 |
| Content-Location | standard | Section 6.2.5 |
| Content-Range | standard | Section 6.3.4 |
| Content-Type | standard | Section 6.2.1 |
| Date | standard | Section 10.1.1.2 |
| ETag | standard | Section 10.2.3 |
| Expect | standard | Section 8.1.1 |
| From | standard | Section 8.6.1 |
| Host | standard | Section 5.6 |
| If-Match | standard | Section 8.2.3 |
| If-Modified-Since | standard | Section 8.2.5 |
| If-None-Match | standard | Section 8.2.4 |
| If-Range | standard | Section 8.2.7 |
| If-Unmodified-Since | standard | Section 8.2.6 |
| Last-Modified | standard | Section 10.2.2 |
| Location | standard | Section 10.1.2 |
| Max-Forwards | standard | Section 8.1.2 |
| Proxy-Authenticate | standard | Section 10.3.2 |
| Proxy-Authentication-Info | standard | Section 10.3.4 |
| Proxy-Authorization | standard | Section 8.5.4 |
| Range | standard | Section 8.3 |
| Referer | standard | Section 8.6.2 |
| Retry-After | standard | Section 10.1.3 |
| Server | standard | Section 10.4.3 |
| Trailer | standard | Section 4.6.3 |
| User-Agent | standard | Section 8.6.3 |
| Vary | standard | Section 10.1.4 |
| Via | standard | Section 5.7.1 |
| WWW-Authenticate | standard | Section 10.3.1 |
+---------------------------+------------+-------------------+
Table 1
5. Message Routing 5. Message Routing
HTTP request message routing is determined by each client based on HTTP request message routing is determined by each client based on
the target resource, the client's proxy configuration, and the target resource, the client's proxy configuration, and
establishment or reuse of an inbound connection. The corresponding establishment or reuse of an inbound connection. The corresponding
response routing follows the same connection chain back to the response routing follows the same connection chain back to the
client. client.
5.1. Identifying a Target Resource 5.1. Identifying a Target Resource
skipping to change at page 36, line 11 skipping to change at page 37, line 30
HTTP communication is initiated by a user agent for some purpose. HTTP communication is initiated by a user agent for some purpose.
The purpose is a combination of request semantics and a target The purpose is a combination of request semantics and a target
resource upon which to apply those semantics. A URI reference resource upon which to apply those semantics. A URI reference
(Section 2.4) is typically used as an identifier for the "target (Section 2.4) is typically used as an identifier for the "target
resource", which a user agent would resolve to its absolute form in resource", which a user agent would resolve to its absolute form in
order to obtain the "target URI". The target URI excludes the order to obtain the "target URI". The target URI excludes the
reference's fragment component, if any, since fragment identifiers reference's fragment component, if any, since fragment identifiers
are reserved for client-side processing ([RFC3986], Section 3.5). are reserved for client-side processing ([RFC3986], Section 3.5).
5.2. Routing Inbound 5.2. Determining Origin
Once the target URI is determined, a client needs to decide whether a The "origin" for a given URI is the triple of scheme, host, and port
network request is necessary to accomplish the desired semantics and, after normalizing the scheme and host to lowercase and normalizing
if so, where that request is to be directed. the port to remove any leading zeros. If port is elided from the
URI, the default port for that scheme is used. For example, the URI
https://Example.Com/happy.js
would have the origin
{ "https", "example.com", "443" }
which can also be described as the normalized URI prefix with port
always present:
https://example.com:443
Each origin defines its own namespace and controls how identifiers
within that namespace are mapped to resources. In turn, how the
origin responds to valid requests, consistently over time, determines
the semantics that users will associate with a URI, and the
usefulness of those semantics is what ultimately transforms these
mechanisms into a "resource" for users to reference and access in the
future.
Two origins are distinct if they differ in scheme, host, or port.
Even when it can be verified that the same entity controls two
distinct origins, the two namespaces under those origins are distinct
unless explicitly aliased by a server authoritative for that origin.
Origin is also used within HTML and related Web protocols, beyond the
scope of this document, as described in [RFC6454].
5.3. Routing Inbound
Once the target URI and its origin are determined, a client decides
whether a network request is necessary to accomplish the desired
semantics and, if so, where that request is to be directed.
If the client has a cache [Caching] and the request can be satisfied If the client has a cache [Caching] and the request can be satisfied
by it, then the request is usually directed there first. by it, then the request is usually directed there first.
If the request is not satisfied by a cache, then a typical client If the request is not satisfied by a cache, then a typical client
will check its configuration to determine whether a proxy is to be will check its configuration to determine whether a proxy is to be
used to satisfy the request. Proxy configuration is implementation- used to satisfy the request. Proxy configuration is implementation-
dependent, but is often based on URI prefix matching, selective dependent, but is often based on URI prefix matching, selective
authority matching, or both, and the proxy itself is usually authority matching, or both, and the proxy itself is usually
identified by an "http" or "https" URI. If a proxy is applicable, identified by an "http" or "https" URI. If a proxy is applicable,
the client connects inbound by establishing (or reusing) a connection the client connects inbound by establishing (or reusing) a connection
to that proxy. to that proxy.
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, usually specific to the target URI's scheme, to connect
directly to an authority for the target resource. How that is directly to an origin for the target resource. How that is
accomplished is dependent on the target URI scheme and defined by its accomplished is dependent on the target URI scheme and defined by its
associated specification, similar to how this specification defines associated specification, similar to how this specification defines
origin server access for resolution of the "http" (Section 2.5.1) and origin server access for resolution of the "http" (Section 2.5.1) and
"https" (Section 2.5.2) schemes. "https" (Section 2.5.2) schemes.
HTTP requirements regarding connection management are defined in HTTP requirements regarding connection management are defined in
Section 9 of [Messaging]. Section 9 of [Messaging].
5.3. Effective Request URI 5.4. Direct Authoritative Access
5.4.1. http origins
Although HTTP is independent of the transport protocol, the "http"
scheme is specific to associating authority with whomever controls
the origin server listening for TCP connections on the indicated port
of whatever host is identified within the authority component. This
is a very weak sense of authority because it depends on both client-
specific name resolution mechanisms and communication that might not
be secured from man-in-the-middle attacks. Nevertheless, it is a
sufficient minimum for binding "http" identifiers to an origin server
for consistent resolution within a trusted environment.
If the host identifier is provided as an IP address, the origin
server is the listener (if any) on the indicated TCP port at that IP
address. If host is a registered name, the registered name is an
indirect identifier for use with a name resolution service, such as
DNS, to find an address for an appropriate origin server.
When an "http" URI is used within a context that calls for access to
the indicated resource, a client MAY attempt access by resolving the
host identifier to an IP address, establishing a TCP connection to
that address on the indicated port, and sending an HTTP request
message to the server containing the URI's identifying data
(Section 2 of [Messaging]).
If the server responds to such a request with a non-interim HTTP
response message, as described in Section 9, then that response is
considered an authoritative answer to the client's request.
Note, however, that the above is not the only means for obtaining an
authoritative response, nor does it imply that an authoritative
response is always necessary (see [Caching]). For example, the Alt-
Svc header field [RFC7838] allows an origin server to identify other
services that are also authoritative for that origin. Access to
"http" identified resources might also be provided by protocols
outside the scope of this document.
See Section 11.1 for security considerations related to establishing
authority.
5.4.2. https origins
The "https" scheme associates authority based on the ability of a
server to use a private key associated with a certificate that the
client considers to be trustworthy for the identified host. If a
server presents a certificate that verifiably applies to the host,
along with proof that it controls the corresponding private key, then
a client will accept a secured connection to that server as being
authoritative for all origins with the same scheme and host.
A client is therefore relying upon a chain of trust, conveyed from
some trust anchor (which is usually prearranged or configured),
through a chain of certificates (e.g., [RFC5280]) to a final
certificate that binds a private key to the host name of the origin.
The handshake and certificate validation in Section 5.4.3 describe
how that final certificate can be used to initiate a secured
connection.
Note that the "https" scheme does not rely on TCP and the connected
port number for associating authority, since both are outside the
secured communication and thus cannot be trusted as definitive.
Hence, the HTTP communication might take place over any channel that
has been secured, as defined in Section 2.5.2, including protocols
that don't use TCP. It is the origin's responsibility to ensure that
any services provided with control over its certificate's private key
are equally responsible for managing the corresponding "https"
namespaces, or at least prepared to reject requests that appear to
have been misdirected. Regardless, the origin's host and port value
are passed within each HTTP request, identifying the target resource
and distinguishing it from other namespaces that might be controlled
by the same server.
In HTTP/1.1 and earlier, the only URIs for which a client will
attribute authority to a server are those for which a TLS connection
was specifically established toward the origin's host. Only the
characteristics of the connection establishment and certificate are
used. For a host that is a domain name, the client MUST include that
name in the TLS server_name extension (if used) and MUST verify that
the name also appears as either the CN field of the certificate
subject or as a dNSName in the subjectAltName field of the
certificate (see [RFC6125]). For a host that is an IP address, the
client MUST verify that the address appears in the subjectAltName of
the certificate.
In HTTP/2, a client will associate authority to all names that are
present in the certificate. However, a client will only do that if
it concludes that it could open a connection to the origin for that
URI. In practice, a client will make a DNS query and see that it
contains the same server IP address. A server sending the ORIGIN
frame removes this restriction [RFC8336].
In addition to the client's verification, an origin server is
responsible for verifying that requests it receives over a connection
correspond to resources for which it actually wants to be the origin.
If a network attacker causes connections for port N to be received at
port Q, checking the effective request URI is necessary to ensure
that the attacker can't cause "https://example.com:N/foo" to be
replaced by "https://example.com:Q/foo" without consent. Likewise, a
server might be unwilling to serve as the origin for some hosts even
when they have the authority to do so.
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
host identifier to an IP address, establishing a TCP connection to
that address on the indicated port, securing the connection end-to-
end by successfully initiating TLS over TCP with confidentiality and
integrity protection, and sending an HTTP request message to the
server over that secured connection containing the URI's identifying
data (Section 2 of [Messaging]).
If the server responds to such a request with a non-interim HTTP
response message, as described in Section 9, then that response is
considered an authoritative answer to the client's request.
Note, however, that the above is not the only means for obtaining an
authoritative response, nor does it imply that an authoritative
response is always necessary (see [Caching]).
5.4.3. Initiating HTTP Over TLS
Conceptually, HTTP/TLS is very simple. Simply use HTTP over TLS
precisely as you would use HTTP over TCP.
The agent acting as the HTTP client should also act as the TLS
client. It should initiate a connection to the server on the
appropriate port and then send the TLS ClientHello to begin the TLS
handshake. When the TLS handshake has finished. The client may then
initiate the first HTTP request. All HTTP data MUST be sent as TLS
"application data". Normal HTTP behavior, including retained
connections should be followed.
5.4.3.1. Identifying HTTPS Servers
In general, HTTP/TLS requests are generated by dereferencing a URI.
As a consequence, the hostname for the server is known to the client.
If the hostname is available, the client MUST check it against the
server's identity as presented in the server's Certificate message,
in order to prevent man-in-the-middle attacks.
If the client has external information as to the expected identity of
the server, the hostname check MAY be omitted. (For instance, a
client may be connecting to a machine whose address and hostname are
dynamic but the client knows the certificate that the server will
present.) In such cases, it is important to narrow the scope of
acceptable certificates as much as possible in order to prevent man
in the middle attacks. In special cases, it may be appropriate for
the client to simply ignore the server's identity, but it must be
understood that this leaves the connection open to active attack.
If a subjectAltName extension of type dNSName is present, that MUST
be used as the identity. Otherwise, the (most specific) Common Name
field in the Subject field of the certificate MUST be used. Although
the use of the Common Name is existing practice, it is deprecated and
Certification Authorities are encouraged to use the dNSName instead.
Matching is performed using the matching rules specified by
[RFC5280]. If more than one identity of a given type is present in
the certificate (e.g., more than one dNSName name, a match in any one
of the set is considered acceptable.) Names may contain the wildcard
character * which is considered to match any single domain name
component or component fragment. E.g., *.a.com matches foo.a.com but
not bar.foo.a.com. f*.com matches foo.com but not bar.com.
In some cases, the URI is specified as an IP address rather than a
hostname. In this case, the iPAddress subjectAltName must be present
in the certificate and must exactly match the IP in the URI.
If the hostname does not match the identity in the certificate, user
oriented clients MUST either notify the user (clients MAY give the
user the opportunity to continue with the connection in any case) or
terminate the connection with a bad certificate error. Automated
clients MUST log the error to an appropriate audit log (if available)
and SHOULD terminate the connection (with a bad certificate error).
Automated clients MAY provide a configuration setting that disables
this check, but MUST provide a setting which enables it.
Note that in many cases the URI itself comes from an untrusted
source. The above-described check provides no protection against
attacks where this source is compromised. For example, if the URI
was obtained by clicking on an HTML page which was itself obtained
without using HTTP/TLS, a man in the middle could have replaced the
URI. In order to prevent this form of attack, users should carefully
examine the certificate presented by the server to determine if it
meets their expectations.
5.4.3.2. Identifying HTTPS Clients
Typically, the server has no external knowledge of what the client's
identity ought to be and so checks (other than that the client has a
certificate chain rooted in an appropriate CA) are not possible. If
a server has such knowledge (typically from some source external to
HTTP or TLS) it SHOULD check the identity as described above.
5.5. Effective Request URI
Once an inbound connection is obtained, the client sends an HTTP Once an inbound connection is obtained, the client sends an HTTP
request message (Section 2 of [Messaging]). request message (Section 2 of [Messaging]).
Depending on the nature of the request, the client's target URI might Depending on the nature of the request, the client's target URI might
be split into components and transmitted (or implied) within various be split into components and transmitted (or implied) within various
parts of a request message. These parts are recombined by each parts of a request message. These parts are recombined by each
recipient, in accordance with their local configuration and incoming recipient, in accordance with their local configuration and incoming
connection context, to form an "effective request URI" for connection context, to form an "effective request URI" for
identifying the intended target resource with respect to that server. identifying the intended target resource with respect to that server.
skipping to change at page 37, line 4 skipping to change at page 43, line 16
Once an inbound connection is obtained, the client sends an HTTP Once an inbound connection is obtained, the client sends an HTTP
request message (Section 2 of [Messaging]). request message (Section 2 of [Messaging]).
Depending on the nature of the request, the client's target URI might Depending on the nature of the request, the client's target URI might
be split into components and transmitted (or implied) within various be split into components and transmitted (or implied) within various
parts of a request message. These parts are recombined by each parts of a request message. These parts are recombined by each
recipient, in accordance with their local configuration and incoming recipient, in accordance with their local configuration and incoming
connection context, to form an "effective request URI" for connection context, to form an "effective request URI" for
identifying the intended target resource with respect to that server. identifying the intended target resource with respect to that server.
Section 3.3 of [Messaging] defines how a server determines the Section 3.3 of [Messaging] defines how a server determines the
effective request URI for an HTTP/1.1 request. effective request URI for an HTTP/1.1 request.
For a user agent, the effective request URI is the target URI. For a user agent, the effective request URI is the target URI.
Once the effective request URI has been constructed, an origin server Once the effective request URI has been constructed, an origin server
needs to decide whether or not to provide service for that URI via needs to decide whether or not to provide service for that URI via
the connection in which the request was received. For example, the the connection in which the request was received. For example, the
request might have been misdirected, deliberately or accidentally, request might have been misdirected, deliberately or accidentally,
such that the information within a received request-target or Host such that the information within a received request-target or Host
header field differs from the host or port upon which the connection header field differs from the host or port upon which the connection
has been made. If the connection is from a trusted gateway, that has been made. If the connection is from a trusted gateway, that
inconsistency might be expected; otherwise, it might indicate an inconsistency might be expected; otherwise, it might indicate an
attempt to bypass security filters, trick the server into delivering attempt to bypass security filters, trick the server into delivering
non-public content, or poison a cache. See Section 13 for security non-public content, or poison a cache. See Section 11 for security
considerations regarding message routing. considerations regarding message routing.
5.4. Host 5.6. Host
The "Host" header field in a request provides the host and port The "Host" header field in a request provides the host and port
information from the target URI, enabling the origin server to information from the target URI, enabling the origin server to
distinguish among resources while servicing requests for multiple distinguish among resources while servicing requests for multiple
host names on a single IP address. host names on a single IP address.
Host = uri-host [ ":" port ] ; Section 2.4 Host = uri-host [ ":" port ] ; Section 2.4
A client MUST send a Host header field in all HTTP/1.1 request A client MUST send a Host header field in all HTTP/1.1 request
messages. If the target URI includes an authority component, then a messages. If the target URI includes an authority component, then a
client MUST send a field-value for Host that is identical to that client MUST send a field value for Host that is identical to that
authority component, excluding any userinfo subcomponent and its "@" authority component, excluding any userinfo subcomponent and its "@"
delimiter (Section 2.5.1). If the authority component is missing or delimiter (Section 2.5.1). If the authority component is missing or
undefined for the target URI, then a client MUST send a Host header undefined for the target URI, then a client MUST send a Host header
field with an empty field-value. field with an empty field value.
Since the Host field-value is critical information for handling a Since the Host field value is critical information for handling a
request, a user agent SHOULD generate Host as the first header field request, a user agent SHOULD generate Host as the first header field
following the request-line. following the request-line.
For example, a GET request to the origin server for For example, a GET request to the origin server for
<http://www.example.org/pub/WWW/> would begin with: <http://www.example.org/pub/WWW/> would begin with:
GET /pub/WWW/ HTTP/1.1 GET /pub/WWW/ HTTP/1.1
Host: www.example.org Host: www.example.org
A client MUST send a Host header field in an HTTP/1.1 request even if A client MUST send a Host header field in an HTTP/1.1 request even if
the request-target is in the absolute-form, since this allows the the request-target is in the absolute-form, since this allows the
Host information to be forwarded through ancient HTTP/1.0 proxies Host information to be forwarded through ancient HTTP/1.0 proxies
that might not have implemented Host. that might not have implemented Host.
When a proxy receives a request with an absolute-form of request- When a proxy receives a request with an absolute-form of request-
target, the proxy MUST ignore the received Host header field (if any) target, the proxy MUST ignore the received Host header field (if any)
and instead replace it with the host information of the request- and instead replace it with the host information of the request-
target. A proxy that forwards such a request MUST generate a new target. A proxy that forwards such a request MUST generate a new
Host field-value based on the received request-target rather than Host field value based on the received request-target rather than
forward the received Host field-value. forward the received Host field value.
When an origin server receives a request with an absolute-form of
request-target, the origin server MUST ignore the received Host
header field (if any) and instead use the host information of the
request-target. Note that if the request-target does not have an
authority component, an empty Host header field will be sent in this
case.
Since the Host header field acts as an application-level routing Since the Host header field acts as an application-level routing
mechanism, it is a frequent target for malware seeking to poison a mechanism, it is a frequent target for malware seeking to poison a
shared cache or redirect a request to an unintended server. An shared cache or redirect a request to an unintended server. An
interception proxy is particularly vulnerable if it relies on the interception proxy is particularly vulnerable if it relies on the
Host field-value for redirecting requests to internal servers, or for Host field value for redirecting requests to internal servers, or for
use as a cache key in a shared cache, without first verifying that use as a cache key in a shared cache, without first verifying that
the intercepted connection is targeting a valid IP address for that the intercepted connection is targeting a valid IP address for that
host. host.
A server MUST respond with a 400 (Bad Request) status code to any A server MUST respond with a 400 (Bad Request) status code to any
HTTP/1.1 request message that lacks a Host header field and to any HTTP/1.1 request message that lacks a Host header field and to any
request message that contains more than one Host header field or a request message that contains more than one Host header field or a
Host header field with an invalid field-value. Host header field with an invalid field value.
5.5. Message Forwarding 5.7. Message Forwarding
As described in Section 2.2, intermediaries can serve a variety of As described in Section 2.2, intermediaries can serve a variety of
roles in the processing of HTTP requests and responses. Some roles in the processing of HTTP requests and responses. Some
intermediaries are used to improve performance or availability. intermediaries are used to improve performance or availability.
Others are used for access control or to filter content. Since an Others are used for access control or to filter content. Since an
HTTP stream has characteristics similar to a pipe-and-filter HTTP stream has characteristics similar to a pipe-and-filter
architecture, there are no inherent limits to the extent an architecture, there are no inherent limits to the extent an
intermediary can enhance (or interfere) with either direction of the intermediary can enhance (or interfere) with either direction of the
stream. stream.
skipping to change at page 39, line 5 skipping to change at page 45, line 24
ought to recognize its own server names, including any aliases, local ought to recognize its own server names, including any aliases, local
variations, or literal IP addresses, and respond to such requests variations, or literal IP addresses, and respond to such requests
directly. directly.
An HTTP message can be parsed as a stream for incremental processing An HTTP message can be parsed as a stream for incremental processing
or forwarding downstream. However, recipients cannot rely on or forwarding downstream. However, recipients cannot rely on
incremental delivery of partial messages, since some implementations incremental delivery of partial messages, since some implementations
will buffer or delay message forwarding for the sake of network will buffer or delay message forwarding for the sake of network
efficiency, security checks, or payload transformations. efficiency, security checks, or payload transformations.
5.5.1. Via 5.7.1. Via
The "Via" header field indicates the presence of intermediate The "Via" header field indicates the presence of intermediate
protocols and recipients between the user agent and the server (on protocols and recipients between the user agent and the server (on
requests) or between the origin server and the client (on responses), requests) or between the origin server and the client (on responses),
similar to the "Received" header field in email (Section 3.6.7 of similar to the "Received" header field in email (Section 3.6.7 of
[RFC5322]). Via can be used for tracking message forwards, avoiding [RFC5322]). Via can be used for tracking message forwards, avoiding
request loops, and identifying the protocol capabilities of senders request loops, and identifying the protocol capabilities of senders
along the request/response chain. along the request/response chain.
Via = 1#( received-protocol RWS received-by [ RWS comment ] ) Via = 1#( received-protocol RWS received-by [ RWS comment ] )
received-protocol = [ protocol-name "/" ] protocol-version received-protocol = [ protocol-name "/" ] protocol-version
; see [Messaging], Section 9.9 ; see [Messaging], Section 9.9
received-by = ( uri-host [ ":" port ] ) / pseudonym received-by = pseudonym [ ":" port ]
pseudonym = token pseudonym = token
Multiple Via field values represent each proxy or gateway that has Each member of the Via field value represents a proxy or gateway that
forwarded the message. Each intermediary appends its own information has forwarded the message. Each intermediary appends its own
about how the message was received, such that the end result is information about how the message was received, such that the end
ordered according to the sequence of forwarding recipients. result is ordered according to the sequence of forwarding recipients.
A proxy MUST send an appropriate Via header field, as described A proxy MUST send an appropriate Via header field, as described
below, in each message that it forwards. An HTTP-to-HTTP gateway below, in each message that it forwards. An HTTP-to-HTTP gateway
MUST send an appropriate Via header field in each inbound request MUST send an appropriate Via header field in each inbound request
message and MAY send a Via header field in forwarded response message and MAY send a Via header field in forwarded response
messages. messages.
For each intermediary, the received-protocol indicates the protocol For each intermediary, the received-protocol indicates the protocol
and protocol version used by the upstream sender of the message. and protocol version used by the upstream sender of the message.
Hence, the Via field value records the advertised protocol Hence, the Via field value records the advertised protocol
capabilities of the request/response chain such that they remain capabilities of the request/response chain such that they remain
visible to downstream recipients; this can be useful for determining visible to downstream recipients; this can be useful for determining
what backwards-incompatible features might be safe to use in what backwards-incompatible features might be safe to use in
response, or within a later request, as described in Section 3.5. response, or within a later request, as described in Section 3.5.
For brevity, the protocol-name is omitted when the received protocol For brevity, the protocol-name is omitted when the received protocol
is HTTP. is HTTP.
The received-by portion of the field value is normally the host and The received-by portion is normally the host and optional port number
optional port number of a recipient server or client that of a recipient server or client that subsequently forwarded the
subsequently forwarded the message. However, if the real host is message. However, if the real host is considered to be sensitive
considered to be sensitive information, a sender MAY replace it with information, a sender MAY replace it with a pseudonym. If a port is
a pseudonym. If a port is not provided, a recipient MAY interpret not provided, a recipient MAY interpret that as meaning it was
that as meaning it was received on the default TCP port, if any, for received on the default TCP port, if any, for the received-protocol.
the received-protocol.
A sender MAY generate comments in the Via header field to identify A sender MAY generate comments to identify the software of each
the software of each recipient, analogous to the User-Agent and recipient, analogous to the User-Agent and Server header fields.
Server header fields. However, all comments in the Via field are However, comments in Via are optional, and a recipient MAY remove
optional, and a recipient MAY remove them prior to forwarding the them prior to forwarding the message.
message.
For example, a request message could be sent from an HTTP/1.0 user For example, a request message could be sent from an HTTP/1.0 user
agent to an internal proxy code-named "fred", which uses HTTP/1.1 to agent to an internal proxy code-named "fred", which uses HTTP/1.1 to
forward the request to a public proxy at p.example.net, which forward the request to a public proxy at p.example.net, which
completes the request by forwarding it to the origin server at completes the request by forwarding it to the origin server at
www.example.com. The request received by www.example.com would then www.example.com. The request received by www.example.com would then
have the following Via header field: have the following Via header field:
Via: 1.0 fred, 1.1 p.example.net Via: 1.0 fred, 1.1 p.example.net
An intermediary used as a portal through a network firewall SHOULD An intermediary used as a portal through a network firewall SHOULD
NOT forward the names and ports of hosts within the firewall region NOT forward the names and ports of hosts within the firewall region
unless it is explicitly enabled to do so. If not enabled, such an unless it is explicitly enabled to do so. If not enabled, such an
intermediary SHOULD replace each received-by host of any host behind intermediary SHOULD replace each received-by host of any host behind
the firewall by an appropriate pseudonym for that host. the firewall by an appropriate pseudonym for that host.
An intermediary MAY combine an ordered subsequence of Via header An intermediary MAY combine an ordered subsequence of Via header
field entries into a single such entry if the entries have identical field list members into a single member if the entries have identical
received-protocol values. For example, received-protocol values. For example,
Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
could be collapsed to could be collapsed to
Via: 1.0 ricky, 1.1 mertz, 1.0 lucy Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
A sender SHOULD NOT combine multiple entries unless they are all A sender SHOULD NOT combine multiple list members unless they are all
under the same organizational control and the hosts have already been under the same organizational control and the hosts have already been
replaced by pseudonyms. A sender MUST NOT combine entries that have replaced by pseudonyms. A sender MUST NOT combine members that have
different received-protocol values. different received-protocol values.
5.5.2. Transformations 5.7.2. Transformations
Some intermediaries include features for transforming messages and Some intermediaries include features for transforming messages and
their payloads. A proxy might, for example, convert between image their payloads. A proxy might, for example, convert between image
formats in order to save cache space or to reduce the amount of formats in order to save cache space or to reduce the amount of
traffic on a slow link. However, operational problems might occur traffic on a slow link. However, operational problems might occur
when these transformations are applied to payloads intended for when these transformations are applied to payloads intended for
critical applications, such as medical imaging or scientific data critical applications, such as medical imaging or scientific data
analysis, particularly when integrity checks or digital signatures analysis, particularly when integrity checks or digital signatures
are used to ensure that the payload received is identical to the are used to ensure that the payload received is identical to the
original. original.
skipping to change at page 43, line 6 skipping to change at page 49, line 26
a data format and various processing models: how to process that data a data format and various processing models: how to process that data
in accordance with each context in which it is received. in accordance with each context in which it is received.
media-type = type "/" subtype *( OWS ";" OWS parameter ) media-type = type "/" subtype *( OWS ";" OWS parameter )
type = token type = token
subtype = token subtype = token
The type and subtype tokens are case-insensitive. The type and subtype tokens are case-insensitive.
The type/subtype MAY be followed by semicolon-delimited parameters The type/subtype MAY be followed by semicolon-delimited parameters
(Section 4.2.3.4) in the form of name=value pairs. The presence or (Section 4.4.1.4) in the form of name=value pairs. The presence or
absence of a parameter might be significant to the processing of a absence of a parameter might be significant to the processing of a
media type, depending on its definition within the media type media type, depending on its definition within the media type
registry. Parameter values might or might not be case-sensitive, registry. Parameter values might or might not be case-sensitive,
depending on the semantics of the parameter name. depending on the semantics of the parameter name.
For example, the following media types are equivalent in describing For example, the following media types are equivalent in describing
HTML text data encoded in the UTF-8 character encoding scheme, but HTML text data encoded in the UTF-8 character encoding scheme, but
the first is preferred for consistency (the "charset" parameter value the first is preferred for consistency (the "charset" parameter value
is defined as being case-insensitive in [RFC2046], Section 4.1.2): is defined as being case-insensitive in [RFC2046], Section 4.1.2):
skipping to change at page 45, line 5 skipping to change at page 51, line 25
Content coding values indicate an encoding transformation that has Content coding values indicate an encoding transformation that has
been or can be applied to a representation. Content codings are been or can be applied to a representation. Content codings are
primarily used to allow a representation to be compressed or primarily used to allow a representation to be compressed or
otherwise usefully transformed without losing the identity of its otherwise usefully transformed without losing the identity of its
underlying media type and without loss of information. Frequently, underlying media type and without loss of information. Frequently,
the representation is stored in coded form, transmitted directly, and the representation is stored in coded form, transmitted directly, and
only decoded by the final recipient. only decoded by the final recipient.
content-coding = token content-coding = token
All content codings are case-insensitive and ought to be registered
within the "HTTP Content Coding Registry", as defined in
Section 6.1.2.4
Content-coding values are used in the Accept-Encoding (Section 8.4.4) Content-coding values are used in the Accept-Encoding (Section 8.4.4)
and Content-Encoding (Section 6.2.2) header fields. and Content-Encoding (Section 6.2.2) header fields.
The following content-coding values are defined by this The following content-coding values are defined by this
specification: specification:
+------------+------------------------------------------+-----------+ +------------+------------------------------------------+-----------+
| Name | Description | Reference | | Name | Description | Reference |
+------------+------------------------------------------+-----------+ +------------+------------------------------------------+-----------+
| compress | UNIX "compress" data format [Welch] | Section 6 | | compress | UNIX "compress" data format [Welch] | Section 6 |
skipping to change at page 46, line 5 skipping to change at page 52, line 48
Note: Some non-conformant implementations send the "deflate" Note: Some non-conformant implementations send the "deflate"
compressed data without the zlib wrapper. compressed data without the zlib wrapper.
6.1.2.3. Gzip Coding 6.1.2.3. Gzip Coding
The "gzip" coding is an LZ77 coding with a 32-bit Cyclic Redundancy The "gzip" coding is an LZ77 coding with a 32-bit Cyclic Redundancy
Check (CRC) that is commonly produced by the gzip file compression Check (CRC) that is commonly produced by the gzip file compression
program [RFC1952]. A recipient SHOULD consider "x-gzip" to be program [RFC1952]. A recipient SHOULD consider "x-gzip" to be
equivalent to "gzip". equivalent to "gzip".
6.1.2.4. Content Coding Extensibility 6.1.2.4. Content Coding Registry
Additional content codings, outside the scope of this specification,
have been specified for use in HTTP. All such content codings ought
to be registered within the "HTTP Content Coding Registry".
6.1.2.4.1. Content Coding Registry
The "HTTP Content Coding Registry", maintained by IANA at The "HTTP Content Coding Registry", maintained by IANA at
<https://www.iana.org/assignments/http-parameters/>, registers <https://www.iana.org/assignments/http-parameters/>, registers
content-coding names. content-coding names.
Content coding registrations MUST include the following fields: Content coding registrations MUST include the following fields:
o Name o Name
o Description o Description
skipping to change at page 47, line 30 skipping to change at page 54, line 23
This general notion of a "range unit" is used in the Accept-Ranges This general notion of a "range unit" is used in the Accept-Ranges
(Section 10.4.1) response header field to advertise support for range (Section 10.4.1) response header field to advertise support for range
requests, the Range (Section 8.3) request header field to delineate requests, the Range (Section 8.3) request header field to delineate
the parts of a representation that are requested, and the Content- the parts of a representation that are requested, and the Content-
Range (Section 6.3.4) payload header field to describe which part of Range (Section 6.3.4) payload header field to describe which part of
a representation is being transferred. a representation is being transferred.
range-unit = token range-unit = token
All range unit names are case-insensitive and ought to be registered
within the "HTTP Range Unit Registry", as defined in Section 6.1.4.4
The following range unit names are defined by this document: The following range unit names are defined by this document:
+------------+-----------------------------------------+------------+ +------------+-----------------------------------------+------------+
| Range Unit | Description | Reference | | Range Unit | Description | Reference |
| Name | | | | Name | | |
+------------+-----------------------------------------+------------+ +------------+-----------------------------------------+------------+
| bytes | a range of octets | Section 6. | | bytes | a range of octets | Section 6. |
| | | 1.4.2 | | | | 1.4.2 |
| none | reserved as keyword to indicate range | Section 10 | | none | reserved as keyword to indicate range | Section 10 |
| | requests are not supported | .4.1 | | | requests are not supported | .4.1 |
skipping to change at page 51, line 4 skipping to change at page 57, line 47
6.1.4.4. Range Unit Registry 6.1.4.4. Range Unit Registry
The "HTTP Range Unit Registry" defines the namespace for the range The "HTTP Range Unit Registry" defines the namespace for the range
unit names and refers to their corresponding specifications. It is unit names and refers to their corresponding specifications. It is
maintained at <https://www.iana.org/assignments/http-parameters>. maintained at <https://www.iana.org/assignments/http-parameters>.
Registration of an HTTP Range Unit MUST include the following fields: Registration of an HTTP Range Unit MUST include the following fields:
o Name o Name
o Description
o Description
o Pointer to specification text o Pointer to specification text
Values to be added to this namespace require IETF Review (see Values to be added to this namespace require IETF Review (see
[RFC8126], Section 4.8). [RFC8126], Section 4.8).
6.2. Representation Metadata 6.2. Representation Metadata
Representation header fields provide metadata about the Representation header fields provide metadata about the
representation. When a message includes a payload body, the representation. When a message includes a payload body, the
representation header fields describe how to interpret the representation header fields describe how to interpret the
representation data enclosed in the payload body. In a response to a representation data enclosed in the payload body. In a response to a
HEAD request, the representation header fields describe the HEAD request, the representation header fields describe the
representation data that would have been enclosed in the payload body representation data that would have been enclosed in the payload body
if the same request had been a GET. if the same request had been a GET.
The following header fields convey representation metadata: The following header fields convey representation metadata:
+-------------------+---------------+ +------------------+---------------+
| Header Field Name | Defined in... | | Field Name | Defined in... |
+-------------------+---------------+ +------------------+---------------+
| Content-Type | Section 6.2.1 | | Content-Type | Section 6.2.1 |
| Content-Encoding | Section 6.2.2 | | Content-Encoding | Section 6.2.2 |
| Content-Language | Section 6.2.3 | | Content-Language | Section 6.2.3 |
| Content-Length | Section 6.2.4 | | Content-Length | Section 6.2.4 |
| Content-Location | Section 6.2.5 | | Content-Location | Section 6.2.5 |
+-------------------+---------------+ +------------------+---------------+
6.2.1. Content-Type 6.2.1. Content-Type
The "Content-Type" header field indicates the media type of the The "Content-Type" header field indicates the media type of the
associated representation: either the representation enclosed in the associated representation: either the representation enclosed in the
message payload or the selected representation, as determined by the message payload or the selected representation, as determined by the
message semantics. The indicated media type defines both the data message semantics. The indicated media type defines both the data
format and how that data is intended to be processed by a recipient, format and how that data is intended to be processed by a recipient,
within the scope of the received message semantics, after any content within the scope of the received message semantics, after any content
codings indicated by Content-Encoding are decoded. codings indicated by Content-Encoding are decoded.
skipping to change at page 54, line 37 skipping to change at page 61, line 36
no Transfer-Encoding is sent and the request method defines a meaning no Transfer-Encoding is sent and the request method defines a meaning
for an enclosed payload body. For example, a Content-Length header for an enclosed payload body. For example, a Content-Length header
field is normally sent in a POST request even when the value is 0 field is normally sent in a POST request even when the value is 0
(indicating an empty payload body). A user agent SHOULD NOT send a (indicating an empty payload body). A user agent SHOULD NOT send a
Content-Length header field when the request message does not contain Content-Length header field when the request message does not contain
a payload body and the method semantics do not anticipate such a a payload body and the method semantics do not anticipate such a
body. body.
A server MAY send a Content-Length header field in a response to a A server MAY send a Content-Length header field in a response to a
HEAD request (Section 7.3.2); a server MUST NOT send Content-Length HEAD request (Section 7.3.2); a server MUST NOT send Content-Length
in such a response unless its field-value equals the decimal number in such a response unless its field value equals the decimal number
of octets that would have been sent in the payload body of a response of octets that would have been sent in the payload body of a response
if the same request had used the GET method. if the same request had used the GET method.
A server MAY send a Content-Length header field in a 304 (Not A server MAY send a Content-Length header field in a 304 (Not
Modified) response to a conditional GET request (Section 9.4.5); a Modified) response to a conditional GET request (Section 9.4.5); a
server MUST NOT send Content-Length in such a response unless its server MUST NOT send Content-Length in such a response unless its
field-value equals the decimal number of octets that would have been field value equals the decimal number of octets that would have been
sent in the payload body of a 200 (OK) response to the same request. sent in the payload body of a 200 (OK) response to the same request.
A server MUST NOT send a Content-Length header field in any response A server MUST NOT send a Content-Length header field in any response
with a status code of 1xx (Informational) or 204 (No Content). A with a status code of 1xx (Informational) or 204 (No Content). A
server MUST NOT send a Content-Length header field in any 2xx server MUST NOT send a Content-Length header field in any 2xx
(Successful) response to a CONNECT request (Section 7.3.6). (Successful) response to a CONNECT request (Section 7.3.6).
Aside from the cases defined above, in the absence of Transfer- Aside from the cases defined above, in the absence of Transfer-
Encoding, an origin server SHOULD send a Content-Length header field Encoding, an origin server SHOULD send a Content-Length header field
when the payload body size is known prior to sending the complete when the payload body size is known prior to sending the complete
header section. This will allow downstream recipients to measure header section. This will allow downstream recipients to measure
transfer progress, know when a received message is complete, and transfer progress, know when a received message is complete, and
potentially reuse the connection for additional requests. potentially reuse the connection for additional requests.
Any Content-Length field value greater than or equal to zero is Any Content-Length field value greater than or equal to zero is
valid. Since there is no predefined limit to the length of a valid. Since there is no predefined limit to the length of a
payload, a recipient MUST anticipate potentially large decimal payload, a recipient MUST anticipate potentially large decimal
numerals and prevent parsing errors due to integer conversion numerals and prevent parsing errors due to integer conversion
overflows (Section 13.5). overflows (Section 11.5).
If a message is received that has multiple Content-Length header If a message is received that has multiple Content-Length header
fields with field-values consisting of the same decimal value, or a fields with field values consisting of the same decimal value, or a
single Content-Length header field with a field value containing a single Content-Length header field with a field value containing a
list of identical decimal values (e.g., "Content-Length: 42, 42"), list of identical decimal values (e.g., "Content-Length: 42, 42"),
indicating that duplicate Content-Length header fields have been indicating that duplicate Content-Length header fields have been
generated or combined by an upstream message processor, then the generated or combined by an upstream message processor, then the
recipient MUST either reject the message as invalid or replace the recipient MUST either reject the message as invalid or replace the
duplicated field-values with a single valid Content-Length field duplicated field values with a single valid Content-Length field
containing that decimal value prior to determining the message body containing that decimal value prior to determining the message body
length or forwarding the message. length or forwarding the message.
6.2.5. Content-Location 6.2.5. Content-Location
The "Content-Location" header field references a URI that can be used The "Content-Location" header field references a URI that can be used
as an identifier for a specific resource corresponding to the as an identifier for a specific resource corresponding to the
representation in this message's payload. In other words, if one representation in this message's payload. In other words, if one
were to perform a GET request on this URI at the time of this were to perform a GET request on this URI at the time of this
message's generation, then a 200 (OK) response would contain the same message's generation, then a 200 (OK) response would contain the same
representation that is enclosed as payload in this message. representation that is enclosed as payload in this message.
Content-Location = absolute-URI / partial-URI Content-Location = absolute-URI / partial-URI
The Content-Location value is not a replacement for the effective The Content-Location value is not a replacement for the effective
Request URI (Section 5.3). It is representation metadata. It has Request URI (Section 5.5). It is representation metadata. It has
the same syntax and semantics as the header field of the same name the same syntax and semantics as the header field of the same name
defined for MIME body parts in Section 4 of [RFC2557]. However, its defined for MIME body parts in Section 4 of [RFC2557]. However, its
appearance in an HTTP message has some special implications for HTTP appearance in an HTTP message has some special implications for HTTP
recipients. recipients.
If Content-Location is included in a 2xx (Successful) response If Content-Location is included in a 2xx (Successful) response
message and its value refers (after conversion to absolute form) to a message and its value refers (after conversion to absolute form) to a
URI that is the same as the effective request URI, then the recipient URI that is the same as the effective request URI, then the recipient
MAY consider the payload to be a current representation of that MAY consider the payload to be a current representation of that
resource at the time indicated by the message origination date. For resource at the time indicated by the message origination date. For
a GET (Section 7.3.1) or HEAD (Section 7.3.2) request, this is the a GET (Section 7.3.1) or HEAD (Section 7.3.2) request, this is the
same as the default semantics when no Content-Location is provided by same as the default semantics when no Content-Location is provided by
the server. For a state-changing request like PUT (Section 7.3.4) or the server. For a state-changing request like PUT (Section 7.3.4) or
POST (Section 7.3.3), it implies that the server's response contains POST (Section 7.3.3), it implies that the server's response contains
the new representation of that resource, thereby distinguishing it the new representation of that resource, thereby distinguishing it
from representations that might only report about the action (e.g., from representations that might only report about the action (e.g.,
"It worked!"). This allows authoring applications to update their "It worked!"). This allows authoring applications to update their
local copies without the need for a subsequent GET request. local copies without the need for a subsequent GET request.
If Content-Location is included in a 2xx (Successful) response If Content-Location is included in a 2xx (Successful) response
message and its field-value refers to a URI that differs from the message and its field value refers to a URI that differs from the
effective request URI, then the origin server claims that the URI is effective request URI, then the origin server claims that the URI is
an identifier for a different resource corresponding to the enclosed an identifier for a different resource corresponding to the enclosed
representation. Such a claim can only be trusted if both identifiers representation. Such a claim can only be trusted if both identifiers
share the same resource owner, which cannot be programmatically share the same resource owner, which cannot be programmatically
determined via HTTP. determined via HTTP.
o For a response to a GET or HEAD request, this is an indication o For a response to a GET or HEAD request, this is an indication
that the effective request URI refers to a resource that is that the effective request URI refers to a resource that is
subject to content negotiation and the Content-Location field- subject to content negotiation and the Content-Location field
value is a more specific identifier for the selected value is a more specific identifier for the selected
representation. representation.
o For a 201 (Created) response to a state-changing method, a o For a 201 (Created) response to a state-changing method, a
Content-Location field-value that is identical to the Location Content-Location field value that is identical to the Location
field-value indicates that this payload is a current field value indicates that this payload is a current
representation of the newly created resource. representation of the newly created resource.
o Otherwise, such a Content-Location indicates that this payload is o Otherwise, such a Content-Location indicates that this payload is
a representation reporting on the requested action's status and a representation reporting on the requested action's status and
that the same report is available (for future access with GET) at that the same report is available (for future access with GET) at
the given URI. For example, a purchase transaction made via a the given URI. For example, a purchase transaction made via a
POST request might include a receipt document as the payload of POST request might include a receipt document as the payload of
the 200 (OK) response; the Content-Location field-value provides the 200 (OK) response; the Content-Location field value provides
an identifier for retrieving a copy of that same receipt in the an identifier for retrieving a copy of that same receipt in the
future. future.
A user agent that sends Content-Location in a request message is A user agent that sends Content-Location in a request message is
stating that its value refers to where the user agent originally stating that its value refers to where the user agent originally
obtained the content of the enclosed representation (prior to any obtained the content of the enclosed representation (prior to any
modifications made by that user agent). In other words, the user modifications made by that user agent). In other words, the user
agent is providing a back link to the source of the original agent is providing a back link to the source of the original
representation. representation.
skipping to change at page 57, line 30 skipping to change at page 64, line 30
the associated representation's header fields (e.g., responses to the associated representation's header fields (e.g., responses to
HEAD) or only some part(s) of the representation data (e.g., the 206 HEAD) or only some part(s) of the representation data (e.g., the 206
(Partial Content) status code). (Partial Content) status code).
Header fields that specifically describe the payload, rather than the Header fields that specifically describe the payload, rather than the
associated representation, are referred to as "payload header associated representation, are referred to as "payload header
fields". Payload header fields are defined in other parts of this fields". Payload header fields are defined in other parts of this
specification, due to their impact on message parsing. specification, due to their impact on message parsing.
+-------------------+----------------------------+ +-------------------+----------------------------+
| Header Field Name | Defined in... | | Field Name | Defined in... |
+-------------------+----------------------------+ +-------------------+----------------------------+
| Content-Range | Section 6.3.4 | | Content-Range | Section 6.3.4 |
| Trailer | Section 4.3.3 | | Trailer | Section 4.6.3 |
| Transfer-Encoding | Section 6.1 of [Messaging] | | Transfer-Encoding | Section 6.1 of [Messaging] |
+-------------------+----------------------------+ +-------------------+----------------------------+
6.3.1. Purpose 6.3.1. Purpose
The purpose of a payload in a request is defined by the method The purpose of a payload in a request is defined by the method
semantics. For example, a representation in the payload of a PUT semantics. For example, a representation in the payload of a PUT
request (Section 7.3.4) represents the desired state of the target request (Section 7.3.4) represents the desired state of the target
resource if the request is successfully applied, whereas a resource if the request is successfully applied, whereas a
representation in the payload of a POST request (Section 7.3.3) representation in the payload of a POST request (Section 7.3.3)
skipping to change at page 58, line 21 skipping to change at page 65, line 21
When a complete or partial representation is transferred in a message When a complete or partial representation is transferred in a message
payload, it is often desirable for the sender to supply, or the payload, it is often desirable for the sender to supply, or the
recipient to determine, an identifier for a resource corresponding to recipient to determine, an identifier for a resource corresponding to
that representation. that representation.
For a request message: For a request message:
o If the request has a Content-Location header field, then the o If the request has a Content-Location header field, then the
sender asserts that the payload is a representation of the sender asserts that the payload is a representation of the
resource identified by the Content-Location field-value. However, resource identified by the Content-Location field value. However,
such an assertion cannot be trusted unless it can be verified by such an assertion cannot be trusted unless it can be verified by
other means (not defined by this specification). The information other means (not defined by this specification). The information
might still be useful for revision history links. might still be useful for revision history links.
o Otherwise, the payload is unidentified. o Otherwise, the payload is unidentified.
For a response message, the following rules are applied in order For a response message, the following rules are applied in order
until a match is found: until a match is found:
1. If the request method is GET or HEAD and the response status code 1. If the request method is GET or HEAD and the response status code
is 200 (OK), 204 (No Content), 206 (Partial Content), or 304 (Not is 200 (OK), 204 (No Content), 206 (Partial Content), or 304 (Not
Modified), the payload is a representation of the resource Modified), the payload is a representation of the resource
identified by the effective request URI (Section 5.3). identified by the effective request URI (Section 5.5).
2. If the request method is GET or HEAD and the response status code 2. If the request method is GET or HEAD and the response status code
is 203 (Non-Authoritative Information), the payload is a is 203 (Non-Authoritative Information), the payload is a
potentially modified or enhanced representation of the target potentially modified or enhanced representation of the target
resource as provided by an intermediary. resource as provided by an intermediary.
3. If the response has a Content-Location header field and its 3. If the response has a Content-Location header field and its field
field-value is a reference to the same URI as the effective value is a reference to the same URI as the effective request
request URI, the payload is a representation of the resource URI, the payload is a representation of the resource identified
identified by the effective request URI. by the effective request URI.
4. If the response has a Content-Location header field and its 4. If the response has a Content-Location header field and its field
field-value is a reference to a URI different from the effective value is a reference to a URI different from the effective
request URI, then the sender asserts that the payload is a request URI, then the sender asserts that the payload is a
representation of the resource identified by the Content-Location representation of the resource identified by the Content-Location
field-value. However, such an assertion cannot be trusted unless field value. However, such an assertion cannot be trusted unless
it can be verified by other means (not defined by this it can be verified by other means (not defined by this
specification). specification).
5. Otherwise, the payload is unidentified. 5. Otherwise, the payload is unidentified.
6.3.3. Payload Body 6.3.3. Payload Body
The payload body contains the data of a request or response. This is The payload body contains the data of a request or response. This is
distinct from the message body (e.g., Section 6 of [Messaging]), distinct from the message body (e.g., Section 6 of [Messaging]),
which is how the payload body is transferred "on the wire", and might which is how the payload body is transferred "on the wire", and might
skipping to change at page 62, line 50 skipping to change at page 69, line 50
Subtype name: byteranges Subtype name: byteranges
Required parameters: boundary Required parameters: boundary
Optional parameters: N/A Optional parameters: N/A
Encoding considerations: only "7bit", "8bit", or "binary" are Encoding considerations: only "7bit", "8bit", or "binary" are
permitted permitted
Security considerations: see Section 13 Security considerations: see Section 11
Interoperability considerations: N/A Interoperability considerations: N/A
Published specification: This specification (see Section 6.3.5). Published specification: This specification (see Section 6.3.5).
Applications that use this media type: HTTP components supporting Applications that use this media type: HTTP components supporting
multiple ranges in a single request. multiple ranges in a single request.
Fragment identifier considerations: N/A Fragment identifier considerations: N/A
Additional information: Additional information:
skipping to change at page 70, line 39 skipping to change at page 77, line 39
7.3. Method Definitions 7.3. Method Definitions
7.3.1. GET 7.3.1. GET
The GET method requests transfer of a current selected representation The GET method requests transfer of a current selected representation
for the target resource. GET is the primary mechanism of information for the target resource. GET is the primary mechanism of information
retrieval and the focus of almost all performance optimizations. retrieval and the focus of almost all performance optimizations.
Hence, when people speak of retrieving some identifiable information Hence, when people speak of retrieving some identifiable information
via HTTP, they are generally referring to making a GET request. via HTTP, they are generally referring to making a GET request.
The GET method is specifically intended to reflect the quality of
"sameness" identified by the request URI as if it were referenced as
an ordinary hypertext link.
It is tempting to think of resource identifiers as remote file system It is tempting to think of resource identifiers as remote file system
pathnames and of representations as being a copy of the contents of pathnames and of representations as being a copy of the contents of
such files. In fact, that is how many resources are implemented (see such files. In fact, that is how many resources are implemented (see
Section 13.3 for related security considerations). However, there Section 11.3 for related security considerations). However, there
are no such limitations in practice. The HTTP interface for a are no such limitations in practice. The HTTP interface for a
resource is just as likely to be implemented as a tree of content resource is just as likely to be implemented as a tree of content
objects, a programmatic view on various database records, or a objects, a programmatic view on various database records, or a
gateway to other information systems. Even when the URI mapping gateway to other information systems. Even when the URI mapping
mechanism is tied to a file system, an origin server might be mechanism is tied to a file system, an origin server might be
configured to execute the files with the request as input and send configured to execute the files with the request as input and send
the output as the representation rather than transfer the files the output as the representation rather than transfer the files
directly. Regardless, only the origin server needs to know how each directly. Regardless, only the origin server needs to know how each
of its resource identifiers corresponds to an implementation and how of its resource identifiers corresponds to an implementation and how
each implementation manages to select and send a current each implementation manages to select and send a current
representation of the target resource in a response to GET. representation of the target resource in a response to GET.
A client can alter the semantics of GET to be a "range request", A client can alter the semantics of GET to be a "range request",
requesting transfer of only some part(s) of the selected requesting transfer of only some part(s) of the selected
representation, by sending a Range header field in the request representation, by sending a Range header field in the request
(Section 8.3). (Section 8.3).
The GET method is specifically intended to reflect the quality of A client SHOULD NOT generate a body in a GET request. A payload
"sameness" identified by the request URI as if it were referenced as received in a GET request has no defined semantics, cannot alter the
an ordinary hypertext link. A client SHOULD NOT generate a body in a meaning or target of the request, and might lead some implementations
GET request. A payload received in a GET request has no defined to reject the request and close the connection because of its
semantics, cannot alter the meaning or target of the request, and potential as a request smuggling attack (Section 11.2 of
might lead some implementations to reject the request and close the [Messaging]).
connection because of its potential as a request smuggling attack
(Section 11.2 of [Messaging]).
The response to a GET request is cacheable; a cache MAY use it to The response to a GET request is cacheable; a cache MAY use it to
satisfy subsequent GET and HEAD requests unless otherwise indicated satisfy subsequent GET and HEAD requests unless otherwise indicated
by the Cache-Control header field (Section 5.2 of [Caching]). A by the Cache-Control header field (Section 5.2 of [Caching]). A
cache that receives a payload in a GET request is likely to ignore cache that receives a payload in a GET request is likely to ignore
that payload and cache regardless of the payload contents. that payload and cache regardless of the payload contents.
7.3.2. HEAD 7.3.2. HEAD
The HEAD method is identical to GET except that the server MUST NOT The HEAD method is identical to GET except that the server MUST NOT
skipping to change at page 73, line 29 skipping to change at page 80, line 29
If the target resource does not have a current representation and the If the target resource does not have a current representation and the
PUT successfully creates one, then the origin server MUST inform the PUT successfully creates one, then the origin server MUST inform the
user agent by sending a 201 (Created) response. If the target user agent by sending a 201 (Created) response. If the target
resource does have a current representation and that representation resource does have a current representation and that representation
is successfully modified in accordance with the state of the enclosed is successfully modified in accordance with the state of the enclosed
representation, then the origin server MUST send either a 200 (OK) or representation, then the origin server MUST send either a 200 (OK) or
a 204 (No Content) response to indicate successful completion of the a 204 (No Content) response to indicate successful completion of the
request. request.
An origin server SHOULD ignore unrecognized header fields received in An origin server SHOULD ignore unrecognized header and trailer fields
a PUT request (i.e., do not save them as part of the resource state). received in a PUT request (i.e., do not save them as part of the
resource state).
An origin server SHOULD verify that the PUT representation is An origin server SHOULD verify that the PUT representation is
consistent with any constraints the server has for the target consistent with any constraints the server has for the target
resource that cannot or will not be changed by the PUT. This is resource that cannot or will not be changed by the PUT. This is
particularly important when the origin server uses internal particularly important when the origin server uses internal
configuration information related to the URI in order to set the configuration information related to the URI in order to set the
values for representation metadata on GET responses. When a PUT values for representation metadata on GET responses. When a PUT
representation is inconsistent with the target resource, the origin representation is inconsistent with the target resource, the origin
server SHOULD either make them consistent, by transforming the server SHOULD either make them consistent, by transforming the
representation or changing the resource configuration, or respond representation or changing the resource configuration, or respond
skipping to change at page 76, line 29 skipping to change at page 83, line 29
o a 202 (Accepted) status code if the action will likely succeed but o a 202 (Accepted) status code if the action will likely succeed but
has not yet been enacted, has not yet been enacted,
o a 204 (No Content) status code if the action has been enacted and o a 204 (No Content) status code if the action has been enacted and
no further information is to be supplied, or no further information is to be supplied, or
o a 200 (OK) status code if the action has been enacted and the o a 200 (OK) status code if the action has been enacted and the
response message includes a representation describing the status. response message includes a representation describing the status.
A payload within a DELETE request message has no defined semantics; A client SHOULD NOT generate a body in a DELETE request. A payload
sending a payload body on a DELETE request might cause some existing received in a DELETE request has no defined semantics, cannot alter
the meaning or target of the request, and might lead some
implementations to reject the request. implementations to reject the request.
Responses to the DELETE method are not cacheable. If a successful Responses to the DELETE method are not cacheable. If a successful
DELETE request passes through a cache that has one or more stored DELETE request passes through a cache that has one or more stored
responses for the effective request URI, those stored responses will responses for the effective request URI, those stored responses will
be invalidated (see Section 4.4 of [Caching]). be invalidated (see Section 4.4 of [Caching]).
7.3.6. CONNECT 7.3.6. CONNECT
The CONNECT method requests that the recipient establish a tunnel to The CONNECT method requests that the recipient establish a tunnel to
skipping to change at page 78, line 33 skipping to change at page 85, line 33
typically depend on the resource, the "*" request is only useful as a typically depend on the resource, the "*" request is only useful as a
"ping" or "no-op" type of method; it does nothing beyond allowing the "ping" or "no-op" type of method; it does nothing beyond allowing the
client to test the capabilities of the server. For example, this can client to test the capabilities of the server. For example, this can
be used to test a proxy for HTTP/1.1 conformance (or lack thereof). be used to test a proxy for HTTP/1.1 conformance (or lack thereof).
If the request-target is not an asterisk, the OPTIONS request applies If the request-target is not an asterisk, the OPTIONS request applies
to the options that are available when communicating with the target to the options that are available when communicating with the target
resource. resource.
A server generating a successful response to OPTIONS SHOULD send any A server generating a successful response to OPTIONS SHOULD send any
header fields that might indicate optional features implemented by header that might indicate optional features implemented by the
the server and applicable to the target resource (e.g., Allow), server and applicable to the target resource (e.g., Allow), including
including potential extensions not defined by this specification. potential extensions not defined by this specification. The response
The response payload, if any, might also describe the communication payload, if any, might also describe the communication options in a
options in a machine or human-readable representation. A standard machine or human-readable representation. A standard format for such
format for such a representation is not defined by this a representation is not defined by this specification, but might be
specification, but might be defined by future extensions to HTTP. defined by future extensions to HTTP.
A client MAY send a Max-Forwards header field in an OPTIONS request A client MAY send a Max-Forwards header field in an OPTIONS request
to target a specific recipient in the request chain (see to target a specific recipient in the request chain (see
Section 8.1.2). A proxy MUST NOT generate a Max-Forwards header Section 8.1.2). A proxy MUST NOT generate a Max-Forwards header
field while forwarding a request unless that request was received field while forwarding a request unless that request was received
with a Max-Forwards field. with a Max-Forwards field.
A client that generates an OPTIONS request containing a payload body A client that generates an OPTIONS request containing a payload body
MUST send a valid Content-Type header field describing the MUST send a valid Content-Type header field describing the
representation media type. Note that this specification does not representation media type. Note that this specification does not
skipping to change at page 79, line 16 skipping to change at page 86, line 16
The TRACE method requests a remote, application-level loop-back of The TRACE method requests a remote, application-level loop-back of
the request message. The final recipient of the request SHOULD the request message. The final recipient of the request SHOULD
reflect the message received, excluding some fields described below, reflect the message received, excluding some fields described below,
back to the client as the message body of a 200 (OK) response with a back to the client as the message body of a 200 (OK) response with a
Content-Type of "message/http" (Section 10.1 of [Messaging]). The Content-Type of "message/http" (Section 10.1 of [Messaging]). The
final recipient is either the origin server or the first server to final recipient is either the origin server or the first server to
receive a Max-Forwards value of zero (0) in the request receive a Max-Forwards value of zero (0) in the request
(Section 8.1.2). (Section 8.1.2).
A client MUST NOT generate header fields in a TRACE request A client MUST NOT generate fields in a TRACE request containing
containing sensitive data that might be disclosed by the response. sensitive data that might be disclosed by the response. For example,
For example, it would be foolish for a user agent to send stored user it would be foolish for a user agent to send stored user credentials
credentials Section 8.5 or cookies [RFC6265] in a TRACE request. The Section 8.5 or cookies [RFC6265] in a TRACE request. The final
final recipient of the request SHOULD exclude any request header recipient of the request SHOULD exclude any request fields that are
fields that are likely to contain sensitive data when that recipient likely to contain sensitive data when that recipient generates the
generates the response body. response body.
TRACE allows the client to see what is being received at the other TRACE allows the client to see what is being received at the other
end of the request chain and use that data for testing or diagnostic end of the request chain and use that data for testing or diagnostic
information. The value of the Via header field (Section 5.5.1) is of information. The value of the Via header field (Section 5.7.1) is of
particular interest, since it acts as a trace of the request chain. particular interest, since it acts as a trace of the request chain.
Use of the Max-Forwards header field allows the client to limit the Use of the Max-Forwards header field allows the client to limit the
length of the request chain, which is useful for testing a chain of length of the request chain, which is useful for testing a chain of
proxies forwarding messages in an infinite loop. proxies forwarding messages in an infinite loop.
A client MUST NOT send a message body in a TRACE request. A client MUST NOT send a message body in a TRACE request.
Responses to the TRACE method are not cacheable. Responses to the TRACE method are not cacheable.
7.4. Method Extensibility 7.4. Method Extensibility
skipping to change at page 81, line 13 skipping to change at page 88, line 13
target resource state, suggest preferred formats for the response, target resource state, suggest preferred formats for the response,
supply authentication credentials, or modify the expected request supply authentication credentials, or modify the expected request
processing. These fields act as request modifiers, similar to the processing. These fields act as request modifiers, similar to the
parameters on a programming language method invocation. parameters on a programming language method invocation.
8.1. Controls 8.1. Controls
Controls are request header fields that direct specific handling of Controls are request header fields that direct specific handling of
the request. the request.
+-------------------+----------------------------+ +---------------+----------------------------+
| Header Field Name | Defined in... | | Field Name | Defined in... |
+-------------------+----------------------------+ +---------------+----------------------------+
| Cache-Control | Section 5.2 of [Caching] | | Cache-Control | Section 5.2 of [Caching] |
| Expect | Section 8.1.1 | | Expect | Section 8.1.1 |
| Host | Section 5.4 | | Host | Section 5.6 |
| Max-Forwards | Section 8.1.2 | | Max-Forwards | Section 8.1.2 |
| Pragma | Section 5.4 of [Caching] | | Pragma | Section 5.4 of [Caching] |
| TE | Section 7.4 of [Messaging] | | TE | Section 7.4 of [Messaging] |
+-------------------+----------------------------+ +---------------+----------------------------+
8.1.1. Expect 8.1.1. Expect
The "Expect" header field in a request indicates a certain set of The "Expect" header field in a request indicates a certain set of
behaviors (expectations) that need to be supported by the server in behaviors (expectations) that need to be supported by the server in
order to properly handle this request. The only such expectation order to properly handle this request. The only such expectation
defined by this specification is 100-continue. defined by this specification is 100-continue.
Expect = "100-continue" Expect = "100-continue"
The Expect field-value is case-insensitive. The Expect field value is case-insensitive.
A server that receives an Expect field-value other than 100-continue A server that receives an Expect field value other than 100-continue
MAY respond with a 417 (Expectation Failed) status code to indicate MAY respond with a 417 (Expectation Failed) status code to indicate
that the unexpected expectation cannot be met. that the unexpected expectation cannot be met.
A 100-continue expectation informs recipients that the client is A 100-continue expectation informs recipients that the client is
about to send a (presumably large) message body in this request and about to send a (presumably large) message body in this request and
wishes to receive a 100 (Continue) interim response if the request- wishes to receive a 100 (Continue) interim response if the request-
line and header fields are not sufficient to cause an immediate line and header fields are not sufficient to cause an immediate
success, redirect, or error response. This allows the client to wait success, redirect, or error response. This allows the client to wait
for an indication that it is worthwhile to send the message body for an indication that it is worthwhile to send the message body
before actually doing so, which can improve efficiency when the before actually doing so, which can improve efficiency when the
skipping to change at page 84, line 14 skipping to change at page 91, line 14
The Max-Forwards value is a decimal integer indicating the remaining The Max-Forwards value is a decimal integer indicating the remaining
number of times this request message can be forwarded. number of times this request message can be forwarded.
Each intermediary that receives a TRACE or OPTIONS request containing Each intermediary that receives a TRACE or OPTIONS request containing
a Max-Forwards header field MUST check and update its value prior to a Max-Forwards header field MUST check and update its value prior to
forwarding the request. If the received value is zero (0), the forwarding the request. If the received value is zero (0), the
intermediary MUST NOT forward the request; instead, the intermediary intermediary MUST NOT forward the request; instead, the intermediary
MUST respond as the final recipient. If the received Max-Forwards MUST respond as the final recipient. If the received Max-Forwards
value is greater than zero, the intermediary MUST generate an updated value is greater than zero, the intermediary MUST generate an updated
Max-Forwards field in the forwarded message with a field-value that Max-Forwards field in the forwarded message with a field value that
is the lesser of a) the received value decremented by one (1) or b) is the lesser of a) the received value decremented by one (1) or b)
the recipient's maximum supported value for Max-Forwards. the recipient's maximum supported value for Max-Forwards.
A recipient MAY ignore a Max-Forwards header field received with any A recipient MAY ignore a Max-Forwards header field received with any
other request methods. other request methods.
8.2. Preconditions 8.2. Preconditions
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
skipping to change at page 85, line 11 skipping to change at page 92, line 11
precondition evaluates to false. Each precondition defined by this precondition evaluates to false. Each precondition defined by this
specification consists of a comparison between a set of validators specification consists of a comparison between a set of validators
obtained from prior representations of the target resource to the obtained from prior representations of the target resource to the
current state of validators for the selected representation current state of validators for the selected representation
(Section 10.2). Hence, these preconditions evaluate whether the (Section 10.2). Hence, these preconditions evaluate whether the
state of the target resource has changed since a given state known by state of the target resource has changed since a given state known by
the client. The effect of such an evaluation depends on the method the client. The effect of such an evaluation depends on the method
semantics and choice of conditional, as defined in Section 8.2.1. semantics and choice of conditional, as defined in Section 8.2.1.
+---------------------+---------------+ +---------------------+---------------+
| Header Field Name | Defined in... | | Field Name | Defined in... |
+---------------------+---------------+ +---------------------+---------------+
| If-Match | Section 8.2.3 | | If-Match | Section 8.2.3 |
| If-None-Match | Section 8.2.4 | | If-None-Match | Section 8.2.4 |
| If-Modified-Since | Section 8.2.5 | | If-Modified-Since | Section 8.2.5 |
| If-Unmodified-Since | Section 8.2.6 | | If-Unmodified-Since | Section 8.2.6 |
| If-Range | Section 8.2.7 | | If-Range | Section 8.2.7 |
+---------------------+---------------+ +---------------------+---------------+
8.2.1. Evaluation 8.2.1. Evaluation
skipping to change at page 88, line 14 skipping to change at page 95, line 14
Any extension to HTTP/1.1 that defines additional conditional request Any extension to HTTP/1.1 that defines additional conditional request
header fields ought to define its own expectations regarding the header fields ought to define its own expectations regarding the
order for evaluating such fields in relation to those defined in this order for evaluating such fields in relation to those defined in this
document and other conditionals that might be found in practice. document and other conditionals that might be found in practice.
8.2.3. If-Match 8.2.3. If-Match
The "If-Match" header field makes the request method conditional on The "If-Match" header field makes the request method conditional on
the recipient origin server either having at least one current the recipient origin server either having at least one current
representation of the target resource, when the field-value is "*", representation of the target resource, when the field value is "*",
or having a current representation of the target resource that has an or having a current representation of the target resource that has an
entity-tag matching a member of the list of entity-tags provided in entity-tag matching a member of the list of entity-tags provided in
the field-value. the field value.
An origin server MUST use the strong comparison function when An origin server MUST use the strong comparison function when
comparing entity-tags for If-Match (Section 10.2.3.2), since the comparing entity-tags for If-Match (Section 10.2.3.2), since the
client intends this precondition to prevent the method from being client intends this precondition to prevent the method from being
applied if there have been any changes to the representation data. applied if there have been any changes to the representation data.
If-Match = "*" / 1#entity-tag If-Match = "*" / 1#entity-tag
Examples: Examples:
skipping to change at page 88, line 41 skipping to change at page 95, line 41
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 safe prevent the "lost update" problem). It can also be used with safe
methods to abort a request if the selected representation does not methods to abort a request if the selected representation does not
match one already stored (or partially stored) from a prior request. match one already stored (or partially stored) from a prior request.
An origin server that receives an If-Match header field MUST evaluate An origin server that receives an If-Match header field MUST evaluate
the condition prior to performing the method (Section 8.2.1). If the the condition prior to performing the method (Section 8.2.1). If the
field-value is "*", the condition is false if the origin server does field value is "*", the condition is false if the origin server does
not have a current representation for the target resource. If the not have a current representation for the target resource. If the
field-value is a list of entity-tags, the condition is false if none field value is a list of entity-tags, the condition is false if none
of the listed tags match the entity-tag of the selected of the listed tags match the entity-tag of the selected
representation. representation.
An origin server MUST NOT perform the requested method if a received An origin server MUST NOT perform the requested method if a received
If-Match condition evaluates to false; instead, the origin server If-Match condition evaluates to false; instead, the origin server
MUST respond with either a) the 412 (Precondition Failed) status code MUST respond with either a) the 412 (Precondition Failed) status code
or b) one of the 2xx (Successful) status codes if the origin server or b) one of the 2xx (Successful) status codes if the origin server
has verified that a state change is being requested and the final has verified that a state change is being requested and the final
state is already reflected in the current state of the target state is already reflected in the current state of the target
resource (i.e., the change requested by the user agent has already resource (i.e., the change requested by the user agent has already
skipping to change at page 89, line 19 skipping to change at page 96, line 19
verify that the request is a duplicate of an immediately prior change verify that the request is a duplicate of an immediately prior change
made by the same user agent. made by the same user agent.
The If-Match header field can be ignored by caches and intermediaries The If-Match header field can be ignored by caches and intermediaries
because it is not applicable to a stored response. because it is not applicable to a stored response.
8.2.4. If-None-Match 8.2.4. If-None-Match
The "If-None-Match" header field makes the request method conditional The "If-None-Match" header field makes the request method conditional
on a recipient cache or origin server either not having any current on a recipient cache or origin server either not having any current
representation of the target resource, when the field-value is "*", representation of the target resource, when the field value is "*",
or having a selected representation with an entity-tag that does not or having a selected representation with an entity-tag that does not
match any of those listed in the field-value. match any of those listed in the field value.
A recipient MUST use the weak comparison function when comparing A recipient MUST use the weak comparison function when comparing
entity-tags for If-None-Match (Section 10.2.3.2), since weak entity- entity-tags for If-None-Match (Section 10.2.3.2), since weak entity-
tags can be used for cache validation even if there have been changes tags can be used for cache validation even if there have been changes
to the representation data. to the representation data.
If-None-Match = "*" / 1#entity-tag If-None-Match = "*" / 1#entity-tag
Examples: Examples:
skipping to change at page 90, line 9 skipping to change at page 97, line 9
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 7.2.1). This is a variation on the "lost update" problem (Section 7.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 An origin server that receives an If-None-Match header field MUST
evaluate the condition prior to performing the method evaluate the condition prior to performing the method
(Section 8.2.1). If the field-value is "*", the condition is false (Section 8.2.1). If the field value is "*", the condition is false
if the origin server has a current representation for the target if the origin server has a current representation for the target
resource. If the field-value is a list of entity-tags, the condition resource. If the field value is a list of entity-tags, the condition
is false if one of the listed tags match the entity-tag of the is false if one of the listed tags match the entity-tag of the
selected representation. selected representation.
An origin server MUST NOT perform the requested method if the An origin server MUST NOT perform the requested method if the
condition evaluates to false; instead, the origin server MUST respond condition evaluates to false; instead, the origin server MUST respond
with either a) the 304 (Not Modified) status code if the request with either a) the 304 (Not Modified) status code if the request
method is GET or HEAD or b) the 412 (Precondition Failed) status code method is GET or HEAD or b) the 412 (Precondition Failed) status code
for all other request methods. 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].
8.2.5. If-Modified-Since 8.2.5. If-Modified-Since
The "If-Modified-Since" header field makes a GET or HEAD request The "If-Modified-Since" header field makes a GET or HEAD request
method conditional on the selected representation's modification date method conditional on the selected representation's modification date
being more recent than the date provided in the field-value. being more recent than the date provided in the field value.
Transfer of the selected representation's data is avoided if that Transfer of the selected representation's data is avoided if that
data has not changed. data has not changed.
If-Modified-Since = HTTP-date If-Modified-Since = HTTP-date
An example of the field is: An example of the field is:
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
A recipient MUST ignore If-Modified-Since if the request contains an A recipient MUST ignore If-Modified-Since if the request contains an
If-None-Match header field; the condition in If-None-Match is If-None-Match header field; the condition in If-None-Match is
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 If- interoperating with older intermediaries that might not implement If-
None-Match. 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, or if the request received field value is not a valid HTTP-date, or if the request
method is neither GET nor HEAD. method is neither GET nor HEAD.
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 field to generate the field value the cached message's Last-Modified field to generate the field value
of If-Modified-Since. This behavior is most interoperable for cases of If-Modified-Since. This behavior is most interoperable for cases
skipping to change at page 91, line 35 skipping to change at page 98, line 35
based on either its own local clock or a Date header field received based on either its own local clock or a Date header field received
from the server in a prior response. Origin servers that choose an from the server in a prior response. Origin servers that choose an
exact timestamp match based on the selected representation's Last- exact timestamp match based on the selected representation's Last-
Modified field will not be able to help the user agent limit its data Modified field will not be able to help the user agent limit its data
transfers to only those changed during the specified window. transfers to only those changed during the specified window.
An origin server that receives an If-Modified-Since header field An origin server that receives an If-Modified-Since header field
SHOULD evaluate the condition prior to performing the method SHOULD evaluate the condition prior to performing the method
(Section 8.2.1). The origin server SHOULD NOT perform the requested (Section 8.2.1). The origin server SHOULD NOT perform the requested
method if the selected representation's last modification date is method 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;
instead, the origin server SHOULD generate a 304 (Not Modified) instead, the origin server SHOULD generate a 304 (Not Modified)
response, including only those metadata that are useful for response, including only those metadata that are useful for
identifying or 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].
8.2.6. If-Unmodified-Since 8.2.6. 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
the user agent does not have an entity-tag for the representation. the user agent does not have an entity-tag for the representation.
If-Unmodified-Since = HTTP-date If-Unmodified-Since = HTTP-date
An example of the field is: An example of the field is:
If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
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. received field value is not a valid HTTP-date.
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 safe prevent the "lost update" problem). It can also be used with safe
methods to abort a request if the selected representation does not methods to abort a request if the selected representation does not
match one already stored (or partially stored) from a prior request. match one already stored (or partially stored) from a prior request.
An origin server that receives an If-Unmodified-Since header field An origin server that receives an If-Unmodified-Since header field
MUST evaluate the condition prior to performing the method MUST evaluate the condition prior to performing the method
(Section 8.2.1). The origin server MUST NOT perform the requested (Section 8.2.1). The origin server MUST NOT perform the requested
method if the selected representation's last modification date is method if the selected representation's last modification date is
more recent than the date provided in the field-value; instead the more recent than the date provided in the field value; instead the
origin server MUST respond with either a) the 412 (Precondition origin server MUST respond with either a) the 412 (Precondition
Failed) status code or b) one of the 2xx (Successful) status codes if Failed) status code or b) one of the 2xx (Successful) status codes if
the origin server has verified that a state change is being requested the origin server has verified that a state change is being requested
and the final state is already reflected in the current state of the and the final state is already reflected in the current state of the
target resource (i.e., the change requested by the user agent has target resource (i.e., the change requested by the user agent has
already succeeded, but the user agent might not be aware of that already succeeded, but the user agent might not be aware of that
because the prior response message was lost or a compatible change because the prior response message was lost or a compatible change
was made by some other user agent). In the latter case, the origin was made by some other user agent). In the latter case, the origin
server MUST NOT send a validator header field in the response unless server MUST NOT send a validator header field in the response unless
it can verify that the request is a duplicate of an immediately prior it can verify that the request is a duplicate of an immediately prior
skipping to change at page 95, line 4 skipping to change at page 102, line 4
byte ranges. byte ranges.
An origin server MUST ignore a Range header field that contains a An origin server MUST ignore a Range header field that contains a
range unit it does not understand. A proxy MAY discard a Range range unit it does not understand. A proxy MAY discard a Range
header field that contains a range unit it does not understand. header field that contains a range unit it does not understand.
A server that supports range requests MAY ignore or reject a Range A server that supports range requests MAY ignore or reject a Range
header field that consists of more than two overlapping ranges, or a header field that consists of more than two overlapping ranges, or a
set of many small ranges that are not listed in ascending order, set of many small ranges that are not listed in ascending order,
since both are indications of either a broken client or a deliberate since both are indications of either a broken client or a deliberate
denial-of-service attack (Section 13.13). A client SHOULD NOT denial-of-service attack (Section 11.13). A client SHOULD NOT
request multiple ranges that are inherently less efficient to process request multiple ranges that are inherently less efficient to process
and transfer than a single range that encompasses the same data. and transfer than a single range that encompasses the same data.
A client that is requesting multiple ranges SHOULD list those ranges A client that is requesting multiple ranges SHOULD list those ranges
in ascending order (the order in which they would typically be in ascending order (the order in which they would typically be
received in a complete representation) unless there is a specific received in a complete representation) unless there is a specific
need to request a later part earlier. For example, a user agent need to request a later part earlier. For example, a user agent
processing a large representation with an internal catalog of parts processing a large representation with an internal catalog of parts
might need to request later parts first, particularly if the might need to request later parts first, particularly if the
representation consists of pages stored in reverse order and the user representation consists of pages stored in reverse order and the user
skipping to change at page 96, line 5 skipping to change at page 103, line 5
8.4. Content Negotiation 8.4. Content Negotiation
The following request header fields are sent by a user agent to The following request header fields are sent by a user agent to
engage in proactive negotiation of the response content, as defined engage in proactive negotiation of the response content, as defined
in Section 6.4.1. The preferences sent in these fields apply to any in Section 6.4.1. The preferences sent in these fields apply to any
content in the response, including representations of the target content in the response, including representations of the target
resource, representations of error or processing status, and resource, representations of error or processing status, and
potentially even the miscellaneous text strings that might appear potentially even the miscellaneous text strings that might appear
within the protocol. within the protocol.
+-------------------+---------------+ +-----------------+---------------+
| Header Field Name | Defined in... | | Field Name | Defined in... |
+-------------------+---------------+ +-----------------+---------------+
| Accept | Section 8.4.2 | | Accept | Section 8.4.2 |
| Accept-Charset | Section 8.4.3 | | Accept-Charset | Section 8.4.3 |
| Accept-Encoding | Section 8.4.4 | | Accept-Encoding | Section 8.4.4 |
| Accept-Language | Section 8.4.5 | | Accept-Language | Section 8.4.5 |
+-------------------+---------------+ +-----------------+---------------+
For each of these header fields, a request that does not contain it For each of these header fields, a request that does not contain it
implies that the user agent has no preference on that axis of implies that the user agent has no preference on that axis of
negotiation. If the header field is present in a request and none of negotiation. If the header field is present in a request and none of
the available representations for the response can be considered the available representations for the response can be considered
acceptable according to it, the origin server can either honor the acceptable according to it, the origin server can either honor the
header field by sending a 406 (Not Acceptable) response or disregard header field by sending a 406 (Not Acceptable) response or disregard
the header field by treating the response as if it is not subject to the header field by treating the response as if it is not subject to
content negotiation for that request header field. This does not content negotiation for that request header field. This does not
imply, however, that the client will be able to use the imply, however, that the client will be able to use the
representation. representation.
Note: Sending these header fields makes it easier for a server to Note: Sending these header fields makes it easier for a server to
identify an individual by virtue of the user agent's request identify an individual by virtue of the user agent's request
characteristics (Section 13.11). characteristics (Section 11.11).
Each of these header fields defines a wildcard value (often, "*") to Each of these header fields defines a wildcard value (often, "*") to
select unspecified values. If no wildcard is present, all values not select unspecified values. If no wildcard is present, all values not
explicitly mentioned in the field are considered "not acceptable" to explicitly mentioned in the field are considered "not acceptable" to
the client. the client.
Note: In practice, using wildcards in content negotiation has limited Note: In practice, using wildcards in content negotiation has limited
practical value, because it is seldom useful to say, for example, "I practical value, because it is seldom useful to say, for example, "I
prefer image/* more or less than (some other specific value)". prefer image/* more or less than (some other specific value)".
Clients can explicitly request a 406 (Not Acceptable) response if a Clients can explicitly request a 406 (Not Acceptable) response if a
skipping to change at page 99, line 46 skipping to change at page 106, line 46
Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
The special value "*", if present in the Accept-Charset field, The special value "*", if present in the Accept-Charset field,
matches every charset that is not mentioned elsewhere in the Accept- matches every charset that is not mentioned elsewhere in the Accept-
Charset field. Charset field.
Note: Accept-Charset is deprecated because UTF-8 has become nearly Note: Accept-Charset is deprecated because UTF-8 has become nearly
ubiquitous and sending a detailed list of user-preferred charsets ubiquitous and sending a detailed list of user-preferred charsets
wastes bandwidth, increases latency, and makes passive fingerprinting wastes bandwidth, increases latency, and makes passive fingerprinting
far too easy (Section 13.11). Most general-purpose user agents do far too easy (Section 11.11). Most general-purpose user agents do
not send Accept-Charset, unless specifically configured to do so. not send Accept-Charset, unless specifically configured to do so.
8.4.4. Accept-Encoding 8.4.4. Accept-Encoding
The "Accept-Encoding" header field can be used by user agents to The "Accept-Encoding" header field can be used by user agents to
indicate their preferences regarding response content-codings indicate their preferences regarding response content-codings
(Section 6.1.2). An "identity" token is used as a synonym for "no (Section 6.1.2). An "identity" token is used as a synonym for "no
encoding" in order to communicate when no encoding is preferred. encoding" in order to communicate when no encoding is preferred.
Accept-Encoding = #( codings [ weight ] ) Accept-Encoding = #( codings [ weight ] )
skipping to change at page 100, line 41 skipping to change at page 107, line 41
1. If no Accept-Encoding field is in the request, any content-coding 1. If no Accept-Encoding field is in the request, any content-coding
is considered acceptable by the user agent. 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 field stating either "identity;q=0" or "*;q=0" without a Encoding field stating either "identity;q=0" or "*;q=0" without a
more specific entry for "identity". more specific entry for "identity".
3. If the representation's content-coding is one of the content- 3. If the representation's content-coding is one of the content-
codings listed in the Accept-Encoding field, then it is codings listed in the Accept-Encoding field value, then it is
acceptable unless it is accompanied by a qvalue of 0. (As acceptable unless it is accompanied by a qvalue of 0. (As
defined in Section 8.4.1, a qvalue of 0 means "not acceptable".) defined in Section 8.4.1, a qvalue of 0 means "not acceptable".)
4. If multiple content-codings are acceptable, then the acceptable 4. If multiple content-codings are acceptable, then the acceptable
content-coding with the highest non-zero qvalue is preferred. content-coding with the highest non-zero qvalue is preferred.
An Accept-Encoding header field with a combined field-value that is An Accept-Encoding header field with a field value that is empty
empty implies that the user agent does not want any content-coding in implies that the user agent does not want any content-coding in
response. If an Accept-Encoding header field is present in a request response. If an Accept-Encoding header field is present in a request
and none of the available representations for the response have a and none of the available representations for the response have a
content-coding that is listed as acceptable, the origin server SHOULD content-coding that is listed as acceptable, the origin server SHOULD
send a response without any content-coding. send a response without any content-coding.
Note: Most HTTP/1.0 applications do not recognize or obey qvalues Note: Most HTTP/1.0 applications do not recognize or obey qvalues
associated with content-codings. This means that qvalues might associated with content-codings. This means that qvalues might
not work and are not permitted with x-gzip or x-compress. not work and are not permitted with x-gzip or x-compress.
8.4.5. Accept-Language 8.4.5. Accept-Language
skipping to change at page 101, line 47 skipping to change at page 108, line 47
found in Section 2.3 of [RFC4647]. found in Section 2.3 of [RFC4647].
For matching, Section 3 of [RFC4647] defines several matching For matching, Section 3 of [RFC4647] defines several matching
schemes. Implementations can offer the most appropriate matching schemes. Implementations can offer the most appropriate matching
scheme for their requirements. The "Basic Filtering" scheme scheme for their requirements. The "Basic Filtering" scheme
([RFC4647], Section 3.3.1) is identical to the matching scheme that ([RFC4647], Section 3.3.1) is identical to the matching scheme that
was previously defined for HTTP in Section 14.4 of [RFC2616]. was previously defined for HTTP in Section 14.4 of [RFC2616].
It might be contrary to the privacy expectations of the user to send It might be contrary to the privacy expectations of the user to send
an Accept-Language header field with the complete linguistic an Accept-Language header field with the complete linguistic
preferences of the user in every request (Section 13.11). preferences of the user in every request (Section 11.11).
Since intelligibility is highly dependent on the individual user, Since intelligibility is highly dependent on the individual user,
user agents need to allow user control over the linguistic preference user agents need to allow user control over the linguistic preference
(either through configuration of the user agent itself or by (either through configuration of the user agent itself or by
defaulting to a user controllable system setting). A user agent that defaulting to a user controllable system setting). A user agent that
does not provide such control to the user MUST NOT send an Accept- does not provide such control to the user MUST NOT send an Accept-
Language header field. Language header field.
Note: User agents ought to provide guidance to users when setting Note: User agents ought to provide guidance to users when setting
a preference, since users are rarely familiar with the details of a preference, since users are rarely familiar with the details of
skipping to change at page 102, line 28 skipping to change at page 109, line 28
HTTP provides a general framework for access control and HTTP provides a general framework for access control and
authentication, via an extensible set of challenge-response authentication, via an extensible set of challenge-response
authentication schemes, which can be used by a server to challenge a authentication schemes, which can be used by a server to challenge a
client request and by a client to provide authentication information. client request and by a client to provide authentication information.
Two header fields are used for carrying authentication credentials. Two header fields are used for carrying authentication credentials.
Note that various custom mechanisms for user authentication use the Note that various custom mechanisms for user authentication use the
Cookie header field for this purpose, as defined in [RFC6265]. Cookie header field for this purpose, as defined in [RFC6265].
+---------------------+---------------+ +---------------------+---------------+
| Header Field Name | Defined in... | | Field Name | Defined in... |
+---------------------+---------------+ +---------------------+---------------+
| Authorization | Section 8.5.3 | | Authorization | Section 8.5.3 |
| Proxy-Authorization | Section 8.5.4 | | Proxy-Authorization | Section 8.5.4 |
+---------------------+---------------+ +---------------------+---------------+
8.5.1. Challenge and Response 8.5.1. Challenge and Response
HTTP provides a simple challenge-response authentication framework HTTP provides a simple challenge-response authentication framework
that can be used by a server to challenge a client request and by a that can be used by a server to challenge a client request and by a
client to provide authentication information. It uses a case- client to provide authentication information. It uses a case-
skipping to change at page 104, line 5 skipping to change at page 111, line 5
Both the Authorization field value and the Proxy-Authorization field Both the Authorization field value and the Proxy-Authorization field
value contain the client's credentials for the realm of the resource value contain the client's credentials for the realm of the resource
being requested, based upon a challenge received in a response being requested, based upon a challenge received in a response
(possibly at some point in the past). When creating their values, (possibly at some point in the past). When creating their values,
the user agent ought to do so by selecting the challenge with what it the user agent ought to do so by selecting the challenge with what it
considers to be the most secure auth-scheme that it understands, considers to be the most secure auth-scheme that it understands,
obtaining credentials from the user as appropriate. Transmission of obtaining credentials from the user as appropriate. Transmission of
credentials within header field values implies significant security credentials within header field values implies significant security
considerations regarding the confidentiality of the underlying considerations regarding the confidentiality of the underlying
connection, as described in Section 13.14.1. connection, as described in Section 11.14.1.
credentials = auth-scheme [ 1*SP ( token68 / #auth-param ) ] credentials = auth-scheme [ 1*SP ( token68 / #auth-param ) ]
Upon receipt of a request for a protected resource that omits Upon receipt of a request for a protected resource that omits
credentials, contains invalid credentials (e.g., a bad password) or credentials, contains invalid credentials (e.g., a bad password) or
partial credentials (e.g., when the authentication scheme requires partial credentials (e.g., when the authentication scheme requires
more than one round trip), an origin server SHOULD send a 401 more than one round trip), an origin server SHOULD send a 401
(Unauthorized) response that contains a WWW-Authenticate header field (Unauthorized) response that contains a WWW-Authenticate header field
with at least one (possibly new) challenge applicable to the with at least one (possibly new) challenge applicable to the
requested resource. requested resource.
skipping to change at page 104, line 41 skipping to change at page 111, line 41
authentication information. However, such additional mechanisms are authentication information. However, such additional mechanisms are
not defined by this specification. not defined by this specification.
8.5.2. Protection Space (Realm) 8.5.2. Protection Space (Realm)
The "realm" authentication parameter is reserved for use by The "realm" authentication parameter is reserved for use by
authentication schemes that wish to indicate a scope of protection. authentication schemes that wish to indicate a scope of protection.
A protection space is defined by the canonical root URI (the scheme A protection space is defined by the canonical root URI (the scheme
and authority components of the effective request URI; see and authority components of the effective request URI; see
Section 5.3) of the server being accessed, in combination with the Section 5.5) of the server being accessed, in combination with the
realm value if present. These realms allow the protected resources realm value if present. These realms allow the protected resources
on a server to be partitioned into a set of protection spaces, each on a server to be partitioned into a set of protection spaces, each
with its own authentication scheme and/or authorization database. with its own authentication scheme and/or authorization database.
The realm value is a string, generally assigned by the origin server, The realm value is a string, generally assigned by the origin server,
that can have additional semantics specific to the authentication that can have additional semantics specific to the authentication
scheme. Note that a response can have multiple challenges with the scheme. Note that a response can have multiple challenges with the
same auth-scheme but with different realms. same auth-scheme but with different realms.
The protection space determines the domain over which credentials can The protection space determines the domain over which credentials can
be automatically applied. If a prior request has been authorized, be automatically applied. If a prior request has been authorized,
skipping to change at page 108, line 4 skipping to change at page 115, line 4
defining new parameters (such as "update the specification" or defining new parameters (such as "update the specification" or
"use this registry"). "use this registry").
o Authentication schemes need to document whether they are usable in o Authentication schemes need to document whether they are usable in
origin-server authentication (i.e., using WWW-Authenticate), and/ origin-server authentication (i.e., using WWW-Authenticate), and/
or proxy authentication (i.e., using Proxy-Authenticate). or proxy authentication (i.e., using Proxy-Authenticate).
o The credentials carried in an Authorization header field are o The credentials carried in an Authorization header field are
specific to the user agent and, therefore, have the same effect on specific to the user agent and, therefore, have the same effect on
HTTP caches as the "private" Cache-Control response directive HTTP caches as the "private" Cache-Control response directive
(Section 5.2.2.6 of [Caching]), within the scope of the request in (Section 5.2.2.7 of [Caching]), within the scope of the request in
which they appear. which they appear.
Therefore, new authentication schemes that choose not to carry Therefore, new authentication schemes that choose not to carry
credentials in the Authorization header field (e.g., using a newly credentials in the Authorization header field (e.g., using a newly
defined header field) will need to explicitly disallow caching, by defined header field) will need to explicitly disallow caching, by
mandating the use of Cache-Control response directives (e.g., mandating the use of Cache-Control response directives (e.g.,
"private"). "private").
o Schemes using Authentication-Info, Proxy-Authentication-Info, or o Schemes using Authentication-Info, Proxy-Authentication-Info, or
any other authentication related response header field need to any other authentication related response header field need to
consider and document the related security considerations (see consider and document the related security considerations (see
Section 13.14.4). Section 11.14.4).
8.6. Request Context 8.6. Request Context
The following request header fields provide additional information The following request header fields provide additional information
about the request context, including information about the user, user about the request context, including information about the user, user
agent, and resource behind the request. agent, and resource behind the request.
+-------------------+---------------+ +------------+---------------+
| Header Field Name | Defined in... | | Field Name | Defined in... |
+-------------------+---------------+ +------------+---------------+
| From | Section 8.6.1 | | From | Section 8.6.1 |
| Referer | Section 8.6.2 | | Referer | Section 8.6.2 |
| User-Agent | Section 8.6.3 | | User-Agent | Section 8.6.3 |
+-------------------+---------------+ +------------+---------------+
8.6.1. From 8.6.1. From
The "From" header field contains an Internet email address for a The "From" header field contains an Internet email address for a
human user who controls the requesting user agent. The address ought human user who controls the requesting user agent. The address ought
to be machine-usable, as defined by "mailbox" in Section 3.4 of to be machine-usable, as defined by "mailbox" in Section 3.4 of
[RFC5322]: [RFC5322]:
From = mailbox From = mailbox
skipping to change at page 110, line 7 skipping to change at page 117, line 7
The Referer field has the potential to reveal information about the The Referer field has the potential to reveal information about the
request context or browsing history of the user, which is a privacy request context or browsing history of the user, which is a privacy
concern if the referring resource's identifier reveals personal concern if the referring resource's identifier reveals personal
information (such as an account name) or a resource that is supposed information (such as an account name) or a resource that is supposed
to be confidential (such as behind a firewall or internal to a to be confidential (such as behind a firewall or internal to a
secured service). Most general-purpose user agents do not send the secured service). Most general-purpose user agents do not send the
Referer header field when the referring resource is a local "file" or Referer header field when the referring resource is a local "file" or
"data" URI. A user agent MUST NOT send a Referer header field in an "data" URI. A user agent MUST NOT send a Referer header field in an
unsecured HTTP request if the referring page was received with a unsecured HTTP request if the referring page was received with a
secure protocol. See Section 13.8 for additional security secure protocol. See Section 11.8 for additional security
considerations. considerations.
Some intermediaries have been known to indiscriminately remove Some intermediaries have been known to indiscriminately remove
Referer header fields from outgoing requests. This has the Referer header fields from outgoing requests. This has the
unfortunate side effect of interfering with protection against CSRF unfortunate side effect of interfering with protection against CSRF
attacks, which can be far more harmful to their users. attacks, which can be far more harmful to their users.
Intermediaries and user agent extensions that wish to limit Intermediaries and user agent extensions that wish to limit
information disclosure in Referer ought to restrict their changes to information disclosure in Referer ought to restrict their changes to
specific edits, such as replacing internal domain names with specific edits, such as replacing internal domain names with
pseudonyms or truncating the query and/or path components. An pseudonyms or truncating the query and/or path components. An
skipping to change at page 110, line 34 skipping to change at page 117, line 34
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 field in each request use. A user agent SHOULD send a User-Agent field in each request
unless specifically configured not to do so. unless specifically configured not to do so.
User-Agent = product *( RWS ( product / comment ) ) User-Agent = product *( RWS ( product / comment ) )
The User-Agent field-value consists of one or more product The User-Agent field value consists of one or more product
identifiers, each followed by zero or more comments identifiers, each followed by zero or more comments
(Section 4.2.3.3), which together identify the user agent software (Section 4.4.1.3), which together identify the user agent software
and its significant subproducts. By convention, the product and its significant subproducts. By convention, the product
identifiers are listed in decreasing order of their significance for identifiers are listed in decreasing order of their significance for
identifying the user agent software. Each product identifier identifying the user agent software. Each product identifier
consists of a name and optional version. consists of a name and optional version.
product = token ["/" product-version] product = token ["/" product-version]
product-version = token product-version = token
A sender SHOULD limit generated product identifiers to what is A sender SHOULD limit generated product identifiers to what is
necessary to identify the product; a sender MUST NOT generate necessary to identify the product; a sender MUST NOT generate
skipping to change at page 111, line 33 skipping to change at page 118, line 33
9. Response Status Codes 9. Response Status Codes
The (response) status code is a three-digit integer code giving the The (response) status code is a three-digit integer code giving the
result of the attempt to understand and satisfy the request. result of the attempt to understand and satisfy the request.
HTTP status codes are extensible. HTTP clients are not required to HTTP status codes are extensible. HTTP clients are not required to
understand the meaning of all registered status codes, though such understand the meaning of all registered status codes, though such
understanding is obviously desirable. However, a client MUST understanding is obviously desirable. However, a client MUST
understand the class of any status code, as indicated by the first understand the class of any status code, as indicated by the first
digit, and treat an unrecognized status code as being equivalent to digit, and treat an unrecognized status code as being equivalent to
the x00 status code of that class, with the exception that a the x00 status code of that class.
recipient MUST NOT cache a response with an unrecognized status code.
For example, if an unrecognized status code of 471 is received by a For example, if an unrecognized status code of 471 is received by a
client, the client can assume that there was something wrong with its client, the client can assume that there was something wrong with its
request and treat the response as if it had received a 400 (Bad request and treat the response as if it had received a 400 (Bad
Request) status code. The response message will usually contain a Request) status code. The response message will usually contain a
representation that explains the status. representation that explains the status.
The first digit of the status code defines the class of response. The first digit of the status code defines the class of response.
The last two digits do not have any categorization role. There are The last two digits do not have any categorization role. There are
five values for the first digit: five values for the first digit:
skipping to change at page 112, line 11 skipping to change at page 119, line 11
o 3xx (Redirection): Further action needs to be taken in order to o 3xx (Redirection): Further action needs to be taken in order to
complete the request complete the request
o 4xx (Client Error): The request contains bad syntax or cannot be o 4xx (Client Error): The request contains bad syntax or cannot be
fulfilled fulfilled
o 5xx (Server Error): The server failed to fulfill an apparently o 5xx (Server Error): The server failed to fulfill an apparently
valid request valid request
A single request can have multiple associated responses: zero or more
interim (non-final) responses with status codes in the
"informational" (1xx) range, followed by exactly one final response
with a status code in one of the other ranges.
9.1. Overview of Status Codes 9.1. Overview of Status Codes
The status codes listed below are defined in this specification. The The status codes listed below are defined in this specification. The
reason phrases listed here are only recommendations -- they can be reason phrases listed here are only recommendations -- they can be
replaced by local equivalents without affecting the protocol. replaced by local equivalents without affecting the protocol.
Responses with status codes that are defined as heuristically Responses with status codes that are defined as heuristically
cacheable (e.g., 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, cacheable (e.g., 200, 203, 204, 206, 300, 301, 404, 405, 410, 414,
and 501 in this specification) can be reused by a cache with and 501 in this specification) can be reused by a cache with
heuristic expiration unless otherwise indicated by the method heuristic expiration unless otherwise indicated by the method
skipping to change at page 116, line 16 skipping to change at page 123, line 19
until the process is completed. The representation sent with this until the process is completed. The representation sent with this
response ought to describe the request's current status and point to response ought to describe the request's current status and point to
(or embed) a status monitor that can provide the user with an (or embed) a status monitor that can provide the user with an
estimate of when the request will be fulfilled. estimate of when the request will be fulfilled.
9.3.4. 203 Non-Authoritative Information 9.3.4. 203 Non-Authoritative Information
The 203 (Non-Authoritative Information) status code indicates that The 203 (Non-Authoritative Information) status code indicates that
the request was successful but the enclosed payload has been modified the request was successful but the enclosed payload has been modified
from that of the origin server's 200 (OK) response by a transforming from that of the origin server's 200 (OK) response by a transforming
proxy (Section 5.5.2). This status code allows the proxy to notify proxy (Section 5.7.2). This status code allows the proxy to notify
recipients when a transformation has been applied, since that recipients when a transformation has been applied, since that
knowledge might impact later decisions regarding the content. For knowledge might impact later decisions regarding the content. For
example, future cache validation requests for the content might only example, future cache validation requests for the content might only
be applicable along the same request path (through the same proxies). be applicable along the same request path (through the same proxies).
The 203 response is similar to the Warning code of 214 Transformation The 203 response is similar to the Warning code of 214 Transformation
Applied (Section 5.5 of [Caching]), which has the advantage of being Applied (Section 5.5 of [Caching]), which has the advantage of being
applicable to responses with any status code. applicable to responses with any status code.
A 203 response is heuristically cacheable; i.e., unless otherwise A 203 response is heuristically cacheable; i.e., unless otherwise
skipping to change at page 116, line 39 skipping to change at page 123, line 42
9.3.5. 204 No Content 9.3.5. 204 No Content
The 204 (No Content) status code indicates that the server has The 204 (No Content) status code indicates that the server has
successfully fulfilled the request and that there is no additional successfully fulfilled the request and that there is no additional
content to send in the response payload body. Metadata in the content to send in the response payload body. Metadata in the
response header fields refer to the target resource and its selected response header fields refer to the target resource and its selected
representation after the requested action was applied. representation after the requested action was applied.
For example, if a 204 status code is received in response to a PUT For example, if a 204 status code is received in response to a PUT
request and the response contains an ETag header field, then the PUT request and the response contains an ETag field, then the PUT was
was successful and the ETag field-value contains the entity-tag for successful and the ETag field value contains the entity-tag for the
the new representation of that target resource. new representation of that target resource.
The 204 response allows a server to indicate that the action has been The 204 response allows a server to indicate that the action has been
successfully applied to the target resource, while implying that the successfully applied to the target resource, while implying that the
user agent does not need to traverse away from its current "document user agent does not need to traverse away from its current "document
view" (if any). The server assumes that the user agent will provide view" (if any). The server assumes that the user agent will provide
some indication of the success to its user, in accord with its own some indication of the success to its user, in accord with its own
interface, and apply any new or updated metadata in the response to interface, and apply any new or updated metadata in the response to
its active representation. its active representation.
For example, a 204 status code is commonly used with document editing For example, a 204 status code is commonly used with document editing
skipping to change at page 122, line 51 skipping to change at page 129, line 51
A 300 response is heuristically cacheable; i.e., unless otherwise A 300 response is heuristically cacheable; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [Caching]). Section 4.2.2 of [Caching]).
Note: The original proposal for the 300 status code defined the Note: The original proposal for the 300 status code defined the
URI header field as providing a list of alternative URI header field as providing a list of alternative
representations, such that it would be usable for 200, 300, and representations, such that it would be usable for 200, 300, and
406 responses and be transferred in responses to the HEAD method. 406 responses and be transferred in responses to the HEAD method.
However, lack of deployment and disagreement over syntax led to However, lack of deployment and disagreement over syntax led to
both URI and Alternates (a subsequent proposal) being dropped from both URI and Alternates (a subsequent proposal) being dropped from
this specification. It is possible to communicate the list using this specification. It is possible to communicate the list as a
a set of Link header fields [RFC8288], each with a relationship of Link header field value [RFC8288] whose members have a
"alternate", though deployment is a chicken-and-egg problem. relationship of "alternate", though deployment is a chicken-and-
egg problem.
9.4.2. 301 Moved Permanently 9.4.2. 301 Moved Permanently
The 301 (Moved Permanently) status code indicates that the target The 301 (Moved Permanently) status code indicates that the target
resource has been assigned a new permanent URI and any future resource has been assigned a new permanent URI and any future
references to this resource ought to use one of the enclosed URIs. references to this resource ought to use one of the enclosed URIs.
Clients with link-editing capabilities ought to automatically re-link Clients with link-editing capabilities ought to automatically re-link
references to the effective request URI to one or more of the new references to the effective request URI to one or more of the new
references sent by the server, where possible. references sent by the server, where possible.
skipping to change at page 131, line 52 skipping to change at page 138, line 52
9.5.19. 418 (Unused) 9.5.19. 418 (Unused)
[RFC2324] was an April 1 RFC that lampooned the various ways HTTP was [RFC2324] was an April 1 RFC that lampooned the various ways HTTP was
abused; one such abuse was the definition of an application-specific abused; one such abuse was the definition of an application-specific
418 status code. In the intervening years, this status code has been 418 status code. In the intervening years, this status code has been
widely implemented as an "Easter Egg", and therefore is effectively widely implemented as an "Easter Egg", and therefore is effectively
consumed by this use. consumed by this use.
Therefore, the 418 status code is reserved in the IANA HTTP Status Therefore, the 418 status code is reserved in the IANA HTTP Status
Code registry. This indicates that the status code cannot be Code Registry. This indicates that the status code cannot be
assigned to other applications currently. If future circumstances assigned to other applications currently. If future circumstances
require its use (e.g., exhaustion of 4NN status codes), it can be re- require its use (e.g., exhaustion of 4NN status codes), it can be re-
assigned to another use. assigned to another use.
9.5.20. 422 Unprocessable Payload 9.5.20. 422 Unprocessable Payload
The 422 (Unprocessable Payload) status code indicates that the server The 422 (Unprocessable Payload) status code indicates that the server
understands the content type of the request payload (hence a 415 understands the content type of the request payload (hence a 415
(Unsupported Media Type) status code is inappropriate), and the (Unsupported Media Type) status code is inappropriate), and the
syntax of the request payload is correct, but was unable to process syntax of the request payload is correct, but was unable to process
skipping to change at page 135, line 12 skipping to change at page 142, line 12
to avoid allocating a specific number for the code until there is to avoid allocating a specific number for the code until there is
clear consensus that it will be registered; instead, early drafts can clear consensus that it will be registered; instead, early drafts can
use a notation such as "4NN", or "3N0" .. "3N9", to indicate the use a notation such as "4NN", or "3N0" .. "3N9", to indicate the
class of the proposed status code(s) without consuming a number class of the proposed status code(s) without consuming a number
prematurely. prematurely.
The definition of a new status code ought to explain the request The definition of a new status code ought to explain the request
conditions that would cause a response containing that status code conditions that would cause a response containing that status code
(e.g., combinations of request header fields and/or method(s)) along (e.g., combinations of request header fields and/or method(s)) along
with any dependencies on response header fields (e.g., what fields with any dependencies on response header fields (e.g., what fields
are required, what fields can modify the semantics, and what header are required, what fields can modify the semantics, and what field
field semantics are further refined when used with the new status semantics are further refined when used with the new status code).
code).
The definition of a new status code ought to specify whether or not The definition of a new status code ought to specify whether or not
it is cacheable. Note that all status codes can be cached if the it is cacheable. Note that all status codes can be cached if the
response they occur in has explicit freshness information; however, response they occur in has explicit freshness information; however,
status codes that are defined as being cacheable are allowed to be status codes that are defined as being cacheable are allowed to be
cached without explicit freshness information. Likewise, the cached without explicit freshness information. Likewise, the
definition of a status code can place constraints upon cache definition of a status code can place constraints upon cache
behavior. See [Caching] for more information. behavior. See [Caching] for more information.
Finally, the definition of a new status code ought to indicate Finally, the definition of a new status code ought to indicate
skipping to change at page 136, line 5 skipping to change at page 143, line 5
Although each response header field has a defined meaning, in Although each response header field has a defined meaning, in
general, the precise semantics might be further refined by the general, the precise semantics might be further refined by the
semantics of the request method and/or response status code. semantics of the request method and/or response status code.
10.1. Control Data 10.1. Control Data
Response header fields can supply control data that supplements the Response header fields can supply control data that supplements the
status code, directs caching, or instructs the client where to go status code, directs caching, or instructs the client where to go
next. next.
+-------------------+--------------------------+ +---------------+--------------------------+
| Header Field Name | Defined in... | | Field Name | Defined in... |
+-------------------+--------------------------+ +---------------+--------------------------+
| Age | Section 5.1 of [Caching] | | Age | Section 5.1 of [Caching] |
| Cache-Control | Section 5.2 of [Caching] | | Cache-Control | Section 5.2 of [Caching] |
| Expires | Section 5.3 of [Caching] | | Expires | Section 5.3 of [Caching] |
| Date | Section 10.1.1.2 | | Date | Section 10.1.1.2 |
| Location | Section 10.1.2 | | Location | Section 10.1.2 |
| Retry-After | Section 10.1.3 | | Retry-After | Section 10.1.3 |
| Vary | Section 10.1.4 | | Vary | Section 10.1.4 |
| Warning | Section 5.5 of [Caching] | | Warning | Section 5.5 of [Caching] |
+-------------------+--------------------------+ +---------------+--------------------------+
10.1.1. Origination Date 10.1.1. Origination Date
10.1.1.1. Date/Time Formats 10.1.1.1. Date/Time Formats
Prior to 1995, there were three different formats commonly used by Prior to 1995, there were three different formats commonly used by
servers to communicate timestamps. For compatibility with old servers to communicate timestamps. For compatibility with old
implementations, all three are defined here. The preferred format is implementations, all three are defined here. The preferred format is
a fixed-length and single-zone subset of the date and time a fixed-length and single-zone subset of the date and time
specification used by the Internet Message Format [RFC5322]. specification used by the Internet Message Format [RFC5322].
skipping to change at page 136, line 39 skipping to change at page 143, line 39
An example of the preferred format is An example of the preferred format is
Sun, 06 Nov 1994 08:49:37 GMT ; IMF-fixdate Sun, 06 Nov 1994 08:49:37 GMT ; IMF-fixdate
Examples of the two obsolete formats are Examples of the two obsolete formats are
Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format
Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
A recipient that parses a timestamp value in an HTTP header field A recipient that parses a timestamp value in an HTTP field MUST
MUST accept all three HTTP-date formats. When a sender generates a accept all three HTTP-date formats. When a sender generates a field
header field that contains one or more timestamps defined as HTTP- that contains one or more timestamps defined as HTTP-date, the sender
date, the sender MUST generate those timestamps in the IMF-fixdate MUST generate those timestamps in the IMF-fixdate format.
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. A sender that generates HTTP-date values from a local
clock ought to use NTP ([RFC5905]) or some similar protocol to clock ought to use NTP ([RFC5905]) or some similar protocol to
synchronize its clock to UTC. synchronize its clock to UTC.
Preferred format: Preferred format:
skipping to change at page 141, line 24 skipping to change at page 148, line 18
Vary = "*" / 1#field-name Vary = "*" / 1#field-name
A Vary field value of "*" signals that anything about the request A Vary field value of "*" signals that anything about the request
might play a role in selecting the response representation, possibly might play a role in selecting the response representation, possibly
including elements outside the message syntax (e.g., the client's including elements outside the message syntax (e.g., the client's
network address). A recipient will not be able to determine whether network address). A recipient will not be able to determine whether
this response is appropriate for a later request without forwarding this response is appropriate for a later request without forwarding
the request to the origin server. A proxy MUST NOT generate a Vary the request to the origin server. A proxy MUST NOT generate a Vary
field with a "*" value. field with a "*" value.
A Vary field value consisting of a comma-separated list of names A Vary field value consisting of a list of field names indicates that
indicates that the named request header fields, known as the the named request header fields, known as the selecting header
selecting header fields, might have a role in selecting the fields, might have a role in selecting the representation. The
representation. The potential selecting header fields are not potential selecting header fields are not limited to those defined by
limited to those defined by this specification. this specification.
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 fields (or lack thereof) as Accept-Encoding and Accept-Language fields (or lack thereof) as
determining factors while choosing the content for this response. determining factors while choosing the content for this response.
An origin server might send Vary with a list of fields for two An origin server might send Vary with a list of fields for two
skipping to change at page 142, line 33 skipping to change at page 149, line 31
fields describe the selected representation chosen by the origin fields describe the selected representation chosen by the origin
server while handling the response. Note that, depending on the server while handling the response. Note that, depending on the
status code semantics, the selected representation for a given status code semantics, the selected representation for a given
response is not necessarily the same as the representation enclosed response is not necessarily the same as the representation enclosed
as response payload. as response payload.
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 header field in a 201 (Created) response For example, an ETag field in a 201 (Created) response communicates
communicates the entity-tag of the newly created resource's the entity-tag of the newly created resource's representation, so
representation, so that it can be used in later conditional requests that it can be used in later conditional requests to prevent the
to prevent the "lost update" problem Section 8.2. "lost update" problem Section 8.2.
+-------------------+----------------+ +---------------+----------------+
| Header Field Name | Defined in... | | Field Name | Defined in... |
+-------------------+----------------+ +---------------+----------------+
| ETag | Section 10.2.3 | | ETag | Section 10.2.3 |
| Last-Modified | Section 10.2.2 | | Last-Modified | Section 10.2.2 |
+-------------------+----------------+ +---------------+----------------+
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 10.2.2) and opaque entity tags modification dates (Section 10.2.2) and opaque entity tags
(Section 10.2.3). Additional metadata that reflects resource state (Section 10.2.3). Additional metadata that reflects resource state
has been defined by various extensions of HTTP, such as Web has been defined by various extensions of HTTP, such as Web
Distributed Authoring and Versioning (WebDAV, [RFC4918]), that are Distributed Authoring and Versioning (WebDAV, [RFC4918]), that are
beyond the scope of this specification. A resource metadata value is beyond the scope of this specification. A resource metadata value is
referred to as a "validator" when it is used within a precondition. referred to as a "validator" when it is used within a precondition.
skipping to change at page 146, line 47 skipping to change at page 153, line 44
same Last-Modified time, then at least one of those responses would same Last-Modified time, then at least one of those responses would
have a Date value equal to its Last-Modified time. The arbitrary have a Date value equal to its Last-Modified time. The arbitrary
60-second limit guards against the possibility that the Date and 60-second limit guards against the possibility that the Date and
Last-Modified values are generated from different clocks or at Last-Modified values are generated from different clocks or at
somewhat different times during the preparation of the response. An somewhat different times during the preparation of the response. An
implementation MAY use a value larger than 60 seconds, if it is implementation MAY use a value larger than 60 seconds, if it is
believed that 60 seconds is too short. believed that 60 seconds is too short.
10.2.3. ETag 10.2.3. ETag
The "ETag" header field in a response provides the current entity-tag The "ETag" field in a response provides the current entity-tag for
for the selected representation, as determined at the conclusion of the selected representation, as determined at the conclusion of
handling the request. An entity-tag is an opaque validator for handling the request. An entity-tag is an opaque validator for
differentiating between multiple representations of the same differentiating between multiple representations of the same
resource, regardless of whether those multiple representations are resource, regardless of whether those multiple representations are
due to resource state changes over time, content negotiation due to resource state changes over time, content negotiation
resulting in multiple representations being valid at the same time, resulting in multiple representations being valid at the same time,
or both. An entity-tag consists of an opaque quoted string, possibly or both. An entity-tag consists of an opaque quoted string, possibly
prefixed by a weakness indicator. prefixed by a weakness indicator.
ETag = entity-tag ETag = entity-tag
skipping to change at page 147, line 40 skipping to change at page 154, line 37
ETag: W/"xyzzy" ETag: W/"xyzzy"
ETag: "" ETag: ""
An entity-tag can be either a weak or strong validator, with strong An entity-tag can be either a weak or strong validator, with strong
being the default. If an origin server provides an entity-tag for a being the default. If an origin server provides an entity-tag for a
representation and the generation of that entity-tag does not satisfy representation and the generation of that entity-tag does not satisfy
all of the characteristics of a strong validator (Section 10.2.1), all of the characteristics of a strong validator (Section 10.2.1),
then the origin server MUST mark the entity-tag as weak by prefixing then the origin server MUST mark the entity-tag as weak by prefixing
its opaque value with "W/" (case-sensitive). its opaque value with "W/" (case-sensitive).
A sender MAY send the Etag field in a trailer section (see
Section 4.6). However, since trailers are often ignored, it is
preferable to send Etag as a header field unless the entity-tag is
generated while sending the message body.
10.2.3.1. Generation 10.2.3.1. Generation
The principle behind entity-tags is that only the service author The principle behind entity-tags is that only the service author
knows the implementation of a resource well enough to select the most knows the implementation of a resource well enough to select the most
accurate and efficient validation mechanism for that resource, and accurate and efficient validation mechanism for that resource, and
that any such mechanism can be mapped to a simple sequence of octets that any such mechanism can be mapped to a simple sequence of octets
for easy comparison. Since the value is opaque, there is no need for for easy comparison. Since the value is opaque, there is no need for
the client to be aware of how each entity-tag is constructed. the client to be aware of how each entity-tag is constructed.
For example, a resource that has implementation-specific versioning For example, a resource that has implementation-specific versioning
skipping to change at page 150, line 48 skipping to change at page 157, line 48
an entity-tag and a Last-Modified value have been provided by the 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 origin server. This allows both HTTP/1.0 and HTTP/1.1 caches to
respond appropriately. respond appropriately.
10.3. Authentication Challenges 10.3. Authentication Challenges
Authentication challenges indicate what mechanisms are available for Authentication challenges indicate what mechanisms are available for
the client to provide authentication credentials in future requests. the client to provide authentication credentials in future requests.
+--------------------+----------------+ +--------------------+----------------+
| Header Field Name | Defined in... | | Field Name | Defined in... |
+--------------------+----------------+ +--------------------+----------------+
| WWW-Authenticate | Section 10.3.1 | | WWW-Authenticate | Section 10.3.1 |
| Proxy-Authenticate | Section 10.3.2 | | Proxy-Authenticate | Section 10.3.2 |
+--------------------+----------------+ +--------------------+----------------+
Furthermore, the "Authentication-Info" and "Proxy-Authentication- Furthermore, the "Authentication-Info" and "Proxy-Authentication-
Info" response header fields are defined for use in authentication Info" response header fields are defined for use in authentication
schemes that need to return information once the client's schemes that need to return information once the client's
authentication credentials have been accepted. authentication credentials have been accepted.
+---------------------------+----------------+ +---------------------------+----------------+
| Header Field Name | Defined in... | | Field Name | Defined in... |
+---------------------------+----------------+ +---------------------------+----------------+
| Authentication-Info | Section 10.3.3 | | Authentication-Info | Section 10.3.3 |
| Proxy-Authentication-Info | Section 10.3.4 | | Proxy-Authentication-Info | Section 10.3.4 |
+---------------------------+----------------+ +---------------------------+----------------+
10.3.1. WWW-Authenticate 10.3.1. WWW-Authenticate
The "WWW-Authenticate" header field indicates the authentication The "WWW-Authenticate" header field indicates the authentication
scheme(s) and parameters applicable to the target resource. scheme(s) and parameters applicable to the target resource.
skipping to change at page 152, line 11 skipping to change at page 159, line 11
well. Therefore, a sequence of comma, whitespace, and comma can well. Therefore, a sequence of comma, whitespace, and comma can
be considered either as applying to the preceding challenge, or to be considered either as applying to the preceding challenge, or to
be an empty entry in the list of challenges. In practice, this be an empty entry in the list of challenges. In practice, this
ambiguity does not affect the semantics of the header field value ambiguity does not affect the semantics of the header field value
and thus is harmless. and thus is harmless.
10.3.2. Proxy-Authenticate 10.3.2. Proxy-Authenticate
The "Proxy-Authenticate" header field consists of at least one The "Proxy-Authenticate" header field consists of at least one
challenge that indicates the authentication scheme(s) and parameters challenge that indicates the authentication scheme(s) and parameters
applicable to the proxy for this effective request URI (Section 5.3). applicable to the proxy for this effective request URI (Section 5.5).
A proxy MUST send at least one Proxy-Authenticate header field in A proxy MUST send at least one Proxy-Authenticate header field in
each 407 (Proxy Authentication Required) response that it generates. each 407 (Proxy Authentication Required) response that it generates.
Proxy-Authenticate = 1#challenge Proxy-Authenticate = 1#challenge
Unlike WWW-Authenticate, the Proxy-Authenticate header field applies Unlike WWW-Authenticate, the Proxy-Authenticate header field applies
only to the next outbound client on the response chain. This is only to the next outbound client on the response chain. This is
because only the client that chose a given proxy is likely to have because only the client that chose a given proxy is likely to have
the credentials necessary for authentication. However, when multiple the credentials necessary for authentication. However, when multiple
proxies are used within the same administrative domain, such as proxies are used within the same administrative domain, such as
skipping to change at page 153, line 16 skipping to change at page 160, line 16
A proxy forwarding a response is not allowed to modify the field A proxy forwarding a response is not allowed to modify the field
value in any way. value in any way.
Authentication-Info can be used inside trailers (Section 7.1.2 of Authentication-Info can be used inside trailers (Section 7.1.2 of
[Messaging]) when the authentication scheme explicitly allows this. [Messaging]) when the authentication scheme explicitly allows this.
10.3.3.1. Parameter Value Format 10.3.3.1. Parameter Value Format
Parameter values can be expressed either as "token" or as "quoted- Parameter values can be expressed either as "token" or as "quoted-
string" (Section 4.2.3). string" (Section 4.4.1).
Authentication scheme definitions need to allow both notations, both Authentication scheme definitions need to allow both notations, both
for senders and recipients. This allows recipients to use generic for senders and recipients. This allows recipients to use generic
parsing components, independent of the authentication scheme in use. parsing components, independent of the authentication scheme in use.
For backwards compatibility, authentication scheme definitions can For backwards compatibility, authentication scheme definitions can
restrict the format for senders to one of the two variants. This can restrict the format for senders to one of the two variants. This can
be important when it is known that deployed implementations will fail be important when it is known that deployed implementations will fail
when encountering one of the two formats. when encountering one of the two formats.
skipping to change at page 154, line 10 skipping to change at page 161, line 10
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.
10.4. Response Context 10.4. Response Context
The remaining response header fields provide more information about The remaining response header fields provide more information about
the target resource for potential use in later requests. the target resource for potential use in later requests.
+-------------------+----------------+ +---------------+----------------+
| Header Field Name | Defined in... | | Field Name | Defined in... |
+-------------------+----------------+ +---------------+----------------+
| Accept-Ranges | Section 10.4.1 | | Accept-Ranges | Section 10.4.1 |
| Allow | Section 10.4.2 | | Allow | Section 10.4.2 |
| Server | Section 10.4.3 | | Server | Section 10.4.3 |
+-------------------+----------------+ +---------------+----------------+
10.4.1. Accept-Ranges 10.4.1. Accept-Ranges
The "Accept-Ranges" header field allows a server to indicate that it The "Accept-Ranges" header field allows a server to indicate that it
supports range requests for the target resource. supports range requests for the target resource.
Accept-Ranges = acceptable-ranges Accept-Ranges = acceptable-ranges
acceptable-ranges = 1#range-unit / "none" acceptable-ranges = 1#range-unit / "none"
An origin server that supports byte-range requests for a given target An origin server that supports byte-range requests for a given target
skipping to change at page 155, line 30 skipping to change at page 162, line 30
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 field in its system use. An origin server MAY generate a Server field in its
responses. responses.
Server = product *( RWS ( product / comment ) ) Server = product *( RWS ( product / comment ) )
The Server field-value consists of one or more product identifiers, The Server field value consists of one or more product identifiers,
each followed by zero or more comments (Section 4.2.3.3), which each followed by zero or more comments (Section 4.4.1.3), which
together identify the origin server software and its significant together identify the origin server software and its significant
subproducts. By convention, the product identifiers are listed in subproducts. By convention, the product identifiers are listed in
decreasing order of their significance for identifying the origin decreasing order of their significance for identifying the origin
server software. Each product identifier consists of a name and server software. Each product identifier consists of a name and
optional version, as defined in Section 8.6.3. optional version, as defined in Section 8.6.3.
Example: Example:
Server: CERN/3.0 libwww/2.17 Server: CERN/3.0 libwww/2.17
An origin server SHOULD NOT generate a Server field containing An origin server SHOULD NOT generate a Server 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
attackers to find and exploit known security holes. attackers to find and exploit known security holes.
11. Generic Syntax 11. Security Considerations
11.1. Whitespace
This specification uses three rules to denote the use of linear
whitespace: OWS (optional whitespace), RWS (required whitespace), and
BWS ("bad" whitespace).
The OWS rule is used where zero or more linear whitespace octets
might appear. For protocol elements where optional whitespace is
preferred to improve readability, a sender SHOULD generate the
optional whitespace as a single SP; otherwise, a sender SHOULD NOT
generate optional whitespace except as needed to white out invalid or
unwanted protocol elements during in-place message filtering.
The RWS rule is used when at least one linear whitespace octet is
required to separate field tokens. A sender SHOULD generate RWS as a
single SP.
The BWS rule is used where the grammar allows optional whitespace
only for historical reasons. A sender MUST NOT generate BWS in
messages. A recipient MUST parse for such bad whitespace and remove
it before interpreting the protocol element.
OWS = *( SP / HTAB )
; optional whitespace
RWS = 1*( SP / HTAB )
; required whitespace
BWS = OWS
; "bad" whitespace
12. ABNF List Extension: #rule
A #rule extension to the ABNF rules of [RFC5234] is used to improve
readability in the definitions of some header field values.
A construct "#" is defined, similar to "*", for defining comma-
delimited lists of elements. The full form is "<n>#<m>element"
indicating at least <n> and at most <m> elements, each separated by a
single comma (",") and optional whitespace (OWS).
12.1. Sender Requirements
In any production that uses the list construct, a sender MUST NOT
generate empty list elements. In other words, a sender MUST generate
lists that satisfy the following syntax:
1#element => element *( OWS "," OWS element )
and:
#element => [ 1#element ]
and for n >= 1 and m > 1:
<n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element )
12.2. Recipient Requirements
Empty elements do not contribute to the count of elements present. A
recipient MUST parse and ignore a reasonable number of empty list
elements: enough to handle common mistakes by senders that merge
values, but not so much that they could be used as a denial-of-
service mechanism. In other words, a recipient MUST accept lists
that satisfy the following syntax:
#element => [ element ] *( OWS "," OWS [ element ] )
Note that because of the potential presence of empty list elements,
the RFC 5234 ABNF cannot enforce the cardinality of list elements,
and consequently all cases are mapped is if there was no cardinality
specified.
For example, given these ABNF productions:
example-list = 1#example-list-elmt
example-list-elmt = token ; see Section 4.2.3.1
Then the following are valid values for example-list (not including
the double quotes, which are present for delimitation only):
"foo,bar"
"foo ,bar,"
"foo , ,bar,charlie"
In contrast, the following values would be invalid, since at least
one non-empty element is required by the example-list production:
""
","
", ,"
Appendix A shows the collected ABNF for recipients after the list
constructs have been expanded.
13. Security Considerations
This section is meant to inform developers, information providers, This section is meant to inform developers, information providers,
and users of known security concerns relevant to HTTP semantics and and users of known security concerns relevant to HTTP semantics and
its use for transferring information over the Internet. its use for transferring information over the Internet.
Considerations related to message syntax, parsing, and routing are Considerations related to message syntax, parsing, and routing are
discussed in Section 11 of [Messaging]. discussed in Section 11 of [Messaging].
The list of considerations below is not exhaustive. Most security The list of considerations below is not exhaustive. Most security
concerns related to HTTP semantics are about securing server-side concerns related to HTTP semantics are about securing server-side
applications (code behind the HTTP interface), securing user agent applications (code behind the HTTP interface), securing user agent
processing of payloads received via HTTP, or secure use of the processing of payloads received via HTTP, or secure use of the
Internet in general, rather than security of the protocol. Various Internet in general, rather than security of the protocol. Various
organizations maintain topical information and links to current organizations maintain topical information and links to current
research on Web application security (e.g., [OWASP]). research on Web application security (e.g., [OWASP]).
13.1. Establishing Authority 11.1. Establishing Authority
HTTP relies on the notion of an authoritative response: a response HTTP relies on the notion of an authoritative response: a response
that has been determined by (or at the direction of) the origin that has been determined by (or at the direction of) the origin
server identified within the target URI to be the most appropriate server identified within the target URI to be the most appropriate
response for that request given the state of the target resource at response for that request given the state of the target resource at
the time of response message origination. the time of response message origination.
When a registered name is used in the authority component, the "http" When a registered name is used in the authority component, the "http"
URI scheme (Section 2.5.1) relies on the user's local name resolution URI scheme (Section 2.5.1) relies on the user's local name resolution
service to determine where it can find authoritative responses. This service to determine where it can find authoritative responses. This
skipping to change at page 158, line 48 skipping to change at page 163, line 48
[RFC4033]) are one way to improve authenticity. [RFC4033]) are one way to improve authenticity.
Furthermore, after an IP address is obtained, establishing authority Furthermore, after an IP address is obtained, establishing authority
for an "http" URI is vulnerable to attacks on Internet Protocol for an "http" URI is vulnerable to attacks on Internet Protocol
routing. routing.
The "https" scheme (Section 2.5.2) is intended to prevent (or at The "https" scheme (Section 2.5.2) is intended to prevent (or at
least reveal) many of these potential attacks on establishing least reveal) many of these potential attacks on establishing
authority, provided that the negotiated TLS connection is secured and authority, provided that the negotiated TLS connection is secured and
the client properly verifies that the communicating server's identity the client properly verifies that the communicating server's identity
matches the target URI's authority component (Section 2.5.2.2). matches the target URI's authority component (Section 5.4.3.1).
Correctly implementing such verification can be difficult (see Correctly implementing such verification can be difficult (see
[Georgiev]). [Georgiev]).
Authority for a given origin server can be delegated through protocol Authority for a given origin server can be delegated through protocol
extensions; for example, [RFC7838]. Likewise, the set of servers extensions; for example, [RFC7838]. Likewise, the set of servers
that a connection is considered authoritative for can be changed with that a connection is considered authoritative for can be changed with
a protocol extension like [RFC8336]. a protocol extension like [RFC8336].
Providing a response from a non-authoritative source, such as a Providing a response from a non-authoritative source, such as a
shared proxy cache, is often useful to improve performance and shared proxy cache, is often useful to improve performance and
skipping to change at page 159, line 26 skipping to change at page 164, line 26
For example, phishing is an attack on the user's perception of For example, phishing is an attack on the user's perception of
authority, where that perception can be misled by presenting similar authority, where that perception can be misled by presenting similar
branding in hypertext, possibly aided by userinfo obfuscating the branding in hypertext, possibly aided by userinfo obfuscating the
authority component (see Section 2.5.1). User agents can reduce the authority component (see Section 2.5.1). User agents can reduce the
impact of phishing attacks by enabling users to easily inspect a impact of phishing attacks by enabling users to easily inspect a
target URI prior to making an action, by prominently distinguishing target URI prior to making an action, by prominently distinguishing
(or rejecting) userinfo when present, and by not sending stored (or rejecting) userinfo when present, and by not sending stored
credentials and cookies when the referring document is from an credentials and cookies when the referring document is from an
unknown or untrusted source. unknown or untrusted source.
See also [RFC6454] for a formalisation of authority that is used by 11.2. Risks of Intermediaries
many clients.
13.2. Risks of Intermediaries
By their very nature, HTTP intermediaries are men-in-the-middle and, By their very nature, HTTP intermediaries are men-in-the-middle and,
thus, represent an opportunity for man-in-the-middle attacks. thus, represent an opportunity for man-in-the-middle attacks.
Compromise of the systems on which the intermediaries run can result Compromise of the systems on which the intermediaries run can result
in serious security and privacy problems. Intermediaries might have in serious security and privacy problems. Intermediaries might have
access to security-related information, personal information about access to security-related information, personal information about
individual users and organizations, and proprietary information individual users and organizations, and proprietary information
belonging to users and content providers. A compromised belonging to users and content providers. A compromised
intermediary, or an intermediary implemented or configured without intermediary, or an intermediary implemented or configured without
regard to security and privacy considerations, might be used in the regard to security and privacy considerations, might be used in the
skipping to change at page 160, line 5 skipping to change at page 165, line 5
to cache poisoning attacks, as described in Section 7 of [Caching]. to cache poisoning attacks, as described in Section 7 of [Caching].
Implementers need to consider the privacy and security implications Implementers need to consider the privacy and security implications
of their design and coding decisions, and of the configuration of their design and coding decisions, and of the configuration
options they provide to operators (especially the default options they provide to operators (especially the default
configuration). configuration).
Users need to be aware that intermediaries are no more trustworthy Users need to be aware that intermediaries are no more trustworthy
than the people who run them; HTTP itself cannot solve this problem. than the people who run them; HTTP itself cannot solve this problem.
13.3. Attacks Based on File and Path Names 11.3. Attacks Based on File and Path Names
Origin servers frequently make use of their local file system to Origin servers frequently make use of their local file system to
manage the mapping from effective request URI to resource manage the mapping from effective request URI to resource
representations. Most file systems are not designed to protect representations. Most file systems are not designed to protect
against malicious file or path names. Therefore, an origin server against malicious file or path names. Therefore, an origin server
needs to avoid accessing names that have a special significance to needs to avoid accessing names that have a special significance to
the system when mapping the request target to files, folders, or the system when mapping the request target to files, folders, or
directories. directories.
For example, UNIX, Microsoft Windows, and other operating systems use For example, UNIX, Microsoft Windows, and other operating systems use
skipping to change at page 160, line 30 skipping to change at page 165, line 30
systems have an annoying tendency to prefer user-friendliness over systems have an annoying tendency to prefer user-friendliness over
security when handling invalid or unexpected characters, security when handling invalid or unexpected characters,
recomposition of decomposed characters, and case-normalization of recomposition of decomposed characters, and case-normalization of
case-insensitive names. case-insensitive names.
Attacks based on such special names tend to focus on either denial- Attacks based on such special names tend to focus on either denial-
of-service (e.g., telling the server to read from a COM port) or of-service (e.g., telling the server to read from a COM port) or
disclosure of configuration and source files that are not meant to be disclosure of configuration and source files that are not meant to be
served. served.
13.4. Attacks Based on Command, Code, or Query Injection 11.4. Attacks Based on Command, Code, or Query Injection
Origin servers often use parameters within the URI as a means of Origin servers often use parameters within the URI as a means of
identifying system services, selecting database entries, or choosing identifying system services, selecting database entries, or choosing
a data source. However, data received in a request cannot be a data source. However, data received in a request cannot be
trusted. An attacker could construct any of the request data trusted. An attacker could construct any of the request data
elements (method, request-target, header fields, or body) to contain elements (method, request-target, header fields, or body) to contain
data that might be misinterpreted as a command, code, or query when data that might be misinterpreted as a command, code, or query when
passed through a command invocation, language interpreter, or passed through a command invocation, language interpreter, or
database interface. database interface.
skipping to change at page 161, line 12 skipping to change at page 166, line 12
Parameters ought to be compared to fixed strings and acted upon as a Parameters ought to be compared to fixed strings and acted upon as a
result of that comparison, rather than passed through an interface result of that comparison, rather than passed through an interface
that is not prepared for untrusted data. Received data that isn't that is not prepared for untrusted data. Received data that isn't
based on fixed parameters ought to be carefully filtered or encoded based on fixed parameters ought to be carefully filtered or encoded
to avoid being misinterpreted. to avoid being misinterpreted.
Similar considerations apply to request data when it is stored and Similar considerations apply to request data when it is stored and
later processed, such as within log files, monitoring tools, or when later processed, such as within log files, monitoring tools, or when
included within a data format that allows embedded scripts. included within a data format that allows embedded scripts.
13.5. Attacks via Protocol Element Length 11.5. Attacks via Protocol Element Length
Because HTTP uses mostly textual, character-delimited fields, parsers Because HTTP uses mostly textual, character-delimited fields, parsers
are often vulnerable to attacks based on sending very long (or very are often vulnerable to attacks based on sending very long (or very
slow) streams of data, particularly where an implementation is slow) streams of data, particularly where an implementation is
expecting a protocol element with no predefined length (Section 3.3). expecting a protocol element with no predefined length (Section 3.3).
To promote interoperability, specific recommendations are made for To promote interoperability, specific recommendations are made for
minimum size limits on request-line (Section 3 of [Messaging]) and minimum size limits on request-line (Section 3 of [Messaging]) and
header fields (Section 4). These are minimum recommendations, chosen fields (Section 4). These are minimum recommendations, chosen to be
to be supportable even by implementations with limited resources; it supportable even by implementations with limited resources; it is
is expected that most implementations will choose substantially expected that most implementations will choose substantially higher
higher limits. limits.
A server can reject a message that has a request-target that is too A server can reject a message that has a request-target that is too
long (Section 9.5.15) or a request payload that is too large long (Section 9.5.15) or a request payload that is too large
(Section 9.5.14). Additional status codes related to capacity limits (Section 9.5.14). Additional status codes related to capacity limits
have been defined by extensions to HTTP [RFC6585]. have been defined by extensions to HTTP [RFC6585].
Recipients ought to carefully limit the extent to which they process Recipients ought to carefully limit the extent to which they process
other protocol elements, including (but not limited to) request other protocol elements, including (but not limited to) request
methods, response status phrases, header field-names, numeric values, methods, response status phrases, field names, numeric values, and
and body chunks. Failure to limit such processing can result in body chunks. Failure to limit such processing can result in buffer
buffer overflows, arithmetic overflows, or increased vulnerability to overflows, arithmetic overflows, or increased vulnerability to
denial-of-service attacks. denial-of-service attacks.
13.6. Disclosure of Personal Information 11.6. Disclosure of Personal Information
Clients are often privy to large amounts of personal information, Clients are often privy to large amounts of personal information,
including both information provided by the user to interact with including both information provided by the user to interact with
resources (e.g., the user's name, location, mail address, passwords, resources (e.g., the user's name, location, mail address, passwords,
encryption keys, etc.) and information about the user's browsing encryption keys, etc.) and information about the user's browsing
activity over time (e.g., history, bookmarks, etc.). Implementations activity over time (e.g., history, bookmarks, etc.). Implementations
need to prevent unintentional disclosure of personal information. need to prevent unintentional disclosure of personal information.
13.7. Privacy of Server Log Information 11.7. Privacy of Server Log Information
A server is in the position to save personal data about a user's A server is in the position to save personal data about a user's
requests over time, which might identify their reading patterns or requests over time, which might identify their reading patterns or
subjects of interest. In particular, log information gathered at an subjects of interest. In particular, log information gathered at an
intermediary often contains a history of user agent interaction, intermediary often contains a history of user agent interaction,
across a multitude of sites, that can be traced to individual users. across a multitude of sites, that can be traced to individual users.
HTTP log information is confidential in nature; its handling is often HTTP log information is confidential in nature; its handling is often
constrained by laws and regulations. Log information needs to be constrained by laws and regulations. Log information needs to be
securely stored and appropriate guidelines followed for its analysis. securely stored and appropriate guidelines followed for its analysis.
skipping to change at page 162, line 23 skipping to change at page 167, line 23
characteristics. As such, access traces that are keyed to a specific characteristics. As such, access traces that are keyed to a specific
client are unsafe to publish even if the key is pseudonymous. client are unsafe to publish even if the key is pseudonymous.
To minimize the risk of theft or accidental publication, log To minimize the risk of theft or accidental publication, log
information ought to be purged of personally identifiable information ought to be purged of personally identifiable
information, including user identifiers, IP addresses, and user- information, including user identifiers, IP addresses, and user-
provided query parameters, as soon as that information is no longer provided query parameters, as soon as that information is no longer
necessary to support operational needs for security, auditing, or necessary to support operational needs for security, auditing, or
fraud control. fraud control.
13.8. Disclosure of Sensitive Information in URIs 11.8. Disclosure of Sensitive Information in URIs
URIs are intended to be shared, not secured, even when they identify URIs are intended to be shared, not secured, even when they identify
secure resources. URIs are often shown on displays, added to secure resources. URIs are often shown on displays, added to
templates when a page is printed, and stored in a variety of templates when a page is printed, and stored in a variety of
unprotected bookmark lists. It is therefore unwise to include unprotected bookmark lists. It is therefore unwise to include
information within a URI that is sensitive, personally identifiable, information within a URI that is sensitive, personally identifiable,
or a risk to disclose. or a risk to disclose.
Authors of services ought to avoid GET-based forms for the submission Authors of services ought to avoid GET-based forms for the submission
of sensitive data because that data will be placed in the request- of sensitive data because that data will be placed in the request-
skipping to change at page 162, line 46 skipping to change at page 167, line 46
third parties. Such services ought to use POST-based form submission third parties. Such services ought to use POST-based form submission
instead. instead.
Since the Referer header field tells a target site about the context Since the Referer header field tells a target site about the context
that resulted in a request, it has the potential to reveal that resulted in a request, it has the potential to reveal
information about the user's immediate browsing history and any information about the user's immediate browsing history and any
personal information that might be found in the referring resource's personal information that might be found in the referring resource's
URI. Limitations on the Referer header field are described in URI. Limitations on the Referer header field are described in
Section 8.6.2 to address some of its security considerations. Section 8.6.2 to address some of its security considerations.
13.9. Disclosure of Fragment after Redirects 11.9. 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.1.2), this might have the effect of reference in Location (Section 10.1.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.
13.10. Disclosure of Product Information 11.10. Disclosure of Product Information
The User-Agent (Section 8.6.3), Via (Section 5.5.1), and Server The User-Agent (Section 8.6.3), Via (Section 5.7.1), and Server
(Section 10.4.3) header fields often reveal information about the (Section 10.4.3) 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.
13.11. Browser Fingerprinting 11.11. Browser Fingerprinting
Browser fingerprinting is a set of techniques for identifying a Browser fingerprinting is a set of techniques for identifying a
specific user agent over time through its unique set of specific user agent over time through its unique set of
characteristics. These characteristics might include information characteristics. These characteristics might include information
related to its TCP behavior, feature capabilities, and scripting related to its TCP behavior, feature capabilities, and scripting
environment, though of particular interest here is the set of unique environment, though of particular interest here is the set of unique
characteristics that might be communicated via HTTP. Fingerprinting characteristics that might be communicated via HTTP. Fingerprinting
is considered a privacy concern because it enables tracking of a user is considered a privacy concern because it enables tracking of a user
agent's behavior over time without the corresponding controls that agent's behavior over time ([Bujlow]) without the corresponding
the user might have over other forms of data collection (e.g., controls that the user might have over other forms of data collection
cookies). Many general-purpose user agents (i.e., Web browsers) have (e.g., cookies). Many general-purpose user agents (i.e., Web
taken steps to reduce their fingerprints. browsers) have taken steps to reduce their fingerprints.
There are a number of request header fields that might reveal There are a number of request header fields that might reveal
information to servers that is sufficiently unique to enable information to servers that is sufficiently unique to enable
fingerprinting. The From header field is the most obvious, though it fingerprinting. The From header field is the most obvious, though it
is expected that From will only be sent when self-identification is is expected that From will only be sent when self-identification is
desired by the user. Likewise, Cookie header fields are deliberately desired by the user. Likewise, Cookie header fields are deliberately
designed to enable re-identification, so fingerprinting concerns only designed to enable re-identification, so fingerprinting concerns only
apply to situations where cookies are disabled or restricted by the apply to situations where cookies are disabled or restricted by the
user agent's configuration. user agent's configuration.
skipping to change at page 164, line 27 skipping to change at page 169, line 27
language negotiation might be useful. language negotiation might be useful.
In environments where proxies are used to enhance privacy, user In environments where proxies are used to enhance privacy, user
agents ought to be conservative in sending proactive negotiation agents ought to be conservative in sending proactive negotiation
header fields. General-purpose user agents that provide a high header fields. General-purpose user agents that provide a high
degree of header field configurability ought to inform users about degree of header field configurability ought to inform users about
the loss of privacy that might result if too much detail is provided. the loss of privacy that might result if too much detail is provided.
As an extreme privacy measure, proxies could filter the proactive As an extreme privacy measure, proxies could filter the proactive
negotiation header fields in relayed requests. negotiation header fields in relayed requests.
13.12. Validator Retention 11.12. Validator Retention
The validators defined by this specification are not intended to The validators defined by this specification are not intended to
ensure the validity of a representation, guard against malicious ensure the validity of a representation, guard against malicious
changes, or detect man-in-the-middle attacks. At best, they enable changes, or detect man-in-the-middle attacks. At best, they enable
more efficient cache updates and optimistic concurrent writes when more efficient cache updates and optimistic concurrent writes when
all participants are behaving nicely. At worst, the conditions will all participants are behaving nicely. At worst, the conditions will
fail and the client will receive a response that is no more harmful fail and the client will receive a response that is no more harmful
than an HTTP exchange without conditional requests. than an HTTP exchange without conditional requests.
An entity-tag can be abused in ways that create privacy risks. For An entity-tag can be abused in ways that create privacy risks. For
skipping to change at page 165, line 5 skipping to change at page 170, line 5
entity-tag that is unique to the user or user agent, send it in a entity-tag that is unique to the user or user agent, send it in a
cacheable response with a long freshness time, and then read that cacheable response with a long freshness time, and then read that
entity-tag in later conditional requests as a means of re-identifying entity-tag in later conditional requests as a means of re-identifying
that user or user agent. Such an identifying tag would become a that user or user agent. Such an identifying tag would become a
persistent identifier for as long as the user agent retained the persistent identifier for as long as the user agent retained the
original cache entry. User agents that cache representations ought original cache entry. User agents that cache representations ought
to ensure that the cache is cleared or replaced whenever the user to ensure that the cache is cleared or replaced whenever the user
performs privacy-maintaining actions, such as clearing stored cookies performs privacy-maintaining actions, such as clearing stored cookies
or changing to a private browsing mode. or changing to a private browsing mode.
13.13. Denial-of-Service Attacks Using Range 11.13. Denial-of-Service Attacks Using Range
Unconstrained multiple range requests are susceptible to denial-of- Unconstrained multiple range requests are susceptible to denial-of-
service attacks because the effort required to request many service attacks because the effort required to request many
overlapping ranges of the same data is tiny compared to the time, overlapping ranges of the same data is tiny compared to the time,
memory, and bandwidth consumed by attempting to serve the requested memory, and bandwidth consumed by attempting to serve the requested
data in many parts. Servers ought to ignore, coalesce, or reject data in many parts. Servers ought to ignore, coalesce, or reject
egregious range requests, such as requests for more than two egregious range requests, such as requests for more than two
overlapping ranges or for many small ranges in a single set, overlapping ranges or for many small ranges in a single set,
particularly when the ranges are requested out of order for no particularly when the ranges are requested out of order for no
apparent reason. Multipart range requests are not designed to apparent reason. Multipart range requests are not designed to
support random access. support random access.
13.14. Authentication Considerations 11.14. Authentication Considerations
Everything about the topic of HTTP authentication is a security Everything about the topic of HTTP authentication is a security
consideration, so the list of considerations below is not exhaustive. consideration, so the list of considerations below is not exhaustive.
Furthermore, it is limited to security considerations regarding the Furthermore, it is limited to security considerations regarding the
authentication framework, in general, rather than discussing all of authentication framework, in general, rather than discussing all of
the potential considerations for specific authentication schemes the potential considerations for specific authentication schemes
(which ought to be documented in the specifications that define those (which ought to be documented in the specifications that define those
schemes). Various organizations maintain topical information and schemes). Various organizations maintain topical information and
links to current research on Web application security (e.g., links to current research on Web application security (e.g.,
[OWASP]), including common pitfalls for implementing and using the [OWASP]), including common pitfalls for implementing and using the
authentication schemes found in practice. authentication schemes found in practice.
13.14.1. Confidentiality of Credentials 11.14.1. Confidentiality of Credentials
The HTTP authentication framework does not define a single mechanism The HTTP authentication framework does not define a single mechanism
for maintaining the confidentiality of credentials; instead, each for maintaining the confidentiality of credentials; instead, each
authentication scheme defines how the credentials are encoded prior authentication scheme defines how the credentials are encoded prior
to transmission. While this provides flexibility for the development to transmission. While this provides flexibility for the development
of future authentication schemes, it is inadequate for the protection of future authentication schemes, it is inadequate for the protection
of existing schemes that provide no confidentiality on their own, or of existing schemes that provide no confidentiality on their own, or
that do not sufficiently protect against replay attacks. that do not sufficiently protect against replay attacks.
Furthermore, if the server expects credentials that are specific to Furthermore, if the server expects credentials that are specific to
each individual user, the exchange of those credentials will have the each individual user, the exchange of those credentials will have the
effect of identifying that user even if the content within effect of identifying that user even if the content within
credentials remains confidential. credentials remains confidential.
HTTP depends on the security properties of the underlying transport- HTTP depends on the security properties of the underlying transport-
or session-level connection to provide confidential transmission of or session-level connection to provide confidential transmission of
header fields. In other words, if a server limits access to fields. In other words, if a server limits access to authenticated
authenticated users using this framework, the server needs to ensure users using this framework, the server needs to ensure that the
that the connection is properly secured in accordance with the nature connection is properly secured in accordance with the nature of the
of the authentication scheme used. For example, services that depend authentication scheme used. For example, services that depend on
on individual user authentication often require a connection to be individual user authentication often require a connection to be
secured with TLS ("Transport Layer Security", [RFC8446]) prior to secured with TLS ("Transport Layer Security", [RFC8446]) prior to
exchanging any credentials. exchanging any credentials.
13.14.2. Credentials and Idle Clients 11.14.2. Credentials and Idle Clients
Existing HTTP clients and user agents typically retain authentication Existing HTTP clients and user agents typically retain authentication
information indefinitely. HTTP does not provide a mechanism for the information indefinitely. HTTP does not provide a mechanism for the
origin server to direct clients to discard these cached credentials, origin server to direct clients to discard these cached credentials,
since the protocol has no awareness of how credentials are obtained since the protocol has no awareness of how credentials are obtained
or managed by the user agent. The mechanisms for expiring or or managed by the user agent. The mechanisms for expiring or
revoking credentials can be specified as part of an authentication revoking credentials can be specified as part of an authentication
scheme definition. scheme definition.
Circumstances under which credential caching can interfere with the Circumstances under which credential caching can interfere with the
skipping to change at page 166, line 33 skipping to change at page 171, line 33
o Applications that include a session termination indication (such o Applications that include a session termination indication (such
as a "logout" or "commit" button on a page) after which the server as a "logout" or "commit" button on a page) after which the server
side of the application "knows" that there is no further reason side of the application "knows" that there is no further reason
for the client to retain the credentials. for the client to retain the credentials.
User agents that cache credentials are encouraged to provide a User agents that cache credentials are encouraged to provide a
readily accessible mechanism for discarding cached credentials under readily accessible mechanism for discarding cached credentials under
user control. user control.
13.14.3. Protection Spaces 11.14.3. Protection Spaces
Authentication schemes that solely rely on the "realm" mechanism for Authentication schemes that solely rely on the "realm" mechanism for
establishing a protection space will expose credentials to all establishing a protection space will expose credentials to all
resources on an origin server. Clients that have successfully made resources on an origin server. Clients that have successfully made
authenticated requests with a resource can use the same authenticated requests with a resource can use the same
authentication credentials for other resources on the same origin authentication credentials for other resources on the same origin
server. This makes it possible for a different resource to harvest server. This makes it possible for a different resource to harvest
authentication credentials for other resources. authentication credentials for other resources.
This is of particular concern when an origin server hosts resources This is of particular concern when an origin server hosts resources
for multiple parties under the same canonical root URI for multiple parties under the same canonical root URI
(Section 8.5.2). Possible mitigation strategies include restricting (Section 8.5.2). Possible mitigation strategies include restricting
direct access to authentication credentials (i.e., not making the direct access to authentication credentials (i.e., not making the
content of the Authorization request header field available), and content of the Authorization request header field available), and
separating protection spaces by using a different host name (or port separating protection spaces by using a different host name (or port
number) for each party. number) for each party.
13.14.4. Additional Response Header Fields 11.14.4. Additional Response Fields
Adding information to responses that are sent over an unencrypted Adding information to responses that are sent over an unencrypted
channel can affect security and privacy. The presence of the channel can affect security and privacy. The presence of the
Authentication-Info and Proxy-Authentication-Info header fields alone Authentication-Info and Proxy-Authentication-Info header fields alone
indicates that HTTP authentication is in use. Additional information indicates that HTTP authentication is in use. Additional information
could be exposed by the contents of the authentication-scheme could be exposed by the contents of the authentication-scheme
specific parameters; this will have to be considered in the specific parameters; this will have to be considered in the
definitions of these schemes. definitions of these schemes.
14. IANA Considerations 12. IANA Considerations
The change controller for the following registrations is: "IETF The change controller for the following registrations is: "IETF
(iesg@ietf.org) - Internet Engineering Task Force". (iesg@ietf.org) - Internet Engineering Task Force".
14.1. URI Scheme Registration 12.1. URI Scheme Registration
Please update the registry of URI Schemes [BCP35] at Please update the registry of URI Schemes [BCP35] at
<https://www.iana.org/assignments/uri-schemes/> with the permanent <https://www.iana.org/assignments/uri-schemes/> with the permanent
schemes listed in the first table of Section 2.5. schemes listed in the first table of Section 2.5.
14.2. Method Registration 12.2. Method Registration
Please update the "Hypertext Transfer Protocol (HTTP) Method Please update the "Hypertext Transfer Protocol (HTTP) Method
Registry" at <https://www.iana.org/assignments/http-methods> with the Registry" at <https://www.iana.org/assignments/http-methods> with the
registration procedure of Section 7.4.1 and the method names registration procedure of Section 7.4.1 and the method names
summarized in the table of Section 7.2. summarized in the table of Section 7.2.
14.3. Status Code Registration 12.3. Status Code Registration
Please update the "Hypertext Transfer Protocol (HTTP) Status Code Please update the "Hypertext Transfer Protocol (HTTP) Status Code
Registry" at <https://www.iana.org/assignments/http-status-codes> Registry" at <https://www.iana.org/assignments/http-status-codes>
with the registration procedure of Section 9.7.1 and the status code with the registration procedure of Section 9.7.1 and the status code
values summarized in the table of Section 9.1. values summarized in the table of Section 9.1.
Additionally, please update the following entry in the Hypertext Additionally, please update the following entry in the Hypertext
Transfer Protocol (HTTP) Status Code Registry: Transfer Protocol (HTTP) Status Code Registry:
Value: 418 Value: 418
Description: (Unused) Description: (Unused)
Reference Section 9.5.19 Reference Section 9.5.19
14.4. Header Field Registration 12.4. HTTP Field Name Registration
Please create a new registry as outlined in Section 4.1.1. Please create a new registry as outlined in Section 4.3.2.
After creating the registry, all entries in the Permanent and After creating the registry, all entries in the Permanent and
Provisional Message Header Registries with the protocol 'http' are to Provisional Message Header Registries with the protocol 'http' are to
be moved to it, with the following changes applied: be moved to it, with the following changes applied:
1. The 'Applicable Protocol' field is to be omitted. 1. The 'Applicable Protocol' field is to be omitted.
2. Entries with a status of 'standard', 'experimental', or 2. Entries with a status of 'standard', 'experimental', 'reserved',
'informational' are to have a status of 'permanent'. or 'informational' are to have a status of 'permanent'.
3. Provisional entries without a status are to have a status of 3. Provisional entries without a status are to have a status of
'provisional'. 'provisional'.
4. Permanent entries without a status (after confirmation that the 4. Permanent entries without a status (after confirmation that the
registration document did not define one) will have a status of registration document did not define one) will have a status of
'provisional'. The Expert(s) can choose to update their status 'provisional'. The Expert(s) can choose to update their status
if there is evidence that another is more appropriate. if there is evidence that another is more appropriate.
Please annotate the Permanent and Provisional Message Header Please annotate the Permanent and Provisional Message Header
registries to indicate that HTTP header field registrations have registries to indicate that HTTP field name registrations have moved,
moved, with an appropriate link. with an appropriate link.
After that is complete, please update the new registry with the After that is complete, please update the new registry with the field
header field names listed in the table of Section 4.1. names listed in the table of Section 4.3.
Finally, please update the "Content-MD5" entry in the new registry to Finally, please update the "Content-MD5" entry in the new registry to
have a status of 'obsoleted' with references to Section 14.15 of have a status of 'obsoleted' with references to Section 14.15 of
[RFC2616] (for the definition of the header field) and Appendix B of [RFC2616] (for the definition of the header field) and Appendix B of
[RFC7231] (which removed the field definition from the updated [RFC7231] (which removed the field definition from the updated
specification). specification).
14.5. Authentication Scheme Registration 12.5. Authentication Scheme Registration
Please update the "Hypertext Transfer Protocol (HTTP) Authentication Please update the "Hypertext Transfer Protocol (HTTP) Authentication
Scheme Registry" at <https://www.iana.org/assignments/http- Scheme Registry" at <https://www.iana.org/assignments/http-
authschemes> with the registration procedure of Section 8.5.5.1. No authschemes> with the registration procedure of Section 8.5.5.1. No
authentication schemes are defined in this document. authentication schemes are defined in this document.
14.6. Content Coding Registration 12.6. Content Coding Registration
Please update the "HTTP Content Coding Registry" at Please update the "HTTP Content Coding Registry" at
<https://www.iana.org/assignments/http-parameters/> with the <https://www.iana.org/assignments/http-parameters/> with the
registration procedure of Section 6.1.2.4.1 and the content coding registration procedure of Section 6.1.2.4 and the content coding
names summarized in the table of Section 6.1.2. names summarized in the table of Section 6.1.2.
14.7. Range Unit Registration 12.7. Range Unit Registration
Please update the "HTTP Range Unit Registry" at Please update the "HTTP Range Unit Registry" at
<https://www.iana.org/assignments/http-parameters/> with the <https://www.iana.org/assignments/http-parameters/> with the
registration procedure of Section 6.1.4.4 and the range unit names registration procedure of Section 6.1.4.4 and the range unit names
summarized in the table of Section 6.1.4. summarized in the table of Section 6.1.4.
14.8. Media Type Registration 12.8. Media Type Registration
Please update the "Media Types" registry at Please update the "Media Types" registry at
<https://www.iana.org/assignments/media-types> with the registration <https://www.iana.org/assignments/media-types> with the registration
information in Section 6.3.5 for the media type "multipart/ information in Section 6.3.5 for the media type "multipart/
byteranges". byteranges".
14.9. Port Registration 12.9. Port Registration
Please update the "Service Name and Transport Protocol Port Number" Please update the "Service Name and Transport Protocol Port Number"
registry at <https://www.iana.org/assignments/service-names-port- registry at <https://www.iana.org/assignments/service-names-port-
numbers/> for the services on ports 80 and 443 that use UDP or TCP numbers/> for the services on ports 80 and 443 that use UDP or TCP
to: to:
1. use this document as "Reference", and 1. use this document as "Reference", and
2. when currently unspecified, set "Assignee" to "IESG" and 2. when currently unspecified, set "Assignee" to "IESG" and
"Contact" to "IETF_Chair". "Contact" to "IETF_Chair".
15. References 13. References
15.1. Normative References 13.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", draft-ietf-httpbis-cache-06 (work in Ed., "HTTP Caching", draft-ietf-httpbis-cache-07 (work in
progress), November 2019. progress), March 2020.
[Messaging] [Messaging]
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP/1.1 Messaging", draft-ietf-httpbis-messaging-06 Ed., "HTTP/1.1 Messaging", draft-ietf-httpbis-messaging-07
(work in progress), November 2019. (work in progress), March 2020.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>. <https://www.rfc-editor.org/info/rfc793>.
[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format
Specification version 3.3", RFC 1950, Specification version 3.3", RFC 1950,
DOI 10.17487/RFC1950, May 1996, DOI 10.17487/RFC1950, May 1996,
<https://www.rfc-editor.org/info/rfc1950>. <https://www.rfc-editor.org/info/rfc1950>.
skipping to change at page 171, line 18 skipping to change at page 176, line 18
[RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in
Internationalization in the IETF", BCP 166, RFC 6365, Internationalization in the IETF", BCP 166, RFC 6365,
DOI 10.17487/RFC6365, September 2011, DOI 10.17487/RFC6365, September 2011,
<https://www.rfc-editor.org/info/rfc6365>. <https://www.rfc-editor.org/info/rfc6365>.
[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
RFC 7405, DOI 10.17487/RFC7405, December 2014, RFC 7405, DOI 10.17487/RFC7405, December 2014,
<https://www.rfc-editor.org/info/rfc7405>. <https://www.rfc-editor.org/info/rfc7405>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[USASCII] American National Standards Institute, "Coded Character [USASCII] American National Standards Institute, "Coded Character
Set -- 7-bit American Standard Code for Information Set -- 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986. Interchange", ANSI X3.4, 1986.
[Welch] Welch, T., "A Technique for High-Performance Data [Welch] Welch, T., "A Technique for High-Performance Data
Compression", IEEE Computer 17(6), Compression", IEEE Computer 17(6),
DOI 10.1109/MC.1984.1659158, June 1984, DOI 10.1109/MC.1984.1659158, June 1984,
<https://ieeexplore.ieee.org/document/1659158/>. <https://ieeexplore.ieee.org/document/1659158/>.
15.2. Informative References 13.2. Informative References
[BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type [BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, Specifications and Registration Procedures", BCP 13,
RFC 6838, January 2013, RFC 6838, January 2013,
<https://www.rfc-editor.org/info/bcp13>. <https://www.rfc-editor.org/info/bcp13>.
[BCP178] Saint-Andre, P., Crocker, D., and M. Nottingham, [BCP178] Saint-Andre, P., Crocker, D., and M. Nottingham,
"Deprecating the "X-" Prefix and Similar Constructs in "Deprecating the "X-" Prefix and Similar Constructs in
Application Protocols", BCP 178, RFC 6648, June 2012, Application Protocols", BCP 178, RFC 6648, June 2012,
<https://www.rfc-editor.org/info/bcp178>. <https://www.rfc-editor.org/info/bcp178>.
[BCP35] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines [BCP35] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines
and Registration Procedures for URI Schemes", BCP 35, and Registration Procedures for URI Schemes", BCP 35,
RFC 7595, June 2015, RFC 7595, June 2015,
<https://www.rfc-editor.org/info/bcp35>. <https://www.rfc-editor.org/info/bcp35>.
[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration [Bujlow] Bujlow, T., Carela-Espanol, V., Sole-Pareta, J., and P.
Procedures for Message Header Fields", BCP 90, RFC 3864, Barlet-Ros, "A Survey on Web Tracking: Mechanisms,
September 2004, <https://www.rfc-editor.org/info/bcp90>. Implications, and Defenses",
DOI 10.1109/JPROC.2016.2637878, Proceedings of the
IEEE 105(8), August 2017.
[Err1912] RFC Errata, Erratum ID 1912, RFC 2978, [Err1912] RFC Errata, Erratum ID 1912, RFC 2978,
<https://www.rfc-editor.org/errata/eid1912>. <https://www.rfc-editor.org/errata/eid1912>.
[Err5433] RFC Errata, Erratum ID 5433, RFC 2978, [Err5433] RFC Errata, Erratum ID 5433, RFC 2978,
<https://www.rfc-editor.org/errata/eid5433>. <https://www.rfc-editor.org/errata/eid5433>.
[Georgiev] [Georgiev]
Georgiev, M., Iyengar, S., Jana, S., Anubhai, R., Boneh, Georgiev, M., Iyengar, S., Jana, S., Anubhai, R., Boneh,
D., and V. Shmatikov, "The Most Dangerous Code in the D., and V. Shmatikov, "The Most Dangerous Code in the
World: Validating SSL Certificates in Non-browser World: Validating SSL Certificates in Non-browser
Software", In Proceedings of the 2012 ACM Conference on Software", DOI 10.1145/2382196.2382204, In Proceedings of
Computer and Communications Security (CCS '12), pp. 38-49, the 2012 ACM Conference on Computer and Communications
October 2012, Security (CCS '12), pp. 38-49, October 2012.
<http://doi.acm.org/10.1145/2382196.2382204>.
[ISO-8859-1] [ISO-8859-1]
International Organization for Standardization, International Organization for Standardization,
"Information technology -- 8-bit single-byte coded graphic "Information technology -- 8-bit single-byte coded graphic
character sets -- Part 1: Latin alphabet No. 1", ISO/ character sets -- Part 1: Latin alphabet No. 1", ISO/
IEC 8859-1:1998, 1998. IEC 8859-1:1998, 1998.
[Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and [Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and
Politics", ACM Transactions on Internet Technology 1(2), Politics", ACM Transactions on Internet Technology 1(2),
November 2001, <http://arxiv.org/abs/cs.SE/0105018>. November 2001, <http://arxiv.org/abs/cs.SE/0105018>.
skipping to change at page 174, line 33 skipping to change at page 179, line 38
[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>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011, DOI 10.17487/RFC6265, April 2011,
<https://www.rfc-editor.org/info/rfc6265>. <https://www.rfc-editor.org/info/rfc6265>.
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
DOI 10.17487/RFC6454, December 2011, DOI 10.17487/RFC6454, December 2011,
<https://www.rfc-editor.org/info/rfc6454>. <https://www.rfc-editor.org/info/rfc6454>.
[RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status [RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status
Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012, Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012,
skipping to change at page 177, line 8 skipping to change at page 182, line 8
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[Sniffing] [Sniffing]
WHATWG, "MIME Sniffing", WHATWG, "MIME Sniffing",
<https://mimesniff.spec.whatwg.org>. <https://mimesniff.spec.whatwg.org>.
Appendix A. Collected ABNF Appendix A. Collected ABNF
In the collected ABNF below, list rules are expanded as per In the collected ABNF below, list rules are expanded as per
Section 12. Section 4.5.
Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [ Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
OWS ( media-range [ accept-params ] ) ] ) ] OWS ( media-range [ accept-params ] ) ] ) ]
Accept-Charset = *( "," OWS ) ( ( charset / "*" ) [ weight ] ) *( OWS Accept-Charset = *( "," OWS ) ( ( charset / "*" ) [ weight ] ) *( OWS
"," [ OWS ( ( charset / "*" ) [ weight ] ) ] ) "," [ OWS ( ( charset / "*" ) [ weight ] ) ] )
Accept-Encoding = [ ( "," / ( codings [ weight ] ) ) *( OWS "," [ OWS Accept-Encoding = [ ( "," / ( codings [ weight ] ) ) *( OWS "," [ OWS
( codings [ weight ] ) ] ) ] ( codings [ weight ] ) ] ) ]
Accept-Language = *( "," OWS ) ( language-range [ weight ] ) *( OWS Accept-Language = *( "," OWS ) ( language-range [ weight ] ) *( OWS
"," [ OWS ( language-range [ weight ] ) ] ) "," [ OWS ( language-range [ weight ] ) ] )
Accept-Ranges = acceptable-ranges Accept-Ranges = acceptable-ranges
skipping to change at page 180, line 41 skipping to change at page 185, line 41
) )
parameter = parameter-name "=" parameter-value parameter = parameter-name "=" parameter-value
parameter-name = token parameter-name = token
parameter-value = ( token / quoted-string ) parameter-value = ( token / quoted-string )
partial-URI = relative-part [ "?" query ] partial-URI = relative-part [ "?" query ]
path-abempty = <path-abempty, see [RFC3986], Section 3.3> path-abempty = <path-abempty, see [RFC3986], Section 3.3>
port = <port, see [RFC3986], Section 3.2.3> port = <port, see [RFC3986], Section 3.2.3>
product = token [ "/" product-version ] product = token [ "/" product-version ]
product-version = token product-version = token
protocol-name = <protocol-name, see [Messaging], Section 9.8> protocol-name = <protocol-name, see [Messaging], Section 9.9>
protocol-version = <protocol-version, see [Messaging], Section 9.8> protocol-version = <protocol-version, see [Messaging], Section 9.9>
pseudonym = token pseudonym = token
qdtext = HTAB / SP / "!" / %x23-5B ; '#'-'[' qdtext = HTAB / SP / "!" / %x23-5B ; '#'-'['
/ %x5D-7E ; ']'-'~' / %x5D-7E ; ']'-'~'
/ obs-text / obs-text
query = <query, see [RFC3986], Section 3.4> query = <query, see [RFC3986], Section 3.4>
quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text ) quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] ) qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
range-resp = incl-range "/" ( complete-length / "*" ) range-resp = incl-range "/" ( complete-length / "*" )
range-set = [ range-spec ] *( OWS "," OWS [ range-spec ] ) range-set = [ range-spec ] *( OWS "," OWS [ range-spec ] )
range-spec = int-range / suffix-range / other-range range-spec = int-range / suffix-range / other-range
range-unit = token range-unit = token
ranges-specifier = range-unit "=" range-set ranges-specifier = range-unit "=" range-set
received-by = ( uri-host [ ":" port ] ) / pseudonym received-by = pseudonym [ ":" port ]
received-protocol = [ protocol-name "/" ] protocol-version received-protocol = [ protocol-name "/" ] protocol-version
relative-part = <relative-part, see [RFC3986], Section 4.2> relative-part = <relative-part, see [RFC3986], Section 4.2>
request-target = <request-target, see [Messaging], Section 3.2> request-target = <request-target, see [Messaging], Section 3.2>
rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT
second = 2DIGIT second = 2DIGIT
segment = <segment, see [RFC3986], Section 3.3> segment = <segment, see [RFC3986], Section 3.3>
subtype = token subtype = token
suffix-length = 1*DIGIT suffix-length = 1*DIGIT
suffix-range = "-" suffix-length suffix-range = "-" suffix-length
skipping to change at page 181, line 37 skipping to change at page 186, line 37
type = token type = token
unsatisfied-range = "*/" complete-length unsatisfied-range = "*/" complete-length
uri-host = <host, see [RFC3986], Section 3.2.2> uri-host = <host, see [RFC3986], Section 3.2.2>
weak = %x57.2F ; W/ weak = %x57.2F ; W/
weight = OWS ";" OWS "q=" qvalue weight = OWS ";" OWS "q=" qvalue
year = 4DIGIT year = 4DIGIT
Appendix B. Changes from RFC 7230 Appendix B. Changes from previous RFCs
B.1. Changes from RFC 2818
None yet.
B.2. Changes from RFC 7230
The sections introducing HTTP's design goals, history, architecture, The sections introducing HTTP's design goals, history, architecture,
conformance criteria, protocol versioning, URIs, message routing, and conformance criteria, protocol versioning, URIs, message routing, and
header fields have been moved here (without substantive change). header fields have been moved here (without substantive change).
"Field value" now refers to the value after multiple instances are
combined with commas -- by far the most common use. To refer to a
single header line's value, use "field line value". (Section 4)
Trailer field semantics now transcend the specifics of chunked Trailer field semantics now transcend the specifics of chunked
encoding. Use of trailer fields has been further limited to only encoding. Use of trailer fields has been further limited to only
allow generation as a trailer field when the sender knows the field allow generation as a trailer field when the sender knows the field
defines that usage and to only allow merging into the header section defines that usage and to only allow merging into the header section
if the recipient knows the corresponding field definition permits and if the recipient knows the corresponding field definition permits and
defines how to merge. In all other cases, implementations are defines how to merge. In all other cases, implementations are
encouraged to either store the trailer fields separately or discard encouraged to either store the trailer fields separately or discard
them instead of merging (Section 4.3.2). them instead of merging. (Section 4.6.2)
Made the priority of the absolute form of the request URI over the
Host header by origin servers explicit, to align with proxy handling.
(Section 5.6)
The grammar definition for the Via field's "received-by" was expanded
in 7230 due to changes in the URI grammar for host [RFC3986] that are
not desirable for Via. For simplicity, we have removed uri-host from
the received-by production because it can be encompassed by the
existing grammar for pseudonym. In particular, this change removed
comma from the allowed set of charaters for a host name in received-
by. (Section 5.7.1)
Added status code 308 (previously defined in [RFC7538]) so that it's Added status code 308 (previously defined in [RFC7538]) so that it's
defined closer to status codes 301, 302, and 307 (Section 9.4.9). defined closer to status codes 301, 302, and 307. (Section 9.4.9)
Added status code 422 (previously defined in Section 11.2 of Added status code 422 (previously defined in Section 11.2 of
[RFC4918]) because of its general applicability (Section 9.5.20). [RFC4918]) because of its general applicability. (Section 9.5.20)
Appendix C. Changes from RFC 2818 The description of an origin and authoritative access to origin
servers has been extended for both "http" and "https" URIs to account
for alternative services and secured connections that are not
necessarily based on TCP. (Section 2.5.1, Section 2.5.2,
Section 5.2, Section 5.4)
None yet. B.3. Changes from RFC 7231
Appendix D. Changes from RFC 7231 Minimum URI lengths to be supported by implementations are now
recommended. (Section 2.5)
Range units are compared in a case insensitive fashion.
(Section 6.1.4)
Restrictions on client retries have been loosened, to reflect Restrictions on client retries have been loosened, to reflect
implementation behavior. (Section 7.2.2) implementation behavior. (Section 7.2.2)
Clarified that request bodies on GET and DELETE are not
interoperable. (Section 7.3.1, Section 7.3.5)
Removed a superfluous requirement about setting Content-Length from Removed a superfluous requirement about setting Content-Length from
the description of the OPTIONS method. (Section 7.3.7) the description of the OPTIONS method. (Section 7.3.7)
Minimum URI lengths to be supported by implementations are now B.4. Changes from RFC 7232
recommended. (Section 2.5)
Clarified that request bodies on GET are not interoperable.
(Section 7.3.1)
Appendix E. Changes from RFC 7232
None yet. None yet.
Appendix F. Changes from RFC 7233 B.5. Changes from RFC 7233
Refactored the range-unit and ranges-specifier grammars to simplify Refactored the range-unit and ranges-specifier grammars to simplify
and reduce artificial distinctions between bytes and other and reduce artificial distinctions between bytes and other
(extension) range units, removing the overlapping grammar of other- (extension) range units, removing the overlapping grammar of other-
range-unit by defining range units generically as a token and placing range-unit by defining range units generically as a token and placing
extensions within the scope of a range-spec (other-range). This extensions within the scope of a range-spec (other-range). This
disambiguates the role of list syntax (commas) in all range sets, disambiguates the role of list syntax (commas) in all range sets,
including extension range units, for indicating a range-set of more including extension range units, for indicating a range-set of more
than one range. Moving the extension grammar into range specifiers than one range. Moving the extension grammar into range specifiers
also allows protocol specific to byte ranges to be specified also allows protocol specific to byte ranges to be specified
separately. separately.
Appendix G. Changes from RFC 7235 B.6. Changes from RFC 7235
None yet. None yet.
Appendix H. Changes from RFC 7538 B.7. Changes from RFC 7538
None yet. None yet.
Appendix I. Changes from RFC 7615 B.8. Changes from RFC 7615
None yet. None yet.
Appendix J. Change Log Appendix C. Change Log
This section is to be removed before publishing as an RFC. This section is to be removed before publishing as an RFC.
J.1. Between RFC723x and draft 00 C.1. Between RFC723x and draft 00
The changes were purely editorial: The changes were purely editorial:
o Change boilerplate and abstract to indicate the "draft" status, o Change boilerplate and abstract to indicate the "draft" status,
and update references to ancestor specifications. and update references to ancestor specifications.
o Remove version "1.1" from document title, indicating that this o Remove version "1.1" from document title, indicating that this
specification applies to all HTTP versions. specification applies to all HTTP versions.
o Adjust historical notes. o Adjust historical notes.
o Update links to sibling specifications. o Update links to sibling specifications.
o Replace sections listing changes from RFC 2616 by new empty o Replace sections listing changes from RFC 2616 by new empty
sections referring to RFC 723x. sections referring to RFC 723x.
o Remove acknowledgements specific to RFC 723x. o Remove acknowledgements specific to RFC 723x.
o Move "Acknowledgements" to the very end and make them unnumbered. o Move "Acknowledgements" to the very end and make them unnumbered.
J.2. Since draft-ietf-httpbis-semantics-00 C.2. Since draft-ietf-httpbis-semantics-00
The changes in this draft are editorial, with respect to HTTP as a The changes in this draft are editorial, with respect to HTTP as a
whole, to merge core HTTP semantics into this document: whole, to merge core HTTP semantics into this document:
o Merged introduction, architecture, conformance, and ABNF o Merged introduction, architecture, conformance, and ABNF
extensions from RFC 7230 (Messaging). extensions from RFC 7230 (Messaging).
o Rearranged architecture to extract conformance, http(s) schemes, o Rearranged architecture to extract conformance, http(s) schemes,
and protocol versioning into a separate major section. and protocol versioning into a separate major section.
skipping to change at page 184, line 14 skipping to change at page 189, line 39
o Merged entire content of RFC 7233 (Range Requests). o Merged entire content of RFC 7233 (Range Requests).
o Merged entire content of RFC 7235 (Auth Framework). o Merged entire content of RFC 7235 (Auth Framework).
o Moved all extensibility tips, registration procedures, and o Moved all extensibility tips, registration procedures, and
registry tables from the IANA considerations to normative registry tables from the IANA considerations to normative
sections, reducing the IANA considerations to just instructions sections, reducing the IANA considerations to just instructions
that will be removed prior to publication as an RFC. that will be removed prior to publication as an RFC.
J.3. Since draft-ietf-httpbis-semantics-01 C.3. Since draft-ietf-httpbis-semantics-01
o Improve [Welch] citation (<https://github.com/httpwg/http-core/ o Improve [Welch] citation (<https://github.com/httpwg/http-core/
issues/63>) issues/63>)
o Remove HTTP/1.1-ism about Range Requests o Remove HTTP/1.1-ism about Range Requests
(<https://github.com/httpwg/http-core/issues/71>) (<https://github.com/httpwg/http-core/issues/71>)
o Cite RFC 8126 instead of RFC 5226 (<https://github.com/httpwg/ o Cite RFC 8126 instead of RFC 5226 (<https://github.com/httpwg/
http-core/issues/75>) http-core/issues/75>)
skipping to change at page 185, line 25 skipping to change at page 190, line 48
<https://www.rfc-editor.org/errata/eid5162>) <https://www.rfc-editor.org/errata/eid5162>)
o Replace "response code" with "response status code" and "status- o Replace "response code" with "response status code" and "status-
code" (the ABNF production name from the HTTP/1.1 message format) code" (the ABNF production name from the HTTP/1.1 message format)
by "status code" (<https://github.com/httpwg/http-core/issues/94>, by "status code" (<https://github.com/httpwg/http-core/issues/94>,
<https://www.rfc-editor.org/errata/eid4050>) <https://www.rfc-editor.org/errata/eid4050>)
o Added a missing word in Section 9.4 (<https://github.com/httpwg/ o Added a missing word in Section 9.4 (<https://github.com/httpwg/
http-core/issues/98>, <https://www.rfc-editor.org/errata/eid4452>) http-core/issues/98>, <https://www.rfc-editor.org/errata/eid4452>)
o In Section 12, fixed an example that had trailing whitespace where o In Section 4.5, fixed an example that had trailing whitespace
it shouldn't (<https://github.com/httpwg/http-core/issues/104>, where it shouldn't (<https://github.com/httpwg/http-core/
<https://www.rfc-editor.org/errata/eid4169>) issues/104>, <https://www.rfc-editor.org/errata/eid4169>)
o In Section 9.3.7, remove words that were potentially misleading o In Section 9.3.7, remove words that were potentially misleading
with respect to the relation to the requested ranges with respect to the relation to the requested ranges
(<https://github.com/httpwg/http-core/issues/102>, (<https://github.com/httpwg/http-core/issues/102>,
<https://www.rfc-editor.org/errata/eid4358>) <https://www.rfc-editor.org/errata/eid4358>)
J.4. Since draft-ietf-httpbis-semantics-02 C.4. Since draft-ietf-httpbis-semantics-02
o Included (Proxy-)Auth-Info header field definition from RFC 7615 o Included (Proxy-)Auth-Info header field definition from RFC 7615
(<https://github.com/httpwg/http-core/issues/9>) (<https://github.com/httpwg/http-core/issues/9>)
o In Section 7.3.3, clarify POST caching o In Section 7.3.3, clarify POST caching
(<https://github.com/httpwg/http-core/issues/17>) (<https://github.com/httpwg/http-core/issues/17>)
o Add Section 9.5.19 to reserve the 418 status code o Add Section 9.5.19 to reserve the 418 status code
(<https://github.com/httpwg/http-core/issues/43>) (<https://github.com/httpwg/http-core/issues/43>)
skipping to change at page 186, line 27 skipping to change at page 192, line 5
issues/123>) issues/123>)
o In Section 9.5.17, fixed prose about byte range comparison o In Section 9.5.17, fixed prose about byte range comparison
(<https://github.com/httpwg/http-core/issues/135>, (<https://github.com/httpwg/http-core/issues/135>,
<https://www.rfc-editor.org/errata/eid5474>) <https://www.rfc-editor.org/errata/eid5474>)
o In Section 2.1, explain that request/response correlation is o In Section 2.1, explain that request/response correlation is
version specific (<https://github.com/httpwg/http-core/ version specific (<https://github.com/httpwg/http-core/
issues/145>) issues/145>)
J.5. Since draft-ietf-httpbis-semantics-03 C.5. Since draft-ietf-httpbis-semantics-03
o In Section 9.4.9, include status code 308 from RFC 7538 o In Section 9.4.9, include status code 308 from RFC 7538
(<https://github.com/httpwg/http-core/issues/3>) (<https://github.com/httpwg/http-core/issues/3>)
o In Section 6.1.1, clarify that the charset parameter value is o In Section 6.1.1, clarify that the charset parameter value is
case-insensitive due to the definition in RFC 2046 case-insensitive due to the definition in RFC 2046
(<https://github.com/httpwg/http-core/issues/13>) (<https://github.com/httpwg/http-core/issues/13>)
o Define a separate registry for HTTP header field names o Define a separate registry for HTTP header field names
(<https://github.com/httpwg/http-core/issues/42>) (<https://github.com/httpwg/http-core/issues/42>)
o In Section 8.4, refactor and clarify description of wildcard ("*") o In Section 8.4, refactor and clarify description of wildcard ("*")
handling (<https://github.com/httpwg/http-core/issues/46>) handling (<https://github.com/httpwg/http-core/issues/46>)
o Deprecate Accept-Charset (<https://github.com/httpwg/http-core/ o Deprecate Accept-Charset (<https://github.com/httpwg/http-core/
issues/61>) issues/61>)
o In Section 8.2.1, mention Cache-Control: immutable o In Section 8.2.1, mention Cache-Control: immutable
(<https://github.com/httpwg/http-core/issues/69>) (<https://github.com/httpwg/http-core/issues/69>)
o In Section 4.2.1, clarify when header field combination is allowed o In Section 4.1, clarify when header field combination is allowed
(<https://github.com/httpwg/http-core/issues/74>) (<https://github.com/httpwg/http-core/issues/74>)
o In Section 14.4, instruct IANA to mark Content-MD5 as obsolete o In Section 12.4, instruct IANA to mark Content-MD5 as obsolete
(<https://github.com/httpwg/http-core/issues/93>) (<https://github.com/httpwg/http-core/issues/93>)
o Use RFC 7405 ABNF notation for case-sensitive string constants o Use RFC 7405 ABNF notation for case-sensitive string constants
(<https://github.com/httpwg/http-core/issues/133>) (<https://github.com/httpwg/http-core/issues/133>)
o Rework Section 2.1 to be more version-independent o Rework Section 2.1 to be more version-independent
(<https://github.com/httpwg/http-core/issues/142>) (<https://github.com/httpwg/http-core/issues/142>)
o In Section 7.3.5, clarify that DELETE needs to be successful to o In Section 7.3.5, clarify that DELETE needs to be successful to
invalidate cache (<https://github.com/httpwg/http-core/ invalidate cache (<https://github.com/httpwg/http-core/
issues/167>, <https://www.rfc-editor.org/errata/eid5541>) issues/167>, <https://www.rfc-editor.org/errata/eid5541>)
J.6. Since draft-ietf-httpbis-semantics-04 C.6. Since draft-ietf-httpbis-semantics-04
o In Section 4.2, fix field-content ABNF o In Section 4.4, fix field-content ABNF
(<https://github.com/httpwg/http-core/issues/19>, (<https://github.com/httpwg/http-core/issues/19>,
<https://www.rfc-editor.org/errata/eid4189>) <https://www.rfc-editor.org/errata/eid4189>)
o Move Section 4.2.3.4 into its own section o Move Section 4.4.1.4 into its own section
(<https://github.com/httpwg/http-core/issues/45>) (<https://github.com/httpwg/http-core/issues/45>)
o In Section 6.2.1, reference MIME Sniffing o In Section 6.2.1, reference MIME Sniffing
(<https://github.com/httpwg/http-core/issues/51>) (<https://github.com/httpwg/http-core/issues/51>)
o In Section 12, simplify the #rule mapping for recipients o In Section 4.5, simplify the #rule mapping for recipients
(<https://github.com/httpwg/http-core/issues/164>, (<https://github.com/httpwg/http-core/issues/164>,
<https://www.rfc-editor.org/errata/eid5257>) <https://www.rfc-editor.org/errata/eid5257>)
o In Section 7.3.7, remove misleading text about "extension" of HTTP o In Section 7.3.7, remove misleading text about "extension" of HTTP
is needed to define method payloads (<https://github.com/httpwg/ is needed to define method payloads (<https://github.com/httpwg/
http-core/issues/204>) http-core/issues/204>)
o Fix editorial issue in Section 6 (<https://github.com/httpwg/http- o Fix editorial issue in Section 6 (<https://github.com/httpwg/http-
core/issues/223>) core/issues/223>)
o In Section 9.5.20, rephrase language not to use "entity" anymore, o In Section 9.5.20, rephrase language not to use "entity" anymore,
and also avoid lowercase "may" (<https://github.com/httpwg/http- and also avoid lowercase "may" (<https://github.com/httpwg/http-
core/issues/224>) core/issues/224>)
o Move discussion of retries from [Messaging] into Section 7.2.2 o Move discussion of retries from [Messaging] into Section 7.2.2
(<https://github.com/httpwg/http-core/issues/230>) (<https://github.com/httpwg/http-core/issues/230>)
J.7. Since draft-ietf-httpbis-semantics-05 C.7. Since draft-ietf-httpbis-semantics-05
o Moved transport-independent part of the description of trailers o Moved transport-independent part of the description of trailers
into Section 4.3 (<https://github.com/httpwg/http-core/issues/16>) into Section 4.6 (<https://github.com/httpwg/http-core/issues/16>)
o Loosen requirements on retries based upon implementation behavior o Loosen requirements on retries based upon implementation behavior
(<https://github.com/httpwg/http-core/issues/27>) (<https://github.com/httpwg/http-core/issues/27>)
o In Section 14.9, update IANA port registry for TCP/UDP on ports 80 o In Section 12.9, update IANA port registry for TCP/UDP on ports 80
and 443 (<https://github.com/httpwg/http-core/issues/36>) and 443 (<https://github.com/httpwg/http-core/issues/36>)
o In Section 4.4, revise guidelines for new header field names o In Section 4.7, revise guidelines for new header field names
(<https://github.com/httpwg/http-core/issues/47>) (<https://github.com/httpwg/http-core/issues/47>)
o In Section 7.2.3, remove concept of "cacheable methods" in favor o In Section 7.2.3, remove concept of "cacheable methods" in favor
of prose (<https://github.com/httpwg/http-core/issues/54>) of prose (<https://github.com/httpwg/http-core/issues/54>,
<https://www.rfc-editor.org/errata/eid5300>)
o In Section 13.1, mention that the concept of authority can be o In Section 11.1, mention that the concept of authority can be
modified by protocol extensions (<https://github.com/httpwg/http- modified by protocol extensions (<https://github.com/httpwg/http-
core/issues/143>) core/issues/143>)
o Create new subsection on payload body in Section 6.3.3, taken from o Create new subsection on payload body in Section 6.3.3, taken from
portions of message body (<https://github.com/httpwg/http-core/ portions of message body (<https://github.com/httpwg/http-core/
issues/159>) issues/159>)
o Moved definition of "Whitespace" into new container "Generic o Moved definition of "Whitespace" into new container "Generic
Syntax" (Section 11) (<https://github.com/httpwg/http-core/ Syntax" (<https://github.com/httpwg/http-core/issues/162>)
issues/162>)
o In Section 2.5, recommend minimum URI size support for o In Section 2.5, recommend minimum URI size support for
implementations (<https://github.com/httpwg/http-core/issues/169>) implementations (<https://github.com/httpwg/http-core/issues/169>)
o In Section 6.1.4, refactored the range-unit and ranges-specifier o In Section 6.1.4, refactored the range-unit and ranges-specifier
grammars (<https://github.com/httpwg/http-core/issues/196>) grammars (<https://github.com/httpwg/http-core/issues/196>,
<https://www.rfc-editor.org/errata/eid5620>)
o In Section 7.3.1, caution against a request body more strongly o In Section 7.3.1, caution against a request body more strongly
(<https://github.com/httpwg/http-core/issues/202>) (<https://github.com/httpwg/http-core/issues/202>)
o Reorganized text in Section 4.4 (<https://github.com/httpwg/http- o Reorganized text in Section 4.7 (<https://github.com/httpwg/http-
core/issues/214>) core/issues/214>)
o In Section 9.5.4, replace "authorize" with "fulfill" o In Section 9.5.4, replace "authorize" with "fulfill"
(<https://github.com/httpwg/http-core/issues/218>) (<https://github.com/httpwg/http-core/issues/218>)
o In Section 7.3.7, removed a misleading statement about Content- o In Section 7.3.7, removed a misleading statement about Content-
Length (<https://github.com/httpwg/http-core/issues/235>, Length (<https://github.com/httpwg/http-core/issues/235>,
<https://www.rfc-editor.org/errata/eid5806>) <https://www.rfc-editor.org/errata/eid5806>)
o In Section 13.1, add text from RFC 2818 o In Section 11.1, add text from RFC 2818
(<https://github.com/httpwg/http-core/issues/236>) (<https://github.com/httpwg/http-core/issues/236>)
o Changed "cacheable by default" to "heuristically cacheable" o Changed "cacheable by default" to "heuristically cacheable"
throughout (<https://github.com/httpwg/http-core/issues/242>) throughout (<https://github.com/httpwg/http-core/issues/242>)
C.8. Since draft-ietf-httpbis-semantics-06
o In Section 5.7.1, simplify received-by grammar (and disallow comma
character) (<https://github.com/httpwg/http-core/issues/24>)
o In Section 4.3, give guidance on interoperable field names
(<https://github.com/httpwg/http-core/issues/30>)
o In Section 1.2.1, define the semantics and possible replacement of
whitespace when it is known to occur (<https://github.com/httpwg/
http-core/issues/53>)
o In Section 4, introduce field terminology and distinguish between
field line values and field values; use terminology consistently
throughout (<https://github.com/httpwg/http-core/issues/111>)
o Moved #rule definition into Section 4.4 and whitespace into
Section 1.2 (<https://github.com/httpwg/http-core/issues/162>)
o In Section 6.1.4, explicitly call out range unit names as case-
insensitive, and encourage registration
(<https://github.com/httpwg/http-core/issues/179>)
o In Section 6.1.2, explicitly call out content codings as case-
insensitive, and encourage registration
(<https://github.com/httpwg/http-core/issues/179>)
o In Section 4.3, explicitly call out field names as case-
insensitive (<https://github.com/httpwg/http-core/issues/179>)
o In Section 11.11, cite [Bujlow] (<https://github.com/httpwg/http-
core/issues/185>)
o In Section 9, formally define "final" and "interim" status codes
(<https://github.com/httpwg/http-core/issues/245>)
o In Section 7.3.5, caution against a request body more strongly
(<https://github.com/httpwg/http-core/issues/258>)
o In Section 10.2.3, note that Etag can be used in trailers
(<https://github.com/httpwg/http-core/issues/262>)
o In Section 12.4, consider reserved fields as well
(<https://github.com/httpwg/http-core/issues/273>)
o In Section 2.5.4, be more correct about what was deprecated by RFC
3986 (<https://github.com/httpwg/http-core/issues/278>,
<https://www.rfc-editor.org/errata/eid5964>)
o In Section 4.1, recommend comma SP when combining field lines
(<https://github.com/httpwg/http-core/issues/148>)
o In Section 5.6, make explicit requirements on origin server to use
authority from absolute-form when available
(<https://github.com/httpwg/http-core/issues/191>)
o In Section 2.5.1, Section 2.5.2, Section 5.2, and Section 5.4,
refactored schemes to define origin and authoritative access to an
origin server for both "http" and "https" URIs to account for
alternative services and secured connections that are not
necessarily based on TCP (<https://github.com/httpwg/http-core/
issues/237>)
o In Section 1.1, reference RFC 8174 as well
(<https://github.com/httpwg/http-core/issues/303>)
Index Index
1 1
100 Continue (status code) 114 100 Continue (status code) 121
100-continue (expect value) 81 100-continue (expect value) 88
101 Switching Protocols (status code) 114 101 Switching Protocols (status code) 121
1xx Informational (status code class) 113 1xx Informational (status code class) 120
2 2
200 OK (status code) 114 200 OK (status code) 121
201 Created (status code) 115 201 Created (status code) 122
202 Accepted (status code) 115 202 Accepted (status code) 122
203 Non-Authoritative Information (status code) 116 203 Non-Authoritative Information (status code) 123
204 No Content (status code) 116 204 No Content (status code) 123
205 Reset Content (status code) 117 205 Reset Content (status code) 124
206 Partial Content (status code) 117 206 Partial Content (status code) 124
2xx Successful (status code class) 114 2xx Successful (status code class) 121
3 3
300 Multiple Choices (status code) 122 300 Multiple Choices (status code) 129
301 Moved Permanently (status code) 123 301 Moved Permanently (status code) 130
302 Found (status code) 123 302 Found (status code) 130
303 See Other (status code) 124 303 See Other (status code) 131
304 Not Modified (status code) 124 304 Not Modified (status code) 131
305 Use Proxy (status code) 125 305 Use Proxy (status code) 132
306 (Unused) (status code) 125 306 (Unused) (status code) 132
307 Temporary Redirect (status code) 125 307 Temporary Redirect (status code) 132
308 Permanent Redirect (status code) 126 308 Permanent Redirect (status code) 133
3xx Redirection (status code class) 120 3xx Redirection (status code class) 127
4 4
400 Bad Request (status code) 126 400 Bad Request (status code) 133
401 Unauthorized (status code) 126 401 Unauthorized (status code) 133
402 Payment Required (status code) 127 402 Payment Required (status code) 134
403 Forbidden (status code) 127 403 Forbidden (status code) 134
404 Not Found (status code) 127 404 Not Found (status code) 134
405 Method Not Allowed (status code) 128 405 Method Not Allowed (status code) 135
406 Not Acceptable (status code) 128 406 Not Acceptable (status code) 135
407 Proxy Authentication Required (status code) 128 407 Proxy Authentication Required (status code) 135
408 Request Timeout (status code) 128 408 Request Timeout (status code) 135
409 Conflict (status code) 129 409 Conflict (status code) 136
410 Gone (status code) 129 410 Gone (status code) 136
411 Length Required (status code) 129 411 Length Required (status code) 136
412 Precondition Failed (status code) 130 412 Precondition Failed (status code) 137
413 Payload Too Large (status code) 130 413 Payload Too Large (status code) 137
414 URI Too Long (status code) 130 414 URI Too Long (status code) 137
415 Unsupported Media Type (status code) 130 415 Unsupported Media Type (status code) 137
416 Range Not Satisfiable (status code) 131 416 Range Not Satisfiable (status code) 138
417 Expectation Failed (status code) 131 417 Expectation Failed (status code) 138
418 (Unused) (status code) 131 418 (Unused) (status code) 138
422 Unprocessable Payload (status code) 132 422 Unprocessable Payload (status code) 139
426 Upgrade Required (status code) 132 426 Upgrade Required (status code) 139
4xx Client Error (status code class) 126 4xx Client Error (status code class) 133
5 5
500 Internal Server Error (status code) 133 500 Internal Server Error (status code) 140
501 Not Implemented (status code) 133 501 Not Implemented (status code) 140
502 Bad Gateway (status code) 133 502 Bad Gateway (status code) 140
503 Service Unavailable (status code) 133 503 Service Unavailable (status code) 140
504 Gateway Timeout (status code) 133 504 Gateway Timeout (status code) 140
505 HTTP Version Not Supported (status code) 133 505 HTTP Version Not Supported (status code) 140
5xx Server Error (status code class) 132 5xx Server Error (status code class) 139
A A
Accept header field 97 Accept header field 104
Accept-Charset header field 99 Accept-Charset header field 106
Accept-Encoding header field 100 Accept-Encoding header field 107
Accept-Language header field 101 Accept-Language header field 108
Accept-Ranges header field 154 Accept-Ranges header field 161
Allow header field 154 Allow header field 161
Authentication-Info header field 152 Authentication-Info header field 159
Authorization header field 105 Authorization header field 112
accelerator 13 accelerator 14
authoritative response 158 authoritative response 163
B B
browser 10 browser 11
C C
CONNECT method 76 CONNECT method 83
Canonical Root URI 104 Canonical Root URI 111
Content-Encoding header field 52 Content-Encoding header field 59
Content-Language header field 53 Content-Language header field 60
Content-Length header field 54 Content-Length header field 61
Content-Location header field 55 Content-Location header field 62
Content-MD5 header field 168 Content-MD5 header field 173
Content-Range header field 59 Content-Range header field 66
Content-Type header field 51 Content-Type header field 58
cache 14 cache 15
cacheable 14 cacheable 15
captive portal 14 captive portal 15
client 10 client 11
compress (Coding Format) 45 compress (Coding Format) 52
compress (content coding) 44 compress (content coding) 51
conditional request 84 conditional request 91
connection 10 connection 11
content coding 44 content coding 51
content negotiation 9 content negotiation 9
D D
DELETE method 75 DELETE method 82
Date header field 138 Date header field 145
Delimiters 30 Delimiters 30
deflate (Coding Format) 45 deflate (Coding Format) 52
deflate (content coding) 44 deflate (content coding) 51
downstream 12 downstream 14
E E
ETag header field 146 ETag field 153
Expect header field 81 Expect header field 88
effective request URI 36 effective request URI 43
F F
Fields
Accept 104
Accept-Charset 106
Accept-Encoding 107
Accept-Language 108
Accept-Ranges 161
Allow 161
Authentication-Info 159
Authorization 112
Content-Encoding 59
Content-Language 60
Content-Length 61
Content-Location 62
Content-MD5 173
Content-Range 66
Content-Type 58
Date 145
ETag 153
Expect 88
From 115
Host 43
If-Match 95
If-Modified-Since 97
If-None-Match 96
If-Range 100
If-Unmodified-Since 98
Last-Modified 151
Location 146
Max-Forwards 90
Proxy-Authenticate 159
Proxy-Authentication-Info 160
Proxy-Authorization 112
Range 101
Referer 116
Retry-After 147
Server 162
Trailer 34
User-Agent 117
Vary 147
Via 45
WWW-Authenticate 158
Fragment Identifiers 20 Fragment Identifiers 20
From header field 108 From header field 115
field 24
field line 24
field line value 24
field name 24
field value 24
G G
GET method 70 GET method 77
Grammar Grammar
absolute-path 15 absolute-path 16
absolute-URI 15 absolute-URI 16
Accept 97 Accept 104
Accept-Charset 99 Accept-Charset 106
Accept-Encoding 100 Accept-Encoding 107
accept-ext 97 accept-ext 104
Accept-Language 101 Accept-Language 108
accept-params 97 accept-params 104
Accept-Ranges 154 Accept-Ranges 161
acceptable-ranges 154 acceptable-ranges 161
Allow 154 Allow 161
ALPHA 9 ALPHA 10
asctime-date 137 asctime-date 144
auth-param 103 auth-param 110
auth-scheme 103 auth-scheme 110
Authentication-Info 152 Authentication-Info 159
authority 15 authority 16
Authorization 105 Authorization 112
BWS 156 BWS 11
challenge 103 challenge 110
charset 43 charset 49
codings 100 codings 107
comment 31 comment 31
complete-length 60 complete-length 67
content-coding 44 content-coding 51
Content-Encoding 52 Content-Encoding 59
Content-Language 53 Content-Language 60
Content-Length 54 Content-Length 61
Content-Location 55 Content-Location 62
Content-Range 60 Content-Range 67
Content-Type 51 Content-Type 58
CR 9 CR 10
credentials 104 credentials 111
CRLF 9 CRLF 10
ctext 31 ctext 31
CTL 9 CTL 10
Date 138 Date 145
date1 137 date1 144
day 137 day 144
day-name 137 day-name 144
day-name-l 137 day-name-l 144
delay-seconds 140 delay-seconds 147
DIGIT 9 DIGIT 10
DQUOTE 9 DQUOTE 10
entity-tag 147 entity-tag 154
ETag 147 ETag 154
etagc 147 etagc 154
Expect 81 Expect 88
field-content 28 field-content 28
field-name 25, 33 field-name 26, 34
field-value 28 field-value 28
field-vchar 28 field-vchar 28
first-pos 48, 60 first-pos 55, 67
From 108 From 115
GMT 137 GMT 144
HEXDIG 9 HEXDIG 10
Host 37 Host 43
hour 137 hour 144
HTAB 9 HTAB 10
HTTP-date 136 HTTP-date 143
http-URI 16 http-URI 17
https-URI 18 https-URI 18
If-Match 88 If-Match 95
If-Modified-Since 90 If-Modified-Since 97
If-None-Match 89 If-None-Match 96
If-Range 93 If-Range 100
If-Unmodified-Since 91 If-Unmodified-Since 98
IMF-fixdate 137 IMF-fixdate 144
incl-range 60 incl-range 67
int-range 48 int-range 55
language-range 101 language-range 108
language-tag 46 language-tag 53
Last-Modified 144 Last-Modified 151
last-pos 48, 60 last-pos 55, 67
LF 9 LF 10
Location 139 Location 146
Max-Forwards 83 Max-Forwards 90
media-range 97 media-range 104
media-type 42 media-type 49
method 66 method 73
minute 137 minute 144
month 137 month 144
obs-date 137 obs-date 144
obs-text 30 obs-text 30
OCTET 9 OCTET 10
opaque-tag 147 opaque-tag 154
other-range 48 other-range 55
OWS 156 OWS 11
parameter 31 parameter 31
parameter-name 31 parameter-name 31
parameter-value 31 parameter-value 31
partial-URI 15 partial-URI 16
port 15 port 16
product 110 product 117
product-version 110 product-version 117
protocol-name 39 protocol-name 45
protocol-version 39 protocol-version 45
Proxy-Authenticate 152 Proxy-Authenticate 159
Proxy-Authentication-Info 153 Proxy-Authentication-Info 160
Proxy-Authorization 105 Proxy-Authorization 112
pseudonym 39 pseudonym 45
qdtext 30 qdtext 30
query 15 query 16
quoted-pair 31 quoted-pair 30
quoted-string 30 quoted-string 30
qvalue 97 qvalue 104
Range 94 Range 101
range-resp 60 range-resp 67
range-set 48 range-set 55
range-spec 48 range-spec 55
range-unit 47 range-unit 54
ranges-specifier 48 ranges-specifier 55
received-by 39 received-by 45
received-protocol 39 received-protocol 45
Referer 109 Referer 116
Retry-After 140 Retry-After 147
rfc850-date 137 rfc850-date 144
RWS 156 RWS 11
second 137 second 144
segment 15 segment 16
Server 155 Server 162
SP 9 SP 10
subtype 42 subtype 49
suffix-length 48 suffix-length 55
suffix-range 48 suffix-range 55
tchar 30 tchar 30
time-of-day 137 time-of-day 144
token 30 token 30
token68 103 token68 110
Trailer 33 Trailer 34
type 42 type 49
unsatisfied-range 60 unsatisfied-range 67
uri-host 15 uri-host 16
URI-reference 15 URI-reference 16
User-Agent 110 User-Agent 117
Vary 141 Vary 148
VCHAR 9 VCHAR 10
Via 39 Via 45
weak 147 weak 154
weight 97 weight 104
WWW-Authenticate 151 WWW-Authenticate 158
year 137 year 144
gateway 13 gateway 14
gzip (Coding Format) 45 gzip (Coding Format) 52
gzip (content coding) 44 gzip (content coding) 51
H H
HEAD method 71 HEAD method 78
Host header field 37 Header Fields
http URI scheme 16 Accept 104
Accept-Charset 106
Accept-Encoding 107
Accept-Language 108
Accept-Ranges 161
Allow 161
Authentication-Info 159
Authorization 112
Content-Encoding 59
Content-Language 60
Content-Length 61
Content-Location 62
Content-MD5 173
Content-Range 66
Content-Type 58
Date 145
ETag 153
Expect 88
From 115
Host 43
If-Match 95
If-Modified-Since 97
If-None-Match 96
If-Range 100
If-Unmodified-Since 98
Last-Modified 151
Location 146
Max-Forwards 90
Proxy-Authenticate 159
Proxy-Authentication-Info 160
Proxy-Authorization 112
Range 101
Referer 116
Retry-After 147
Server 162
Trailer 34
User-Agent 117
Vary 147
Via 45
WWW-Authenticate 158
Host header field 43
header section 24
http URI scheme 17
https URI scheme 18 https URI scheme 18
I I
If-Match header field 88 If-Match header field 95
If-Modified-Since header field 90 If-Modified-Since header field 97
If-None-Match header field 89 If-None-Match header field 96
If-Range header field 93 If-Range header field 100
If-Unmodified-Since header field 91 If-Unmodified-Since header field 98
idempotent 69 idempotent 76
inbound 12 inbound 14
interception proxy 14 interception proxy 15
intermediary 12 intermediary 13
L L
Last-Modified header field 144 Last-Modified header field 151
Location header field 139 Location header field 146
M M
Max-Forwards header field 83 Max-Forwards header field 90
Media Type Media Type
multipart/byteranges 61 multipart/byteranges 68
multipart/x-byteranges 62 multipart/x-byteranges 69
message 11 message 12
metadata 142 metadata 149
multipart/byteranges Media Type 61 multipart/byteranges Media Type 68
multipart/x-byteranges Media Type 62 multipart/x-byteranges Media Type 69
N N
non-transforming proxy 40 non-transforming proxy 47
O O
OPTIONS method 78 OPTIONS method 85
origin server 10 origin 37
outbound 12 origin server 11
outbound 14
P P
POST method 72 POST method 79
PUT method 73 PUT method 80
Protection Space 104 Protection Space 111
Proxy-Authenticate header field 152 Proxy-Authenticate header field 159
Proxy-Authentication-Info header field 153 Proxy-Authentication-Info header field 160
Proxy-Authorization header field 105 Proxy-Authorization header field 112
payload 57 payload 64
phishing 158 phishing 163
proxy 13 proxy 14
R R
Range header field 94 Range header field 101
Realm 104 Realm 111
Referer header field 109 Referer header field 116
Retry-After header field 140 Retry-After header field 147
recipient 10 recipient 11
representation 41 representation 48
request 11 request 12
resource 15 resource 16
response 11 response 12
reverse proxy 13 reverse proxy 14
S S
Server header field 155 Server header field 162
Status Code 118
Status Codes
Final 119
Informational 119
Interim 119
Status Codes Classes Status Codes Classes
1xx Informational 113 1xx Informational 120
2xx Successful 114 2xx Successful 121
3xx Redirection 120 3xx Redirection 127
4xx Client Error 126 4xx Client Error 133
5xx Server Error 132 5xx Server Error 139
safe 68 safe 75
selected representation 41, 84, 142 secured 18
sender 10 selected representation 48, 91, 149
server 10 sender 11
spider 10 server 11
spider 11
T T
TRACE method 79 TRACE method 86
Trailer header field 33 Trailer Fields
target URI 35 ETag 153
target resource 35 Trailer header field 34
trailer fields 32 target URI 37
trailers 32 target resource 37
transforming proxy 40 trailer fields 33
transparent proxy 14 trailer section 24
tunnel 13 trailers 33
transforming proxy 47
transparent proxy 15
tunnel 14
U U
URI
origin 37
URI scheme URI scheme
http 16 http 17
https 18 https 18
User-Agent header field 110 User-Agent header field 117
upstream 12 upstream 14
user agent 10 user agent 11
V V
Vary header field 141 Vary header field 147
Via header field 39 Via header field 45
validator 142 validator 149
strong 143 strong 150
weak 143 weak 150
W W
WWW-Authenticate header field 151 WWW-Authenticate header field 158
X X
x-compress (content coding) 44 x-compress (content coding) 51
x-gzip (content coding) 44 x-gzip (content coding) 51
Acknowledgments Acknowledgments
This edition of the HTTP specification builds on the many This edition of the HTTP specification builds on the many
contributions that went into RFC 1945, RFC 2068, RFC 2145, RFC 2616, contributions that went into RFC 1945, RFC 2068, RFC 2145, RFC 2616,
and RFC 2818, including substantial contributions made by the and RFC 2818, including substantial contributions made by the
previous authors, editors, and Working Group Chairs: Tim Berners-Lee, previous authors, editors, and Working Group Chairs: Tim Berners-Lee,
Ari Luotonen, Roy T. Fielding, Henrik Frystyk Nielsen, Jim Gettys, Ari Luotonen, Roy T. Fielding, Henrik Frystyk Nielsen, Jim Gettys,
Jeffrey C. Mogul, Larry Masinter, Paul J. Leach, Eric Rescorla, and Jeffrey C. Mogul, Larry Masinter, Paul J. Leach, Eric Rescorla, and
Yves Lafon. Yves Lafon.
 End of changes. 345 change blocks. 
1453 lines changed or deleted 1872 lines changed or added

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