draft-ietf-httpbis-semantics-06.txt   draft-ietf-httpbis-semantics-latest.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: July 25, 2020 January 22, 2020
HTTP Semantics HTTP Semantics
draft-ietf-httpbis-semantics-06 draft-ietf-httpbis-semantics-latest
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 J.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 July 25, 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 52 skipping to change at page 2, line 52
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 9 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 9
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 9 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 9
2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 10 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 10 2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 10
2.2. Intermediaries . . . . . . . . . . . . . . . . . . . . . 12 2.2. Intermediaries . . . . . . . . . . . . . . . . . . . . . 12
2.3. Caches . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3. Caches . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4. Uniform Resource Identifiers . . . . . . . . . . . . . . 15 2.4. Uniform Resource Identifiers . . . . . . . . . . . . . . 15
2.5. Resources . . . . . . . . . . . . . . . . . . . . . . . . 16 2.5. Resources . . . . . . . . . . . . . . . . . . . . . . . . 16
2.5.1. http URI Scheme . . . . . . . . . . . . . . . . . . . 16 2.5.1. http URI Scheme . . . . . . . . . . . . . . . . . . . 16
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 . . . 18
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 . . . 19
3.1. Implementation Diversity . . . . . . . . . . . . . . . . 21 3. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2. Role-based Requirements . . . . . . . . . . . . . . . . . 21 3.1. Implementation Diversity . . . . . . . . . . . . . . . . 19
3.3. Parsing Elements . . . . . . . . . . . . . . . . . . . . 22 3.2. Role-based Requirements . . . . . . . . . . . . . . . . . 20
3.4. Error Handling . . . . . . . . . . . . . . . . . . . . . 23 3.3. Parsing Elements . . . . . . . . . . . . . . . . . . . . 21
3.5. Protocol Versioning . . . . . . . . . . . . . . . . . . . 23 3.4. Error Handling . . . . . . . . . . . . . . . . . . . . . 21
4. Header Fields . . . . . . . . . . . . . . . . . . . . . . . . 24 3.5. Protocol Versioning . . . . . . . . . . . . . . . . . . . 22
4.1. Header Field Names . . . . . . . . . . . . . . . . . . . 24 4. Header Fields . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1.1. Header Field Name Registry . . . . . . . . . . . . . 27 4.1. Header Field Names . . . . . . . . . . . . . . . . . . . 23
4.1.2. Header Field Extensibility . . . . . . . . . . . . . 28 4.1.1. Header Field Name Registry . . . . . . . . . . . . . 26
4.2. Header Field Values . . . . . . . . . . . . . . . . . . . 28 4.1.2. Header Field Extensibility . . . . . . . . . . . . . 27
4.2.1. Header Field Order . . . . . . . . . . . . . . . . . 29 4.2. Header Field Values . . . . . . . . . . . . . . . . . . . 27
4.2.2. Header Field Limits . . . . . . . . . . . . . . . . . 30 4.2.1. Header Field Order . . . . . . . . . . . . . . . . . 28
4.2.3. Header Field Value Components . . . . . . . . . . . . 30 4.2.2. Header Field Limits . . . . . . . . . . . . . . . . . 29
4.3. Trailer Fields . . . . . . . . . . . . . . . . . . . . . 32 4.2.3. Header Field Value Components . . . . . . . . . . . . 29
4.3.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 32 4.3. Trailer Fields . . . . . . . . . . . . . . . . . . . . . 31
4.3.2. Limitations . . . . . . . . . . . . . . . . . . . . . 32 4.3.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 31
4.3.3. Trailer . . . . . . . . . . . . . . . . . . . . . . . 33 4.3.2. Limitations . . . . . . . . . . . . . . . . . . . . . 31
4.4. Considerations for New Header Fields . . . . . . . . . . 33 4.3.3. Trailer . . . . . . . . . . . . . . . . . . . . . . . 32
5. Message Routing . . . . . . . . . . . . . . . . . . . . . . . 35 4.4. Considerations for New Header Fields . . . . . . . . . . 32
5.1. Identifying a Target Resource . . . . . . . . . . . . . . 35 5. Message Routing . . . . . . . . . . . . . . . . . . . . . . . 34
5.2. Routing Inbound . . . . . . . . . . . . . . . . . . . . . 36 5.1. Identifying a Target Resource . . . . . . . . . . . . . . 34
5.3. Effective Request URI . . . . . . . . . . . . . . . . . . 36 5.2. Routing Inbound . . . . . . . . . . . . . . . . . . . . . 35
5.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . 37 5.3. Initiating HTTP Over TLS . . . . . . . . . . . . . . . . 35
5.5. Message Forwarding . . . . . . . . . . . . . . . . . . . 38 5.3.1. Identifying HTTPS Servers . . . . . . . . . . . . . . 36
5.5.1. Via . . . . . . . . . . . . . . . . . . . . . . . . . 39 5.3.2. Identifying HTTPS Clients . . . . . . . . . . . . . . 37
5.5.2. Transformations . . . . . . . . . . . . . . . . . . . 40 5.4. Effective Request URI . . . . . . . . . . . . . . . . . . 37
6. Representations . . . . . . . . . . . . . . . . . . . . . . . 41 5.5. Host . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.1. Representation Data . . . . . . . . . . . . . . . . . . . 42 5.6. Message Forwarding . . . . . . . . . . . . . . . . . . . 39
6.1.1. Media Type . . . . . . . . . . . . . . . . . . . . . 42 5.6.1. Via . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.1.2. Content Codings . . . . . . . . . . . . . . . . . . . 44 5.6.2. Transformations . . . . . . . . . . . . . . . . . . . 41
6.1.3. Language Tags . . . . . . . . . . . . . . . . . . . . 46 6. Representations . . . . . . . . . . . . . . . . . . . . . . . 42
6.1.4. Range Units . . . . . . . . . . . . . . . . . . . . . 47 6.1. Representation Data . . . . . . . . . . . . . . . . . . . 43
6.2. Representation Metadata . . . . . . . . . . . . . . . . . 51 6.1.1. Media Type . . . . . . . . . . . . . . . . . . . . . 43
6.2.1. Content-Type . . . . . . . . . . . . . . . . . . . . 51 6.1.2. Content Codings . . . . . . . . . . . . . . . . . . . 45
6.2.2. Content-Encoding . . . . . . . . . . . . . . . . . . 52 6.1.3. Language Tags . . . . . . . . . . . . . . . . . . . . 47
6.2.3. Content-Language . . . . . . . . . . . . . . . . . . 53 6.1.4. Range Units . . . . . . . . . . . . . . . . . . . . . 48
6.2.4. Content-Length . . . . . . . . . . . . . . . . . . . 54 6.2. Representation Metadata . . . . . . . . . . . . . . . . . 52
6.2.5. Content-Location . . . . . . . . . . . . . . . . . . 55 6.2.1. Content-Type . . . . . . . . . . . . . . . . . . . . 52
6.3. Payload . . . . . . . . . . . . . . . . . . . . . . . . . 57 6.2.2. Content-Encoding . . . . . . . . . . . . . . . . . . 53
6.3.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 57 6.2.3. Content-Language . . . . . . . . . . . . . . . . . . 54
6.3.2. Identification . . . . . . . . . . . . . . . . . . . 58 6.2.4. Content-Length . . . . . . . . . . . . . . . . . . . 55
6.3.3. Payload Body . . . . . . . . . . . . . . . . . . . . 59 6.2.5. Content-Location . . . . . . . . . . . . . . . . . . 56
6.3.4. Content-Range . . . . . . . . . . . . . . . . . . . . 59 6.3. Payload . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.3.5. Media Type multipart/byteranges . . . . . . . . . . . 61 6.3.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 58
6.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 63 6.3.2. Identification . . . . . . . . . . . . . . . . . . . 59
6.4.1. Proactive Negotiation . . . . . . . . . . . . . . . . 64 6.3.3. Payload Body . . . . . . . . . . . . . . . . . . . . 60
6.4.2. Reactive Negotiation . . . . . . . . . . . . . . . . 65 6.3.4. Content-Range . . . . . . . . . . . . . . . . . . . . 60
7. Request Methods . . . . . . . . . . . . . . . . . . . . . . . 66 6.3.5. Media Type multipart/byteranges . . . . . . . . . . . 62
7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 66 6.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 64
7.2. Common Method Properties . . . . . . . . . . . . . . . . 67 6.4.1. Proactive Negotiation . . . . . . . . . . . . . . . . 65
7.2.1. Safe Methods . . . . . . . . . . . . . . . . . . . . 68 6.4.2. Reactive Negotiation . . . . . . . . . . . . . . . . 66
7.2.2. Idempotent Methods . . . . . . . . . . . . . . . . . 69 7. Request Methods . . . . . . . . . . . . . . . . . . . . . . . 67
7.2.3. Methods and Caching . . . . . . . . . . . . . . . . . 70 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 67
7.3. Method Definitions . . . . . . . . . . . . . . . . . . . 70 7.2. Common Method Properties . . . . . . . . . . . . . . . . 68
7.3.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 70 7.2.1. Safe Methods . . . . . . . . . . . . . . . . . . . . 69
7.3.2. HEAD . . . . . . . . . . . . . . . . . . . . . . . . 71 7.2.2. Idempotent Methods . . . . . . . . . . . . . . . . . 70
7.3.3. POST . . . . . . . . . . . . . . . . . . . . . . . . 72 7.2.3. Methods and Caching . . . . . . . . . . . . . . . . . 71
7.3.4. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 73 7.3. Method Definitions . . . . . . . . . . . . . . . . . . . 71
7.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . 75 7.3.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 71
7.3.6. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 76 7.3.2. HEAD . . . . . . . . . . . . . . . . . . . . . . . . 72
7.3.7. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 78 7.3.3. POST . . . . . . . . . . . . . . . . . . . . . . . . 73
7.3.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . 79 7.3.4. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 74
7.4. Method Extensibility . . . . . . . . . . . . . . . . . . 79 7.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . 76
7.4.1. Method Registry . . . . . . . . . . . . . . . . . . . 79 7.3.6. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 77
7.4.2. Considerations for New Methods . . . . . . . . . . . 80 7.3.7. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 79
8. Request Header Fields . . . . . . . . . . . . . . . . . . . . 80 7.3.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . 80
8.1. Controls . . . . . . . . . . . . . . . . . . . . . . . . 81 7.4. Method Extensibility . . . . . . . . . . . . . . . . . . 80
8.1.1. Expect . . . . . . . . . . . . . . . . . . . . . . . 81 7.4.1. Method Registry . . . . . . . . . . . . . . . . . . . 80
8.1.2. Max-Forwards . . . . . . . . . . . . . . . . . . . . 83 7.4.2. Considerations for New Methods . . . . . . . . . . . 81
8.2. Preconditions . . . . . . . . . . . . . . . . . . . . . . 84 8. Request Header Fields . . . . . . . . . . . . . . . . . . . . 81
8.2.1. Evaluation . . . . . . . . . . . . . . . . . . . . . 85 8.1. Controls . . . . . . . . . . . . . . . . . . . . . . . . 82
8.2.2. Precedence . . . . . . . . . . . . . . . . . . . . . 86 8.1.1. Expect . . . . . . . . . . . . . . . . . . . . . . . 82
8.2.3. If-Match . . . . . . . . . . . . . . . . . . . . . . 88 8.1.2. Max-Forwards . . . . . . . . . . . . . . . . . . . . 84
8.2.4. If-None-Match . . . . . . . . . . . . . . . . . . . . 89 8.2. Preconditions . . . . . . . . . . . . . . . . . . . . . . 85
8.2.5. If-Modified-Since . . . . . . . . . . . . . . . . . . 90 8.2.1. Evaluation . . . . . . . . . . . . . . . . . . . . . 86
8.2.6. If-Unmodified-Since . . . . . . . . . . . . . . . . . 91 8.2.2. Precedence . . . . . . . . . . . . . . . . . . . . . 87
8.2.7. If-Range . . . . . . . . . . . . . . . . . . . . . . 93 8.2.3. If-Match . . . . . . . . . . . . . . . . . . . . . . 89
8.3. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 94 8.2.4. If-None-Match . . . . . . . . . . . . . . . . . . . . 90
8.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 95 8.2.5. If-Modified-Since . . . . . . . . . . . . . . . . . . 91
8.4.1. Quality Values . . . . . . . . . . . . . . . . . . . 96 8.2.6. If-Unmodified-Since . . . . . . . . . . . . . . . . . 92
8.4.2. Accept . . . . . . . . . . . . . . . . . . . . . . . 97 8.2.7. If-Range . . . . . . . . . . . . . . . . . . . . . . 94
8.4.3. Accept-Charset . . . . . . . . . . . . . . . . . . . 99 8.3. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 95
8.4.4. Accept-Encoding . . . . . . . . . . . . . . . . . . . 100 8.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 96
8.4.5. Accept-Language . . . . . . . . . . . . . . . . . . . 101 8.4.1. Quality Values . . . . . . . . . . . . . . . . . . . 97
8.5. Authentication Credentials . . . . . . . . . . . . . . . 102 8.4.2. Accept . . . . . . . . . . . . . . . . . . . . . . . 98
8.5.1. Challenge and Response . . . . . . . . . . . . . . . 102 8.4.3. Accept-Charset . . . . . . . . . . . . . . . . . . . 100
8.5.2. Protection Space (Realm) . . . . . . . . . . . . . . 104 8.4.4. Accept-Encoding . . . . . . . . . . . . . . . . . . . 101
8.5.3. Authorization . . . . . . . . . . . . . . . . . . . . 105 8.4.5. Accept-Language . . . . . . . . . . . . . . . . . . . 102
8.5.4. Proxy-Authorization . . . . . . . . . . . . . . . . . 105 8.5. Authentication Credentials . . . . . . . . . . . . . . . 103
8.5.5. Authentication Scheme Extensibility . . . . . . . . . 106 8.5.1. Challenge and Response . . . . . . . . . . . . . . . 103
8.6. Request Context . . . . . . . . . . . . . . . . . . . . . 108 8.5.2. Protection Space (Realm) . . . . . . . . . . . . . . 105
8.6.1. From . . . . . . . . . . . . . . . . . . . . . . . . 108 8.5.3. Authorization . . . . . . . . . . . . . . . . . . . . 106
8.6.2. Referer . . . . . . . . . . . . . . . . . . . . . . . 109 8.5.4. Proxy-Authorization . . . . . . . . . . . . . . . . . 106
8.6.3. User-Agent . . . . . . . . . . . . . . . . . . . . . 110 8.5.5. Authentication Scheme Extensibility . . . . . . . . . 107
9. Response Status Codes . . . . . . . . . . . . . . . . . . . . 111 8.6. Request Context . . . . . . . . . . . . . . . . . . . . . 109
9.1. Overview of Status Codes . . . . . . . . . . . . . . . . 112 8.6.1. From . . . . . . . . . . . . . . . . . . . . . . . . 109
9.2. Informational 1xx . . . . . . . . . . . . . . . . . . . . 113 8.6.2. Referer . . . . . . . . . . . . . . . . . . . . . . . 110
9.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 114 8.6.3. User-Agent . . . . . . . . . . . . . . . . . . . . . 111
9.2.2. 101 Switching Protocols . . . . . . . . . . . . . . . 114 9. Response Status Codes . . . . . . . . . . . . . . . . . . . . 112
9.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . 114 9.1. Overview of Status Codes . . . . . . . . . . . . . . . . 113
9.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 114 9.2. Informational 1xx . . . . . . . . . . . . . . . . . . . . 114
9.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 115 9.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 115
9.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . 115 9.2.2. 101 Switching Protocols . . . . . . . . . . . . . . . 115
9.3.4. 203 Non-Authoritative Information . . . . . . . . . . 116 9.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . 115
9.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . 116 9.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 115
9.3.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 117 9.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 116
9.3.7. 206 Partial Content . . . . . . . . . . . . . . . . . 117 9.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . 116
9.4. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 120 9.3.4. 203 Non-Authoritative Information . . . . . . . . . . 117
9.4.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 122 9.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . 117
9.4.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 123 9.3.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 118
9.4.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 123 9.3.7. 206 Partial Content . . . . . . . . . . . . . . . . . 118
9.4.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 124 9.4. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 121
9.4.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 124 9.4.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 123
9.4.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 125 9.4.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 124
9.4.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . 125 9.4.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 124
9.4.8. 307 Temporary Redirect . . . . . . . . . . . . . . . 125 9.4.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 125
9.4.9. 308 Permanent Redirect . . . . . . . . . . . . . . . 126 9.4.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 125
9.5. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 126 9.4.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 126
9.5.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 126 9.4.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . 126
9.5.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 126 9.4.8. 307 Temporary Redirect . . . . . . . . . . . . . . . 126
9.5.3. 402 Payment Required . . . . . . . . . . . . . . . . 127 9.4.9. 308 Permanent Redirect . . . . . . . . . . . . . . . 127
9.5.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 127 9.5. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 127
9.5.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 127 9.5.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 127
9.5.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 128 9.5.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 127
9.5.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 128 9.5.3. 402 Payment Required . . . . . . . . . . . . . . . . 128
9.5.8. 407 Proxy Authentication Required . . . . . . . . . . 128 9.5.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 128
9.5.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 128 9.5.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 128
9.5.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . 129 9.5.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 129
9.5.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 129 9.5.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 129
9.5.12. 411 Length Required . . . . . . . . . . . . . . . . . 129 9.5.8. 407 Proxy Authentication Required . . . . . . . . . . 129
9.5.13. 412 Precondition Failed . . . . . . . . . . . . . . . 130 9.5.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 129
9.5.14. 413 Payload Too Large . . . . . . . . . . . . . . . . 130 9.5.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . 130
9.5.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . 130 9.5.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 130
9.5.16. 415 Unsupported Media Type . . . . . . . . . . . . . 130 9.5.12. 411 Length Required . . . . . . . . . . . . . . . . . 130
9.5.17. 416 Range Not Satisfiable . . . . . . . . . . . . . . 131 9.5.13. 412 Precondition Failed . . . . . . . . . . . . . . . 131
9.5.18. 417 Expectation Failed . . . . . . . . . . . . . . . 131 9.5.14. 413 Payload Too Large . . . . . . . . . . . . . . . . 131
9.5.19. 418 (Unused) . . . . . . . . . . . . . . . . . . . . 131 9.5.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . 131
9.5.20. 422 Unprocessable Payload . . . . . . . . . . . . . . 132 9.5.16. 415 Unsupported Media Type . . . . . . . . . . . . . 131
9.5.21. 426 Upgrade Required . . . . . . . . . . . . . . . . 132 9.5.17. 416 Range Not Satisfiable . . . . . . . . . . . . . . 132
9.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 132 9.5.18. 417 Expectation Failed . . . . . . . . . . . . . . . 132
9.6.1. 500 Internal Server Error . . . . . . . . . . . . . . 133 9.5.19. 418 (Unused) . . . . . . . . . . . . . . . . . . . . 132
9.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 133 9.5.20. 422 Unprocessable Payload . . . . . . . . . . . . . . 133
9.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 133 9.5.21. 426 Upgrade Required . . . . . . . . . . . . . . . . 133
9.6.4. 503 Service Unavailable . . . . . . . . . . . . . . . 133 9.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 133
9.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 133 9.6.1. 500 Internal Server Error . . . . . . . . . . . . . . 134
9.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . 133 9.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 134
9.7. Status Code Extensibility . . . . . . . . . . . . . . . . 134 9.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 134
9.7.1. Status Code Registry . . . . . . . . . . . . . . . . 134 9.6.4. 503 Service Unavailable . . . . . . . . . . . . . . . 134
9.7.2. Considerations for New Status Codes . . . . . . . . . 134 9.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 134
10. Response Header Fields . . . . . . . . . . . . . . . . . . . 135 9.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . 134
10.1. Control Data . . . . . . . . . . . . . . . . . . . . . . 135 9.7. Status Code Extensibility . . . . . . . . . . . . . . . . 135
10.1.1. Origination Date . . . . . . . . . . . . . . . . . . 136 9.7.1. Status Code Registry . . . . . . . . . . . . . . . . 135
10.1.2. Location . . . . . . . . . . . . . . . . . . . . . . 139 9.7.2. Considerations for New Status Codes . . . . . . . . . 135
10.1.3. Retry-After . . . . . . . . . . . . . . . . . . . . 140 10. Response Header Fields . . . . . . . . . . . . . . . . . . . 136
10.1.4. Vary . . . . . . . . . . . . . . . . . . . . . . . . 141 10.1. Control Data . . . . . . . . . . . . . . . . . . . . . . 136
10.2. Validators . . . . . . . . . . . . . . . . . . . . . . . 142 10.1.1. Origination Date . . . . . . . . . . . . . . . . . . 137
10.2.1. Weak versus Strong . . . . . . . . . . . . . . . . . 143 10.1.2. Location . . . . . . . . . . . . . . . . . . . . . . 140
10.2.2. Last-Modified . . . . . . . . . . . . . . . . . . . 144 10.1.3. Retry-After . . . . . . . . . . . . . . . . . . . . 141
10.2.3. ETag . . . . . . . . . . . . . . . . . . . . . . . . 146 10.1.4. Vary . . . . . . . . . . . . . . . . . . . . . . . . 142
10.2.4. When to Use Entity-Tags and Last-Modified Dates . . 150 10.2. Validators . . . . . . . . . . . . . . . . . . . . . . . 143
10.3. Authentication Challenges . . . . . . . . . . . . . . . 150 10.2.1. Weak versus Strong . . . . . . . . . . . . . . . . . 144
10.3.1. WWW-Authenticate . . . . . . . . . . . . . . . . . . 151 10.2.2. Last-Modified . . . . . . . . . . . . . . . . . . . 145
10.3.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . 152 10.2.3. ETag . . . . . . . . . . . . . . . . . . . . . . . . 147
10.3.3. Authentication-Info . . . . . . . . . . . . . . . . 152 10.2.4. When to Use Entity-Tags and Last-Modified Dates . . 151
10.3.4. Proxy-Authentication-Info . . . . . . . . . . . . . 153 10.3. Authentication Challenges . . . . . . . . . . . . . . . 151
10.4. Response Context . . . . . . . . . . . . . . . . . . . . 154 10.3.1. WWW-Authenticate . . . . . . . . . . . . . . . . . . 152
10.4.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . 154 10.3.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . 153
10.4.2. Allow . . . . . . . . . . . . . . . . . . . . . . . 154 10.3.3. Authentication-Info . . . . . . . . . . . . . . . . 153
10.4.3. Server . . . . . . . . . . . . . . . . . . . . . . . 155 10.3.4. Proxy-Authentication-Info . . . . . . . . . . . . . 154
11. Generic Syntax . . . . . . . . . . . . . . . . . . . . . . . 156 10.4. Response Context . . . . . . . . . . . . . . . . . . . . 155
11.1. Whitespace . . . . . . . . . . . . . . . . . . . . . . . 156 10.4.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . 155
12. ABNF List Extension: #rule . . . . . . . . . . . . . . . . . 156 10.4.2. Allow . . . . . . . . . . . . . . . . . . . . . . . 155
12.1. Sender Requirements . . . . . . . . . . . . . . . . . . 156 10.4.3. Server . . . . . . . . . . . . . . . . . . . . . . . 156
12.2. Recipient Requirements . . . . . . . . . . . . . . . . . 157 11. Generic Syntax . . . . . . . . . . . . . . . . . . . . . . . 157
13. Security Considerations . . . . . . . . . . . . . . . . . . . 158 11.1. Whitespace . . . . . . . . . . . . . . . . . . . . . . . 157
13.1. Establishing Authority . . . . . . . . . . . . . . . . . 158 12. ABNF List Extension: #rule . . . . . . . . . . . . . . . . . 157
13.2. Risks of Intermediaries . . . . . . . . . . . . . . . . 159 12.1. Sender Requirements . . . . . . . . . . . . . . . . . . 157
13.3. Attacks Based on File and Path Names . . . . . . . . . . 160 12.2. Recipient Requirements . . . . . . . . . . . . . . . . . 158
13.4. Attacks Based on Command, Code, or Query Injection . . . 160 13. Security Considerations . . . . . . . . . . . . . . . . . . . 159
13.5. Attacks via Protocol Element Length . . . . . . . . . . 161 13.1. Establishing Authority . . . . . . . . . . . . . . . . . 159
13.6. Disclosure of Personal Information . . . . . . . . . . . 161 13.2. Risks of Intermediaries . . . . . . . . . . . . . . . . 160
13.7. Privacy of Server Log Information . . . . . . . . . . . 161 13.3. Attacks Based on File and Path Names . . . . . . . . . . 161
13.8. Disclosure of Sensitive Information in URIs . . . . . . 162 13.4. Attacks Based on Command, Code, or Query Injection . . . 161
13.9. Disclosure of Fragment after Redirects . . . . . . . . . 162 13.5. Attacks via Protocol Element Length . . . . . . . . . . 162
13.10. Disclosure of Product Information . . . . . . . . . . . 163 13.6. Disclosure of Personal Information . . . . . . . . . . . 162
13.11. Browser Fingerprinting . . . . . . . . . . . . . . . . . 163 13.7. Privacy of Server Log Information . . . . . . . . . . . 162
13.12. Validator Retention . . . . . . . . . . . . . . . . . . 164 13.8. Disclosure of Sensitive Information in URIs . . . . . . 163
13.13. Denial-of-Service Attacks Using Range . . . . . . . . . 165 13.9. Disclosure of Fragment after Redirects . . . . . . . . . 163
13.14. Authentication Considerations . . . . . . . . . . . . . 165 13.10. Disclosure of Product Information . . . . . . . . . . . 164
13.14.1. Confidentiality of Credentials . . . . . . . . . . 165 13.11. Browser Fingerprinting . . . . . . . . . . . . . . . . . 164
13.14.2. Credentials and Idle Clients . . . . . . . . . . . 166 13.12. Validator Retention . . . . . . . . . . . . . . . . . . 165
13.14.3. Protection Spaces . . . . . . . . . . . . . . . . . 166 13.13. Denial-of-Service Attacks Using Range . . . . . . . . . 166
13.14.4. Additional Response Header Fields . . . . . . . . . 167 13.14. Authentication Considerations . . . . . . . . . . . . . 166
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 167 13.14.1. Confidentiality of Credentials . . . . . . . . . . 166
14.1. URI Scheme Registration . . . . . . . . . . . . . . . . 167 13.14.2. Credentials and Idle Clients . . . . . . . . . . . 167
14.2. Method Registration . . . . . . . . . . . . . . . . . . 167 13.14.3. Protection Spaces . . . . . . . . . . . . . . . . . 167
14.3. Status Code Registration . . . . . . . . . . . . . . . . 167 13.14.4. Additional Response Header Fields . . . . . . . . . 168
14.4. Header Field Registration . . . . . . . . . . . . . . . 168 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 168
14.5. Authentication Scheme Registration . . . . . . . . . . . 168 14.1. URI Scheme Registration . . . . . . . . . . . . . . . . 168
14.6. Content Coding Registration . . . . . . . . . . . . . . 168 14.2. Method Registration . . . . . . . . . . . . . . . . . . 168
14.7. Range Unit Registration . . . . . . . . . . . . . . . . 169 14.3. Status Code Registration . . . . . . . . . . . . . . . . 168
14.8. Media Type Registration . . . . . . . . . . . . . . . . 169 14.4. Header Field Registration . . . . . . . . . . . . . . . 169
14.9. Port Registration . . . . . . . . . . . . . . . . . . . 169 14.5. Authentication Scheme Registration . . . . . . . . . . . 169
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 169 14.6. Content Coding Registration . . . . . . . . . . . . . . 169
15.1. Normative References . . . . . . . . . . . . . . . . . . 169 14.7. Range Unit Registration . . . . . . . . . . . . . . . . 170
15.2. Informative References . . . . . . . . . . . . . . . . . 171 14.8. Media Type Registration . . . . . . . . . . . . . . . . 170
Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 177 14.9. Port Registration . . . . . . . . . . . . . . . . . . . 170
Appendix B. Changes from RFC 7230 . . . . . . . . . . . . . . . 181 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 170
Appendix C. Changes from RFC 2818 . . . . . . . . . . . . . . . 182 15.1. Normative References . . . . . . . . . . . . . . . . . . 170
Appendix D. Changes from RFC 7231 . . . . . . . . . . . . . . . 182 15.2. Informative References . . . . . . . . . . . . . . . . . 172
Appendix E. Changes from RFC 7232 . . . . . . . . . . . . . . . 182 Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 178
Appendix F. Changes from RFC 7233 . . . . . . . . . . . . . . . 182 Appendix B. Changes from RFC 7230 . . . . . . . . . . . . . . . 182
Appendix G. Changes from RFC 7235 . . . . . . . . . . . . . . . 182 Appendix C. Changes from RFC 2818 . . . . . . . . . . . . . . . 183
Appendix H. Changes from RFC 7538 . . . . . . . . . . . . . . . 183 Appendix D. Changes from RFC 7231 . . . . . . . . . . . . . . . 183
Appendix I. Changes from RFC 7615 . . . . . . . . . . . . . . . 183 Appendix E. Changes from RFC 7232 . . . . . . . . . . . . . . . 183
Appendix J. Change Log . . . . . . . . . . . . . . . . . . . . . 183 Appendix F. Changes from RFC 7233 . . . . . . . . . . . . . . . 183
J.1. Between RFC723x and draft 00 . . . . . . . . . . . . . . 183 Appendix G. Changes from RFC 7235 . . . . . . . . . . . . . . . 183
J.2. Since draft-ietf-httpbis-semantics-00 . . . . . . . . . . 183 Appendix H. Changes from RFC 7538 . . . . . . . . . . . . . . . 184
J.3. Since draft-ietf-httpbis-semantics-01 . . . . . . . . . . 184 Appendix I. Changes from RFC 7615 . . . . . . . . . . . . . . . 184
J.4. Since draft-ietf-httpbis-semantics-02 . . . . . . . . . . 185 Appendix J. Change Log . . . . . . . . . . . . . . . . . . . . . 184
J.5. Since draft-ietf-httpbis-semantics-03 . . . . . . . . . . 186 J.1. Between RFC723x and draft 00 . . . . . . . . . . . . . . 184
J.6. Since draft-ietf-httpbis-semantics-04 . . . . . . . . . . 187 J.2. Since draft-ietf-httpbis-semantics-00 . . . . . . . . . . 184
J.7. Since draft-ietf-httpbis-semantics-05 . . . . . . . . . . 187 J.3. Since draft-ietf-httpbis-semantics-01 . . . . . . . . . . 185
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 J.4. Since draft-ietf-httpbis-semantics-02 . . . . . . . . . . 186
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 196 J.5. Since draft-ietf-httpbis-semantics-03 . . . . . . . . . . 187
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 197 J.6. Since draft-ietf-httpbis-semantics-04 . . . . . . . . . . 188
J.7. Since draft-ietf-httpbis-semantics-05 . . . . . . . . . . 188
J.8. Since draft-ietf-httpbis-semantics-06 . . . . . . . . . . 190
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 197
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 198
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 13, line 20 skipping to change at page 13, line 26
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.6.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 6
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.4).
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 17, line 46 skipping to change at page 18, line 5
Although HTTP is independent of the transport protocol, the "http" Although HTTP is independent of the transport protocol, the "http"
scheme is specific to TCP-based services because the name delegation scheme is specific to TCP-based services because the name delegation
process depends on TCP for establishing authority. An HTTP service process depends on TCP for establishing authority. An HTTP service
based on some other underlying connection protocol would presumably based on some other underlying connection protocol would presumably
be identified using a different URI scheme, just as the "https" be identified using a different URI scheme, just as the "https"
scheme (below) is used for resources that require an end-to-end scheme (below) is used for resources that require an end-to-end
secured connection. Other protocols might also be used to provide secured connection. Other protocols might also be used to provide
access to "http" identified resources -- it is only the authoritative access to "http" identified resources -- it is only the authoritative
interface that is specific to TCP. 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 the purpose of minting
identifiers according to their association with the hierarchical identifiers according to their association with the hierarchical
namespace governed by a potential HTTP origin server listening to a namespace governed by a potential HTTP origin server listening to a
given TCP port for TLS-secured connections ([RFC8446]). given TCP port for TLS-secured connections ([RFC8446]).
All of the requirements listed above for the "http" scheme are also All of the requirements listed above for the "http" scheme are also
requirements for the "https" scheme, except that TCP port 443 is the 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 default if the port subcomponent is empty or not given, and the user
skipping to change at page 18, line 38 skipping to change at page 18, line 32
establishing authority. Resources made available via the "https" establishing authority. Resources made available via the "https"
scheme have no shared identity with the "http" scheme even if their scheme have no shared identity with the "http" scheme even if their
resource identifiers indicate the same authority (the same host resource identifiers indicate the same authority (the same host
listening to the same TCP port). They are distinct namespaces and listening to the same TCP port). They are distinct namespaces and
are considered to be distinct origin servers. However, an extension are considered to be distinct origin servers. However, an extension
to HTTP that is defined to apply to entire host domains, such as the to HTTP that is defined to apply to entire host domains, such as the
Cookie protocol [RFC6265], can allow information set by one service Cookie protocol [RFC6265], can allow information set by one service
to impact communication with other services within a matching group to impact communication with other services within a matching group
of host domains. of host domains.
2.5.2.1. Initiating HTTP Over TLS 2.5.3. http and https URI Normalization and Comparison
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.
2.5.2.2. 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.
2.5.2.3. 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.
2.5.3. Fragment Identifiers on http(s) URI References
Fragment identifiers allow for indirect identification of a secondary
resource, independent of the URI scheme, as defined in Section 3.5 of
[RFC3986]. Some protocol elements that refer to a URI allow
inclusion of a fragment, while others do not. They are distinguished
by use of the ABNF rule for elements where fragment is allowed;
otherwise, a specific rule that excludes fragments is used (see
Section 5.1).
Note: the fragment identifier component is not part of the actual
scheme definition for a URI scheme (see Section 4.3 of [RFC3986]),
thus does not appear in the ABNF definitions for the "http" and
"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 Since the "http" and "https" schemes conform to the URI generic
syntax, such URIs are normalized and compared according to the syntax, such URIs are normalized and compared according to the
algorithm defined in Section 6 of [RFC3986], using the defaults algorithm defined in Section 6 of [RFC3986], using the defaults
described above for each scheme. described above for each scheme.
If the port is equal to the default port for a scheme, the normal 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 form is to omit the port subcomponent. When not being used in
absolute form as the request target of an OPTIONS request, an empty absolute form as the request target of an OPTIONS request, an empty
path component is equivalent to an absolute path of "/", so the path component is equivalent to an absolute path of "/", so the
skipping to change at page 21, line 9 skipping to change at page 19, line 9
than those in the "reserved" set are equivalent to their percent- than those in the "reserved" set are equivalent to their percent-
encoded octets: the normal form is to not encode them (see Sections encoded octets: the normal form is to not encode them (see Sections
2.1 and 2.2 of [RFC3986]). 2.1 and 2.2 of [RFC3986]).
For example, the following three URIs are equivalent: For example, the following three URIs are equivalent:
http://example.com:80/~smith/home.html http://example.com:80/~smith/home.html
http://EXAMPLE.com/%7Esmith/home.html http://EXAMPLE.com/%7Esmith/home.html
http://EXAMPLE.com:/%7esmith/home.html http://EXAMPLE.com:/%7esmith/home.html
2.5.4. Deprecated userinfo
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.5. Fragment Identifiers on http(s) URI References
Fragment identifiers allow for indirect identification of a secondary
resource, independent of the URI scheme, as defined in Section 3.5 of
[RFC3986]. Some protocol elements that refer to a URI allow
inclusion of a fragment, while others do not. They are distinguished
by use of the ABNF rule for elements where fragment is allowed;
otherwise, a specific rule that excludes fragments is used (see
Section 5.1).
Note: the fragment identifier component is not part of the actual
scheme definition for a URI scheme (see Section 4.3 of [RFC3986]),
thus does not appear in the ABNF definitions for the "http" and
"https" URI schemes above.
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 26, line 26 skipping to change at page 25, line 26
| Content-Encoding | standard | Section 6.2.2 | | Content-Encoding | standard | Section 6.2.2 |
| Content-Language | standard | Section 6.2.3 | | Content-Language | standard | Section 6.2.3 |
| Content-Length | standard | Section 6.2.4 | | Content-Length | standard | Section 6.2.4 |
| Content-Location | standard | Section 6.2.5 | | Content-Location | standard | Section 6.2.5 |
| Content-Range | standard | Section 6.3.4 | | Content-Range | standard | Section 6.3.4 |
| Content-Type | standard | Section 6.2.1 | | Content-Type | standard | Section 6.2.1 |
| Date | standard | Section 10.1.1.2 | | Date | standard | Section 10.1.1.2 |
| ETag | standard | Section 10.2.3 | | ETag | standard | Section 10.2.3 |
| Expect | standard | Section 8.1.1 | | Expect | standard | Section 8.1.1 |
| From | standard | Section 8.6.1 | | From | standard | Section 8.6.1 |
| Host | standard | Section 5.4 | | Host | standard | Section 5.5 |
| If-Match | standard | Section 8.2.3 | | If-Match | standard | Section 8.2.3 |
| If-Modified-Since | standard | Section 8.2.5 | | If-Modified-Since | standard | Section 8.2.5 |
| If-None-Match | standard | Section 8.2.4 | | If-None-Match | standard | Section 8.2.4 |
| If-Range | standard | Section 8.2.7 | | If-Range | standard | Section 8.2.7 |
| If-Unmodified-Since | standard | Section 8.2.6 | | If-Unmodified-Since | standard | Section 8.2.6 |
| Last-Modified | standard | Section 10.2.2 | | Last-Modified | standard | Section 10.2.2 |
| Location | standard | Section 10.1.2 | | Location | standard | Section 10.1.2 |
| Max-Forwards | standard | Section 8.1.2 | | Max-Forwards | standard | Section 8.1.2 |
| Proxy-Authenticate | standard | Section 10.3.2 | | Proxy-Authenticate | standard | Section 10.3.2 |
| Proxy-Authentication-Info | standard | Section 10.3.4 | | Proxy-Authentication-Info | standard | Section 10.3.4 |
| Proxy-Authorization | standard | Section 8.5.4 | | Proxy-Authorization | standard | Section 8.5.4 |
| Range | standard | Section 8.3 | | Range | standard | Section 8.3 |
| Referer | standard | Section 8.6.2 | | Referer | standard | Section 8.6.2 |
| Retry-After | standard | Section 10.1.3 | | Retry-After | standard | Section 10.1.3 |
| Server | standard | Section 10.4.3 | | Server | standard | Section 10.4.3 |
| Trailer | standard | Section 4.3.3 | | Trailer | standard | Section 4.3.3 |
| User-Agent | standard | Section 8.6.3 | | User-Agent | standard | Section 8.6.3 |
| Vary | standard | Section 10.1.4 | | Vary | standard | Section 10.1.4 |
| Via | standard | Section 5.5.1 | | Via | standard | Section 5.6.1 |
| WWW-Authenticate | standard | Section 10.3.1 | | WWW-Authenticate | standard | Section 10.3.1 |
+---------------------------+------------+-------------------+ +---------------------------+------------+-------------------+
Table 1 Table 1
4.1.1. Header Field Name Registry 4.1.1. Header Field Name Registry
The "Hypertext Transfer Protocol (HTTP) Header Field Registry" The "Hypertext Transfer Protocol (HTTP) Header Field Registry"
defines the namespace for HTTP header field names. defines the namespace for HTTP header field names.
skipping to change at page 36, line 40 skipping to change at page 35, line 40
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 authority 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.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.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.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.4. 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 37, line 29
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 13 for security
considerations regarding message routing. considerations regarding message routing.
5.4. Host 5.5. 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
skipping to change at page 38, line 26 skipping to change at page 39, line 5
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.6. 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 39, line 33
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.6.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 ] )
skipping to change at page 40, line 38 skipping to change at page 41, line 20
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 entries 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 entries that have
different received-protocol values. different received-protocol values.
5.5.2. Transformations 5.6.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 51, line 4 skipping to change at page 51, 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
skipping to change at page 55, line 41 skipping to change at page 56, line 41
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.4). 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
skipping to change at page 58, line 34 skipping to change at page 59, line 34
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.4).
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-value is a reference to the same URI as the effective field-value is a reference to the same URI as the effective
request URI, the payload is a representation of the resource request URI, the payload is a representation of the resource
identified by the effective request URI. identified by the effective request URI.
skipping to change at page 79, line 26 skipping to change at page 80, line 26
A client MUST NOT generate header fields in a TRACE request A client MUST NOT generate header fields in a TRACE request
containing sensitive data that might be disclosed by the response. containing sensitive data that might be disclosed by the response.
For example, it would be foolish for a user agent to send stored user For example, it would be foolish for a user agent to send stored user
credentials Section 8.5 or cookies [RFC6265] in a TRACE request. The credentials Section 8.5 or cookies [RFC6265] in a TRACE request. The
final recipient of the request SHOULD exclude any request header final recipient of the request SHOULD exclude any request header
fields that are likely to contain sensitive data when that recipient fields that are likely to contain sensitive data when that recipient
generates the response body. generates the 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.6.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 18 skipping to change at page 82, line 18
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... | | Header 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.5 |
| 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
skipping to change at page 104, line 41 skipping to change at page 105, 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.4) 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 116, line 16 skipping to change at page 117, line 16
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.6.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 152, line 11 skipping to change at page 153, 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.4).
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 158, line 48 skipping to change at page 159, 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.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 163, line 13 skipping to change at page 164, line 13
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 13.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.6.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
skipping to change at page 169, line 37 skipping to change at page 170, line 37
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 15. References
15.1. Normative References 15.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-latest (work Ed., "HTTP Caching", draft-ietf-httpbis-cache-latest (work
in progress), November 2019. in progress), January 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- Ed., "HTTP/1.1 Messaging", draft-ietf-httpbis-messaging-
latest (work in progress), November 2019. latest (work in progress), January 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 182, line 17 skipping to change at page 183, line 17
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 Appendix C. Changes from RFC 2818
None yet. None yet.
Appendix D. Changes from RFC 7231 Appendix D. Changes from RFC 7231
Restrictions on client retries have been loosened, to reflect
implementation behavior. (Section 7.2.2)
Removed a superfluous requirement about setting Content-Length from
the description of the OPTIONS method. (Section 7.3.7)
Minimum URI lengths to be supported by implementations are now Minimum URI lengths to be supported by implementations are now
recommended. (Section 2.5) recommended. (Section 2.5)
Restrictions on client retries have been loosened, to reflect
implementation behavior. (Section 7.2.2)
Clarified that request bodies on GET are not interoperable. Clarified that request bodies on GET are not interoperable.
(Section 7.3.1) (Section 7.3.1)
Removed a superfluous requirement about setting Content-Length from
the description of the OPTIONS method. (Section 7.3.7)
Appendix E. Changes from RFC 7232 Appendix E. Changes from RFC 7232
None yet. None yet.
Appendix F. Changes from RFC 7233 Appendix F. 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
skipping to change at page 188, line 12 skipping to change at page 189, line 12
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 14.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.4, 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 13.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" (Section 11) (<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.4 (<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 13.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>)
J.8. Since draft-ietf-httpbis-semantics-06
None yet.
Index Index
1 1
100 Continue (status code) 114 100 Continue (status code) 115
100-continue (expect value) 81 100-continue (expect value) 82
101 Switching Protocols (status code) 114 101 Switching Protocols (status code) 115
1xx Informational (status code class) 113 1xx Informational (status code class) 114
2 2
200 OK (status code) 114 200 OK (status code) 115
201 Created (status code) 115 201 Created (status code) 116
202 Accepted (status code) 115 202 Accepted (status code) 116
203 Non-Authoritative Information (status code) 116 203 Non-Authoritative Information (status code) 117
204 No Content (status code) 116 204 No Content (status code) 117
205 Reset Content (status code) 117 205 Reset Content (status code) 118
206 Partial Content (status code) 117 206 Partial Content (status code) 118
2xx Successful (status code class) 114 2xx Successful (status code class) 115
3 3
300 Multiple Choices (status code) 122 300 Multiple Choices (status code) 123
301 Moved Permanently (status code) 123 301 Moved Permanently (status code) 124
302 Found (status code) 123 302 Found (status code) 124
303 See Other (status code) 124 303 See Other (status code) 125
304 Not Modified (status code) 124 304 Not Modified (status code) 125
305 Use Proxy (status code) 125 305 Use Proxy (status code) 126
306 (Unused) (status code) 125 306 (Unused) (status code) 126
307 Temporary Redirect (status code) 125 307 Temporary Redirect (status code) 126
308 Permanent Redirect (status code) 126 308 Permanent Redirect (status code) 127
3xx Redirection (status code class) 120 3xx Redirection (status code class) 121
4 4
400 Bad Request (status code) 126 400 Bad Request (status code) 127
401 Unauthorized (status code) 126 401 Unauthorized (status code) 127
402 Payment Required (status code) 127 402 Payment Required (status code) 128
403 Forbidden (status code) 127 403 Forbidden (status code) 128
404 Not Found (status code) 127 404 Not Found (status code) 128
405 Method Not Allowed (status code) 128 405 Method Not Allowed (status code) 129
406 Not Acceptable (status code) 128 406 Not Acceptable (status code) 129
407 Proxy Authentication Required (status code) 128 407 Proxy Authentication Required (status code) 129
408 Request Timeout (status code) 128 408 Request Timeout (status code) 129
409 Conflict (status code) 129 409 Conflict (status code) 130
410 Gone (status code) 129 410 Gone (status code) 130
411 Length Required (status code) 129 411 Length Required (status code) 130
412 Precondition Failed (status code) 130 412 Precondition Failed (status code) 131
413 Payload Too Large (status code) 130 413 Payload Too Large (status code) 131
414 URI Too Long (status code) 130 414 URI Too Long (status code) 131
415 Unsupported Media Type (status code) 130 415 Unsupported Media Type (status code) 131
416 Range Not Satisfiable (status code) 131 416 Range Not Satisfiable (status code) 132
417 Expectation Failed (status code) 131 417 Expectation Failed (status code) 132
418 (Unused) (status code) 131 418 (Unused) (status code) 132
422 Unprocessable Payload (status code) 132 422 Unprocessable Payload (status code) 133
426 Upgrade Required (status code) 132 426 Upgrade Required (status code) 133
4xx Client Error (status code class) 126 4xx Client Error (status code class) 127
5 5
500 Internal Server Error (status code) 133 500 Internal Server Error (status code) 134
501 Not Implemented (status code) 133 501 Not Implemented (status code) 134
502 Bad Gateway (status code) 133 502 Bad Gateway (status code) 134
503 Service Unavailable (status code) 133 503 Service Unavailable (status code) 134
504 Gateway Timeout (status code) 133 504 Gateway Timeout (status code) 134
505 HTTP Version Not Supported (status code) 133 505 HTTP Version Not Supported (status code) 134
5xx Server Error (status code class) 132 5xx Server Error (status code class) 133
A A
Accept header field 97 Accept header field 98
Accept-Charset header field 99 Accept-Charset header field 100
Accept-Encoding header field 100 Accept-Encoding header field 101
Accept-Language header field 101 Accept-Language header field 102
Accept-Ranges header field 154 Accept-Ranges header field 155
Allow header field 154 Allow header field 155
Authentication-Info header field 152 Authentication-Info header field 153
Authorization header field 105 Authorization header field 106
accelerator 13 accelerator 13
authoritative response 158 authoritative response 159
B B
browser 10 browser 10
C C
CONNECT method 76 CONNECT method 77
Canonical Root URI 104 Canonical Root URI 105
Content-Encoding header field 52 Content-Encoding header field 53
Content-Language header field 53 Content-Language header field 54
Content-Length header field 54 Content-Length header field 55
Content-Location header field 55 Content-Location header field 56
Content-MD5 header field 168 Content-MD5 header field 169
Content-Range header field 59 Content-Range header field 60
Content-Type header field 51 Content-Type header field 52
cache 14 cache 14
cacheable 14 cacheable 15
captive portal 14 captive portal 14
client 10 client 10
compress (Coding Format) 45 compress (Coding Format) 46
compress (content coding) 44 compress (content coding) 45
conditional request 84 conditional request 85
connection 10 connection 10
content coding 44 content coding 45
content negotiation 9 content negotiation 9
D D
DELETE method 75 DELETE method 76
Date header field 138 Date header field 139
Delimiters 30 Delimiters 29
deflate (Coding Format) 45 deflate (Coding Format) 46
deflate (content coding) 44 deflate (content coding) 45
downstream 12 downstream 13
E E
ETag header field 146 ETag header field 147
Expect header field 81 Expect header field 82
effective request URI 36 effective request URI 37
F F
Fragment Identifiers 20 Fragment Identifiers 19
From header field 108 From header field 109
G G
GET method 70 GET method 71
Grammar Grammar
absolute-path 15 absolute-path 15
absolute-URI 15 absolute-URI 15
Accept 97 Accept 98
Accept-Charset 99 Accept-Charset 100
Accept-Encoding 100 Accept-Encoding 101
accept-ext 97 accept-ext 98
Accept-Language 101 Accept-Language 102
accept-params 97 accept-params 98
Accept-Ranges 154 Accept-Ranges 155
acceptable-ranges 154 acceptable-ranges 155
Allow 154 Allow 155
ALPHA 9 ALPHA 9
asctime-date 137 asctime-date 138
auth-param 103 auth-param 104
auth-scheme 103 auth-scheme 104
Authentication-Info 152 Authentication-Info 153
authority 15 authority 15
Authorization 105 Authorization 106
BWS 156 BWS 157
challenge 103 challenge 104
charset 43 charset 44
codings 100 codings 101
comment 31 comment 30
complete-length 60 complete-length 61
content-coding 44 content-coding 45
Content-Encoding 52 Content-Encoding 53
Content-Language 53 Content-Language 54
Content-Length 54 Content-Length 55
Content-Location 55 Content-Location 56
Content-Range 60 Content-Range 61
Content-Type 51 Content-Type 52
CR 9 CR 9
credentials 104 credentials 105
CRLF 9 CRLF 9
ctext 31 ctext 30
CTL 9 CTL 9
Date 138 Date 139
date1 137 date1 138
day 137 day 138
day-name 137 day-name 138
day-name-l 137 day-name-l 138
delay-seconds 140 delay-seconds 141
DIGIT 9 DIGIT 9
DQUOTE 9 DQUOTE 9
entity-tag 147 entity-tag 148
ETag 147 ETag 148
etagc 147 etagc 148
Expect 81 Expect 82
field-content 28 field-content 27
field-name 25, 33 field-name 23, 32
field-value 28 field-value 27
field-vchar 28 field-vchar 27
first-pos 48, 60 first-pos 49, 61
From 108 From 109
GMT 137 GMT 138
HEXDIG 9 HEXDIG 9
Host 37 Host 38
hour 137 hour 138
HTAB 9 HTAB 9
HTTP-date 136 HTTP-date 137
http-URI 16 http-URI 16
https-URI 18 https-URI 18
If-Match 88 If-Match 89
If-Modified-Since 90 If-Modified-Since 91
If-None-Match 89 If-None-Match 90
If-Range 93 If-Range 94
If-Unmodified-Since 91 If-Unmodified-Since 92
IMF-fixdate 137 IMF-fixdate 138
incl-range 60 incl-range 61
int-range 48 int-range 49
language-range 101 language-range 102
language-tag 46 language-tag 47
Last-Modified 144 Last-Modified 145
last-pos 48, 60 last-pos 49, 61
LF 9 LF 9
Location 139 Location 140
Max-Forwards 83 Max-Forwards 84
media-range 97 media-range 98
media-type 42 media-type 43
method 66 method 67
minute 137 minute 138
month 137 month 138
obs-date 137 obs-date 138
obs-text 30 obs-text 29
OCTET 9 OCTET 9
opaque-tag 147 opaque-tag 148
other-range 48 other-range 49
OWS 156 OWS 157
parameter 31 parameter 30
parameter-name 31 parameter-name 30
parameter-value 31 parameter-value 30
partial-URI 15 partial-URI 15
port 15 port 15
product 110 product 111
product-version 110 product-version 111
protocol-name 39 protocol-name 39
protocol-version 39 protocol-version 39
Proxy-Authenticate 152 Proxy-Authenticate 153
Proxy-Authentication-Info 153 Proxy-Authentication-Info 154
Proxy-Authorization 105 Proxy-Authorization 106
pseudonym 39 pseudonym 39
qdtext 30 qdtext 29
query 15 query 15
quoted-pair 31 quoted-pair 30
quoted-string 30 quoted-string 29
qvalue 97 qvalue 98
Range 94 Range 95
range-resp 60 range-resp 61
range-set 48 range-set 49
range-spec 48 range-spec 49
range-unit 47 range-unit 48
ranges-specifier 48 ranges-specifier 49
received-by 39 received-by 39
received-protocol 39 received-protocol 39
Referer 109 Referer 110
Retry-After 140 Retry-After 141
rfc850-date 137 rfc850-date 138
RWS 156 RWS 157
second 137 second 138
segment 15 segment 15
Server 155 Server 156
SP 9 SP 9
subtype 42 subtype 43
suffix-length 48 suffix-length 49
suffix-range 48 suffix-range 49
tchar 30 tchar 29
time-of-day 137 time-of-day 138
token 30 token 29
token68 103 token68 104
Trailer 33 Trailer 32
type 42 type 43
unsatisfied-range 60 unsatisfied-range 61
uri-host 15 uri-host 15
URI-reference 15 URI-reference 15
User-Agent 110 User-Agent 111
Vary 141 Vary 142
VCHAR 9 VCHAR 9
Via 39 Via 39
weak 147 weak 148
weight 97 weight 98
WWW-Authenticate 151 WWW-Authenticate 152
year 137 year 138
gateway 13 gateway 13
gzip (Coding Format) 45 gzip (Coding Format) 46
gzip (content coding) 44 gzip (content coding) 45
H H
HEAD method 71 HEAD method 72
Host header field 37 Host header field 37
http URI scheme 16 http URI scheme 16
https URI scheme 18 https URI scheme 18
I I
If-Match header field 88 If-Match header field 89
If-Modified-Since header field 90 If-Modified-Since header field 91
If-None-Match header field 89 If-None-Match header field 90
If-Range header field 93 If-Range header field 94
If-Unmodified-Since header field 91 If-Unmodified-Since header field 92
idempotent 69 idempotent 70
inbound 12 inbound 13
interception proxy 14 interception proxy 14
intermediary 12 intermediary 12
L L
Last-Modified header field 144 Last-Modified header field 145
Location header field 139 Location header field 140
M M
Max-Forwards header field 83 Max-Forwards header field 84
Media Type Media Type
multipart/byteranges 61 multipart/byteranges 62
multipart/x-byteranges 62 multipart/x-byteranges 63
message 11 message 11
metadata 142 metadata 143
multipart/byteranges Media Type 61 multipart/byteranges Media Type 62
multipart/x-byteranges Media Type 62 multipart/x-byteranges Media Type 63
N N
non-transforming proxy 40 non-transforming proxy 41
O O
OPTIONS method 78 OPTIONS method 79
origin server 10 origin server 10
outbound 12 outbound 13
P P
POST method 72 POST method 73
PUT method 73 PUT method 74
Protection Space 104 Protection Space 105
Proxy-Authenticate header field 152 Proxy-Authenticate header field 153
Proxy-Authentication-Info header field 153 Proxy-Authentication-Info header field 154
Proxy-Authorization header field 105 Proxy-Authorization header field 106
payload 57 payload 58
phishing 158 phishing 159
proxy 13 proxy 13
R R
Range header field 94 Range header field 95
Realm 104 Realm 105
Referer header field 109 Referer header field 110
Retry-After header field 140 Retry-After header field 141
recipient 10 recipient 10
representation 41 representation 42
request 11 request 11
resource 15 resource 15
response 11 response 11
reverse proxy 13 reverse proxy 13
S S
Server header field 155 Server header field 156
Status Codes Classes Status Codes Classes
1xx Informational 113 1xx Informational 114
2xx Successful 114 2xx Successful 115
3xx Redirection 120 3xx Redirection 121
4xx Client Error 126 4xx Client Error 127
5xx Server Error 132 5xx Server Error 133
safe 68 safe 69
selected representation 41, 84, 142 selected representation 42, 85, 143
sender 10 sender 10
server 10 server 10
spider 10 spider 10
T T
TRACE method 79 TRACE method 80
Trailer header field 33 Trailer header field 32
target URI 35 target URI 34
target resource 35 target resource 34
trailer fields 32 trailer fields 31
trailers 32 trailers 31
transforming proxy 40 transforming proxy 41
transparent proxy 14 transparent proxy 14
tunnel 13 tunnel 13
U U
URI scheme URI scheme
http 16 http 16
https 18 https 18
User-Agent header field 110 User-Agent header field 111
upstream 12 upstream 13
user agent 10 user agent 10
V V
Vary header field 141 Vary header field 142
Via header field 39 Via header field 39
validator 142 validator 143
strong 143 strong 144
weak 143 weak 144
W W
WWW-Authenticate header field 151 WWW-Authenticate header field 152
X X
x-compress (content coding) 44 x-compress (content coding) 45
x-gzip (content coding) 44 x-gzip (content coding) 45
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. 96 change blocks. 
626 lines changed or deleted 638 lines changed or added

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