draft-ietf-httpbis-semantics-05.txt   draft-ietf-httpbis-semantics-06.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.
7230,7231,7232,7233,7235,7538 Fastly 2818,7230,7231,7232,7233,7235 Fastly
,7615 (if approved) J. Reschke, Ed. ,7538,7615 (if approved) J. Reschke, Ed.
Intended status: Standards Track greenbytes Intended status: Standards Track greenbytes
Expires: January 9, 2020 July 8, 2019 Expires: May 7, 2020 November 4, 2019
HTTP Semantics HTTP Semantics
draft-ietf-httpbis-semantics-05 draft-ietf-httpbis-semantics-06
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.
This document obsoletes RFC 7231, RFC 7232, RFC 7233, RFC 7235, RFC This document obsoletes RFC 2818, RFC 7231, RFC 7232, RFC 7233, RFC
7538, RFC 7615, and portions of RFC 7230. 7235, RFC 7538, RFC 7615, and portions of RFC 7230.
Editorial Note Editorial Note
This note is to be removed before publishing as an RFC. This note is to be removed before publishing as an RFC.
Discussion of this draft takes place on the HTTP working group Discussion of this draft takes place on the HTTP working group
mailing list (ietf-http-wg@w3.org), which is archived at mailing list (ietf-http-wg@w3.org), which is archived at
<https://lists.w3.org/Archives/Public/ietf-http-wg/>. <https://lists.w3.org/Archives/Public/ietf-http-wg/>.
Working Group information can be found at <https://httpwg.org/>; Working Group information can be found at <https://httpwg.org/>;
source code and issues list for this draft can be found at source code and issues list for this draft can be found at
<https://github.com/httpwg/http-core>. <https://github.com/httpwg/http-core>.
The changes in this draft are summarized in Appendix I.6. The changes in this draft are summarized in Appendix J.7.
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 January 9, 2020. This Internet-Draft will expire on May 7, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
skipping to change at page 2, line 49 skipping to change at page 2, line 49
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . . . . . . . . . . 15 2.5. Resources . . . . . . . . . . . . . . . . . . . . . . . . 16
2.5.1. http URI Scheme . . . . . . . . . . . . . . . . . . . 16 2.5.1. http URI Scheme . . . . . . . . . . . . . . . . . . . 16
2.5.2. https URI Scheme . . . . . . . . . . . . . . . . . . 17 2.5.2. https URI Scheme . . . . . . . . . . . . . . . . . . 18
2.5.3. Fragment Identifiers on http(s) URI References . . . 18 2.5.3. Fragment Identifiers on http(s) URI References . . . 20
2.5.4. http and https URI Normalization and Comparison . . . 18 2.5.4. http and https URI Normalization and Comparison . . . 20
3. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 19 3. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1. Implementation Diversity . . . . . . . . . . . . . . . . 19 3.1. Implementation Diversity . . . . . . . . . . . . . . . . 21
3.2. Role-based Requirements . . . . . . . . . . . . . . . . . 20 3.2. Role-based Requirements . . . . . . . . . . . . . . . . . 21
3.3. Parsing Elements . . . . . . . . . . . . . . . . . . . . 20 3.3. Parsing Elements . . . . . . . . . . . . . . . . . . . . 22
3.4. Error Handling . . . . . . . . . . . . . . . . . . . . . 21 3.4. Error Handling . . . . . . . . . . . . . . . . . . . . . 23
3.5. Protocol Versioning . . . . . . . . . . . . . . . . . . . 21 3.5. Protocol Versioning . . . . . . . . . . . . . . . . . . . 23
4. Message Abstraction . . . . . . . . . . . . . . . . . . . . . 23 4. Header Fields . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1. Header Field Names . . . . . . . . . . . . . . . . . . . 23 4.1. Header Field Names . . . . . . . . . . . . . . . . . . . 24
4.1.1. Header Field Name Registry . . . . . . . . . . . . . 25 4.1.1. Header Field Name Registry . . . . . . . . . . . . . 27
4.1.2. Header Field Extensibility . . . . . . . . . . . . . 26 4.1.2. Header Field Extensibility . . . . . . . . . . . . . 28
4.1.3. Considerations for New Header Fields . . . . . . . . 26 4.2. Header Field Values . . . . . . . . . . . . . . . . . . . 28
4.2. Header Field Values . . . . . . . . . . . . . . . . . . . 27 4.2.1. Header Field Order . . . . . . . . . . . . . . . . . 29
4.2.1. Header Field Order . . . . . . . . . . . . . . . . . 28 4.2.2. Header Field Limits . . . . . . . . . . . . . . . . . 30
4.2.2. Header Field Limits . . . . . . . . . . . . . . . . . 29 4.2.3. Header Field Value Components . . . . . . . . . . . . 30
4.2.3. Header Field Value Components . . . . . . . . . . . . 29 4.3. Trailer Fields . . . . . . . . . . . . . . . . . . . . . 32
4.2.4. Designing New Header Field Values . . . . . . . . . . 31 4.3.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 32
4.3. Whitespace . . . . . . . . . . . . . . . . . . . . . . . 32 4.3.2. Limitations . . . . . . . . . . . . . . . . . . . . . 32
4.4. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 32 4.3.3. Trailer . . . . . . . . . . . . . . . . . . . . . . . 33
5. Message Routing . . . . . . . . . . . . . . . . . . . . . . . 33 4.4. Considerations for New Header Fields . . . . . . . . . . 33
5.1. Identifying a Target Resource . . . . . . . . . . . . . . 33 5. Message Routing . . . . . . . . . . . . . . . . . . . . . . . 35
5.2. Routing Inbound . . . . . . . . . . . . . . . . . . . . . 33 5.1. Identifying a Target Resource . . . . . . . . . . . . . . 35
5.3. Effective Request URI . . . . . . . . . . . . . . . . . . 34 5.2. Routing Inbound . . . . . . . . . . . . . . . . . . . . . 36
5.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . 34 5.3. Effective Request URI . . . . . . . . . . . . . . . . . . 36
5.5. Message Forwarding . . . . . . . . . . . . . . . . . . . 35 5.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.5.1. Via . . . . . . . . . . . . . . . . . . . . . . . . . 36 5.5. Message Forwarding . . . . . . . . . . . . . . . . . . . 38
5.5.2. Transformations . . . . . . . . . . . . . . . . . . . 38 5.5.1. Via . . . . . . . . . . . . . . . . . . . . . . . . . 39
6. Representations . . . . . . . . . . . . . . . . . . . . . . . 39 5.5.2. Transformations . . . . . . . . . . . . . . . . . . . 40
6.1. Representation Data . . . . . . . . . . . . . . . . . . . 39 6. Representations . . . . . . . . . . . . . . . . . . . . . . . 41
6.1.1. Media Type . . . . . . . . . . . . . . . . . . . . . 40 6.1. Representation Data . . . . . . . . . . . . . . . . . . . 42
6.1.2. Content Codings . . . . . . . . . . . . . . . . . . . 42 6.1.1. Media Type . . . . . . . . . . . . . . . . . . . . . 42
6.1.3. Language Tags . . . . . . . . . . . . . . . . . . . . 44 6.1.2. Content Codings . . . . . . . . . . . . . . . . . . . 44
6.1.4. Range Units . . . . . . . . . . . . . . . . . . . . . 44 6.1.3. Language Tags . . . . . . . . . . . . . . . . . . . . 46
6.2. Representation Metadata . . . . . . . . . . . . . . . . . 47 6.1.4. Range Units . . . . . . . . . . . . . . . . . . . . . 47
6.2.1. Content-Type . . . . . . . . . . . . . . . . . . . . 48 6.2. Representation Metadata . . . . . . . . . . . . . . . . . 51
6.2.2. Content-Encoding . . . . . . . . . . . . . . . . . . 49 6.2.1. Content-Type . . . . . . . . . . . . . . . . . . . . 51
6.2.3. Content-Language . . . . . . . . . . . . . . . . . . 50 6.2.2. Content-Encoding . . . . . . . . . . . . . . . . . . 52
6.2.4. Content-Length . . . . . . . . . . . . . . . . . . . 50 6.2.3. Content-Language . . . . . . . . . . . . . . . . . . 53
6.2.5. Content-Location . . . . . . . . . . . . . . . . . . 52 6.2.4. Content-Length . . . . . . . . . . . . . . . . . . . 54
6.3. Payload . . . . . . . . . . . . . . . . . . . . . . . . . 54 6.2.5. Content-Location . . . . . . . . . . . . . . . . . . 55
6.3.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 54 6.3. Payload . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.3.2. Identification . . . . . . . . . . . . . . . . . . . 54 6.3.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 57
6.3.3. Content-Range . . . . . . . . . . . . . . . . . . . . 55 6.3.2. Identification . . . . . . . . . . . . . . . . . . . 58
6.3.4. Media Type multipart/byteranges . . . . . . . . . . . 57 6.3.3. Payload Body . . . . . . . . . . . . . . . . . . . . 59
6.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 59 6.3.4. Content-Range . . . . . . . . . . . . . . . . . . . . 59
6.4.1. Proactive Negotiation . . . . . . . . . . . . . . . . 60 6.3.5. Media Type multipart/byteranges . . . . . . . . . . . 61
6.4.2. Reactive Negotiation . . . . . . . . . . . . . . . . 61 6.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 63
7. Request Methods . . . . . . . . . . . . . . . . . . . . . . . 62 6.4.1. Proactive Negotiation . . . . . . . . . . . . . . . . 64
7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 62 6.4.2. Reactive Negotiation . . . . . . . . . . . . . . . . 65
7.2. Common Method Properties . . . . . . . . . . . . . . . . 64 7. Request Methods . . . . . . . . . . . . . . . . . . . . . . . 66
7.2.1. Safe Methods . . . . . . . . . . . . . . . . . . . . 64 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 66
7.2.2. Idempotent Methods . . . . . . . . . . . . . . . . . 65 7.2. Common Method Properties . . . . . . . . . . . . . . . . 67
7.2.3. Cacheable Methods . . . . . . . . . . . . . . . . . . 66 7.2.1. Safe Methods . . . . . . . . . . . . . . . . . . . . 68
7.3. Method Definitions . . . . . . . . . . . . . . . . . . . 66 7.2.2. Idempotent Methods . . . . . . . . . . . . . . . . . 69
7.3.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 66 7.2.3. Methods and Caching . . . . . . . . . . . . . . . . . 70
7.3.2. HEAD . . . . . . . . . . . . . . . . . . . . . . . . 67 7.3. Method Definitions . . . . . . . . . . . . . . . . . . . 70
7.3.3. POST . . . . . . . . . . . . . . . . . . . . . . . . 67 7.3.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 70
7.3.4. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 68 7.3.2. HEAD . . . . . . . . . . . . . . . . . . . . . . . . 71
7.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . 71 7.3.3. POST . . . . . . . . . . . . . . . . . . . . . . . . 72
7.3.6. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 72 7.3.4. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 73
7.3.7. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 73 7.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . 75
7.3.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . 74 7.3.6. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 76
7.4. Method Extensibility . . . . . . . . . . . . . . . . . . 75 7.3.7. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 78
7.4.1. Method Registry . . . . . . . . . . . . . . . . . . . 75 7.3.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . 79
7.4.2. Considerations for New Methods . . . . . . . . . . . 75 7.4. Method Extensibility . . . . . . . . . . . . . . . . . . 79
8. Request Header Fields . . . . . . . . . . . . . . . . . . . . 76 7.4.1. Method Registry . . . . . . . . . . . . . . . . . . . 79
8.1. Controls . . . . . . . . . . . . . . . . . . . . . . . . 76 7.4.2. Considerations for New Methods . . . . . . . . . . . 80
8.1.1. Expect . . . . . . . . . . . . . . . . . . . . . . . 77 8. Request Header Fields . . . . . . . . . . . . . . . . . . . . 80
8.1.2. Max-Forwards . . . . . . . . . . . . . . . . . . . . 79 8.1. Controls . . . . . . . . . . . . . . . . . . . . . . . . 81
8.2. Preconditions . . . . . . . . . . . . . . . . . . . . . . 80 8.1.1. Expect . . . . . . . . . . . . . . . . . . . . . . . 81
8.2.1. Evaluation . . . . . . . . . . . . . . . . . . . . . 81 8.1.2. Max-Forwards . . . . . . . . . . . . . . . . . . . . 83
8.2.2. Precedence . . . . . . . . . . . . . . . . . . . . . 82 8.2. Preconditions . . . . . . . . . . . . . . . . . . . . . . 84
8.2.3. If-Match . . . . . . . . . . . . . . . . . . . . . . 84 8.2.1. Evaluation . . . . . . . . . . . . . . . . . . . . . 85
8.2.4. If-None-Match . . . . . . . . . . . . . . . . . . . . 85 8.2.2. Precedence . . . . . . . . . . . . . . . . . . . . . 86
8.2.5. If-Modified-Since . . . . . . . . . . . . . . . . . . 86 8.2.3. If-Match . . . . . . . . . . . . . . . . . . . . . . 88
8.2.6. If-Unmodified-Since . . . . . . . . . . . . . . . . . 87 8.2.4. If-None-Match . . . . . . . . . . . . . . . . . . . . 89
8.2.7. If-Range . . . . . . . . . . . . . . . . . . . . . . 88 8.2.5. If-Modified-Since . . . . . . . . . . . . . . . . . . 90
8.3. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 90 8.2.6. If-Unmodified-Since . . . . . . . . . . . . . . . . . 91
8.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 91 8.2.7. If-Range . . . . . . . . . . . . . . . . . . . . . . 93
8.4.1. Quality Values . . . . . . . . . . . . . . . . . . . 92 8.3. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 94
8.4.2. Accept . . . . . . . . . . . . . . . . . . . . . . . 93 8.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 95
8.4.3. Accept-Charset . . . . . . . . . . . . . . . . . . . 95 8.4.1. Quality Values . . . . . . . . . . . . . . . . . . . 96
8.4.4. Accept-Encoding . . . . . . . . . . . . . . . . . . . 96 8.4.2. Accept . . . . . . . . . . . . . . . . . . . . . . . 97
8.4.5. Accept-Language . . . . . . . . . . . . . . . . . . . 97 8.4.3. Accept-Charset . . . . . . . . . . . . . . . . . . . 99
8.5. Authentication Credentials . . . . . . . . . . . . . . . 98 8.4.4. Accept-Encoding . . . . . . . . . . . . . . . . . . . 100
8.5.1. Challenge and Response . . . . . . . . . . . . . . . 98 8.4.5. Accept-Language . . . . . . . . . . . . . . . . . . . 101
8.5.2. Protection Space (Realm) . . . . . . . . . . . . . . 100 8.5. Authentication Credentials . . . . . . . . . . . . . . . 102
8.5.3. Authorization . . . . . . . . . . . . . . . . . . . . 101 8.5.1. Challenge and Response . . . . . . . . . . . . . . . 102
8.5.4. Proxy-Authorization . . . . . . . . . . . . . . . . . 101 8.5.2. Protection Space (Realm) . . . . . . . . . . . . . . 104
8.5.5. Authentication Scheme Extensibility . . . . . . . . . 102 8.5.3. Authorization . . . . . . . . . . . . . . . . . . . . 105
8.6. Request Context . . . . . . . . . . . . . . . . . . . . . 104 8.5.4. Proxy-Authorization . . . . . . . . . . . . . . . . . 105
8.6.1. From . . . . . . . . . . . . . . . . . . . . . . . . 104 8.5.5. Authentication Scheme Extensibility . . . . . . . . . 106
8.6.2. Referer . . . . . . . . . . . . . . . . . . . . . . . 105 8.6. Request Context . . . . . . . . . . . . . . . . . . . . . 108
8.6.3. User-Agent . . . . . . . . . . . . . . . . . . . . . 106 8.6.1. From . . . . . . . . . . . . . . . . . . . . . . . . 108
9. Response Status Codes . . . . . . . . . . . . . . . . . . . . 107 8.6.2. Referer . . . . . . . . . . . . . . . . . . . . . . . 109
9.1. Overview of Status Codes . . . . . . . . . . . . . . . . 108 8.6.3. User-Agent . . . . . . . . . . . . . . . . . . . . . 110
9.2. Informational 1xx . . . . . . . . . . . . . . . . . . . . 109
9.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 110 9. Response Status Codes . . . . . . . . . . . . . . . . . . . . 111
9.2.2. 101 Switching Protocols . . . . . . . . . . . . . . . 110 9.1. Overview of Status Codes . . . . . . . . . . . . . . . . 112
9.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . 110 9.2. Informational 1xx . . . . . . . . . . . . . . . . . . . . 113
9.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 110 9.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 114
9.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 111 9.2.2. 101 Switching Protocols . . . . . . . . . . . . . . . 114
9.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . 111 9.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . 114
9.3.4. 203 Non-Authoritative Information . . . . . . . . . . 112 9.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 114
9.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . 112 9.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 115
9.3.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 113 9.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . 115
9.3.7. 206 Partial Content . . . . . . . . . . . . . . . . . 113 9.3.4. 203 Non-Authoritative Information . . . . . . . . . . 116
9.4. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 116 9.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . 116
9.4.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 118 9.3.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 117
9.4.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 119 9.3.7. 206 Partial Content . . . . . . . . . . . . . . . . . 117
9.4.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 119 9.4. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 120
9.4.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 120 9.4.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 122
9.4.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 120 9.4.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 123
9.4.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 121 9.4.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 123
9.4.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . 121 9.4.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 124
9.4.8. 307 Temporary Redirect . . . . . . . . . . . . . . . 121 9.4.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 124
9.4.9. 308 Permanent Redirect . . . . . . . . . . . . . . . 122 9.4.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 125
9.5. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 122 9.4.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . 125
9.5.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 122 9.4.8. 307 Temporary Redirect . . . . . . . . . . . . . . . 125
9.5.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 122 9.4.9. 308 Permanent Redirect . . . . . . . . . . . . . . . 126
9.5.3. 402 Payment Required . . . . . . . . . . . . . . . . 123 9.5. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 126
9.5.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 123 9.5.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 126
9.5.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 123 9.5.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 126
9.5.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 124 9.5.3. 402 Payment Required . . . . . . . . . . . . . . . . 127
9.5.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 124 9.5.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 127
9.5.8. 407 Proxy Authentication Required . . . . . . . . . . 124 9.5.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 127
9.5.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 124 9.5.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 128
9.5.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . 125 9.5.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 128
9.5.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 125 9.5.8. 407 Proxy Authentication Required . . . . . . . . . . 128
9.5.12. 411 Length Required . . . . . . . . . . . . . . . . . 125 9.5.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 128
9.5.13. 412 Precondition Failed . . . . . . . . . . . . . . . 126 9.5.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . 129
9.5.14. 413 Payload Too Large . . . . . . . . . . . . . . . . 126 9.5.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 129
9.5.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . 126 9.5.12. 411 Length Required . . . . . . . . . . . . . . . . . 129
9.5.16. 415 Unsupported Media Type . . . . . . . . . . . . . 126 9.5.13. 412 Precondition Failed . . . . . . . . . . . . . . . 130
9.5.17. 416 Range Not Satisfiable . . . . . . . . . . . . . . 127 9.5.14. 413 Payload Too Large . . . . . . . . . . . . . . . . 130
9.5.18. 417 Expectation Failed . . . . . . . . . . . . . . . 127 9.5.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . 130
9.5.19. 418 (Unused) . . . . . . . . . . . . . . . . . . . . 127 9.5.16. 415 Unsupported Media Type . . . . . . . . . . . . . 130
9.5.20. 422 Unprocessable Payload . . . . . . . . . . . . . . 128 9.5.17. 416 Range Not Satisfiable . . . . . . . . . . . . . . 131
9.5.21. 426 Upgrade Required . . . . . . . . . . . . . . . . 128 9.5.18. 417 Expectation Failed . . . . . . . . . . . . . . . 131
9.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 128 9.5.19. 418 (Unused) . . . . . . . . . . . . . . . . . . . . 131
9.6.1. 500 Internal Server Error . . . . . . . . . . . . . . 129 9.5.20. 422 Unprocessable Payload . . . . . . . . . . . . . . 132
9.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 129 9.5.21. 426 Upgrade Required . . . . . . . . . . . . . . . . 132
9.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 129 9.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 132
9.6.4. 503 Service Unavailable . . . . . . . . . . . . . . . 129 9.6.1. 500 Internal Server Error . . . . . . . . . . . . . . 133
9.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 129 9.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 133
9.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . 129 9.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 133
9.7. Status Code Extensibility . . . . . . . . . . . . . . . . 130 9.6.4. 503 Service Unavailable . . . . . . . . . . . . . . . 133
9.7.1. Status Code Registry . . . . . . . . . . . . . . . . 130 9.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 133
9.7.2. Considerations for New Status Codes . . . . . . . . . 130 9.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . 133
10. Response Header Fields . . . . . . . . . . . . . . . . . . . 131 9.7. Status Code Extensibility . . . . . . . . . . . . . . . . 134
10.1. Control Data . . . . . . . . . . . . . . . . . . . . . . 131 9.7.1. Status Code Registry . . . . . . . . . . . . . . . . 134
10.1.1. Origination Date . . . . . . . . . . . . . . . . . . 132 9.7.2. Considerations for New Status Codes . . . . . . . . . 134
10.1.2. Location . . . . . . . . . . . . . . . . . . . . . . 135 10. Response Header Fields . . . . . . . . . . . . . . . . . . . 135
10.1.3. Retry-After . . . . . . . . . . . . . . . . . . . . 136 10.1. Control Data . . . . . . . . . . . . . . . . . . . . . . 135
10.1.4. Vary . . . . . . . . . . . . . . . . . . . . . . . . 137 10.1.1. Origination Date . . . . . . . . . . . . . . . . . . 136
10.2. Validators . . . . . . . . . . . . . . . . . . . . . . . 138 10.1.2. Location . . . . . . . . . . . . . . . . . . . . . . 139
10.2.1. Weak versus Strong . . . . . . . . . . . . . . . . . 139 10.1.3. Retry-After . . . . . . . . . . . . . . . . . . . . 140
10.2.2. Last-Modified . . . . . . . . . . . . . . . . . . . 140 10.1.4. Vary . . . . . . . . . . . . . . . . . . . . . . . . 141
10.2.3. ETag . . . . . . . . . . . . . . . . . . . . . . . . 142 10.2. Validators . . . . . . . . . . . . . . . . . . . . . . . 142
10.2.4. When to Use Entity-Tags and Last-Modified Dates . . 146 10.2.1. Weak versus Strong . . . . . . . . . . . . . . . . . 143
10.3. Authentication Challenges . . . . . . . . . . . . . . . 146 10.2.2. Last-Modified . . . . . . . . . . . . . . . . . . . 144
10.3.1. WWW-Authenticate . . . . . . . . . . . . . . . . . . 147 10.2.3. ETag . . . . . . . . . . . . . . . . . . . . . . . . 146
10.3.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . 148 10.2.4. When to Use Entity-Tags and Last-Modified Dates . . 150
10.3.3. Authentication-Info . . . . . . . . . . . . . . . . 148 10.3. Authentication Challenges . . . . . . . . . . . . . . . 150
10.3.4. Proxy-Authentication-Info . . . . . . . . . . . . . 149 10.3.1. WWW-Authenticate . . . . . . . . . . . . . . . . . . 151
10.4. Response Context . . . . . . . . . . . . . . . . . . . . 150 10.3.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . 152
10.4.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . 150 10.3.3. Authentication-Info . . . . . . . . . . . . . . . . 152
10.4.2. Allow . . . . . . . . . . . . . . . . . . . . . . . 150 10.3.4. Proxy-Authentication-Info . . . . . . . . . . . . . 153
10.4.3. Server . . . . . . . . . . . . . . . . . . . . . . . 151 10.4. Response Context . . . . . . . . . . . . . . . . . . . . 154
11. ABNF List Extension: #rule . . . . . . . . . . . . . . . . . 152 10.4.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . 154
11.1. Sender Requirements . . . . . . . . . . . . . . . . . . 152 10.4.2. Allow . . . . . . . . . . . . . . . . . . . . . . . 154
11.2. Recipient Requirements . . . . . . . . . . . . . . . . . 152 10.4.3. Server . . . . . . . . . . . . . . . . . . . . . . . 155
12. Security Considerations . . . . . . . . . . . . . . . . . . . 153 11. Generic Syntax . . . . . . . . . . . . . . . . . . . . . . . 156
12.1. Establishing Authority . . . . . . . . . . . . . . . . . 153 11.1. Whitespace . . . . . . . . . . . . . . . . . . . . . . . 156
12.2. Risks of Intermediaries . . . . . . . . . . . . . . . . 154 12. ABNF List Extension: #rule . . . . . . . . . . . . . . . . . 156
12.3. Attacks Based on File and Path Names . . . . . . . . . . 155 12.1. Sender Requirements . . . . . . . . . . . . . . . . . . 156
12.4. Attacks Based on Command, Code, or Query Injection . . . 155 12.2. Recipient Requirements . . . . . . . . . . . . . . . . . 157
12.5. Attacks via Protocol Element Length . . . . . . . . . . 156 13. Security Considerations . . . . . . . . . . . . . . . . . . . 158
12.6. Disclosure of Personal Information . . . . . . . . . . . 156 13.1. Establishing Authority . . . . . . . . . . . . . . . . . 158
12.7. Privacy of Server Log Information . . . . . . . . . . . 157 13.2. Risks of Intermediaries . . . . . . . . . . . . . . . . 159
12.8. Disclosure of Sensitive Information in URIs . . . . . . 157 13.3. Attacks Based on File and Path Names . . . . . . . . . . 160
12.9. Disclosure of Fragment after Redirects . . . . . . . . . 158 13.4. Attacks Based on Command, Code, or Query Injection . . . 160
12.10. Disclosure of Product Information . . . . . . . . . . . 158 13.5. Attacks via Protocol Element Length . . . . . . . . . . 161
12.11. Browser Fingerprinting . . . . . . . . . . . . . . . . . 158 13.6. Disclosure of Personal Information . . . . . . . . . . . 161
12.12. Validator Retention . . . . . . . . . . . . . . . . . . 159 13.7. Privacy of Server Log Information . . . . . . . . . . . 161
12.13. Denial-of-Service Attacks Using Range . . . . . . . . . 160 13.8. Disclosure of Sensitive Information in URIs . . . . . . 162
12.14. Authentication Considerations . . . . . . . . . . . . . 160 13.9. Disclosure of Fragment after Redirects . . . . . . . . . 162
12.14.1. Confidentiality of Credentials . . . . . . . . . . 160 13.10. Disclosure of Product Information . . . . . . . . . . . 163
12.14.2. Credentials and Idle Clients . . . . . . . . . . . 161 13.11. Browser Fingerprinting . . . . . . . . . . . . . . . . . 163
12.14.3. Protection Spaces . . . . . . . . . . . . . . . . . 161 13.12. Validator Retention . . . . . . . . . . . . . . . . . . 164
12.14.4. Additional Response Header Fields . . . . . . . . . 162 13.13. Denial-of-Service Attacks Using Range . . . . . . . . . 165
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 162 13.14. Authentication Considerations . . . . . . . . . . . . . 165
13.1. URI Scheme Registration . . . . . . . . . . . . . . . . 162 13.14.1. Confidentiality of Credentials . . . . . . . . . . 165
13.2. Method Registration . . . . . . . . . . . . . . . . . . 162 13.14.2. Credentials and Idle Clients . . . . . . . . . . . 166
13.3. Status Code Registration . . . . . . . . . . . . . . . . 162 13.14.3. Protection Spaces . . . . . . . . . . . . . . . . . 166
13.4. Header Field Registration . . . . . . . . . . . . . . . 163 13.14.4. Additional Response Header Fields . . . . . . . . . 167
13.5. Authentication Scheme Registration . . . . . . . . . . . 163 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 167
13.6. Content Coding Registration . . . . . . . . . . . . . . 163 14.1. URI Scheme Registration . . . . . . . . . . . . . . . . 167
13.7. Range Unit Registration . . . . . . . . . . . . . . . . 164 14.2. Method Registration . . . . . . . . . . . . . . . . . . 167
13.8. Media Type Registration . . . . . . . . . . . . . . . . 164 14.3. Status Code Registration . . . . . . . . . . . . . . . . 167
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 164 14.4. Header Field Registration . . . . . . . . . . . . . . . 168
14.1. Normative References . . . . . . . . . . . . . . . . . . 164 14.5. Authentication Scheme Registration . . . . . . . . . . . 168
14.2. Informative References . . . . . . . . . . . . . . . . . 166 14.6. Content Coding Registration . . . . . . . . . . . . . . 168
Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 172 14.7. Range Unit Registration . . . . . . . . . . . . . . . . 169
Appendix B. Changes from RFC 7230 . . . . . . . . . . . . . . . 176 14.8. Media Type Registration . . . . . . . . . . . . . . . . 169
Appendix C. Changes from RFC 7231 . . . . . . . . . . . . . . . 177 14.9. Port Registration . . . . . . . . . . . . . . . . . . . 169
Appendix D. Changes from RFC 7232 . . . . . . . . . . . . . . . 177 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 169
Appendix E. Changes from RFC 7233 . . . . . . . . . . . . . . . 177 15.1. Normative References . . . . . . . . . . . . . . . . . . 169
Appendix F. Changes from RFC 7235 . . . . . . . . . . . . . . . 177 15.2. Informative References . . . . . . . . . . . . . . . . . 171
Appendix G. Changes from RFC 7538 . . . . . . . . . . . . . . . 177 Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 177
Appendix H. Changes from RFC 7615 . . . . . . . . . . . . . . . 177 Appendix B. Changes from RFC 7230 . . . . . . . . . . . . . . . 181
Appendix I. Change Log . . . . . . . . . . . . . . . . . . . . . 177 Appendix C. Changes from RFC 2818 . . . . . . . . . . . . . . . 182
I.1. Between RFC723x and draft 00 . . . . . . . . . . . . . . 177 Appendix D. Changes from RFC 7231 . . . . . . . . . . . . . . . 182
I.2. Since draft-ietf-httpbis-semantics-00 . . . . . . . . . . 178 Appendix E. Changes from RFC 7232 . . . . . . . . . . . . . . . 182
I.3. Since draft-ietf-httpbis-semantics-01 . . . . . . . . . . 178 Appendix F. Changes from RFC 7233 . . . . . . . . . . . . . . . 182
I.4. Since draft-ietf-httpbis-semantics-02 . . . . . . . . . . 180 Appendix G. Changes from RFC 7235 . . . . . . . . . . . . . . . 182
I.5. Since draft-ietf-httpbis-semantics-03 . . . . . . . . . . 180 Appendix H. Changes from RFC 7538 . . . . . . . . . . . . . . . 183
I.6. Since draft-ietf-httpbis-semantics-04 . . . . . . . . . . 181 Appendix I. Changes from RFC 7615 . . . . . . . . . . . . . . . 183
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 Appendix J. Change Log . . . . . . . . . . . . . . . . . . . . . 183
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 190 J.1. Between RFC723x and draft 00 . . . . . . . . . . . . . . 183
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 190 J.2. Since draft-ietf-httpbis-semantics-00 . . . . . . . . . . 183
J.3. Since draft-ietf-httpbis-semantics-01 . . . . . . . . . . 184
J.4. Since draft-ietf-httpbis-semantics-02 . . . . . . . . . . 185
J.5. Since draft-ietf-httpbis-semantics-03 . . . . . . . . . . 186
J.6. Since draft-ietf-httpbis-semantics-04 . . . . . . . . . . 187
J.7. Since draft-ietf-httpbis-semantics-05 . . . . . . . . . . 187
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 196
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 197
1. Introduction 1. Introduction
The Hypertext Transfer Protocol (HTTP) is a stateless application- The Hypertext Transfer Protocol (HTTP) is a stateless application-
level request/response protocol that uses extensible semantics and level request/response protocol that uses extensible semantics and
self-descriptive messages for flexible interaction with network-based self-descriptive messages for flexible interaction with network-based
hypertext information systems. HTTP is defined by a series of hypertext information systems. HTTP is defined by a series of
documents that collectively form the HTTP/1.1 specification: documents that collectively form the HTTP/1.1 specification:
o "HTTP Semantics" (this document) o "HTTP Semantics" (this document)
skipping to change at page 9, line 14 skipping to change at page 9, line 20
selection algorithms that are collectively referred to as "content selection algorithms that are collectively referred to as "content
negotiation" (Section 6.4). negotiation" (Section 6.4).
This document defines HTTP range requests, partial responses, and the This document defines HTTP range requests, partial responses, and the
multipart/byteranges media type. multipart/byteranges media type.
This document obsoletes the portions of RFC 7230 that are independent This document obsoletes the portions of RFC 7230 that are independent
of the HTTP/1.1 messaging syntax and connection management, with the of the HTTP/1.1 messaging syntax and connection management, with the
changes being summarized in Appendix B. The other parts of RFC 7230 changes being summarized in Appendix B. The other parts of RFC 7230
are obsoleted by "HTTP/1.1 Messaging" [Messaging]. This document are obsoleted by "HTTP/1.1 Messaging" [Messaging]. This document
also obsoletes RFC 7231 (see Appendix C), RFC 7232 (see Appendix D), also obsoletes RFC 2818 (see Appendix C), RFC 7231 (see Appendix D),
RFC 7233 (see Appendix E), RFC 7235 (see Appendix F), RFC 7538 (see RFC 7232 (see Appendix E), RFC 7233 (see Appendix F), RFC 7235 (see
Appendix G), and RFC 7615 (see Appendix H). Appendix G), RFC 7538 (see Appendix H), and RFC 7615 (see
Appendix I).
1.1. Requirements Notation 1.1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Conformance criteria and considerations regarding error handling are Conformance criteria and considerations regarding error handling are
defined in Section 3. defined in Section 3.
1.2. Syntax Notation 1.2. Syntax Notation
This specification uses the Augmented Backus-Naur Form (ABNF) This specification uses the Augmented Backus-Naur Form (ABNF)
notation of [RFC5234], extended with the notation for case- notation of [RFC5234], extended with the notation for case-
sensitivity in strings defined in [RFC7405]. sensitivity in strings defined in [RFC7405].
It also uses a list extension, defined in Section 11, that allows for It also uses a list extension, defined in Section 12, that allows for
compact definition of comma-separated lists using a '#' operator compact definition of comma-separated lists using a '#' operator
(similar to how the '*' operator indicates repetition). Appendix A (similar to how the '*' operator indicates repetition). Appendix A
shows the collected grammar with all list operators expanded to shows the collected grammar with all list operators expanded to
standard ABNF notation. standard ABNF notation.
As a convention, ABNF rule names prefixed with "obs-" denote As a convention, ABNF rule names prefixed with "obs-" denote
"obsolete" grammar rules that appear for historical reasons. "obsolete" grammar rules that appear for historical reasons.
The following core rules are included by reference, as defined in The following core rules are included by reference, as defined in
Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return),
skipping to change at page 10, line 8 skipping to change at page 10, line 14
quote), HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF quote), HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF
(line feed), OCTET (any 8-bit sequence of data), SP (space), and (line feed), OCTET (any 8-bit sequence of data), SP (space), and
VCHAR (any visible US-ASCII character). VCHAR (any visible US-ASCII character).
Section 4.2.3 defines some generic syntactic components for header Section 4.2.3 defines some generic syntactic components for header
field values. field values.
The rules below are defined in [Messaging]: The rules below are defined in [Messaging]:
obs-fold = <obs-fold, see [Messaging], Section 5.2> obs-fold = <obs-fold, see [Messaging], Section 5.2>
protocol-name = <protocol-name, see [Messaging], Section 9.8> protocol-name = <protocol-name, see [Messaging], Section 9.9>
protocol-version = <protocol-version, see [Messaging], Section 9.8> protocol-version = <protocol-version, see [Messaging], Section 9.9>
request-target = <request-target, see [Messaging], Section 3.2> request-target = <request-target, see [Messaging], Section 3.2>
This specification uses the terms "character", "character encoding This specification uses the terms "character", "character encoding
scheme", "charset", and "protocol element" as they are defined in scheme", "charset", and "protocol element" as they are defined in
[RFC6365]. [RFC6365].
2. Architecture 2. Architecture
HTTP was created for the World Wide Web (WWW) architecture and has HTTP was created for the World Wide Web (WWW) architecture and has
evolved over time to support the scalability needs of a worldwide evolved over time to support the scalability needs of a worldwide
skipping to change at page 11, line 9 skipping to change at page 11, line 19
Most HTTP communication consists of a retrieval request (GET) for a Most HTTP communication consists of a retrieval request (GET) for a
representation of some resource identified by a URI. In the simplest representation of some resource identified by a URI. In the simplest
case, this might be accomplished via a single bidirectional case, this might be accomplished via a single bidirectional
connection (===) between the user agent (UA) and the origin server connection (===) between the user agent (UA) and the origin server
(O). (O).
request > request >
UA ======================================= O UA ======================================= O
< response < response
Each major version of HTTP defines its own syntax for the inclusion
of information in messages. Nevertheless, a common abstraction is
that a message includes some form of envelope/framing, a potential
set of named header fields up front (a header section), a potential
body, and a potential set of named trailer fields.
A client sends an HTTP request to a server in the form of a request A client sends an HTTP request to a server in the form of a request
message, beginning with a method (Section 7) and URI, followed by message, beginning with a method (Section 7) and URI, followed by
header fields containing request modifiers, client information, and header fields containing request modifiers, client information, and
representation metadata (Section 5 of [Messaging]), and finally a representation metadata (Section 4), and finally a payload body (if
message body containing the payload body (if any, Section 6 of any, Section 6.3.3).
[Messaging]).
A server responds to a client's request by sending one or more HTTP A server responds to a client's request by sending one or more HTTP
response messages, each beginning with a success or error code response messages, each beginning with a success or error code
(Section 9), possibly followed by header fields containing server (Section 9), possibly followed by header fields containing server
information, resource metadata, and representation metadata information, resource metadata, and representation metadata
(Section 5 of [Messaging]), and finally a message body containing the (Section 4), and finally a payload body (if any, Section 6.3.3).
payload body (if any, Section 6 of [Messaging]).
A connection might be used for multiple request/response exchanges. A connection might be used for multiple request/response exchanges.
The mechanism used to correlate between request and response messages The mechanism used to correlate between request and response messages
is version dependent; some versions of HTTP use implicit ordering of is version dependent; some versions of HTTP use implicit ordering of
messages, while others use an explicit identifier. messages, while others use an explicit identifier.
Responses (both final and non-final) can be sent at any time after a Responses (both final and non-final) can be sent at any time after a
request is received, even if it is not yet complete. However, request is received, even if it is not yet complete. However,
clients (including intermediaries) might abandon a request if the clients (including intermediaries) might abandon a request if the
response is not forthcoming within a reasonable period of time. response is not forthcoming within a reasonable period of time.
skipping to change at page 13, line 36 skipping to change at page 13, line 44
However, an HTTP-to-HTTP gateway that wishes to interoperate with However, an HTTP-to-HTTP gateway that wishes to interoperate with
third-party HTTP servers ought to conform to user agent requirements third-party HTTP servers ought to conform to user agent requirements
on the gateway's inbound connection. on the gateway's inbound connection.
A "tunnel" acts as a blind relay between two connections without A "tunnel" acts as a blind relay between two connections without
changing the messages. Once active, a tunnel is not considered a changing the messages. Once active, a tunnel is not considered a
party to the HTTP communication, though the tunnel might have been party to the HTTP communication, though the tunnel might have been
initiated by an HTTP request. A tunnel ceases to exist when both initiated by an HTTP request. A tunnel ceases to exist when both
ends of the relayed connection are closed. Tunnels are used to ends of the relayed connection are closed. Tunnels are used to
extend a virtual connection through an intermediary, such as when extend a virtual connection through an intermediary, such as when
Transport Layer Security (TLS, [RFC5246]) is used to establish Transport Layer Security (TLS, [RFC8446]) is used to establish
confidential communication through a shared firewall proxy. confidential communication through a shared firewall proxy.
The above categories for intermediary only consider those acting as The above categories for intermediary only consider those acting as
participants in the HTTP communication. There are also participants in the HTTP communication. There are also
intermediaries that can act on lower layers of the network protocol intermediaries that can act on lower layers of the network protocol
stack, filtering or redirecting HTTP traffic without the knowledge or stack, filtering or redirecting HTTP traffic without the knowledge or
permission of message senders. Network intermediaries are permission of message senders. Network intermediaries are
indistinguishable (at a protocol level) from a man-in-the-middle indistinguishable (at a protocol level) from a man-in-the-middle
attack, often introducing security flaws or interoperability problems attack, often introducing security flaws or interoperability problems
due to mistakenly violating HTTP semantics. due to mistakenly violating HTTP semantics.
skipping to change at page 15, line 44 skipping to change at page 16, line 5
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.3).
It is RECOMMENDED that all senders and recipients support, at a
minimum, URIs with lengths of 8000 octets in protocol elements. Note
that this implies some structures and on-wire representations (for
example, the request line in HTTP/1.1) will necessarily be larger in
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
limit the nature of a resource; it merely defines an interface that limit the nature of a resource; it merely defines an interface that
might be used to interact with resources. Each resource is might be used to interact with resources. Each resource is
identified by a Uniform Resource Identifier (URI), as described in identified by a Uniform Resource Identifier (URI), as described in
Section 2.4. Section 2.4.
One design goal of HTTP is to separate resource identification from One design goal of HTTP is to separate resource identification from
request semantics, which is made possible by vesting the request request semantics, which is made possible by vesting the request
skipping to change at page 17, line 9 skipping to change at page 17, line 24
subcomponent is empty or not given, TCP port 80 (the reserved port subcomponent is empty or not given, TCP port 80 (the reserved port
for WWW services) is the default. for WWW services) is the default.
Note that the presence of a URI with a given authority component does Note that the presence of a URI with a given authority component does
not imply that there is always an HTTP server listening for not imply that there is always an HTTP server listening for
connections on that host and port. Anyone can mint a URI. What the connections on that host and port. Anyone can mint a URI. What the
authority component determines is who has the right to respond authority component determines is who has the right to respond
authoritatively to requests that target the identified resource. The authoritatively to requests that target the identified resource. The
delegated nature of registered names and IP addresses creates a delegated nature of registered names and IP addresses creates a
federated namespace, based on control over the indicated host and federated namespace, based on control over the indicated host and
port, whether or not an HTTP server is present. See Section 12.1 for port, whether or not an HTTP server is present. See Section 13.1 for
security considerations related to establishing authority. security considerations related to establishing authority.
When an "http" URI is used within a context that calls for access to When an "http" URI is used within a context that calls for access to
the indicated resource, a client MAY attempt access by resolving the the indicated resource, a client MAY attempt access by resolving the
host to an IP address, establishing a TCP connection to that address host to an IP address, establishing a TCP connection to that address
on the indicated port, and sending an HTTP request message (Section 2 on the indicated port, and sending an HTTP request message (Section 2
of [Messaging]) containing the URI's identifying data to the server. of [Messaging]) containing the URI's identifying data to the server.
If the server responds to that request with a non-interim HTTP If the server responds to that request with a non-interim HTTP
response message, as described in Section 9, then that response is response message, as described in Section 9, then that response is
considered an authoritative answer to the client's request. considered an authoritative answer to the client's request.
skipping to change at page 17, line 50 skipping to change at page 18, line 16
target or header field value. Before making use of an "http" URI target or header field value. Before making use of an "http" URI
reference received from an untrusted source, a recipient SHOULD parse reference received from an untrusted source, a recipient SHOULD parse
for userinfo and treat its presence as an error; it is likely being for userinfo and treat its presence as an error; it is likely being
used to obscure the authority for the sake of phishing attacks. 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 ([RFC5246]). 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
agent MUST ensure that its connection to the origin server is secured agent MUST ensure that its connection to the origin server is secured
through the use of strong encryption, end-to-end, prior to sending through the use of strong encryption, end-to-end, prior to sending
the first HTTP request. the first HTTP request.
https-URI = "https:" "//" authority path-abempty [ "?" query ] https-URI = "https:" "//" authority path-abempty [ "?" query ]
skipping to change at page 18, line 25 skipping to change at page 18, line 38
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.
The process for authoritative access to an "https" identified 2.5.2.1. Initiating HTTP Over TLS
resource is defined in [RFC2818].
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 2.5.3. Fragment Identifiers on http(s) URI References
Fragment identifiers allow for indirect identification of a secondary Fragment identifiers allow for indirect identification of a secondary
resource, independent of the URI scheme, as defined in Section 3.5 of resource, independent of the URI scheme, as defined in Section 3.5 of
[RFC3986]. Some protocol elements that refer to a URI allow [RFC3986]. Some protocol elements that refer to a URI allow
inclusion of a fragment, while others do not. They are distinguished inclusion of a fragment, while others do not. They are distinguished
by use of the ABNF rule for elements where fragment is allowed; by use of the ABNF rule for elements where fragment is allowed;
otherwise, a specific rule that excludes fragments is used (see otherwise, a specific rule that excludes fragments is used (see
Section 5.1). Section 5.1).
skipping to change at page 21, line 36 skipping to change at page 23, line 27
Unless noted otherwise, a recipient MAY attempt to recover a usable Unless noted otherwise, a recipient MAY attempt to recover a usable
protocol element from an invalid construct. HTTP does not define protocol element from an invalid construct. HTTP does not define
specific error handling mechanisms except when they have a direct specific error handling mechanisms except when they have a direct
impact on security, since different applications of the protocol impact on security, since different applications of the protocol
require different error handling strategies. For example, a Web require different error handling strategies. For example, a Web
browser might wish to transparently recover from a response where the browser might wish to transparently recover from a response where the
Location header field doesn't parse according to the ABNF, whereas a Location header field doesn't parse according to the ABNF, whereas a
systems control client might consider any form of error recovery to systems control client might consider any form of error recovery to
be dangerous. be dangerous.
Some requests can be automatically retried by a client in the event
of an underlying connection failure, as described in Section 7.2.2.
3.5. Protocol Versioning 3.5. Protocol Versioning
The HTTP version number consists of two decimal digits separated by a The HTTP version number consists of two decimal digits separated by a
"." (period or decimal point). The first digit ("major version") "." (period or decimal point). The first digit ("major version")
indicates the HTTP messaging syntax, whereas the second digit ("minor indicates the HTTP messaging syntax, whereas the second digit ("minor
version") indicates the highest minor version within that major version") indicates the highest minor version within that major
version to which the sender is conformant and able to understand for version to which the sender is conformant and able to understand for
future communication. future communication.
The protocol version as a whole indicates the sender's conformance The protocol version as a whole indicates the sender's conformance
skipping to change at page 23, line 5 skipping to change at page 24, line 41
message with a higher minor version, when sent to a recipient that message with a higher minor version, when sent to a recipient that
has not yet indicated support for that higher version, is has not yet indicated support for that higher version, is
sufficiently backwards-compatible to be safely processed by any sufficiently backwards-compatible to be safely processed by any
implementation of the same major version. implementation of the same major version.
When a major version of HTTP does not define any minor versions, the When a major version of HTTP does not define any minor versions, the
minor version "0" is implied and is used when referring to that minor version "0" is implied and is used when referring to that
protocol within a protocol element that requires sending a minor protocol within a protocol element that requires sending a minor
version. version.
4. Message Abstraction 4. Header Fields
Each major version of HTTP defines its own syntax for the inclusion This section defines the abstraction for message fields as field-name
of information in messages. Nevertheless, a common abstraction is and field-value pairs.
that a message includes some form of envelope/framing, a potential
set of named data fields, and a potential body. This section defines
the abstraction for message fields as field-name and field-value
pairs.
4.1. Header Field Names 4.1. Header Field Names
Header fields are key:value pairs that can be used to communicate Header fields are key:value pairs that can be used to communicate
data about the message, its payload, the target resource, or the data about the message, its payload, the target resource, or the
connection (i.e., control data). connection (i.e., control data).
The requirements for header field names are defined in [BCP90]. The requirements for header field names are defined in [BCP90].
The field-name token labels the corresponding field-value as having The field-name token labels the corresponding field-value as having
skipping to change at page 24, line 20 skipping to change at page 26, line 20
| Accept-Encoding | standard | Section 8.4.4 | | Accept-Encoding | standard | Section 8.4.4 |
| Accept-Language | standard | Section 8.4.5 | | Accept-Language | standard | Section 8.4.5 |
| Accept-Ranges | standard | Section 10.4.1 | | Accept-Ranges | standard | Section 10.4.1 |
| Allow | standard | Section 10.4.2 | | Allow | standard | Section 10.4.2 |
| Authentication-Info | standard | Section 10.3.3 | | Authentication-Info | standard | Section 10.3.3 |
| Authorization | standard | Section 8.5.3 | | Authorization | standard | Section 8.5.3 |
| 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.3 | | 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.4 |
| 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 |
skipping to change at page 24, line 42 skipping to change at page 26, line 42
| 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.4 | | 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.5.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.
Any party can request registration of a HTTP header field. See Any party can request registration of a HTTP header field. See
Section 4.1.3 for considerations to take into account when creating a Section 4.4 for considerations to take into account when creating a
new HTTP header field. new HTTP header field.
The "HTTP Header Field Name" registry is located at The "HTTP Header Field Name" registry is located at
"https://www.iana.org/assignments/http-headers/". Registration "https://www.iana.org/assignments/http-headers/". Registration
requests can be made by following the instructions located there or requests can be made by following the instructions located there or
by sending an email to the "ietf-http-wg@ietf.org" mailing list. by sending an email to the "ietf-http-wg@ietf.org" mailing list.
Header field names are registered on the advice of a Designated Header field names are registered on the advice of a Designated
Expert (appointed by the IESG or their delegate). Header fields with Expert (appointed by the IESG or their delegate). Header fields with
the status 'permanent' are Specification Required (using terminology the status 'permanent' are Specification Required (using terminology
skipping to change at page 26, line 31 skipping to change at page 28, line 31
A proxy MUST forward unrecognized header fields unless the field-name A proxy MUST forward unrecognized header fields unless the field-name
is listed in the Connection header field (Section 9.1 of [Messaging]) is listed in the Connection header field (Section 9.1 of [Messaging])
or the proxy is specifically configured to block, or otherwise or the proxy is specifically configured to block, or otherwise
transform, such fields. Other recipients SHOULD ignore unrecognized transform, such fields. Other recipients SHOULD ignore unrecognized
header fields. These requirements allow HTTP's functionality to be header fields. These requirements allow HTTP's functionality to be
enhanced without requiring prior update of deployed intermediaries. enhanced without requiring prior update of deployed intermediaries.
All defined header fields ought to be registered with IANA in the All defined header fields ought to be registered with IANA in the
"HTTP Header Field Name" registry. "HTTP Header Field Name" registry.
4.1.3. Considerations for New Header Fields
Authors of specifications defining new fields are advised to keep the
name as short as practical and not to prefix the name with "X-"
unless the header field will never be used on the Internet. (The
"X-" prefix idiom has been extensively misused in practice; it was
intended to only be used as a mechanism for avoiding name collisions
inside proprietary software or intranet processing, since the prefix
would ensure that private names never collide with a newly registered
Internet name; see [BCP178] for further information).
Authors of specifications defining new header fields are advised to
consider documenting:
o Whether the field is a single value or whether it can be a list
(delimited by commas; see Section 5 of [Messaging]).
If it does not use the list syntax, document how to treat messages
where the field occurs multiple times (a sensible default would be
to ignore the field, but this might not always be the right
choice).
Note that intermediaries and software libraries might combine
multiple header field instances into a single one, despite the
field's definition not allowing the list syntax. A robust format
enables recipients to discover these situations (good example:
"Content-Type", as the comma can only appear inside quoted
strings; bad example: "Location", as a comma can occur inside a
URI).
o Under what conditions the header field can be used; e.g., only in
responses or requests, in all messages, only on responses to a
particular request method, etc.
o Whether the field should be stored by origin servers that
understand it upon a PUT request.
o Whether the field semantics are further refined by the context,
such as by existing request methods or status codes.
o Whether it is appropriate to list the field-name in the Connection
header field (i.e., if the header field is to be hop-by-hop; see
Section 9.1 of [Messaging]).
o Under what conditions intermediaries are allowed to insert,
delete, or modify the field's value.
o Whether it is appropriate to list the field-name in a Vary
response header field (e.g., when the request header field is used
by an origin server's content selection algorithm; see
Section 10.1.4).
o Whether the header field is useful or allowable in trailers (see
Section 7.1 of [Messaging]).
o Whether the header field ought to be preserved across redirects.
o Whether it introduces any additional security considerations, such
as disclosure of privacy-related data.
4.2. Header Field Values 4.2. Header Field Values
This specification does not use ABNF rules to define each "Field- This specification does not use ABNF rules to define each "Field-
Name: Field Value" pair, as was done in earlier editions. Instead, Name: Field Value" pair, as was done in earlier editions. Instead,
this specification uses ABNF rules that are named according to each this specification uses ABNF rules that are named according to each
registered field name, wherein the rule defines the valid grammar for registered field name, wherein the rule defines the valid grammar for
that field's corresponding field values (i.e., after the field-value that field's corresponding field values (i.e., after the field-value
has been extracted by a generic field parser). has been extracted by a generic field parser).
field-value = *( field-content / obs-fold ) field-value = *( field-content / obs-fold )
skipping to change at page 31, line 12 skipping to change at page 32, line 5
be seen in media types (Section 6.1.1) and the Accept header field be seen in media types (Section 6.1.1) and the Accept header field
(Section 8.4.2). (Section 8.4.2).
A parameter value that matches the token production can be A parameter value that matches the token production can be
transmitted either as a token or within a quoted-string. The quoted transmitted either as a token or within a quoted-string. The quoted
and unquoted values are equivalent. and unquoted values are equivalent.
Note: Parameters do not allow whitespace (not even "bad" Note: Parameters do not allow whitespace (not even "bad"
whitespace) around the "=" character. whitespace) around the "=" character.
4.2.4. Designing New Header Field Values 4.3. Trailer Fields
New header field values typically have their syntax defined using 4.3.1. Purpose
ABNF ([RFC5234]), using the extension defined in Section 11 as
necessary, and are usually constrained to the range of US-ASCII In some HTTP versions, additional metadata can be sent after the
characters. Header fields needing a greater range of characters can initial header section has been completed (during or after
use an encoding such as the one defined in [RFC8187]. transmission of the payload body), such as a message integrity check,
digital signature, or post-processing status. For example, the
chunked coding in HTTP/1.1 allows a trailer section after the payload
body (Section 7.1.2 of [Messaging]) which can contain trailer fields:
field names and values that share the same syntax and namespace as
header fields but are received after the header section.
Trailer fields ought to be processed and stored separately from the
fields in the header section to avoid contradicting message semantics
known at the time the header section was complete. The presence or
absence of certain header fields might impact choices made for the
routing or processing of the message as a whole before the trailers
are received; those choices cannot be unmade by the later discovery
of trailer fields.
4.3.2. Limitations
Many header fields cannot be processed outside the header section
because their evaluation is necessary prior to receiving the message
body, such as fields that describe message framing, routing,
authentication, request modifiers, response controls, or payload
format. A sender MUST NOT generate a trailer field unless the sender
knows the corresponding header field name's definition permits the
field to be sent in trailers.
Trailer fields can be difficult to process by intermediaries that
forward messages from one protocol version to another. If the entire
message can be buffered in transit, some intermediaries could merge
trailer fields into the header section (as appropriate) before it is
forwarded. However, in most cases, the trailers are simply
discarded. A recipient MUST NOT merge a trailer field into a header
section unless the recipient understands the corresponding header
field definition and that definition explicitly permits and defines
how trailer field values can be safely merged.
A client can send a TE header field indicating "trailers" is
acceptable, as described in Section 7.4 of [Messaging], to inform the
server that it will not discard trailer fields.
Because of the potential for trailer fields to be discarded in
transit, a server SHOULD NOT generate trailer fields that it believes
are necessary for the user agent to receive.
4.3.3. Trailer
The "Trailer" header field provides a list of field names that the
sender anticipates sending as trailer fields within that message.
This allows a recipient to prepare for receipt of the indicated
metadata before it starts processing the body.
Trailer = 1#field-name
For example, a sender might indicate that a message integrity check
will be computed as the payload is being streamed and provide the
final signature as a trailer field. This allows a recipient to
perform the same check on the fly as the payload data is received.
A sender that intends to generate one or more trailer fields in a
message SHOULD generate a Trailer header field in the header section
of that message to indicate which fields might be present in the
trailers.
4.4. Considerations for New Header Fields
Authors of specifications defining new fields are advised to choose a
short but descriptive field name. Short names avoid needless data
transmission; descriptive names avoid confusion and "squatting" on
names that might have broader uses.
To that end, limited-use fields (such as a header confined to a
single application or use case) are encouraged to use a name that
includes its name (or an abbreviation) as a prefix; for example, if
the Foo Application needs a Description field, it might use "Foo-
Desc"; "Description" is too generic, and "Foo-Description" is
needlessly long.
Header field names ought not be prefixed with "X-"; see [BCP178] for
further information.
Other prefixes are sometimes used in HTTP header field names; for
example, "Accept-" is used in many content negotiation headers.
These prefixes are only an aid to recognizing the purpose of a header
field, and do not trigger automatic processing.
Header field values typically have their syntax defined using ABNF
([RFC5234]), using the extension defined in Section 12 as necessary,
and are usually constrained to the range of US-ASCII characters.
Header fields needing a greater range of characters can use an
encoding such as the one defined in [RFC8187].
Leading and trailing whitespace in raw field values is removed upon Leading and trailing whitespace in raw field values is removed upon
field parsing (Section 5.1 of [Messaging]). Field definitions where field parsing (Section 5.1 of [Messaging]). Field definitions where
leading or trailing whitespace in values is significant will have to leading or trailing whitespace in values is significant will have to
use a container syntax such as quoted-string (Section 4.2.3). use a container syntax such as quoted-string (Section 4.2.3.2).
Because commas (",") are used as a generic delimiter between field- Because commas (",") are used as a generic delimiter between field-
values, they need to be treated with care if they are allowed in the values, they need to be treated with care if they are allowed in the
field-value. Typically, components that might contain a comma are field-value. Typically, components that might contain a comma are
protected with double-quotes using the quoted-string ABNF production. protected with double-quotes using the quoted-string ABNF production.
For example, a textual date and a URI (either of which might contain For example, a textual date and a URI (either of which might contain
a comma) could be safely carried in field-values like these: a comma) could be safely carried in field-values like these:
Example-URI-Field: "http://example.com/a.html,foo", Example-URI-Field: "http://example.com/a.html,foo",
skipping to change at page 32, line 5 skipping to change at page 34, line 34
quotes will likely cause unnecessary confusion. quotes will likely cause unnecessary confusion.
Many header fields (such as Content-Type, defined in Section 6.2.1) Many header fields (such as Content-Type, defined in Section 6.2.1)
use a common syntax for parameters that allows both unquoted (token) use a common syntax for parameters that allows both unquoted (token)
and quoted (quoted-string) syntax for a parameter value and quoted (quoted-string) syntax for a parameter value
(Section 4.2.3.4). Use of common syntax allows recipients to reuse (Section 4.2.3.4). Use of common syntax allows recipients to reuse
existing parser components. When allowing both forms, the meaning of existing parser components. When allowing both forms, the meaning of
a parameter value ought to be the same whether it was received as a a parameter value ought to be the same whether it was received as a
token or a quoted string. token or a quoted string.
4.3. Whitespace Authors of specifications defining new header fields are advised to
consider documenting:
This specification uses three rules to denote the use of linear o Whether the field is a single value or whether it can be a list
whitespace: OWS (optional whitespace), RWS (required whitespace), and (delimited by commas; see Section 4.2).
BWS ("bad" whitespace).
The OWS rule is used where zero or more linear whitespace octets If it does not use the list syntax, document how to treat messages
might appear. For protocol elements where optional whitespace is where the field occurs multiple times (a sensible default would be
preferred to improve readability, a sender SHOULD generate the to ignore the field, but this might not always be the right
optional whitespace as a single SP; otherwise, a sender SHOULD NOT choice).
generate optional whitespace except as needed to white out invalid or
unwanted protocol elements during in-place message filtering.
The RWS rule is used when at least one linear whitespace octet is Note that intermediaries and software libraries might combine
required to separate field tokens. A sender SHOULD generate RWS as a multiple header field instances into a single one, despite the
single SP. field's definition not allowing the list syntax. A robust format
enables recipients to discover these situations (good example:
"Content-Type", as the comma can only appear inside quoted
strings; bad example: "Location", as a comma can occur inside a
URI).
The BWS rule is used where the grammar allows optional whitespace o Under what conditions the header field can be used; e.g., only in
only for historical reasons. A sender MUST NOT generate BWS in responses or requests, in all messages, only on responses to a
messages. A recipient MUST parse for such bad whitespace and remove particular request method, etc.
it before interpreting the protocol element.
OWS = *( SP / HTAB ) o Whether the field should be stored by origin servers that
; optional whitespace understand it upon a PUT request.
RWS = 1*( SP / HTAB )
; required whitespace
BWS = OWS
; "bad" whitespace
4.4. Trailer o Whether the field semantics are further refined by the context,
such as by existing request methods or status codes.
[[CREF2: The "Trailer" header field in a message indicates fields o Whether it is appropriate to list the field-name in the Connection
that the sender anticipates sending after the message header block header field (i.e., if the header field is to be hop-by-hop; see
(i.e., during or after the payload is sent). This is typically used Section 9.1 of [Messaging]).
to supply metadata that might be dynamically generated while the data
is sent, such as a message integrity check, digital signature, or
post-processing status. ]]
Trailer = 1#field-name o Under what conditions intermediaries are allowed to insert,
delete, or modify the field's value.
[[CREF3: How, where, and when trailer fields might be sent depends on o Whether it is appropriate to list the field-name in a Vary
both the protocol in use (HTTP version and/or transfer coding) and response header field (e.g., when the request header field is used
the semantics of each named header field. Many header fields cannot by an origin server's content selection algorithm; see
be processed outside the header section because their evaluation is Section 10.1.4).
necessary for message routing, authentication, or configuration prior
to receiving the representation data. ]] o Whether the header field is useful or allowable in trailers (see
Section 7.1 of [Messaging]).
o Whether the header field ought to be preserved across redirects.
o Whether it introduces any additional security considerations, such
as disclosure of privacy-related data.
5. Message Routing 5. Message Routing
HTTP request message routing is determined by each client based on HTTP request message routing is determined by each client based on
the target resource, the client's proxy configuration, and the target resource, the client's proxy configuration, and
establishment or reuse of an inbound connection. The corresponding establishment or reuse of an inbound connection. The corresponding
response routing follows the same connection chain back to the response routing follows the same connection chain back to the
client. client.
5.1. Identifying a Target Resource 5.1. Identifying a Target Resource
skipping to change at page 34, line 35 skipping to change at page 37, line 19
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 12 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.4. 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
skipping to change at page 36, line 37 skipping to change at page 39, line 18
protocols and recipients between the user agent and the server (on protocols and recipients between the user agent and the server (on
requests) or between the origin server and the client (on responses), requests) or between the origin server and the client (on responses),
similar to the "Received" header field in email (Section 3.6.7 of similar to the "Received" header field in email (Section 3.6.7 of
[RFC5322]). Via can be used for tracking message forwards, avoiding [RFC5322]). Via can be used for tracking message forwards, avoiding
request loops, and identifying the protocol capabilities of senders request loops, and identifying the protocol capabilities of senders
along the request/response chain. along the request/response chain.
Via = 1#( received-protocol RWS received-by [ RWS comment ] ) Via = 1#( received-protocol RWS received-by [ RWS comment ] )
received-protocol = [ protocol-name "/" ] protocol-version received-protocol = [ protocol-name "/" ] protocol-version
; see [Messaging], Section 9.8 ; see [Messaging], Section 9.9
received-by = ( uri-host [ ":" port ] ) / pseudonym received-by = ( uri-host [ ":" port ] ) / pseudonym
pseudonym = token pseudonym = token
Multiple Via field values represent each proxy or gateway that has Multiple Via field values represent each proxy or gateway that has
forwarded the message. Each intermediary appends its own information forwarded the message. Each intermediary appends its own information
about how the message was received, such that the end result is about how the message was received, such that the end result is
ordered according to the sequence of forwarding recipients. ordered according to the sequence of forwarding recipients.
A proxy MUST send an appropriate Via header field, as described A proxy MUST send an appropriate Via header field, as described
below, in each message that it forwards. An HTTP-to-HTTP gateway below, in each message that it forwards. An HTTP-to-HTTP gateway
skipping to change at page 42, line 34 skipping to change at page 45, line 14
Content-coding values are used in the Accept-Encoding (Section 8.4.4) Content-coding values are used in the Accept-Encoding (Section 8.4.4)
and Content-Encoding (Section 6.2.2) header fields. and Content-Encoding (Section 6.2.2) header fields.
The following content-coding values are defined by this The following content-coding values are defined by this
specification: specification:
+------------+------------------------------------------+-----------+ +------------+------------------------------------------+-----------+
| Name | Description | Reference | | Name | Description | Reference |
+------------+------------------------------------------+-----------+ +------------+------------------------------------------+-----------+
| compress | UNIX "compress" data format [Welch] | Section | | compress | UNIX "compress" data format [Welch] | Section 6 |
| | | 6.1.2.1 | | | | .1.2.1 |
| deflate | "deflate" compressed data ([RFC1951]) | Section | | deflate | "deflate" compressed data ([RFC1951]) | Section 6 |
| | inside the "zlib" data format | 6.1.2.2 | | | inside the "zlib" data format | .1.2.2 |
| | ([RFC1950]) | | | | ([RFC1950]) | |
| gzip | GZIP file format [RFC1952] | Section | | gzip | GZIP file format [RFC1952] | Section 6 |
| | | 6.1.2.3 | | | | .1.2.3 |
| identity | Reserved (synonym for "no encoding" in | Section | | identity | Reserved (synonym for "no encoding" in | Section 8 |
| | Accept-Encoding) | 8.4.4 | | | Accept-Encoding) | .4.4 |
| x-compress | Deprecated (alias for compress) | Section | | x-compress | Deprecated (alias for compress) | Section 6 |
| | | 6.1.2.1 | | | | .1.2.1 |
| x-gzip | Deprecated (alias for gzip) | Section | | x-gzip | Deprecated (alias for gzip) | Section 6 |
| | | 6.1.2.3 | | | | .1.2.3 |
+------------+------------------------------------------+-----------+ +------------+------------------------------------------+-----------+
Table 2 Table 2
6.1.2.1. Compress Coding 6.1.2.1. Compress Coding
The "compress" coding is an adaptive Lempel-Ziv-Welch (LZW) coding The "compress" coding is an adaptive Lempel-Ziv-Welch (LZW) coding
[Welch] that is commonly produced by the UNIX file compression [Welch] that is commonly produced by the UNIX file compression
program "compress". A recipient SHOULD consider "x-compress" to be program "compress". A recipient SHOULD consider "x-compress" to be
equivalent to "compress". equivalent to "compress".
skipping to change at page 44, line 38 skipping to change at page 47, line 14
language's range (e.g., "en-CA" = the variety of English as language's range (e.g., "en-CA" = the variety of English as
communicated in Canada). Whitespace is not allowed within a language communicated in Canada). Whitespace is not allowed within a language
tag. Example tags include: tag. Example tags include:
fr, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN fr, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN
See [RFC5646] for further information. See [RFC5646] for further information.
6.1.4. Range Units 6.1.4. Range Units
A representation can be partitioned into subranges according to Representation data can be partitioned into subranges when there are
various structural units, depending on the structure inherent in the addressable structural units inherent to that data's content coding
representation's media type. This "range unit" is used in the or media type. For example, octet (a.k.a., byte) boundaries are a
Accept-Ranges (Section 10.4.1) response header field to advertise structural unit common to all representation data, allowing
support for range requests, the Range (Section 8.3) request header partitions of the data to be identified as a range of bytes at some
field to delineate the parts of a representation that are requested, offset from the start or end of that data.
and the Content-Range (Section 6.3.3) payload header field to
describe which part of a representation is being transferred.
range-unit = bytes-unit / other-range-unit This general notion of a "range unit" is used in the Accept-Ranges
(Section 10.4.1) response header field to advertise support for range
requests, the Range (Section 8.3) request header field to delineate
the parts of a representation that are requested, and the Content-
Range (Section 6.3.4) payload header field to describe which part of
a representation is being transferred.
range-unit = token
The following range unit names are defined by this document: The following range unit names are defined by this document:
+-------------+---------------------------------------+-------------+ +------------+-----------------------------------------+------------+
| Range Unit | Description | Reference | | Range Unit | Description | Reference |
| Name | | | | Name | | |
+-------------+---------------------------------------+-------------+ +------------+-----------------------------------------+------------+
| bytes | a range of octets | Section | | bytes | a range of octets | Section 6. |
| | | 6.1.4.1 | | | | 1.4.2 |
| none | reserved as keyword, indicating no | Section | | none | reserved as keyword to indicate range | Section 10 |
| | ranges are supported | 10.4.1 | | | requests are not supported | .4.1 |
+-------------+---------------------------------------+-------------+ +------------+-----------------------------------------+------------+
Table 3 Table 3
6.1.4.1. Byte Ranges 6.1.4.1. Range Specifiers
Since representation data is transferred in payloads as a sequence of Ranges are expressed in terms of a range unit paired with a set of
octets, a byte range is a meaningful substructure for any range specifiers. The range unit name determines what kinds of
representation transferable over HTTP (Section 6). The "bytes" range range-spec are applicable to its own specifiers. Hence, the
unit is defined for expressing subranges of the data's octet following gramar is generic: each range unit is expected to specify
sequence. requirements on when int-range, suffix-range, and other-range are
allowed.
bytes-unit = "bytes" A range request can specify a single range or a set of ranges within
a single representation.
A byte-range request can specify a single range of bytes or a set of ranges-specifier = range-unit "=" range-set
ranges within a single representation. range-set = 1#range-spec
range-spec = int-range
/ suffix-range
/ other-range
byte-ranges-specifier = bytes-unit "=" byte-range-set An int-range is a range expressed as two non-negative integers or as
byte-range-set = 1#( byte-range-spec / suffix-byte-range-spec ) one non-negative integer through to the end of the representation
byte-range-spec = first-byte-pos "-" [ last-byte-pos ] data. The range unit specifies what the integers mean (e.g., they
first-byte-pos = 1*DIGIT might indicate unit offsets from the beginning, inclusive numbered
last-byte-pos = 1*DIGIT parts, etc.).
The first-byte-pos value in a byte-range-spec gives the byte-offset int-range = first-pos "-" [ last-pos ]
of the first byte in a range. The last-byte-pos value gives the first-pos = 1*DIGIT
byte-offset of the last byte in the range; that is, the byte last-pos = 1*DIGIT
positions specified are inclusive. Byte offsets start at zero.
Examples of byte-ranges-specifier values: An int-range is invalid if the last-pos value is present and less
than the first-pos.
A suffix-range is a range expressed as a suffix of the representation
data with the provided non-negative integer maximum length (in range
units). In other words, the last N units of the representation data.
suffix-range = "-" suffix-length
suffix-length = 1*DIGIT
To provide for extensibility, the other-range rule is a mostly
unconstrained grammar that allows application-specific or future
range units to define additional range specifiers.
other-range = 1*( %x21-2B / %x2D-7E )
; 1*(VCHAR excluding comma)
6.1.4.2. Byte Ranges
The "bytes" range unit is used to express subranges of a
representation data's octet sequence. Each byte range is expressed
as an integer range at some offset, relative to either the beginning
(int-range) or end (suffix-range) of the representation data. Byte
ranges do not use the other-range specifier.
The first-pos value in a bytes int-range gives the offset of the
first byte in a range. The last-pos value gives the offset of the
last byte in the range; that is, the byte positions specified are
inclusive. Byte offsets start at zero.
If the representation data has a content coding applied, each byte
range is calculated with respect to the encoded sequence of bytes,
not the sequence of underlying bytes that would be obtained after
decoding.
Examples of bytes range specifiers:
o The first 500 bytes (byte offsets 0-499, inclusive): o The first 500 bytes (byte offsets 0-499, inclusive):
bytes=0-499 bytes=0-499
o The second 500 bytes (byte offsets 500-999, inclusive): o The second 500 bytes (byte offsets 500-999, inclusive):
bytes=500-999 bytes=500-999
A byte-range-spec is invalid if the last-byte-pos value is present
and less than the first-byte-pos.
A client can limit the number of bytes requested without knowing the A client can limit the number of bytes requested without knowing the
size of the selected representation. If the last-byte-pos value is size of the selected representation. If the last-pos value is
absent, or if the value is greater than or equal to the current absent, or if the value is greater than or equal to the current
length of the representation data, the byte range is interpreted as length of the representation data, the byte range is interpreted as
the remainder of the representation (i.e., the server replaces the the remainder of the representation (i.e., the server replaces the
value of last-byte-pos with a value that is one less than the current value of last-pos with a value that is one less than the current
length of the selected representation). length of the selected representation).
A client can request the last N bytes of the selected representation A client can request the last N bytes of the selected representation
using a suffix-byte-range-spec. using a suffix-range. If the selected representation is shorter than
the specified suffix-length, the entire representation is used.
suffix-byte-range-spec = "-" suffix-length
suffix-length = 1*DIGIT
If the selected representation is shorter than the specified suffix-
length, the entire representation is used.
Additional examples, assuming a representation of length 10000: Additional examples, assuming a representation of length 10000:
o The final 500 bytes (byte offsets 9500-9999, inclusive): o The final 500 bytes (byte offsets 9500-9999, inclusive):
bytes=-500 bytes=-500
Or: Or:
bytes=9500- bytes=9500-
o The first and last bytes only (bytes 0 and 9999): o The first and last bytes only (bytes 0 and 9999):
bytes=0-0,-1 bytes=0-0,-1
o The first, middle, and last 1000 bytes:
bytes= 0-999, 4500-5499, -1000
o Other valid (but not canonical) specifications of the second 500 o Other valid (but not canonical) specifications of the second 500
bytes (byte offsets 500-999, inclusive): bytes (byte offsets 500-999, inclusive):
bytes=500-600,601-999 bytes=500-600,601-999
bytes=500-700,601-999 bytes=500-700,601-999
If a valid byte-range-set includes at least one byte-range-spec with If a valid bytes range-set includes at least one range-spec with a
a first-byte-pos that is less than the current length of the first-pos that is less than the current length of the representation,
representation, or at least one suffix-byte-range-spec with a non- or at least one suffix-range with a non-zero suffix-length, then the
zero suffix-length, then the byte-range-set is satisfiable. bytes range-set is satisfiable. Otherwise, the bytes range-set is
Otherwise, the byte-range-set is unsatisfiable. unsatisfiable.
In the byte-range syntax, first-byte-pos, last-byte-pos, and suffix- In the byte-range syntax, first-pos, last-pos, and suffix-length are
length are expressed as decimal number of octets. Since there is no expressed as decimal number of octets. Since there is no predefined
predefined limit to the length of a payload, recipients MUST limit to the length of a payload, recipients MUST anticipate
anticipate potentially large decimal numerals and prevent parsing potentially large decimal numerals and prevent parsing errors due to
errors due to integer conversion overflows. integer conversion overflows.
6.1.4.2. Other Range Units 6.1.4.3. Other Range Units
Range units are intended to be extensible. New range units ought to Other range units, such as format-specific boundaries like pages,
be registered with IANA, as defined in Section 6.1.4.3. sections, records, rows, or time, are potentially usable in HTTP for
application-specific purposes, but are not commonly used in practice.
Implementors of alternative range units ought to consider how they
would work with content codings and general-purpose intermediaries.
other-range-unit = token Range units are intended to be extensible. New range units ought to
be registered with IANA, as defined in Section 6.1.4.4.
6.1.4.3. 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
skipping to change at page 50, line 46 skipping to change at page 54, line 13
linguistic audiences. An example would be a beginner's language linguistic audiences. An example would be a beginner's language
primer, such as "A First Lesson in Latin", which is clearly intended primer, such as "A First Lesson in Latin", which is clearly intended
to be used by an English-literate audience. In this case, the to be used by an English-literate audience. In this case, the
Content-Language would properly only include "en". Content-Language would properly only include "en".
Content-Language MAY be applied to any media type -- it is not Content-Language MAY be applied to any media type -- it is not
limited to textual documents. limited to textual documents.
6.2.4. Content-Length 6.2.4. Content-Length
[[CREF4: The "Content-Length" header field indicates the number of [[CREF2: The "Content-Length" header field indicates the number of
data octets (body length) for the representation. In some cases, data octets (body length) for the representation. In some cases,
Content-Length is used to define or estimate message framing. ]] Content-Length is used to define or estimate message framing. ]]
Content-Length = 1*DIGIT Content-Length = 1*DIGIT
An example is An example is
Content-Length: 3495 Content-Length: 3495
A sender MUST NOT send a Content-Length header field in any message A sender MUST NOT send a Content-Length header field in any message
that contains a Transfer-Encoding header field. that contains a Transfer-Encoding header field.
A user agent SHOULD send a Content-Length in a request message when A user agent SHOULD send a Content-Length in a request message when
no Transfer-Encoding is sent and the request method defines a meaning no Transfer-Encoding is sent and the request method defines a meaning
for an enclosed payload body. For example, a Content-Length header for an enclosed payload body. For example, a Content-Length header
field is normally sent in a POST request even when the value is 0 field is normally sent in a POST request even when the value is 0
(indicating an empty payload body). A user agent SHOULD NOT send a (indicating an empty payload body). A user agent SHOULD NOT send a
skipping to change at page 51, line 46 skipping to change at page 55, line 16
Encoding, an origin server SHOULD send a Content-Length header field Encoding, an origin server SHOULD send a Content-Length header field
when the payload body size is known prior to sending the complete when the payload body size is known prior to sending the complete
header section. This will allow downstream recipients to measure header section. This will allow downstream recipients to measure
transfer progress, know when a received message is complete, and transfer progress, know when a received message is complete, and
potentially reuse the connection for additional requests. potentially reuse the connection for additional requests.
Any Content-Length field value greater than or equal to zero is Any Content-Length field value greater than or equal to zero is
valid. Since there is no predefined limit to the length of a valid. Since there is no predefined limit to the length of a
payload, a recipient MUST anticipate potentially large decimal payload, a recipient MUST anticipate potentially large decimal
numerals and prevent parsing errors due to integer conversion numerals and prevent parsing errors due to integer conversion
overflows (Section 12.5). overflows (Section 13.5).
If a message is received that has multiple Content-Length header If a message is received that has multiple Content-Length header
fields with field-values consisting of the same decimal value, or a fields with field-values consisting of the same decimal value, or a
single Content-Length header field with a field value containing a single Content-Length header field with a field value containing a
list of identical decimal values (e.g., "Content-Length: 42, 42"), list of identical decimal values (e.g., "Content-Length: 42, 42"),
indicating that duplicate Content-Length header fields have been indicating that duplicate Content-Length header fields have been
generated or combined by an upstream message processor, then the generated or combined by an upstream message processor, then the
recipient MUST either reject the message as invalid or replace the recipient MUST either reject the message as invalid or replace the
duplicated field-values with a single valid Content-Length field duplicated field-values with a single valid Content-Length field
containing that decimal value prior to determining the message body containing that decimal value prior to determining the message body
skipping to change at page 54, line 21 skipping to change at page 57, line 32
(Partial Content) status code). (Partial Content) status code).
Header fields that specifically describe the payload, rather than the Header fields that specifically describe the payload, rather than the
associated representation, are referred to as "payload header associated representation, are referred to as "payload header
fields". Payload header fields are defined in other parts of this fields". Payload header fields are defined in other parts of this
specification, due to their impact on message parsing. specification, due to their impact on message parsing.
+-------------------+----------------------------+ +-------------------+----------------------------+
| Header Field Name | Defined in... | | Header Field Name | Defined in... |
+-------------------+----------------------------+ +-------------------+----------------------------+
| Content-Range | Section 6.3.3 | | Content-Range | Section 6.3.4 |
| Trailer | Section 4.4 | | Trailer | Section 4.3.3 |
| Transfer-Encoding | Section 6.1 of [Messaging] | | Transfer-Encoding | Section 6.1 of [Messaging] |
+-------------------+----------------------------+ +-------------------+----------------------------+
6.3.1. Purpose 6.3.1. Purpose
The purpose of a payload in a request is defined by the method The purpose of a payload in a request is defined by the method
semantics. For example, a representation in the payload of a PUT semantics. For example, a representation in the payload of a PUT
request (Section 7.3.4) represents the desired state of the target request (Section 7.3.4) represents the desired state of the target
resource if the request is successfully applied, whereas a resource if the request is successfully applied, whereas a
representation in the payload of a POST request (Section 7.3.3) representation in the payload of a POST request (Section 7.3.3)
skipping to change at page 55, line 44 skipping to change at page 59, line 9
4. If the response has a Content-Location header field and its 4. If the response has a Content-Location header field and its
field-value is a reference to a URI different from the effective field-value is a reference to a URI different from the effective
request URI, then the sender asserts that the payload is a request URI, then the sender asserts that the payload is a
representation of the resource identified by the Content-Location representation of the resource identified by the Content-Location
field-value. However, such an assertion cannot be trusted unless field-value. However, such an assertion cannot be trusted unless
it can be verified by other means (not defined by this it can be verified by other means (not defined by this
specification). specification).
5. Otherwise, the payload is unidentified. 5. Otherwise, the payload is unidentified.
6.3.3. Content-Range 6.3.3. Payload Body
The payload body contains the data of a request or response. This is
distinct from the message body (e.g., Section 6 of [Messaging]),
which is how the payload body is transferred "on the wire", and might
be encoded, depending on the HTTP version in use.
It is also distinct from a request or response's representation data
(Section 6.1), which can be inferred from protocol operation, rather
than necessarily appearing "on the wire."
The presence of a payload body in a request depends on whether the
request method used defines semantics for it.
The presence of a payload body in a response depends on both the
request method to which it is responding and the response status code
(Section 9).
Responses to the HEAD request method (Section 7.3.2) never include a
payload body because the associated response header fields indicate
only what their values would have been if the request method had been
GET (Section 7.3.1).
2xx (Successful) responses to a CONNECT request method
(Section 7.3.6) switch the connection to tunnel mode instead of
having a payload body.
All 1xx (Informational), 204 (No Content), and 304 (Not Modified)
responses do not include a payload body.
All other responses do include a payload body, although that body
might be of zero length.
6.3.4. Content-Range
The "Content-Range" header field is sent in a single part 206 The "Content-Range" header field is sent in a single part 206
(Partial Content) response to indicate the partial range of the (Partial Content) response to indicate the partial range of the
selected representation enclosed as the message payload, sent in each selected representation enclosed as the message payload, sent in each
part of a multipart 206 response to indicate the range enclosed part of a multipart 206 response to indicate the range enclosed
within each body part, and sent in 416 (Range Not Satisfiable) within each body part, and sent in 416 (Range Not Satisfiable)
responses to provide information about the selected representation. responses to provide information about the selected representation.
Content-Range = byte-content-range Content-Range = range-unit SP
/ other-content-range ( range-resp / unsatisfied-range )
byte-content-range = bytes-unit SP
( byte-range-resp / unsatisfied-range )
byte-range-resp = byte-range "/" ( complete-length / "*" ) range-resp = incl-range "/" ( complete-length / "*" )
byte-range = first-byte-pos "-" last-byte-pos incl-range = first-pos "-" last-pos
unsatisfied-range = "*/" complete-length unsatisfied-range = "*/" complete-length
complete-length = 1*DIGIT complete-length = 1*DIGIT
other-content-range = other-range-unit SP other-range-resp
other-range-resp = *VCHAR
If a 206 (Partial Content) response contains a Content-Range header If a 206 (Partial Content) response contains a Content-Range header
field with a range unit (Section 6.1.4) that the recipient does not field with a range unit (Section 6.1.4) that the recipient does not
understand, the recipient MUST NOT attempt to recombine it with a understand, the recipient MUST NOT attempt to recombine it with a
stored representation. A proxy that receives such a message SHOULD stored representation. A proxy that receives such a message SHOULD
forward it downstream. forward it downstream.
For byte ranges, a sender SHOULD indicate the complete length of the For byte ranges, a sender SHOULD indicate the complete length of the
representation from which the range has been extracted, unless the representation from which the range has been extracted, unless the
complete length is unknown or difficult to determine. An asterisk complete length is unknown or difficult to determine. An asterisk
character ("*") in place of the complete-length indicates that the character ("*") in place of the complete-length indicates that the
skipping to change at page 56, line 43 skipping to change at page 60, line 37
The following example illustrates when the complete length of the The following example illustrates when the complete length of the
selected representation is known by the sender to be 1234 bytes: selected representation is known by the sender to be 1234 bytes:
Content-Range: bytes 42-1233/1234 Content-Range: bytes 42-1233/1234
and this second example illustrates when the complete length is and this second example illustrates when the complete length is
unknown: unknown:
Content-Range: bytes 42-1233/* Content-Range: bytes 42-1233/*
A Content-Range field value is invalid if it contains a byte-range- A Content-Range field value is invalid if it contains a range-resp
resp that has a last-byte-pos value less than its first-byte-pos that has a last-pos value less than its first-pos value, or a
value, or a complete-length value less than or equal to its last- complete-length value less than or equal to its last-pos value. The
byte-pos value. The recipient of an invalid Content-Range MUST NOT recipient of an invalid Content-Range MUST NOT attempt to recombine
attempt to recombine the received content with a stored the received content with a stored representation.
representation.
A server generating a 416 (Range Not Satisfiable) response to a byte- A server generating a 416 (Range Not Satisfiable) response to a byte-
range request SHOULD send a Content-Range header field with an range request SHOULD send a Content-Range header field with an
unsatisfied-range value, as in the following example: unsatisfied-range value, as in the following example:
Content-Range: bytes */1234 Content-Range: bytes */1234
The complete-length in a 416 response indicates the current length of The complete-length in a 416 response indicates the current length of
the selected representation. the selected representation.
skipping to change at page 57, line 34 skipping to change at page 61, line 29
Content-Range: bytes 500-999/1234 Content-Range: bytes 500-999/1234
o All except for the first 500 bytes: o All except for the first 500 bytes:
Content-Range: bytes 500-1233/1234 Content-Range: bytes 500-1233/1234
o The last 500 bytes: o The last 500 bytes:
Content-Range: bytes 734-1233/1234 Content-Range: bytes 734-1233/1234
6.3.4. Media Type multipart/byteranges 6.3.5. Media Type multipart/byteranges
When a 206 (Partial Content) response message includes the content of When a 206 (Partial Content) response message includes the content of
multiple ranges, they are transmitted as body parts in a multipart multiple ranges, they are transmitted as body parts in a multipart
message body ([RFC2046], Section 5.1) with the media type of message body ([RFC2046], Section 5.1) with the media type of
"multipart/byteranges". "multipart/byteranges".
The multipart/byteranges media type includes one or more body parts, The multipart/byteranges media type includes one or more body parts,
each with its own Content-Type and Content-Range fields. The each with its own Content-Type and Content-Range fields. The
required boundary parameter specifies the boundary string used to required boundary parameter specifies the boundary string used to
separate each body part. separate each body part.
skipping to change at page 59, line 4 skipping to change at page 62, line 46
The following information serves as the registration form for the The following information serves as the registration form for the
multipart/byteranges media type. multipart/byteranges media type.
Type name: multipart Type name: multipart
Subtype name: byteranges Subtype name: byteranges
Required parameters: boundary Required parameters: boundary
Optional parameters: N/A Optional parameters: N/A
Encoding considerations: only "7bit", "8bit", or "binary" are Encoding considerations: only "7bit", "8bit", or "binary" are
permitted permitted
Security considerations: see Section 12 Security considerations: see Section 13
Interoperability considerations: N/A Interoperability considerations: N/A
Published specification: This specification (see Section 6.3.5).
Published specification: This specification (see Section 6.3.4).
Applications that use this media type: HTTP components supporting Applications that use this media type: HTTP components supporting
multiple ranges in a single request. multiple ranges in a single request.
Fragment identifier considerations: N/A Fragment identifier considerations: N/A
Additional information: Additional information:
Deprecated alias names for this type: N/A Deprecated alias names for this type: N/A
skipping to change at page 65, line 44 skipping to change at page 69, line 44
Idempotent methods are distinguished because the request can be Idempotent methods are distinguished because the request can be
repeated automatically if a communication failure occurs before the repeated automatically if a communication failure occurs before the
client is able to read the server's response. For example, if a client is able to read the server's response. For example, if a
client sends a PUT request and the underlying connection is closed client sends a PUT request and the underlying connection is closed
before any response is received, then the client can establish a new before any response is received, then the client can establish a new
connection and retry the idempotent request. It knows that repeating connection and retry the idempotent request. It knows that repeating
the request will have the same intended effect, even if the original the request will have the same intended effect, even if the original
request succeeded, though the response might differ. request succeeded, though the response might differ.
A user agent MUST NOT automatically retry a request with a non- A client SHOULD NOT automatically retry a request with a non-
idempotent method unless it has some means to know that the request idempotent method unless it has some means to know that the request
semantics are actually idempotent, regardless of the method, or some semantics are actually idempotent, regardless of the method, or some
means to detect that the original request was never applied. For means to detect that the original request was never applied.
example, a user agent that knows (through design or configuration)
that a POST request to a given resource is safe can repeat that
request automatically. Likewise, a user agent designed specifically
to operate on a version control repository might be able to recover
from partial failure conditions by checking the target resource
revision(s) after a failed connection, reverting or fixing any
changes that were partially applied, and then automatically retrying
the requests that failed.
A proxy MUST NOT automatically retry non-idempotent requests. For example, a user agent that knows (through design or
configuration) that a POST request to a given resource is safe can
repeat that request automatically. Likewise, a user agent designed
specifically to operate on a version control repository might be able
to recover from partial failure conditions by checking the target
resource revision(s) after a failed connection, reverting or fixing
any changes that were partially applied, and then automatically
retrying the requests that failed.
A client SHOULD NOT automatically retry a failed automatic retry. Some clients use weaker signals to initiate automatic retries. For
example, when a POST request is sent, but the underlying transport
connection is closed before any part of the response is received.
Although this is commonly implemented, it is not recommended.
7.2.3. Cacheable Methods A proxy MUST NOT automatically retry non-idempotent requests. A
client SHOULD NOT automatically retry a failed automatic retry.
Request methods can be defined as "cacheable" to indicate that 7.2.3. Methods and Caching
responses to them are allowed to be stored for future reuse; for
specific requirements see [Caching]. In general, safe methods that For a cache to store and use a response, the associated method needs
do not depend on a current or authoritative response are defined as to explicitly allow caching, and detail under what conditions a
cacheable; this specification defines GET, HEAD, and POST as response can be used to satisfy subsequent requests; a method
cacheable, although the overwhelming majority of cache definition which does not do so cannot be cached. For additional
implementations only support GET and HEAD. requirements see [Caching].
This specification defines caching semantics for GET, HEAD, and POST,
although the overwhelming majority of cache implementations only
support GET and HEAD.
7.3. Method Definitions 7.3. Method Definitions
7.3.1. GET 7.3.1. GET
The GET method requests transfer of a current selected representation The GET method requests transfer of a current selected representation
for the target resource. GET is the primary mechanism of information for the target resource. GET is the primary mechanism of information
retrieval and the focus of almost all performance optimizations. retrieval and the focus of almost all performance optimizations.
Hence, when people speak of retrieving some identifiable information Hence, when people speak of retrieving some identifiable information
via HTTP, they are generally referring to making a GET request. via HTTP, they are generally referring to making a GET request.
It is tempting to think of resource identifiers as remote file system It is tempting to think of resource identifiers as remote file system
pathnames and of representations as being a copy of the contents of pathnames and of representations as being a copy of the contents of
such files. In fact, that is how many resources are implemented (see such files. In fact, that is how many resources are implemented (see
Section 12.3 for related security considerations). However, there Section 13.3 for related security considerations). However, there
are no such limitations in practice. The HTTP interface for a are no such limitations in practice. The HTTP interface for a
resource is just as likely to be implemented as a tree of content resource is just as likely to be implemented as a tree of content
objects, a programmatic view on various database records, or a objects, a programmatic view on various database records, or a
gateway to other information systems. Even when the URI mapping gateway to other information systems. Even when the URI mapping
mechanism is tied to a file system, an origin server might be mechanism is tied to a file system, an origin server might be
configured to execute the files with the request as input and send configured to execute the files with the request as input and send
the output as the representation rather than transfer the files the output as the representation rather than transfer the files
directly. Regardless, only the origin server needs to know how each directly. Regardless, only the origin server needs to know how each
of its resource identifiers corresponds to an implementation and how of its resource identifiers corresponds to an implementation and how
each implementation manages to select and send a current each implementation manages to select and send a current
representation of the target resource in a response to GET. representation of the target resource in a response to GET.
A client can alter the semantics of GET to be a "range request", A client can alter the semantics of GET to be a "range request",
requesting transfer of only some part(s) of the selected requesting transfer of only some part(s) of the selected
representation, by sending a Range header field in the request representation, by sending a Range header field in the request
(Section 8.3). (Section 8.3).
A payload within a GET request message has no defined semantics; The GET method is specifically intended to reflect the quality of
sending a payload body on a GET request might cause some existing "sameness" identified by the request URI as if it were referenced as
implementations to reject the request. an ordinary hypertext link. A client SHOULD NOT generate a body in a
GET request. A payload received in a GET request has no defined
semantics, cannot alter the meaning or target of the request, and
might lead some implementations to reject the request and close the
connection because of its potential as a request smuggling attack
(Section 11.2 of [Messaging]).
The response to a GET request is cacheable; a cache MAY use it to The response to a GET request is cacheable; a cache MAY use it to
satisfy subsequent GET and HEAD requests unless otherwise indicated satisfy subsequent GET and HEAD requests unless otherwise indicated
by the Cache-Control header field (Section 5.2 of [Caching]). by the Cache-Control header field (Section 5.2 of [Caching]). A
cache that receives a payload in a GET request is likely to ignore
that payload and cache regardless of the payload contents.
7.3.2. HEAD 7.3.2. HEAD
The HEAD method is identical to GET except that the server MUST NOT The HEAD method is identical to GET except that the server MUST NOT
send a message body in the response (i.e., the response terminates at send a message body in the response (i.e., the response terminates at
the end of the header section). The server SHOULD send the same the end of the header section). The server SHOULD send the same
header fields in response to a HEAD request as it would have sent if header fields in response to a HEAD request as it would have sent if
the request had been a GET, except that the payload header fields the request had been a GET, except that the payload header fields
(Section 6.3) MAY be omitted. This method can be used for obtaining (Section 6.3) MAY be omitted. This method can be used for obtaining
metadata about the selected representation without transferring the metadata about the selected representation without transferring the
skipping to change at page 70, line 50 skipping to change at page 75, line 20
identifying "the current version" (a resource) that is separate from identifying "the current version" (a resource) that is separate from
the URIs identifying each particular version (different resources the URIs identifying each particular version (different resources
that at one point shared the same state as the current version that at one point shared the same state as the current version
resource). A successful PUT request on "the current version" URI resource). A successful PUT request on "the current version" URI
might therefore create a new version resource in addition to changing might therefore create a new version resource in addition to changing
the state of the target resource, and might also cause links to be the state of the target resource, and might also cause links to be
added between the related resources. added between the related resources.
An origin server that allows PUT on a given target resource MUST send An origin server that allows PUT on a given target resource MUST send
a 400 (Bad Request) response to a PUT request that contains a a 400 (Bad Request) response to a PUT request that contains a
Content-Range header field (Section 6.3.3), since the payload is Content-Range header field (Section 6.3.4), since the payload is
likely to be partial content that has been mistakenly PUT as a full likely to be partial content that has been mistakenly PUT as a full
representation. Partial content updates are possible by targeting a representation. Partial content updates are possible by targeting a
separately identified resource with state that overlaps a portion of separately identified resource with state that overlaps a portion of
the larger resource, or by using a different method that has been the larger resource, or by using a different method that has been
specifically defined for partial updates (for example, the PATCH specifically defined for partial updates (for example, the PATCH
method defined in [RFC5789]). method defined in [RFC5789]).
Responses to the PUT method are not cacheable. If a successful PUT Responses to the PUT method are not cacheable. If a successful PUT
request passes through a cache that has one or more stored responses request passes through a cache that has one or more stored responses
for the effective request URI, those stored responses will be for the effective request URI, those stored responses will be
skipping to change at page 72, line 28 skipping to change at page 76, line 46
be invalidated (see Section 4.4 of [Caching]). be invalidated (see Section 4.4 of [Caching]).
7.3.6. CONNECT 7.3.6. CONNECT
The CONNECT method requests that the recipient establish a tunnel to The CONNECT method requests that the recipient establish a tunnel to
the destination origin server identified by the request-target and, the destination origin server identified by the request-target and,
if successful, thereafter restrict its behavior to blind forwarding if successful, thereafter restrict its behavior to blind forwarding
of packets, in both directions, until the tunnel is closed. Tunnels of packets, in both directions, until the tunnel is closed. Tunnels
are commonly used to create an end-to-end virtual connection, through are commonly used to create an end-to-end virtual connection, through
one or more proxies, which can then be secured using TLS (Transport one or more proxies, which can then be secured using TLS (Transport
Layer Security, [RFC5246]). Layer Security, [RFC8446]).
CONNECT is intended only for use in requests to a proxy. An origin CONNECT is intended only for use in requests to a proxy. An origin
server that receives a CONNECT request for itself MAY respond with a server that receives a CONNECT request for itself MAY respond with a
2xx (Successful) status code to indicate that a connection is 2xx (Successful) status code to indicate that a connection is
established. However, most origin servers do not implement CONNECT. established. However, most origin servers do not implement CONNECT.
A client sending a CONNECT request MUST send the authority form of A client sending a CONNECT request MUST send the authority form of
request-target (Section 3.2 of [Messaging]); i.e., the request-target request-target (Section 3.2 of [Messaging]); i.e., the request-target
consists of only the host name and port number of the tunnel consists of only the host name and port number of the tunnel
destination, separated by a colon. For example, destination, separated by a colon. For example,
skipping to change at page 74, line 21 skipping to change at page 78, line 39
to the options that are available when communicating with the target to the options that are available when communicating with the target
resource. resource.
A server generating a successful response to OPTIONS SHOULD send any A server generating a successful response to OPTIONS SHOULD send any
header fields that might indicate optional features implemented by header fields that might indicate optional features implemented by
the server and applicable to the target resource (e.g., Allow), the server and applicable to the target resource (e.g., Allow),
including potential extensions not defined by this specification. including potential extensions not defined by this specification.
The response payload, if any, might also describe the communication The response payload, if any, might also describe the communication
options in a machine or human-readable representation. A standard options in a machine or human-readable representation. A standard
format for such a representation is not defined by this format for such a representation is not defined by this
specification, but might be defined by future extensions to HTTP. A specification, but might be defined by future extensions to HTTP.
server MUST generate a Content-Length field with a value of "0" if no
payload body is to be sent in the response.
A client MAY send a Max-Forwards header field in an OPTIONS request A client MAY send a Max-Forwards header field in an OPTIONS request
to target a specific recipient in the request chain (see to target a specific recipient in the request chain (see
Section 8.1.2). A proxy MUST NOT generate a Max-Forwards header Section 8.1.2). A proxy MUST NOT generate a Max-Forwards header
field while forwarding a request unless that request was received field while forwarding a request unless that request was received
with a Max-Forwards field. with a Max-Forwards field.
A client that generates an OPTIONS request containing a payload body A client that generates an OPTIONS request containing a payload body
MUST send a valid Content-Type header field describing the MUST send a valid Content-Type header field describing the
representation media type. Note that this specification does not representation media type. Note that this specification does not
skipping to change at page 90, line 12 skipping to change at page 94, line 16
"earlier than or equal to" comparison used when evaluating an If- "earlier than or equal to" comparison used when evaluating an If-
Unmodified-Since conditional. Unmodified-Since conditional.
8.3. Range 8.3. Range
The "Range" header field on a GET request modifies the method The "Range" header field on a GET request modifies the method
semantics to request transfer of only one or more subranges of the semantics to request transfer of only one or more subranges of the
selected representation data, rather than the entire selected selected representation data, rather than the entire selected
representation data. representation data.
Range = byte-ranges-specifier / other-ranges-specifier Range = ranges-specifier
other-ranges-specifier = other-range-unit "=" other-range-set
other-range-set = 1*VCHAR
Clients often encounter interrupted data transfers as a result of Clients often encounter interrupted data transfers as a result of
canceled requests or dropped connections. When a client has stored a canceled requests or dropped connections. When a client has stored a
partial representation, it is desirable to request the remainder of partial representation, it is desirable to request the remainder of
that representation in a subsequent request rather than transfer the that representation in a subsequent request rather than transfer the
entire representation. Likewise, devices with limited local storage entire representation. Likewise, devices with limited local storage
might benefit from being able to request only a subset of a larger might benefit from being able to request only a subset of a larger
representation, such as a single page of a very large document, or representation, such as a single page of a very large document, or
the dimensions of an embedded image. the dimensions of an embedded image.
Range requests are an OPTIONAL feature of HTTP, designed so that Range requests are an OPTIONAL feature of HTTP, designed so that
recipients not implementing this feature (or not supporting it for recipients not implementing this feature (or not supporting it for
the target resource) can respond as if it is a normal GET request the target resource) can respond as if it is a normal GET request
without impacting interoperability. Partial responses are indicated without impacting interoperability. Partial responses are indicated
by a distinct status code to not be mistaken for full responses by by a distinct status code to not be mistaken for full responses by
caches that might not implement the feature. caches that might not implement the feature.
A server MAY ignore the Range header field. However, origin servers A server MAY ignore the Range header field. However, origin servers
and intermediate caches ought to support byte ranges when possible, and intermediate caches ought to support byte ranges when possible,
since Range supports efficient recovery from partially failed since they support efficient recovery from partially failed transfers
transfers and partial retrieval of large representations. A server and partial retrieval of large representations. A server MUST ignore
MUST ignore a Range header field received with a request method other a Range header field received with a request method other than GET.
than GET.
Although the range request mechanism is designed to allow for Although the range request mechanism is designed to allow for
extensible range types, this specification only defines requests for extensible range types, this specification only defines requests for
byte ranges. byte ranges.
An origin server MUST ignore a Range header field that contains a An origin server MUST ignore a Range header field that contains a
range unit it does not understand. A proxy MAY discard a Range range unit it does not understand. A proxy MAY discard a Range
header field that contains a range unit it does not understand. header field that contains a range unit it does not understand.
A server that supports range requests MAY ignore or reject a Range A server that supports range requests MAY ignore or reject a Range
header field that consists of more than two overlapping ranges, or a header field that consists of more than two overlapping ranges, or a
set of many small ranges that are not listed in ascending order, set of many small ranges that are not listed in ascending order,
since both are indications of either a broken client or a deliberate since both are indications of either a broken client or a deliberate
denial-of-service attack (Section 12.13). A client SHOULD NOT denial-of-service attack (Section 13.13). A client SHOULD NOT
request multiple ranges that are inherently less efficient to process request multiple ranges that are inherently less efficient to process
and transfer than a single range that encompasses the same data. and transfer than a single range that encompasses the same data.
A client that is requesting multiple ranges SHOULD list those ranges A client that is requesting multiple ranges SHOULD list those ranges
in ascending order (the order in which they would typically be in ascending order (the order in which they would typically be
received in a complete representation) unless there is a specific received in a complete representation) unless there is a specific
need to request a later part earlier. For example, a user agent need to request a later part earlier. For example, a user agent
processing a large representation with an internal catalog of parts processing a large representation with an internal catalog of parts
might need to request later parts first, particularly if the might need to request later parts first, particularly if the
representation consists of pages stored in reverse order and the user representation consists of pages stored in reverse order and the user
skipping to change at page 91, line 27 skipping to change at page 95, line 28
header fields defined in Section 8.2, and only if the result in header fields defined in Section 8.2, and only if the result in
absence of the Range header field would be a 200 (OK) response. In absence of the Range header field would be a 200 (OK) response. In
other words, Range is ignored when a conditional GET would result in other words, Range is ignored when a conditional GET would result in
a 304 (Not Modified) response. a 304 (Not Modified) response.
The If-Range header field (Section 8.2.7) can be used as a The If-Range header field (Section 8.2.7) can be used as a
precondition to applying the Range header field. precondition to applying the Range header field.
If all of the preconditions are true, the server supports the Range If all of the preconditions are true, the server supports the Range
header field for the target resource, and the specified range(s) are header field for the target resource, and the specified range(s) are
valid and satisfiable (as defined in Section 6.1.4.1), the server valid and satisfiable (as defined in Section 6.1.4.2), the server
SHOULD send a 206 (Partial Content) response with a payload SHOULD send a 206 (Partial Content) response with a payload
containing one or more partial representations that correspond to the containing one or more partial representations that correspond to the
satisfiable ranges requested. satisfiable ranges requested.
If all of the preconditions are true, the server supports the Range If all of the preconditions are true, the server supports the Range
header field for the target resource, and the specified range(s) are header field for the target resource, and the specified range(s) are
invalid or unsatisfiable, the server SHOULD send a 416 (Range Not invalid or unsatisfiable, the server SHOULD send a 416 (Range Not
Satisfiable) response. Satisfiable) response.
8.4. Content Negotiation 8.4. Content Negotiation
skipping to change at page 92, line 27 skipping to change at page 96, line 27
the available representations for the response can be considered the available representations for the response can be considered
acceptable according to it, the origin server can either honor the acceptable according to it, the origin server can either honor the
header field by sending a 406 (Not Acceptable) response or disregard header field by sending a 406 (Not Acceptable) response or disregard
the header field by treating the response as if it is not subject to the header field by treating the response as if it is not subject to
content negotiation for that request header field. This does not content negotiation for that request header field. This does not
imply, however, that the client will be able to use the imply, however, that the client will be able to use the
representation. representation.
Note: Sending these header fields makes it easier for a server to Note: Sending these header fields makes it easier for a server to
identify an individual by virtue of the user agent's request identify an individual by virtue of the user agent's request
characteristics (Section 12.11). characteristics (Section 13.11).
Each of these header fields defines a wildcard value (often, "*") to Each of these header fields defines a wildcard value (often, "*") to
select unspecified values. If no wildcard is present, all values not select unspecified values. If no wildcard is present, all values not
explicitly mentioned in the field are considered "not acceptable" to explicitly mentioned in the field are considered "not acceptable" to
the client. the client.
Note: In practice, using wildcards in content negotiation has limited Note: In practice, using wildcards in content negotiation has limited
practical value, because it is seldom useful to say, for example, "I practical value, because it is seldom useful to say, for example, "I
prefer image/* more or less than (some other specific value)". prefer image/* more or less than (some other specific value)".
Clients can explicitly request a 406 (Not Acceptable) response if a Clients can explicitly request a 406 (Not Acceptable) response if a
skipping to change at page 95, line 46 skipping to change at page 99, line 46
Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
The special value "*", if present in the Accept-Charset field, The special value "*", if present in the Accept-Charset field,
matches every charset that is not mentioned elsewhere in the Accept- matches every charset that is not mentioned elsewhere in the Accept-
Charset field. Charset field.
Note: Accept-Charset is deprecated because UTF-8 has become nearly Note: Accept-Charset is deprecated because UTF-8 has become nearly
ubiquitous and sending a detailed list of user-preferred charsets ubiquitous and sending a detailed list of user-preferred charsets
wastes bandwidth, increases latency, and makes passive fingerprinting wastes bandwidth, increases latency, and makes passive fingerprinting
far too easy (Section 12.11). Most general-purpose user agents do far too easy (Section 13.11). Most general-purpose user agents do
not send Accept-Charset, unless specifically configured to do so. not send Accept-Charset, unless specifically configured to do so.
8.4.4. Accept-Encoding 8.4.4. Accept-Encoding
The "Accept-Encoding" header field can be used by user agents to The "Accept-Encoding" header field can be used by user agents to
indicate their preferences regarding response content-codings indicate their preferences regarding response content-codings
(Section 6.1.2). An "identity" token is used as a synonym for "no (Section 6.1.2). An "identity" token is used as a synonym for "no
encoding" in order to communicate when no encoding is preferred. encoding" in order to communicate when no encoding is preferred.
Accept-Encoding = #( codings [ weight ] ) Accept-Encoding = #( codings [ weight ] )
skipping to change at page 97, line 47 skipping to change at page 101, line 47
found in Section 2.3 of [RFC4647]. found in Section 2.3 of [RFC4647].
For matching, Section 3 of [RFC4647] defines several matching For matching, Section 3 of [RFC4647] defines several matching
schemes. Implementations can offer the most appropriate matching schemes. Implementations can offer the most appropriate matching
scheme for their requirements. The "Basic Filtering" scheme scheme for their requirements. The "Basic Filtering" scheme
([RFC4647], Section 3.3.1) is identical to the matching scheme that ([RFC4647], Section 3.3.1) is identical to the matching scheme that
was previously defined for HTTP in Section 14.4 of [RFC2616]. was previously defined for HTTP in Section 14.4 of [RFC2616].
It might be contrary to the privacy expectations of the user to send It might be contrary to the privacy expectations of the user to send
an Accept-Language header field with the complete linguistic an Accept-Language header field with the complete linguistic
preferences of the user in every request (Section 12.11). preferences of the user in every request (Section 13.11).
Since intelligibility is highly dependent on the individual user, Since intelligibility is highly dependent on the individual user,
user agents need to allow user control over the linguistic preference user agents need to allow user control over the linguistic preference
(either through configuration of the user agent itself or by (either through configuration of the user agent itself or by
defaulting to a user controllable system setting). A user agent that defaulting to a user controllable system setting). A user agent that
does not provide such control to the user MUST NOT send an Accept- does not provide such control to the user MUST NOT send an Accept-
Language header field. Language header field.
Note: User agents ought to provide guidance to users when setting Note: User agents ought to provide guidance to users when setting
a preference, since users are rarely familiar with the details of a preference, since users are rarely familiar with the details of
skipping to change at page 100, line 5 skipping to change at page 104, line 5
Both the Authorization field value and the Proxy-Authorization field Both the Authorization field value and the Proxy-Authorization field
value contain the client's credentials for the realm of the resource value contain the client's credentials for the realm of the resource
being requested, based upon a challenge received in a response being requested, based upon a challenge received in a response
(possibly at some point in the past). When creating their values, (possibly at some point in the past). When creating their values,
the user agent ought to do so by selecting the challenge with what it the user agent ought to do so by selecting the challenge with what it
considers to be the most secure auth-scheme that it understands, considers to be the most secure auth-scheme that it understands,
obtaining credentials from the user as appropriate. Transmission of obtaining credentials from the user as appropriate. Transmission of
credentials within header field values implies significant security credentials within header field values implies significant security
considerations regarding the confidentiality of the underlying considerations regarding the confidentiality of the underlying
connection, as described in Section 12.14.1. connection, as described in Section 13.14.1.
credentials = auth-scheme [ 1*SP ( token68 / #auth-param ) ] credentials = auth-scheme [ 1*SP ( token68 / #auth-param ) ]
Upon receipt of a request for a protected resource that omits Upon receipt of a request for a protected resource that omits
credentials, contains invalid credentials (e.g., a bad password) or credentials, contains invalid credentials (e.g., a bad password) or
partial credentials (e.g., when the authentication scheme requires partial credentials (e.g., when the authentication scheme requires
more than one round trip), an origin server SHOULD send a 401 more than one round trip), an origin server SHOULD send a 401
(Unauthorized) response that contains a WWW-Authenticate header field (Unauthorized) response that contains a WWW-Authenticate header field
with at least one (possibly new) challenge applicable to the with at least one (possibly new) challenge applicable to the
requested resource. requested resource.
skipping to change at page 104, line 16 skipping to change at page 108, line 16
Therefore, new authentication schemes that choose not to carry Therefore, new authentication schemes that choose not to carry
credentials in the Authorization header field (e.g., using a newly credentials in the Authorization header field (e.g., using a newly
defined header field) will need to explicitly disallow caching, by defined header field) will need to explicitly disallow caching, by
mandating the use of Cache-Control response directives (e.g., mandating the use of Cache-Control response directives (e.g.,
"private"). "private").
o Schemes using Authentication-Info, Proxy-Authentication-Info, or o Schemes using Authentication-Info, Proxy-Authentication-Info, or
any other authentication related response header field need to any other authentication related response header field need to
consider and document the related security considerations (see consider and document the related security considerations (see
Section 12.14.4). Section 13.14.4).
8.6. Request Context 8.6. Request Context
The following request header fields provide additional information The following request header fields provide additional information
about the request context, including information about the user, user about the request context, including information about the user, user
agent, and resource behind the request. agent, and resource behind the request.
+-------------------+---------------+ +-------------------+---------------+
| Header Field Name | Defined in... | | Header Field Name | Defined in... |
+-------------------+---------------+ +-------------------+---------------+
skipping to change at page 106, line 7 skipping to change at page 110, line 7
The Referer field has the potential to reveal information about the The Referer field has the potential to reveal information about the
request context or browsing history of the user, which is a privacy request context or browsing history of the user, which is a privacy
concern if the referring resource's identifier reveals personal concern if the referring resource's identifier reveals personal
information (such as an account name) or a resource that is supposed information (such as an account name) or a resource that is supposed
to be confidential (such as behind a firewall or internal to a to be confidential (such as behind a firewall or internal to a
secured service). Most general-purpose user agents do not send the secured service). Most general-purpose user agents do not send the
Referer header field when the referring resource is a local "file" or Referer header field when the referring resource is a local "file" or
"data" URI. A user agent MUST NOT send a Referer header field in an "data" URI. A user agent MUST NOT send a Referer header field in an
unsecured HTTP request if the referring page was received with a unsecured HTTP request if the referring page was received with a
secure protocol. See Section 12.8 for additional security secure protocol. See Section 13.8 for additional security
considerations. considerations.
Some intermediaries have been known to indiscriminately remove Some intermediaries have been known to indiscriminately remove
Referer header fields from outgoing requests. This has the Referer header fields from outgoing requests. This has the
unfortunate side effect of interfering with protection against CSRF unfortunate side effect of interfering with protection against CSRF
attacks, which can be far more harmful to their users. attacks, which can be far more harmful to their users.
Intermediaries and user agent extensions that wish to limit Intermediaries and user agent extensions that wish to limit
information disclosure in Referer ought to restrict their changes to information disclosure in Referer ought to restrict their changes to
specific edits, such as replacing internal domain names with specific edits, such as replacing internal domain names with
pseudonyms or truncating the query and/or path components. An pseudonyms or truncating the query and/or path components. An
skipping to change at page 106, line 35 skipping to change at page 110, line 35
agent originating the request, which is often used by servers to help agent originating the request, which is often used by servers to help
identify the scope of reported interoperability problems, to work identify the scope of reported interoperability problems, to work
around or tailor responses to avoid particular user agent around or tailor responses to avoid particular user agent
limitations, and for analytics regarding browser or operating system limitations, and for analytics regarding browser or operating system
use. A user agent SHOULD send a User-Agent field in each request use. A user agent SHOULD send a User-Agent field in each request
unless specifically configured not to do so. unless specifically configured not to do so.
User-Agent = product *( RWS ( product / comment ) ) User-Agent = product *( RWS ( product / comment ) )
The User-Agent field-value consists of one or more product The User-Agent field-value consists of one or more product
identifiers, each followed by zero or more comments (Section 5 of identifiers, each followed by zero or more comments
[Messaging]), which together identify the user agent software and its (Section 4.2.3.3), which together identify the user agent software
significant subproducts. By convention, the product identifiers are and its significant subproducts. By convention, the product
listed in decreasing order of their significance for identifying the identifiers are listed in decreasing order of their significance for
user agent software. Each product identifier consists of a name and identifying the user agent software. Each product identifier
optional version. consists of a name and optional version.
product = token ["/" product-version] product = token ["/" product-version]
product-version = token product-version = token
A sender SHOULD limit generated product identifiers to what is A sender SHOULD limit generated product identifiers to what is
necessary to identify the product; a sender MUST NOT generate necessary to identify the product; a sender MUST NOT generate
advertising or other nonessential information within the product advertising or other nonessential information within the product
identifier. A sender SHOULD NOT generate information in product- identifier. A sender SHOULD NOT generate information in product-
version that is not a version identifier (i.e., successive versions version that is not a version identifier (i.e., successive versions
of the same product name ought to differ only in the product-version of the same product name ought to differ only in the product-version
skipping to change at page 108, line 17 skipping to change at page 112, line 17
o 5xx (Server Error): The server failed to fulfill an apparently o 5xx (Server Error): The server failed to fulfill an apparently
valid request valid request
9.1. Overview of Status Codes 9.1. Overview of Status Codes
The status codes listed below are defined in this specification. The The status codes listed below are defined in this specification. The
reason phrases listed here are only recommendations -- they can be reason phrases listed here are only recommendations -- they can be
replaced by local equivalents without affecting the protocol. replaced by local equivalents without affecting the protocol.
Responses with status codes that are defined as cacheable by default Responses with status codes that are defined as heuristically
(e.g., 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, and 501 in cacheable (e.g., 200, 203, 204, 206, 300, 301, 404, 405, 410, 414,
this specification) can be reused by a cache with heuristic and 501 in this specification) can be reused by a cache with
expiration unless otherwise indicated by the method definition or heuristic expiration unless otherwise indicated by the method
explicit cache controls [Caching]; all other status codes are not definition or explicit cache controls [Caching]; all other status
cacheable by default. codes are not heuristically cacheable.
+-------+-------------------------------+-----------------+ +-------+-------------------------------+-----------------+
| Value | Description | Reference | | Value | Description | Reference |
+-------+-------------------------------+-----------------+ +-------+-------------------------------+-----------------+
| 100 | Continue | Section 9.2.1 | | 100 | Continue | Section 9.2.1 |
| 101 | Switching Protocols | Section 9.2.2 | | 101 | Switching Protocols | Section 9.2.2 |
| 200 | OK | Section 9.3.1 | | 200 | OK | Section 9.3.1 |
| 201 | Created | Section 9.3.2 | | 201 | Created | Section 9.3.2 |
| 202 | Accepted | Section 9.3.3 | | 202 | Accepted | Section 9.3.3 |
| 203 | Non-Authoritative Information | Section 9.3.4 | | 203 | Non-Authoritative Information | Section 9.3.4 |
skipping to change at page 110, line 26 skipping to change at page 114, line 26
discard the 100 response. discard the 100 response.
If the request did not contain an Expect header field containing the If the request did not contain an Expect header field containing the
100-continue expectation, the client can simply discard this interim 100-continue expectation, the client can simply discard this interim
response. response.
9.2.2. 101 Switching Protocols 9.2.2. 101 Switching Protocols
The 101 (Switching Protocols) status code indicates that the server The 101 (Switching Protocols) status code indicates that the server
understands and is willing to comply with the client's request, via understands and is willing to comply with the client's request, via
the Upgrade header field (Section 9.8 of [Messaging]), for a change the Upgrade header field (Section 9.9 of [Messaging]), for a change
in the application protocol being used on this connection. The in the application protocol being used on this connection. The
server MUST generate an Upgrade header field in the response that server MUST generate an Upgrade header field in the response that
indicates which protocol(s) will be switched to immediately after the indicates which protocol(s) will be switched to immediately after the
empty line that terminates the 101 response. empty line that terminates the 101 response.
It is assumed that the server will only agree to switch protocols It is assumed that the server will only agree to switch protocols
when it is advantageous to do so. For example, switching to a newer when it is advantageous to do so. For example, switching to a newer
version of HTTP might be advantageous over older versions, and version of HTTP might be advantageous over older versions, and
switching to a real-time, synchronous protocol might be advantageous switching to a real-time, synchronous protocol might be advantageous
when delivering resources that use such features. when delivering resources that use such features.
skipping to change at page 111, line 24 skipping to change at page 115, line 24
TRACE a representation of the request message as received by the end TRACE a representation of the request message as received by the end
server. server.
Aside from responses to CONNECT, a 200 response always has a payload, Aside from responses to CONNECT, a 200 response always has a payload,
though an origin server MAY generate a payload body of zero length. though an origin server MAY generate a payload body of zero length.
If no payload is desired, an origin server ought to send 204 (No If no payload is desired, an origin server ought to send 204 (No
Content) instead. For CONNECT, no payload is allowed because the Content) instead. For CONNECT, no payload is allowed because the
successful result is a tunnel, which begins immediately after the 200 successful result is a tunnel, which begins immediately after the 200
response header section. response header section.
A 200 response is cacheable by default; i.e., unless otherwise A 200 response is heuristically cacheable; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [Caching]). Section 4.2.2 of [Caching]).
9.3.2. 201 Created 9.3.2. 201 Created
The 201 (Created) status code indicates that the request has been The 201 (Created) status code indicates that the request has been
fulfilled and has resulted in one or more new resources being fulfilled and has resulted in one or more new resources being
created. The primary resource created by the request is identified created. The primary resource created by the request is identified
by either a Location header field in the response or, if no Location by either a Location header field in the response or, if no Location
field is received, by the effective request URI. field is received, by the effective request URI.
skipping to change at page 112, line 26 skipping to change at page 116, line 26
proxy (Section 5.5.2). This status code allows the proxy to notify proxy (Section 5.5.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 cacheable by default; i.e., unless otherwise A 203 response is heuristically cacheable; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [Caching]). Section 4.2.2 of [Caching]).
9.3.5. 204 No Content 9.3.5. 204 No Content
The 204 (No Content) status code indicates that the server has The 204 (No Content) status code indicates that the server has
successfully fulfilled the request and that there is no additional successfully fulfilled the request and that there is no additional
content to send in the response payload body. Metadata in the content to send in the response payload body. Metadata in the
response header fields refer to the target resource and its selected response header fields refer to the target resource and its selected
representation after the requested action was applied. representation after the requested action was applied.
skipping to change at page 113, line 14 skipping to change at page 117, line 14
For example, a 204 status code is commonly used with document editing For example, a 204 status code is commonly used with document editing
interfaces corresponding to a "save" action, such that the document interfaces corresponding to a "save" action, such that the document
being saved remains available to the user for editing. It is also being saved remains available to the user for editing. It is also
frequently used with interfaces that expect automated data transfers frequently used with interfaces that expect automated data transfers
to be prevalent, such as within distributed version control systems. to be prevalent, such as within distributed version control systems.
A 204 response is terminated by the first empty line after the header A 204 response is terminated by the first empty line after the header
fields because it cannot contain a message body. fields because it cannot contain a message body.
A 204 response is cacheable by default; i.e., unless otherwise A 204 response is heuristically cacheable; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [Caching]). Section 4.2.2 of [Caching]).
9.3.6. 205 Reset Content 9.3.6. 205 Reset Content
The 205 (Reset Content) status code indicates that the server has The 205 (Reset Content) status code indicates that the server has
fulfilled the request and desires that the user agent reset the fulfilled the request and desires that the user agent reset the
"document view", which caused the request to be sent, to its original "document view", which caused the request to be sent, to its original
state as received from the origin server. state as received from the origin server.
skipping to change at page 114, line 15 skipping to change at page 118, line 15
Content-Location, and Vary. Content-Location, and Vary.
If a 206 is generated in response to a request with an If-Range If a 206 is generated in response to a request with an If-Range
header field, the sender SHOULD NOT generate other representation header field, the sender SHOULD NOT generate other representation
header fields beyond those required, because the client is understood header fields beyond those required, because the client is understood
to already have a prior response containing those header fields. to already have a prior response containing those header fields.
Otherwise, the sender MUST generate all of the representation header Otherwise, the sender MUST generate all of the representation header
fields that would have been sent in a 200 (OK) response to the same fields that would have been sent in a 200 (OK) response to the same
request. request.
A 206 response is cacheable by default; i.e., unless otherwise A 206 response is heuristically cacheable; i.e., unless otherwise
indicated by explicit cache controls (see Section 4.2.2 of indicated by explicit cache controls (see Section 4.2.2 of
[Caching]). [Caching]).
9.3.7.1. Single Part 9.3.7.1. Single Part
If a single part is being transferred, the server generating the 206 If a single part is being transferred, the server generating the 206
response MUST generate a Content-Range header field, describing what response MUST generate a Content-Range header field, describing what
range of the selected representation is enclosed, and a payload range of the selected representation is enclosed, and a payload
consisting of the range. For example: consisting of the range. For example:
skipping to change at page 114, line 39 skipping to change at page 118, line 39
Content-Range: bytes 21010-47021/47022 Content-Range: bytes 21010-47021/47022
Content-Length: 26012 Content-Length: 26012
Content-Type: image/gif Content-Type: image/gif
... 26012 bytes of partial image data ... ... 26012 bytes of partial image data ...
9.3.7.2. Multiple Parts 9.3.7.2. Multiple Parts
If multiple parts are being transferred, the server generating the If multiple parts are being transferred, the server generating the
206 response MUST generate a "multipart/byteranges" payload, as 206 response MUST generate a "multipart/byteranges" payload, as
defined in Section 6.3.4, and a Content-Type header field containing defined in Section 6.3.5, and a Content-Type header field containing
the multipart/byteranges media type and its required boundary the multipart/byteranges media type and its required boundary
parameter. To avoid confusion with single-part responses, a server parameter. To avoid confusion with single-part responses, a server
MUST NOT generate a Content-Range header field in the HTTP header MUST NOT generate a Content-Range header field in the HTTP header
section of a multiple part response (this field will be sent in each section of a multiple part response (this field will be sent in each
part instead). part instead).
Within the header area of each body part in the multipart payload, Within the header area of each body part in the multipart payload,
the server MUST generate a Content-Range header field corresponding the server MUST generate a Content-Range header field corresponding
to the range being enclosed in that body part. If the selected to the range being enclosed in that body part. If the selected
representation would have had a Content-Type header field in a 200 representation would have had a Content-Type header field in a 200
skipping to change at page 115, line 26 skipping to change at page 119, line 26
--THIS_STRING_SEPARATES --THIS_STRING_SEPARATES
Content-Type: application/pdf Content-Type: application/pdf
Content-Range: bytes 7000-7999/8000 Content-Range: bytes 7000-7999/8000
...the second range ...the second range
--THIS_STRING_SEPARATES-- --THIS_STRING_SEPARATES--
When multiple ranges are requested, a server MAY coalesce any of the When multiple ranges are requested, a server MAY coalesce any of the
ranges that overlap, or that are separated by a gap that is smaller ranges that overlap, or that are separated by a gap that is smaller
than the overhead of sending multiple parts, regardless of the order than the overhead of sending multiple parts, regardless of the order
in which the corresponding byte-range-spec appeared in the received in which the corresponding range-spec appeared in the received Range
Range header field. Since the typical overhead between parts of a header field. Since the typical overhead between parts of a
multipart/byteranges payload is around 80 bytes, depending on the multipart/byteranges payload is around 80 bytes, depending on the
selected representation's media type and the chosen boundary selected representation's media type and the chosen boundary
parameter length, it can be less efficient to transfer many small parameter length, it can be less efficient to transfer many small
disjoint parts than it is to transfer the entire selected disjoint parts than it is to transfer the entire selected
representation. representation.
A server MUST NOT generate a multipart response to a request for a A server MUST NOT generate a multipart response to a request for a
single range, since a client that does not request multiple parts single range, since a client that does not request multiple parts
might not support multipart responses. However, a server MAY might not support multipart responses. However, a server MAY
generate a multipart/byteranges payload with only a single body part generate a multipart/byteranges payload with only a single body part
if multiple ranges were requested and only one range was found to be if multiple ranges were requested and only one range was found to be
satisfiable or only one range remained after coalescing. A client satisfiable or only one range remained after coalescing. A client
that cannot process a multipart/byteranges response MUST NOT generate that cannot process a multipart/byteranges response MUST NOT generate
a request that asks for multiple ranges. a request that asks for multiple ranges.
When a multipart response payload is generated, the server SHOULD When a multipart response payload is generated, the server SHOULD
send the parts in the same order that the corresponding byte-range- send the parts in the same order that the corresponding range-spec
spec appeared in the received Range header field, excluding those appeared in the received Range header field, excluding those ranges
ranges that were deemed unsatisfiable or that were coalesced into that were deemed unsatisfiable or that were coalesced into other
other ranges. A client that receives a multipart response MUST ranges. A client that receives a multipart response MUST inspect the
inspect the Content-Range header field present in each body part in Content-Range header field present in each body part in order to
order to determine which range is contained in that body part; a determine which range is contained in that body part; a client cannot
client cannot rely on receiving the same ranges that it requested, rely on receiving the same ranges that it requested, nor the same
nor the same order that it requested. order that it requested.
9.3.7.3. Combining Parts 9.3.7.3. Combining Parts
A response might transfer only a subrange of a representation if the A response might transfer only a subrange of a representation if the
connection closed prematurely or if the request used one or more connection closed prematurely or if the request used one or more
Range specifications. After several such transfers, a client might Range specifications. After several such transfers, a client might
have received several ranges of the same representation. These have received several ranges of the same representation. These
ranges can only be safely combined if they all have in common the ranges can only be safely combined if they all have in common the
same strong validator (Section 10.2.1). same strong validator (Section 10.2.1).
skipping to change at page 118, line 41 skipping to change at page 122, line 41
metadata and URI reference(s) from which the user or user agent can metadata and URI reference(s) from which the user or user agent can
choose the one most preferred. The user agent MAY make a selection choose the one most preferred. The user agent MAY make a selection
from that list automatically if it understands the provided media from that list automatically if it understands the provided media
type. A specific format for automatic selection is not defined by type. A specific format for automatic selection is not defined by
this specification because HTTP tries to remain orthogonal to the this specification because HTTP tries to remain orthogonal to the
definition of its payloads. In practice, the representation is definition of its payloads. In practice, the representation is
provided in some easily parsed format believed to be acceptable to provided in some easily parsed format believed to be acceptable to
the user agent, as determined by shared design or content the user agent, as determined by shared design or content
negotiation, or in some commonly accepted hypertext format. negotiation, or in some commonly accepted hypertext format.
A 300 response is cacheable by default; i.e., unless otherwise A 300 response is heuristically cacheable; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [Caching]). Section 4.2.2 of [Caching]).
Note: The original proposal for the 300 status code defined the Note: The original proposal for the 300 status code defined the
URI header field as providing a list of alternative URI header field as providing a list of alternative
representations, such that it would be usable for 200, 300, and representations, such that it would be usable for 200, 300, and
406 responses and be transferred in responses to the HEAD method. 406 responses and be transferred in responses to the HEAD method.
However, lack of deployment and disagreement over syntax led to However, lack of deployment and disagreement over syntax led to
both URI and Alternates (a subsequent proposal) being dropped from both URI and Alternates (a subsequent proposal) being dropped from
this specification. It is possible to communicate the list using this specification. It is possible to communicate the list using
skipping to change at page 119, line 27 skipping to change at page 123, line 27
containing a preferred URI reference for the new permanent URI. The containing a preferred URI reference for the new permanent URI. The
user agent MAY use the Location field value for automatic user agent MAY use the Location field value for automatic
redirection. The server's response payload usually contains a short redirection. The server's response payload usually contains a short
hypertext note with a hyperlink to the new URI(s). hypertext note with a hyperlink to the new URI(s).
Note: For historical reasons, a user agent MAY change the request Note: For historical reasons, a user agent MAY change the request
method from POST to GET for the subsequent request. If this method from POST to GET for the subsequent request. If this
behavior is undesired, the 308 (Permanent Redirect) status code behavior is undesired, the 308 (Permanent Redirect) status code
can be used instead. can be used instead.
A 301 response is cacheable by default; i.e., unless otherwise A 301 response is heuristically cacheable; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [Caching]). Section 4.2.2 of [Caching]).
9.4.3. 302 Found 9.4.3. 302 Found
The 302 (Found) status code indicates that the target resource The 302 (Found) status code indicates that the target resource
resides temporarily under a different URI. Since the redirection resides temporarily under a different URI. Since the redirection
might be altered on occasion, the client ought to continue to use the might be altered on occasion, the client ought to continue to use the
effective request URI for future requests. effective request URI for future requests.
skipping to change at page 122, line 20 skipping to change at page 126, line 20
Clients with link editing capabilities ought to automatically re-link Clients with link editing capabilities ought to automatically re-link
references to the effective request URI to one or more of the new references to the effective request URI to one or more of the new
references sent by the server, where possible. references sent by the server, where possible.
The server SHOULD generate a Location header field in the response The server SHOULD generate a Location header field in the response
containing a preferred URI reference for the new permanent URI. The containing a preferred URI reference for the new permanent URI. The
user agent MAY use the Location field value for automatic user agent MAY use the Location field value for automatic
redirection. The server's response payload usually contains a short redirection. The server's response payload usually contains a short
hypertext note with a hyperlink to the new URI(s). hypertext note with a hyperlink to the new URI(s).
A 308 response is cacheable by default; i.e., unless otherwise A 308 response is heuristically cacheable; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [Caching]). Section 4.2.2 of [Caching]).
Note: This status code is much younger (June 2014) than its Note: This status code is much younger (June 2014) than its
sibling codes, and thus might not be recognized everywhere. See sibling codes, and thus might not be recognized everywhere. See
Section 4 of [RFC7538] for deployment considerations. Section 4 of [RFC7538] for deployment considerations.
9.5. Client Error 4xx 9.5. Client Error 4xx
The 4xx (Client Error) class of status code indicates that the client The 4xx (Client Error) class of status code indicates that the client
skipping to change at page 123, line 21 skipping to change at page 127, line 21
the user agent SHOULD present the enclosed representation to the the user agent SHOULD present the enclosed representation to the
user, since it usually contains relevant diagnostic information. user, since it usually contains relevant diagnostic information.
9.5.3. 402 Payment Required 9.5.3. 402 Payment Required
The 402 (Payment Required) status code is reserved for future use. The 402 (Payment Required) status code is reserved for future use.
9.5.4. 403 Forbidden 9.5.4. 403 Forbidden
The 403 (Forbidden) status code indicates that the server understood The 403 (Forbidden) status code indicates that the server understood
the request but refuses to authorize it. A server that wishes to the request but refuses to fulfill it. A server that wishes to make
make public why the request has been forbidden can describe that public why the request has been forbidden can describe that reason in
reason in the response payload (if any). the response payload (if any).
If authentication credentials were provided in the request, the If authentication credentials were provided in the request, the
server considers them insufficient to grant access. The client server considers them insufficient to grant access. The client
SHOULD NOT automatically repeat the request with the same SHOULD NOT automatically repeat the request with the same
credentials. The client MAY repeat the request with new or different credentials. The client MAY repeat the request with new or different
credentials. However, a request might be forbidden for reasons credentials. However, a request might be forbidden for reasons
unrelated to the credentials. unrelated to the credentials.
An origin server that wishes to "hide" the current existence of a An origin server that wishes to "hide" the current existence of a
forbidden target resource MAY instead respond with a status code of forbidden target resource MAY instead respond with a status code of
skipping to change at page 123, line 46 skipping to change at page 127, line 46
9.5.5. 404 Not Found 9.5.5. 404 Not Found
The 404 (Not Found) status code indicates that the origin server did The 404 (Not Found) status code indicates that the origin server did
not find a current representation for the target resource or is not not find a current representation for the target resource or is not
willing to disclose that one exists. A 404 status code does not willing to disclose that one exists. A 404 status code does not
indicate whether this lack of representation is temporary or indicate whether this lack of representation is temporary or
permanent; the 410 (Gone) status code is preferred over 404 if the permanent; the 410 (Gone) status code is preferred over 404 if the
origin server knows, presumably through some configurable means, that origin server knows, presumably through some configurable means, that
the condition is likely to be permanent. the condition is likely to be permanent.
A 404 response is cacheable by default; i.e., unless otherwise A 404 response is heuristically cacheable; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [Caching]). Section 4.2.2 of [Caching]).
9.5.6. 405 Method Not Allowed 9.5.6. 405 Method Not Allowed
The 405 (Method Not Allowed) status code indicates that the method The 405 (Method Not Allowed) status code indicates that the method
received in the request-line is known by the origin server but not received in the request-line is known by the origin server but not
supported by the target resource. The origin server MUST generate an supported by the target resource. The origin server MUST generate an
Allow header field in a 405 response containing a list of the target Allow header field in a 405 response containing a list of the target
resource's currently supported methods. resource's currently supported methods.
A 405 response is cacheable by default; i.e., unless otherwise A 405 response is heuristically cacheable; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [Caching]). Section 4.2.2 of [Caching]).
9.5.7. 406 Not Acceptable 9.5.7. 406 Not Acceptable
The 406 (Not Acceptable) status code indicates that the target The 406 (Not Acceptable) status code indicates that the target
resource does not have a current representation that would be resource does not have a current representation that would be
acceptable to the user agent, according to the proactive negotiation acceptable to the user agent, according to the proactive negotiation
header fields received in the request (Section 8.4), and the server header fields received in the request (Section 8.4), and the server
is unwilling to supply a default representation. is unwilling to supply a default representation.
skipping to change at page 125, line 41 skipping to change at page 129, line 41
The 410 response is primarily intended to assist the task of web The 410 response is primarily intended to assist the task of web
maintenance by notifying the recipient that the resource is maintenance by notifying the recipient that the resource is
intentionally unavailable and that the server owners desire that intentionally unavailable and that the server owners desire that
remote links to that resource be removed. Such an event is common remote links to that resource be removed. Such an event is common
for limited-time, promotional services and for resources belonging to for limited-time, promotional services and for resources belonging to
individuals no longer associated with the origin server's site. It individuals no longer associated with the origin server's site. It
is not necessary to mark all permanently unavailable resources as is not necessary to mark all permanently unavailable resources as
"gone" or to keep the mark for any length of time -- that is left to "gone" or to keep the mark for any length of time -- that is left to
the discretion of the server owner. the discretion of the server owner.
A 410 response is cacheable by default; i.e., unless otherwise A 410 response is heuristically cacheable; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [Caching]). Section 4.2.2 of [Caching]).
9.5.12. 411 Length Required 9.5.12. 411 Length Required
The 411 (Length Required) status code indicates that the server The 411 (Length Required) status code indicates that the server
refuses to accept the request without a defined Content-Length refuses to accept the request without a defined Content-Length
(Section 6.2.4). The client MAY repeat the request if it adds a (Section 6.2.4). The client MAY repeat the request if it adds a
valid Content-Length header field containing the length of the valid Content-Length header field containing the length of the
message body in the request message. message body in the request message.
skipping to change at page 126, line 37 skipping to change at page 130, line 37
The 414 (URI Too Long) status code indicates that the server is The 414 (URI Too Long) status code indicates that the server is
refusing to service the request because the request-target refusing to service the request because the request-target
(Section 3.2 of [Messaging]) is longer than the server is willing to (Section 3.2 of [Messaging]) is longer than the server is willing to
interpret. This rare condition is only likely to occur when a client interpret. This rare condition is only likely to occur when a client
has improperly converted a POST request to a GET request with long has improperly converted a POST request to a GET request with long
query information, when the client has descended into a "black hole" query information, when the client has descended into a "black hole"
of redirection (e.g., a redirected URI prefix that points to a suffix of redirection (e.g., a redirected URI prefix that points to a suffix
of itself) or when the server is under attack by a client attempting of itself) or when the server is under attack by a client attempting
to exploit potential security holes. to exploit potential security holes.
A 414 response is cacheable by default; i.e., unless otherwise A 414 response is heuristically cacheable; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [Caching]). Section 4.2.2 of [Caching]).
9.5.16. 415 Unsupported Media Type 9.5.16. 415 Unsupported Media Type
The 415 (Unsupported Media Type) status code indicates that the The 415 (Unsupported Media Type) status code indicates that the
origin server is refusing to service the request because the payload origin server is refusing to service the request because the payload
is in a format not supported by this method on the target resource. is in a format not supported by this method on the target resource.
The format problem might be due to the request's indicated Content- The format problem might be due to the request's indicated Content-
Type or Content-Encoding, or as a result of inspecting the data Type or Content-Encoding, or as a result of inspecting the data
skipping to change at page 127, line 14 skipping to change at page 131, line 14
9.5.17. 416 Range Not Satisfiable 9.5.17. 416 Range Not Satisfiable
The 416 (Range Not Satisfiable) status code indicates that none of The 416 (Range Not Satisfiable) status code indicates that none of
the ranges in the request's Range header field (Section 8.3) overlap the ranges in the request's Range header field (Section 8.3) overlap
the current extent of the selected representation or that the set of the current extent of the selected representation or that the set of
ranges requested has been rejected due to invalid ranges or an ranges requested has been rejected due to invalid ranges or an
excessive request of small or overlapping ranges. excessive request of small or overlapping ranges.
For byte ranges, failing to overlap the current extent means that the For byte ranges, failing to overlap the current extent means that the
first-byte-pos of all of the byte-range-spec values were greater than first-pos of all of the range-spec values were greater than or equal
or equal to the current length of the selected representation. When to the current length of the selected representation. When this
this status code is generated in response to a byte-range request, status code is generated in response to a byte-range request, the
the sender SHOULD generate a Content-Range header field specifying sender SHOULD generate a Content-Range header field specifying the
the current length of the selected representation (Section 6.3.3). current length of the selected representation (Section 6.3.4).
For example: For example:
HTTP/1.1 416 Range Not Satisfiable HTTP/1.1 416 Range Not Satisfiable
Date: Fri, 20 Jan 2012 15:41:54 GMT Date: Fri, 20 Jan 2012 15:41:54 GMT
Content-Range: bytes */47022 Content-Range: bytes */47022
Note: Because servers are free to ignore Range, many Note: Because servers are free to ignore Range, many
implementations will simply respond with the entire selected implementations will simply respond with the entire selected
representation in a 200 (OK) response. That is partly because representation in a 200 (OK) response. That is partly because
skipping to change at page 128, line 24 skipping to change at page 132, line 24
the contained instructions. For example, this status code can be the contained instructions. For example, this status code can be
sent if an XML request payload contains well-formed (i.e., sent if an XML request payload contains well-formed (i.e.,
syntactically correct), but semantically erroneous XML instructions. syntactically correct), but semantically erroneous XML instructions.
9.5.21. 426 Upgrade Required 9.5.21. 426 Upgrade Required
The 426 (Upgrade Required) status code indicates that the server The 426 (Upgrade Required) status code indicates that the server
refuses to perform the request using the current protocol but might refuses to perform the request using the current protocol but might
be willing to do so after the client upgrades to a different be willing to do so after the client upgrades to a different
protocol. The server MUST send an Upgrade header field in a 426 protocol. The server MUST send an Upgrade header field in a 426
response to indicate the required protocol(s) (Section 9.8 of response to indicate the required protocol(s) (Section 9.9 of
[Messaging]). [Messaging]).
Example: Example:
HTTP/1.1 426 Upgrade Required HTTP/1.1 426 Upgrade Required
Upgrade: HTTP/3.0 Upgrade: HTTP/3.0
Connection: Upgrade Connection: Upgrade
Content-Length: 53 Content-Length: 53
Content-Type: text/plain Content-Type: text/plain
skipping to change at page 129, line 18 skipping to change at page 133, line 18
encountered an unexpected condition that prevented it from fulfilling encountered an unexpected condition that prevented it from fulfilling
the request. the request.
9.6.2. 501 Not Implemented 9.6.2. 501 Not Implemented
The 501 (Not Implemented) status code indicates that the server does The 501 (Not Implemented) status code indicates that the server does
not support the functionality required to fulfill the request. This not support the functionality required to fulfill the request. This
is the appropriate response when the server does not recognize the is the appropriate response when the server does not recognize the
request method and is not capable of supporting it for any resource. request method and is not capable of supporting it for any resource.
A 501 response is cacheable by default; i.e., unless otherwise A 501 response is heuristically cacheable; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [Caching]). Section 4.2.2 of [Caching]).
9.6.3. 502 Bad Gateway 9.6.3. 502 Bad Gateway
The 502 (Bad Gateway) status code indicates that the server, while The 502 (Bad Gateway) status code indicates that the server, while
acting as a gateway or proxy, received an invalid response from an acting as a gateway or proxy, received an invalid response from an
inbound server it accessed while attempting to fulfill the request. inbound server it accessed while attempting to fulfill the request.
9.6.4. 503 Service Unavailable 9.6.4. 503 Service Unavailable
skipping to change at page 151, line 31 skipping to change at page 155, line 31
used by the origin server to handle the request, which is often used used by the origin server to handle the request, which is often used
by clients to help identify the scope of reported interoperability by clients to help identify the scope of reported interoperability
problems, to work around or tailor requests to avoid particular problems, to work around or tailor requests to avoid particular
server limitations, and for analytics regarding server or operating server limitations, and for analytics regarding server or operating
system use. An origin server MAY generate a Server field in its system use. An origin server MAY generate a Server field in its
responses. responses.
Server = product *( RWS ( product / comment ) ) Server = product *( RWS ( product / comment ) )
The Server field-value consists of one or more product identifiers, The Server field-value consists of one or more product identifiers,
each followed by zero or more comments (Section 5 of [Messaging]), each followed by zero or more comments (Section 4.2.3.3), which
which together identify the origin server software and its together identify the origin server software and its significant
significant subproducts. By convention, the product identifiers are subproducts. By convention, the product identifiers are listed in
listed in decreasing order of their significance for identifying the decreasing order of their significance for identifying the origin
origin server software. Each product identifier consists of a name server software. Each product identifier consists of a name and
and optional version, as defined in Section 8.6.3. optional version, as defined in Section 8.6.3.
Example: Example:
Server: CERN/3.0 libwww/2.17 Server: CERN/3.0 libwww/2.17
An origin server SHOULD NOT generate a Server field containing An origin server SHOULD NOT generate a Server field containing
needlessly fine-grained detail and SHOULD limit the addition of needlessly fine-grained detail and SHOULD limit the addition of
subproducts by third parties. Overly long and detailed Server field subproducts by third parties. Overly long and detailed Server field
values increase response latency and potentially reveal internal values increase response latency and potentially reveal internal
implementation details that might make it (slightly) easier for implementation details that might make it (slightly) easier for
attackers to find and exploit known security holes. attackers to find and exploit known security holes.
11. ABNF List Extension: #rule 11. Generic Syntax
11.1. Whitespace
This specification uses three rules to denote the use of linear
whitespace: OWS (optional whitespace), RWS (required whitespace), and
BWS ("bad" whitespace).
The OWS rule is used where zero or more linear whitespace octets
might appear. For protocol elements where optional whitespace is
preferred to improve readability, a sender SHOULD generate the
optional whitespace as a single SP; otherwise, a sender SHOULD NOT
generate optional whitespace except as needed to white out invalid or
unwanted protocol elements during in-place message filtering.
The RWS rule is used when at least one linear whitespace octet is
required to separate field tokens. A sender SHOULD generate RWS as a
single SP.
The BWS rule is used where the grammar allows optional whitespace
only for historical reasons. A sender MUST NOT generate BWS in
messages. A recipient MUST parse for such bad whitespace and remove
it before interpreting the protocol element.
OWS = *( SP / HTAB )
; optional whitespace
RWS = 1*( SP / HTAB )
; required whitespace
BWS = OWS
; "bad" whitespace
12. ABNF List Extension: #rule
A #rule extension to the ABNF rules of [RFC5234] is used to improve A #rule extension to the ABNF rules of [RFC5234] is used to improve
readability in the definitions of some header field values. readability in the definitions of some header field values.
A construct "#" is defined, similar to "*", for defining comma- A construct "#" is defined, similar to "*", for defining comma-
delimited lists of elements. The full form is "<n>#<m>element" delimited lists of elements. The full form is "<n>#<m>element"
indicating at least <n> and at most <m> elements, each separated by a indicating at least <n> and at most <m> elements, each separated by a
single comma (",") and optional whitespace (OWS). single comma (",") and optional whitespace (OWS).
11.1. Sender Requirements 12.1. Sender Requirements
In any production that uses the list construct, a sender MUST NOT In any production that uses the list construct, a sender MUST NOT
generate empty list elements. In other words, a sender MUST generate generate empty list elements. In other words, a sender MUST generate
lists that satisfy the following syntax: lists that satisfy the following syntax:
1#element => element *( OWS "," OWS element ) 1#element => element *( OWS "," OWS element )
and: and:
#element => [ 1#element ] #element => [ 1#element ]
and for n >= 1 and m > 1: and for n >= 1 and m > 1:
<n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element ) <n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element )
11.2. Recipient Requirements 12.2. Recipient Requirements
Empty elements do not contribute to the count of elements present. A Empty elements do not contribute to the count of elements present. A
recipient MUST parse and ignore a reasonable number of empty list recipient MUST parse and ignore a reasonable number of empty list
elements: enough to handle common mistakes by senders that merge elements: enough to handle common mistakes by senders that merge
values, but not so much that they could be used as a denial-of- values, but not so much that they could be used as a denial-of-
service mechanism. In other words, a recipient MUST accept lists service mechanism. In other words, a recipient MUST accept lists
that satisfy the following syntax: that satisfy the following syntax:
#element => [ element ] *( OWS "," OWS [ element ] ) #element => [ element ] *( OWS "," OWS [ element ] )
Note that because of the potential presence of empty list elements, Note that because of the potential presence of empty list elements,
the RFC 5234 ABNF cannot enforce the cardinality of list elements, the RFC 5234 ABNF cannot enforce the cardinality of list elements,
and consequently all cases are mapped is if there was no cardinality and consequently all cases are mapped is if there was no cardinality
specified. specified.
For example, given these ABNF productions: For example, given these ABNF productions:
example-list = 1#example-list-elmt example-list = 1#example-list-elmt
example-list-elmt = token ; see Section 4.2.3 example-list-elmt = token ; see Section 4.2.3.1
Then the following are valid values for example-list (not including Then the following are valid values for example-list (not including
the double quotes, which are present for delimitation only): the double quotes, which are present for delimitation only):
"foo,bar" "foo,bar"
"foo ,bar," "foo ,bar,"
"foo , ,bar,charlie" "foo , ,bar,charlie"
In contrast, the following values would be invalid, since at least In contrast, the following values would be invalid, since at least
one non-empty element is required by the example-list production: one non-empty element is required by the example-list production:
"" ""
"," ","
", ," ", ,"
Appendix A shows the collected ABNF for recipients after the list Appendix A shows the collected ABNF for recipients after the list
constructs have been expanded. constructs have been expanded.
12. Security Considerations 13. Security Considerations
This section is meant to inform developers, information providers, This section is meant to inform developers, information providers,
and users of known security concerns relevant to HTTP semantics and and users of known security concerns relevant to HTTP semantics and
its use for transferring information over the Internet. its use for transferring information over the Internet.
Considerations related to message syntax, parsing, and routing are Considerations related to message syntax, parsing, and routing are
discussed in Section 11 of [Messaging]. discussed in Section 11 of [Messaging].
The list of considerations below is not exhaustive. Most security The list of considerations below is not exhaustive. Most security
concerns related to HTTP semantics are about securing server-side concerns related to HTTP semantics are about securing server-side
applications (code behind the HTTP interface), securing user agent applications (code behind the HTTP interface), securing user agent
processing of payloads received via HTTP, or secure use of the processing of payloads received via HTTP, or secure use of the
Internet in general, rather than security of the protocol. Various Internet in general, rather than security of the protocol. Various
organizations maintain topical information and links to current organizations maintain topical information and links to current
research on Web application security (e.g., [OWASP]). research on Web application security (e.g., [OWASP]).
12.1. Establishing Authority 13.1. Establishing Authority
HTTP relies on the notion of an authoritative response: a response HTTP relies on the notion of an authoritative response: a response
that has been determined by (or at the direction of) the authority that has been determined by (or at the direction of) the origin
identified within the target URI to be the most appropriate response server identified within the target URI to be the most appropriate
for that request given the state of the target resource at the time response for that request given the state of the target resource at
of response message origination. Providing a response from a non- the time of response message origination.
authoritative source, such as a shared cache, is often useful to
improve performance and availability, but only to the extent that the
source can be trusted or the distrusted response can be safely used.
Unfortunately, establishing authority can be difficult. For example,
phishing is an attack on the user's perception of authority, where
that perception can be misled by presenting similar branding in
hypertext, possibly aided by userinfo obfuscating the authority
component (see Section 2.5.1). User agents can reduce the impact of
phishing attacks by enabling users to easily inspect a target URI
prior to making an action, by prominently distinguishing (or
rejecting) userinfo when present, and by not sending stored
credentials and cookies when the referring document is from an
unknown or untrusted source.
When a registered name is used in the authority component, the "http" When a registered name is used in the authority component, the "http"
URI scheme (Section 2.5.1) relies on the user's local name resolution URI scheme (Section 2.5.1) relies on the user's local name resolution
service to determine where it can find authoritative responses. This service to determine where it can find authoritative responses. This
means that any attack on a user's network host table, cached names, means that any attack on a user's network host table, cached names,
or name resolution libraries becomes an avenue for attack on or name resolution libraries becomes an avenue for attack on
establishing authority. Likewise, the user's choice of server for establishing authority for "http" URIs. Likewise, the user's choice
Domain Name Service (DNS), and the hierarchy of servers from which it of server for Domain Name Service (DNS), and the hierarchy of servers
obtains resolution results, could impact the authenticity of address from which it obtains resolution results, could impact the
mappings; DNS Security Extensions (DNSSEC, [RFC4033]) are one way to authenticity of address mappings; DNS Security Extensions (DNSSEC,
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 (see [RFC2818]). matches the target URI's authority component (Section 2.5.2.2).
Correctly implementing such verification can be difficult (see Correctly implementing such verification can be difficult (see
[Georgiev]). [Georgiev]).
12.2. Risks of Intermediaries Authority for a given origin server can be delegated through protocol
extensions; for example, [RFC7838]. Likewise, the set of servers
that a connection is considered authoritative for can be changed with
a protocol extension like [RFC8336].
Providing a response from a non-authoritative source, such as a
shared proxy cache, is often useful to improve performance and
availability, but only to the extent that the source can be trusted
or the distrusted response can be safely used.
Unfortunately, communicating authority to users can be difficult.
For example, phishing is an attack on the user's perception of
authority, where that perception can be misled by presenting similar
branding in hypertext, possibly aided by userinfo obfuscating the
authority component (see Section 2.5.1). User agents can reduce the
impact of phishing attacks by enabling users to easily inspect a
target URI prior to making an action, by prominently distinguishing
(or rejecting) userinfo when present, and by not sending stored
credentials and cookies when the referring document is from an
unknown or untrusted source.
See also [RFC6454] for a formalisation of authority that is used by
many clients.
13.2. Risks of Intermediaries
By their very nature, HTTP intermediaries are men-in-the-middle and, By their very nature, HTTP intermediaries are men-in-the-middle and,
thus, represent an opportunity for man-in-the-middle attacks. thus, represent an opportunity for man-in-the-middle attacks.
Compromise of the systems on which the intermediaries run can result Compromise of the systems on which the intermediaries run can result
in serious security and privacy problems. Intermediaries might have in serious security and privacy problems. Intermediaries might have
access to security-related information, personal information about access to security-related information, personal information about
individual users and organizations, and proprietary information individual users and organizations, and proprietary information
belonging to users and content providers. A compromised belonging to users and content providers. A compromised
intermediary, or an intermediary implemented or configured without intermediary, or an intermediary implemented or configured without
regard to security and privacy considerations, might be used in the regard to security and privacy considerations, might be used in the
skipping to change at page 155, line 10 skipping to change at page 160, line 5
to cache poisoning attacks, as described in Section 7 of [Caching]. to cache poisoning attacks, as described in Section 7 of [Caching].
Implementers need to consider the privacy and security implications Implementers need to consider the privacy and security implications
of their design and coding decisions, and of the configuration of their design and coding decisions, and of the configuration
options they provide to operators (especially the default options they provide to operators (especially the default
configuration). configuration).
Users need to be aware that intermediaries are no more trustworthy Users need to be aware that intermediaries are no more trustworthy
than the people who run them; HTTP itself cannot solve this problem. than the people who run them; HTTP itself cannot solve this problem.
12.3. Attacks Based on File and Path Names 13.3. Attacks Based on File and Path Names
Origin servers frequently make use of their local file system to Origin servers frequently make use of their local file system to
manage the mapping from effective request URI to resource manage the mapping from effective request URI to resource
representations. Most file systems are not designed to protect representations. Most file systems are not designed to protect
against malicious file or path names. Therefore, an origin server against malicious file or path names. Therefore, an origin server
needs to avoid accessing names that have a special significance to needs to avoid accessing names that have a special significance to
the system when mapping the request target to files, folders, or the system when mapping the request target to files, folders, or
directories. directories.
For example, UNIX, Microsoft Windows, and other operating systems use For example, UNIX, Microsoft Windows, and other operating systems use
skipping to change at page 155, line 35 skipping to change at page 160, line 30
systems have an annoying tendency to prefer user-friendliness over systems have an annoying tendency to prefer user-friendliness over
security when handling invalid or unexpected characters, security when handling invalid or unexpected characters,
recomposition of decomposed characters, and case-normalization of recomposition of decomposed characters, and case-normalization of
case-insensitive names. case-insensitive names.
Attacks based on such special names tend to focus on either denial- Attacks based on such special names tend to focus on either denial-
of-service (e.g., telling the server to read from a COM port) or of-service (e.g., telling the server to read from a COM port) or
disclosure of configuration and source files that are not meant to be disclosure of configuration and source files that are not meant to be
served. served.
12.4. Attacks Based on Command, Code, or Query Injection 13.4. Attacks Based on Command, Code, or Query Injection
Origin servers often use parameters within the URI as a means of Origin servers often use parameters within the URI as a means of
identifying system services, selecting database entries, or choosing identifying system services, selecting database entries, or choosing
a data source. However, data received in a request cannot be a data source. However, data received in a request cannot be
trusted. An attacker could construct any of the request data trusted. An attacker could construct any of the request data
elements (method, request-target, header fields, or body) to contain elements (method, request-target, header fields, or body) to contain
data that might be misinterpreted as a command, code, or query when data that might be misinterpreted as a command, code, or query when
passed through a command invocation, language interpreter, or passed through a command invocation, language interpreter, or
database interface. database interface.
skipping to change at page 156, line 20 skipping to change at page 161, line 12
Parameters ought to be compared to fixed strings and acted upon as a Parameters ought to be compared to fixed strings and acted upon as a
result of that comparison, rather than passed through an interface result of that comparison, rather than passed through an interface
that is not prepared for untrusted data. Received data that isn't that is not prepared for untrusted data. Received data that isn't
based on fixed parameters ought to be carefully filtered or encoded based on fixed parameters ought to be carefully filtered or encoded
to avoid being misinterpreted. to avoid being misinterpreted.
Similar considerations apply to request data when it is stored and Similar considerations apply to request data when it is stored and
later processed, such as within log files, monitoring tools, or when later processed, such as within log files, monitoring tools, or when
included within a data format that allows embedded scripts. included within a data format that allows embedded scripts.
12.5. Attacks via Protocol Element Length 13.5. Attacks via Protocol Element Length
Because HTTP uses mostly textual, character-delimited fields, parsers Because HTTP uses mostly textual, character-delimited fields, parsers
are often vulnerable to attacks based on sending very long (or very are often vulnerable to attacks based on sending very long (or very
slow) streams of data, particularly where an implementation is slow) streams of data, particularly where an implementation is
expecting a protocol element with no predefined length (Section 3.3). expecting a protocol element with no predefined length (Section 3.3).
To promote interoperability, specific recommendations are made for To promote interoperability, specific recommendations are made for
minimum size limits on request-line (Section 3 of [Messaging]) and minimum size limits on request-line (Section 3 of [Messaging]) and
header fields (Section 5 of [Messaging]). These are minimum header fields (Section 4). These are minimum recommendations, chosen
recommendations, chosen to be supportable even by implementations to be supportable even by implementations with limited resources; it
with limited resources; it is expected that most implementations will is expected that most implementations will choose substantially
choose substantially higher limits. higher limits.
A server can reject a message that has a request-target that is too A server can reject a message that has a request-target that is too
long (Section 9.5.15) or a request payload that is too large long (Section 9.5.15) or a request payload that is too large
(Section 9.5.14). Additional status codes related to capacity limits (Section 9.5.14). Additional status codes related to capacity limits
have been defined by extensions to HTTP [RFC6585]. have been defined by extensions to HTTP [RFC6585].
Recipients ought to carefully limit the extent to which they process Recipients ought to carefully limit the extent to which they process
other protocol elements, including (but not limited to) request other protocol elements, including (but not limited to) request
methods, response status phrases, header field-names, numeric values, methods, response status phrases, header field-names, numeric values,
and body chunks. Failure to limit such processing can result in and body chunks. Failure to limit such processing can result in
buffer overflows, arithmetic overflows, or increased vulnerability to buffer overflows, arithmetic overflows, or increased vulnerability to
denial-of-service attacks. denial-of-service attacks.
12.6. Disclosure of Personal Information 13.6. Disclosure of Personal Information
Clients are often privy to large amounts of personal information, Clients are often privy to large amounts of personal information,
including both information provided by the user to interact with including both information provided by the user to interact with
resources (e.g., the user's name, location, mail address, passwords, resources (e.g., the user's name, location, mail address, passwords,
encryption keys, etc.) and information about the user's browsing encryption keys, etc.) and information about the user's browsing
activity over time (e.g., history, bookmarks, etc.). Implementations activity over time (e.g., history, bookmarks, etc.). Implementations
need to prevent unintentional disclosure of personal information. need to prevent unintentional disclosure of personal information.
12.7. Privacy of Server Log Information 13.7. Privacy of Server Log Information
A server is in the position to save personal data about a user's A server is in the position to save personal data about a user's
requests over time, which might identify their reading patterns or requests over time, which might identify their reading patterns or
subjects of interest. In particular, log information gathered at an subjects of interest. In particular, log information gathered at an
intermediary often contains a history of user agent interaction, intermediary often contains a history of user agent interaction,
across a multitude of sites, that can be traced to individual users. across a multitude of sites, that can be traced to individual users.
HTTP log information is confidential in nature; its handling is often HTTP log information is confidential in nature; its handling is often
constrained by laws and regulations. Log information needs to be constrained by laws and regulations. Log information needs to be
securely stored and appropriate guidelines followed for its analysis. securely stored and appropriate guidelines followed for its analysis.
skipping to change at page 157, line 31 skipping to change at page 162, line 23
characteristics. As such, access traces that are keyed to a specific characteristics. As such, access traces that are keyed to a specific
client are unsafe to publish even if the key is pseudonymous. client are unsafe to publish even if the key is pseudonymous.
To minimize the risk of theft or accidental publication, log To minimize the risk of theft or accidental publication, log
information ought to be purged of personally identifiable information ought to be purged of personally identifiable
information, including user identifiers, IP addresses, and user- information, including user identifiers, IP addresses, and user-
provided query parameters, as soon as that information is no longer provided query parameters, as soon as that information is no longer
necessary to support operational needs for security, auditing, or necessary to support operational needs for security, auditing, or
fraud control. fraud control.
12.8. Disclosure of Sensitive Information in URIs 13.8. Disclosure of Sensitive Information in URIs
URIs are intended to be shared, not secured, even when they identify URIs are intended to be shared, not secured, even when they identify
secure resources. URIs are often shown on displays, added to secure resources. URIs are often shown on displays, added to
templates when a page is printed, and stored in a variety of templates when a page is printed, and stored in a variety of
unprotected bookmark lists. It is therefore unwise to include unprotected bookmark lists. It is therefore unwise to include
information within a URI that is sensitive, personally identifiable, information within a URI that is sensitive, personally identifiable,
or a risk to disclose. or a risk to disclose.
Authors of services ought to avoid GET-based forms for the submission Authors of services ought to avoid GET-based forms for the submission
of sensitive data because that data will be placed in the request- of sensitive data because that data will be placed in the request-
skipping to change at page 158, line 7 skipping to change at page 162, line 46
third parties. Such services ought to use POST-based form submission third parties. Such services ought to use POST-based form submission
instead. instead.
Since the Referer header field tells a target site about the context Since the Referer header field tells a target site about the context
that resulted in a request, it has the potential to reveal that resulted in a request, it has the potential to reveal
information about the user's immediate browsing history and any information about the user's immediate browsing history and any
personal information that might be found in the referring resource's personal information that might be found in the referring resource's
URI. Limitations on the Referer header field are described in URI. Limitations on the Referer header field are described in
Section 8.6.2 to address some of its security considerations. Section 8.6.2 to address some of its security considerations.
12.9. Disclosure of Fragment after Redirects 13.9. Disclosure of Fragment after Redirects
Although fragment identifiers used within URI references are not sent Although fragment identifiers used within URI references are not sent
in requests, implementers ought to be aware that they will be visible in requests, implementers ought to be aware that they will be visible
to the user agent and any extensions or scripts running as a result to the user agent and any extensions or scripts running as a result
of the response. In particular, when a redirect occurs and the of the response. In particular, when a redirect occurs and the
original request's fragment identifier is inherited by the new original request's fragment identifier is inherited by the new
reference in Location (Section 10.1.2), this might have the effect of reference in Location (Section 10.1.2), this might have the effect of
disclosing one site's fragment to another site. If the first site disclosing one site's fragment to another site. If the first site
uses personal information in fragments, it ought to ensure that uses personal information in fragments, it ought to ensure that
redirects to other sites include a (possibly empty) fragment redirects to other sites include a (possibly empty) fragment
component in order to block that inheritance. component in order to block that inheritance.
12.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.5.1), and Server
(Section 10.4.3) header fields often reveal information about the (Section 10.4.3) header fields often reveal information about the
respective sender's software systems. In theory, this can make it respective sender's software systems. In theory, this can make it
easier for an attacker to exploit known security holes; in practice, easier for an attacker to exploit known security holes; in practice,
attackers tend to try all potential holes regardless of the apparent attackers tend to try all potential holes regardless of the apparent
software versions being used. software versions being used.
Proxies that serve as a portal through a network firewall ought to Proxies that serve as a portal through a network firewall ought to
take special precautions regarding the transfer of header information take special precautions regarding the transfer of header information
that might identify hosts behind the firewall. The Via header field that might identify hosts behind the firewall. The Via header field
allows intermediaries to replace sensitive machine names with allows intermediaries to replace sensitive machine names with
pseudonyms. pseudonyms.
12.11. Browser Fingerprinting 13.11. Browser Fingerprinting
Browser fingerprinting is a set of techniques for identifying a Browser fingerprinting is a set of techniques for identifying a
specific user agent over time through its unique set of specific user agent over time through its unique set of
characteristics. These characteristics might include information characteristics. These characteristics might include information
related to its TCP behavior, feature capabilities, and scripting related to its TCP behavior, feature capabilities, and scripting
environment, though of particular interest here is the set of unique environment, though of particular interest here is the set of unique
characteristics that might be communicated via HTTP. Fingerprinting characteristics that might be communicated via HTTP. Fingerprinting
is considered a privacy concern because it enables tracking of a user is considered a privacy concern because it enables tracking of a user
agent's behavior over time without the corresponding controls that agent's behavior over time without the corresponding controls that
the user might have over other forms of data collection (e.g., the user might have over other forms of data collection (e.g.,
skipping to change at page 159, line 36 skipping to change at page 164, line 27
language negotiation might be useful. language negotiation might be useful.
In environments where proxies are used to enhance privacy, user In environments where proxies are used to enhance privacy, user
agents ought to be conservative in sending proactive negotiation agents ought to be conservative in sending proactive negotiation
header fields. General-purpose user agents that provide a high header fields. General-purpose user agents that provide a high
degree of header field configurability ought to inform users about degree of header field configurability ought to inform users about
the loss of privacy that might result if too much detail is provided. the loss of privacy that might result if too much detail is provided.
As an extreme privacy measure, proxies could filter the proactive As an extreme privacy measure, proxies could filter the proactive
negotiation header fields in relayed requests. negotiation header fields in relayed requests.
12.12. Validator Retention 13.12. Validator Retention
The validators defined by this specification are not intended to The validators defined by this specification are not intended to
ensure the validity of a representation, guard against malicious ensure the validity of a representation, guard against malicious
changes, or detect man-in-the-middle attacks. At best, they enable changes, or detect man-in-the-middle attacks. At best, they enable
more efficient cache updates and optimistic concurrent writes when more efficient cache updates and optimistic concurrent writes when
all participants are behaving nicely. At worst, the conditions will all participants are behaving nicely. At worst, the conditions will
fail and the client will receive a response that is no more harmful fail and the client will receive a response that is no more harmful
than an HTTP exchange without conditional requests. than an HTTP exchange without conditional requests.
An entity-tag can be abused in ways that create privacy risks. For An entity-tag can be abused in ways that create privacy risks. For
skipping to change at page 160, line 10 skipping to change at page 165, line 5
entity-tag that is unique to the user or user agent, send it in a entity-tag that is unique to the user or user agent, send it in a
cacheable response with a long freshness time, and then read that cacheable response with a long freshness time, and then read that
entity-tag in later conditional requests as a means of re-identifying entity-tag in later conditional requests as a means of re-identifying
that user or user agent. Such an identifying tag would become a that user or user agent. Such an identifying tag would become a
persistent identifier for as long as the user agent retained the persistent identifier for as long as the user agent retained the
original cache entry. User agents that cache representations ought original cache entry. User agents that cache representations ought
to ensure that the cache is cleared or replaced whenever the user to ensure that the cache is cleared or replaced whenever the user
performs privacy-maintaining actions, such as clearing stored cookies performs privacy-maintaining actions, such as clearing stored cookies
or changing to a private browsing mode. or changing to a private browsing mode.
12.13. Denial-of-Service Attacks Using Range 13.13. Denial-of-Service Attacks Using Range
Unconstrained multiple range requests are susceptible to denial-of- Unconstrained multiple range requests are susceptible to denial-of-
service attacks because the effort required to request many service attacks because the effort required to request many
overlapping ranges of the same data is tiny compared to the time, overlapping ranges of the same data is tiny compared to the time,
memory, and bandwidth consumed by attempting to serve the requested memory, and bandwidth consumed by attempting to serve the requested
data in many parts. Servers ought to ignore, coalesce, or reject data in many parts. Servers ought to ignore, coalesce, or reject
egregious range requests, such as requests for more than two egregious range requests, such as requests for more than two
overlapping ranges or for many small ranges in a single set, overlapping ranges or for many small ranges in a single set,
particularly when the ranges are requested out of order for no particularly when the ranges are requested out of order for no
apparent reason. Multipart range requests are not designed to apparent reason. Multipart range requests are not designed to
support random access. support random access.
12.14. Authentication Considerations 13.14. Authentication Considerations
Everything about the topic of HTTP authentication is a security Everything about the topic of HTTP authentication is a security
consideration, so the list of considerations below is not exhaustive. consideration, so the list of considerations below is not exhaustive.
Furthermore, it is limited to security considerations regarding the Furthermore, it is limited to security considerations regarding the
authentication framework, in general, rather than discussing all of authentication framework, in general, rather than discussing all of
the potential considerations for specific authentication schemes the potential considerations for specific authentication schemes
(which ought to be documented in the specifications that define those (which ought to be documented in the specifications that define those
schemes). Various organizations maintain topical information and schemes). Various organizations maintain topical information and
links to current research on Web application security (e.g., links to current research on Web application security (e.g.,
[OWASP]), including common pitfalls for implementing and using the [OWASP]), including common pitfalls for implementing and using the
authentication schemes found in practice. authentication schemes found in practice.
12.14.1. Confidentiality of Credentials 13.14.1. Confidentiality of Credentials
The HTTP authentication framework does not define a single mechanism The HTTP authentication framework does not define a single mechanism
for maintaining the confidentiality of credentials; instead, each for maintaining the confidentiality of credentials; instead, each
authentication scheme defines how the credentials are encoded prior authentication scheme defines how the credentials are encoded prior
to transmission. While this provides flexibility for the development to transmission. While this provides flexibility for the development
of future authentication schemes, it is inadequate for the protection of future authentication schemes, it is inadequate for the protection
of existing schemes that provide no confidentiality on their own, or of existing schemes that provide no confidentiality on their own, or
that do not sufficiently protect against replay attacks. that do not sufficiently protect against replay attacks.
Furthermore, if the server expects credentials that are specific to Furthermore, if the server expects credentials that are specific to
each individual user, the exchange of those credentials will have the each individual user, the exchange of those credentials will have the
effect of identifying that user even if the content within effect of identifying that user even if the content within
credentials remains confidential. credentials remains confidential.
HTTP depends on the security properties of the underlying transport- HTTP depends on the security properties of the underlying transport-
or session-level connection to provide confidential transmission of or session-level connection to provide confidential transmission of
header fields. In other words, if a server limits access to header fields. In other words, if a server limits access to
authenticated users using this framework, the server needs to ensure authenticated users using this framework, the server needs to ensure
that the connection is properly secured in accordance with the nature that the connection is properly secured in accordance with the nature
of the authentication scheme used. For example, services that depend of the authentication scheme used. For example, services that depend
on individual user authentication often require a connection to be on individual user authentication often require a connection to be
secured with TLS ("Transport Layer Security", [RFC5246]) prior to secured with TLS ("Transport Layer Security", [RFC8446]) prior to
exchanging any credentials. exchanging any credentials.
12.14.2. Credentials and Idle Clients 13.14.2. Credentials and Idle Clients
Existing HTTP clients and user agents typically retain authentication Existing HTTP clients and user agents typically retain authentication
information indefinitely. HTTP does not provide a mechanism for the information indefinitely. HTTP does not provide a mechanism for the
origin server to direct clients to discard these cached credentials, origin server to direct clients to discard these cached credentials,
since the protocol has no awareness of how credentials are obtained since the protocol has no awareness of how credentials are obtained
or managed by the user agent. The mechanisms for expiring or or managed by the user agent. The mechanisms for expiring or
revoking credentials can be specified as part of an authentication revoking credentials can be specified as part of an authentication
scheme definition. scheme definition.
Circumstances under which credential caching can interfere with the Circumstances under which credential caching can interfere with the
skipping to change at page 161, line 38 skipping to change at page 166, line 33
o Applications that include a session termination indication (such o Applications that include a session termination indication (such
as a "logout" or "commit" button on a page) after which the server as a "logout" or "commit" button on a page) after which the server
side of the application "knows" that there is no further reason side of the application "knows" that there is no further reason
for the client to retain the credentials. for the client to retain the credentials.
User agents that cache credentials are encouraged to provide a User agents that cache credentials are encouraged to provide a
readily accessible mechanism for discarding cached credentials under readily accessible mechanism for discarding cached credentials under
user control. user control.
12.14.3. Protection Spaces 13.14.3. Protection Spaces
Authentication schemes that solely rely on the "realm" mechanism for Authentication schemes that solely rely on the "realm" mechanism for
establishing a protection space will expose credentials to all establishing a protection space will expose credentials to all
resources on an origin server. Clients that have successfully made resources on an origin server. Clients that have successfully made
authenticated requests with a resource can use the same authenticated requests with a resource can use the same
authentication credentials for other resources on the same origin authentication credentials for other resources on the same origin
server. This makes it possible for a different resource to harvest server. This makes it possible for a different resource to harvest
authentication credentials for other resources. authentication credentials for other resources.
This is of particular concern when an origin server hosts resources This is of particular concern when an origin server hosts resources
for multiple parties under the same canonical root URI for multiple parties under the same canonical root URI
(Section 8.5.2). Possible mitigation strategies include restricting (Section 8.5.2). Possible mitigation strategies include restricting
direct access to authentication credentials (i.e., not making the direct access to authentication credentials (i.e., not making the
content of the Authorization request header field available), and content of the Authorization request header field available), and
separating protection spaces by using a different host name (or port separating protection spaces by using a different host name (or port
number) for each party. number) for each party.
12.14.4. Additional Response Header Fields 13.14.4. Additional Response Header Fields
Adding information to responses that are sent over an unencrypted Adding information to responses that are sent over an unencrypted
channel can affect security and privacy. The presence of the channel can affect security and privacy. The presence of the
Authentication-Info and Proxy-Authentication-Info header fields alone Authentication-Info and Proxy-Authentication-Info header fields alone
indicates that HTTP authentication is in use. Additional information indicates that HTTP authentication is in use. Additional information
could be exposed by the contents of the authentication-scheme could be exposed by the contents of the authentication-scheme
specific parameters; this will have to be considered in the specific parameters; this will have to be considered in the
definitions of these schemes. definitions of these schemes.
13. IANA Considerations 14. IANA Considerations
The change controller for the following registrations is: "IETF The change controller for the following registrations is: "IETF
(iesg@ietf.org) - Internet Engineering Task Force". (iesg@ietf.org) - Internet Engineering Task Force".
13.1. URI Scheme Registration 14.1. URI Scheme Registration
Please update the registry of URI Schemes [BCP35] at Please update the registry of URI Schemes [BCP35] at
<https://www.iana.org/assignments/uri-schemes/> with the permanent <https://www.iana.org/assignments/uri-schemes/> with the permanent
schemes listed in the first table of Section 2.5. schemes listed in the first table of Section 2.5.
13.2. Method Registration 14.2. Method Registration
Please update the "Hypertext Transfer Protocol (HTTP) Method Please update the "Hypertext Transfer Protocol (HTTP) Method
Registry" at <https://www.iana.org/assignments/http-methods> with the Registry" at <https://www.iana.org/assignments/http-methods> with the
registration procedure of Section 7.4.1 and the method names registration procedure of Section 7.4.1 and the method names
summarized in the table of Section 7.2. summarized in the table of Section 7.2.
13.3. Status Code Registration 14.3. Status Code Registration
Please update the "Hypertext Transfer Protocol (HTTP) Status Code Please update the "Hypertext Transfer Protocol (HTTP) Status Code
Registry" at <https://www.iana.org/assignments/http-status-codes> Registry" at <https://www.iana.org/assignments/http-status-codes>
with the registration procedure of Section 9.7.1 and the status code with the registration procedure of Section 9.7.1 and the status code
values summarized in the table of Section 9.1. values summarized in the table of Section 9.1.
Additionally, please update the following entry in the Hypertext Additionally, please update the following entry in the Hypertext
Transfer Protocol (HTTP) Status Code Registry: Transfer Protocol (HTTP) Status Code Registry:
Value: 418 Value: 418
Description: (Unused) Description: (Unused)
Reference Section 9.5.19 Reference Section 9.5.19
13.4. Header Field Registration 14.4. Header Field Registration
Please create a new registry as outlined in Section 4.1.1. Please create a new registry as outlined in Section 4.1.1.
After creating the registry, all entries in the Permanent and After creating the registry, all entries in the Permanent and
Provisional Message Header Registries with the protocol 'http' are to Provisional Message Header Registries with the protocol 'http' are to
be moved to it, with the following changes applied: be moved to it, with the following changes applied:
1. The 'Applicable Protocol' field is to be omitted. 1. The 'Applicable Protocol' field is to be omitted.
2. Entries with a status of 'standard', 'experimental', or 2. Entries with a status of 'standard', 'experimental', or
skipping to change at page 163, line 39 skipping to change at page 168, line 39
After that is complete, please update the new registry with the After that is complete, please update the new registry with the
header field names listed in the table of Section 4.1. header field names listed in the table of Section 4.1.
Finally, please update the "Content-MD5" entry in the new registry to Finally, please update the "Content-MD5" entry in the new registry to
have a status of 'obsoleted' with references to Section 14.15 of have a status of 'obsoleted' with references to Section 14.15 of
[RFC2616] (for the definition of the header field) and Appendix B of [RFC2616] (for the definition of the header field) and Appendix B of
[RFC7231] (which removed the field definition from the updated [RFC7231] (which removed the field definition from the updated
specification). specification).
13.5. Authentication Scheme Registration 14.5. Authentication Scheme Registration
Please update the "Hypertext Transfer Protocol (HTTP) Authentication Please update the "Hypertext Transfer Protocol (HTTP) Authentication
Scheme Registry" at <https://www.iana.org/assignments/http- Scheme Registry" at <https://www.iana.org/assignments/http-
authschemes> with the registration procedure of Section 8.5.5.1. No authschemes> with the registration procedure of Section 8.5.5.1. No
authentication schemes are defined in this document. authentication schemes are defined in this document.
13.6. Content Coding Registration 14.6. Content Coding Registration
Please update the "HTTP Content Coding Registry" at Please update the "HTTP Content Coding Registry" at
<https://www.iana.org/assignments/http-parameters/> with the <https://www.iana.org/assignments/http-parameters/> with the
registration procedure of Section 6.1.2.4.1 and the content coding registration procedure of Section 6.1.2.4.1 and the content coding
names summarized in the table of Section 6.1.2. names summarized in the table of Section 6.1.2.
13.7. Range Unit Registration 14.7. Range Unit Registration
Please update the "HTTP Range Unit Registry" at Please update the "HTTP Range Unit Registry" at
<https://www.iana.org/assignments/http-parameters/> with the <https://www.iana.org/assignments/http-parameters/> with the
registration procedure of Section 6.1.4.3 and the range unit names registration procedure of Section 6.1.4.4 and the range unit names
summarized in the table of Section 6.1.4. summarized in the table of Section 6.1.4.
13.8. Media Type Registration 14.8. Media Type Registration
Please update the "Media Types" registry at Please update the "Media Types" registry at
<https://www.iana.org/assignments/media-types> with the registration <https://www.iana.org/assignments/media-types> with the registration
information in Section 6.3.4 for the media type "multipart/ information in Section 6.3.5 for the media type "multipart/
byteranges". byteranges".
14. References 14.9. Port Registration
14.1. Normative References Please update the "Service Name and Transport Protocol Port Number"
registry at <https://www.iana.org/assignments/service-names-port-
numbers/> for the services on ports 80 and 443 that use UDP or TCP
to:
1. use this document as "Reference", and
2. when currently unspecified, set "Assignee" to "IESG" and
"Contact" to "IETF_Chair".
15. 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-05 (work in Ed., "HTTP Caching", draft-ietf-httpbis-cache-06 (work in
progress), July 2019. progress), November 2019.
[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-05 Ed., "HTTP/1.1 Messaging", draft-ietf-httpbis-messaging-06
(work in progress), July 2019. (work in progress), November 2019.
[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 165, line 38 skipping to change at page 170, line 47
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>. <https://www.rfc-editor.org/info/rfc4648>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,
September 2009, <https://www.rfc-editor.org/info/rfc5646>. September 2009, <https://www.rfc-editor.org/info/rfc5646>.
[RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in
Internationalization in the IETF", BCP 166, RFC 6365, Internationalization in the IETF", BCP 166, RFC 6365,
DOI 10.17487/RFC6365, September 2011, DOI 10.17487/RFC6365, September 2011,
<https://www.rfc-editor.org/info/rfc6365>. <https://www.rfc-editor.org/info/rfc6365>.
[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
skipping to change at page 166, line 14 skipping to change at page 171, line 27
[USASCII] American National Standards Institute, "Coded Character [USASCII] American National Standards Institute, "Coded Character
Set -- 7-bit American Standard Code for Information Set -- 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986. Interchange", ANSI X3.4, 1986.
[Welch] Welch, T., "A Technique for High-Performance Data [Welch] Welch, T., "A Technique for High-Performance Data
Compression", IEEE Computer 17(6), Compression", IEEE Computer 17(6),
DOI 10.1109/MC.1984.1659158, June 1984, DOI 10.1109/MC.1984.1659158, June 1984,
<https://ieeexplore.ieee.org/document/1659158/>. <https://ieeexplore.ieee.org/document/1659158/>.
14.2. Informative References 15.2. Informative References
[BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type [BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, Specifications and Registration Procedures", BCP 13,
RFC 6838, January 2013, RFC 6838, January 2013,
<https://www.rfc-editor.org/info/bcp13>. <https://www.rfc-editor.org/info/bcp13>.
[BCP178] Saint-Andre, P., Crocker, D., and M. Nottingham, [BCP178] Saint-Andre, P., Crocker, D., and M. Nottingham,
"Deprecating the "X-" Prefix and Similar Constructs in "Deprecating the "X-" Prefix and Similar Constructs in
Application Protocols", BCP 178, RFC 6648, June 2012, Application Protocols", BCP 178, RFC 6648, June 2012,
<https://www.rfc-editor.org/info/bcp178>. <https://www.rfc-editor.org/info/bcp178>.
skipping to change at page 169, line 10 skipping to change at page 174, line 20
[RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based
Kerberos and NTLM HTTP Authentication in Microsoft Kerberos and NTLM HTTP Authentication in Microsoft
Windows", RFC 4559, DOI 10.17487/RFC4559, June 2006, Windows", RFC 4559, DOI 10.17487/RFC4559, June 2006,
<https://www.rfc-editor.org/info/rfc4559>. <https://www.rfc-editor.org/info/rfc4559>.
[RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed [RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed
Authoring and Versioning (WebDAV)", RFC 4918, Authoring and Versioning (WebDAV)", RFC 4918,
DOI 10.17487/RFC4918, June 2007, DOI 10.17487/RFC4918, June 2007,
<https://www.rfc-editor.org/info/rfc4918>. <https://www.rfc-editor.org/info/rfc4918>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>.
[RFC5322] Resnick, P., "Internet Message Format", RFC 5322, [RFC5322] Resnick, P., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008, DOI 10.17487/RFC5322, October 2008,
<https://www.rfc-editor.org/info/rfc5322>. <https://www.rfc-editor.org/info/rfc5322>.
[RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP", [RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP",
RFC 5789, DOI 10.17487/RFC5789, March 2010, RFC 5789, DOI 10.17487/RFC5789, March 2010,
<https://www.rfc-editor.org/info/rfc5789>. <https://www.rfc-editor.org/info/rfc5789>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>. <https://www.rfc-editor.org/info/rfc5905>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011, DOI 10.17487/RFC6265, April 2011,
<https://www.rfc-editor.org/info/rfc6265>. <https://www.rfc-editor.org/info/rfc6265>.
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
DOI 10.17487/RFC6454, December 2011,
<https://www.rfc-editor.org/info/rfc6454>.
[RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status [RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status
Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012, Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012,
<https://www.rfc-editor.org/info/rfc6585>. <https://www.rfc-editor.org/info/rfc6585>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014, RFC 7230, DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>. <https://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
skipping to change at page 170, line 37 skipping to change at page 175, line 47
[RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP [RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP
Digest Access Authentication", RFC 7616, Digest Access Authentication", RFC 7616,
DOI 10.17487/RFC7616, September 2015, DOI 10.17487/RFC7616, September 2015,
<https://www.rfc-editor.org/info/rfc7616>. <https://www.rfc-editor.org/info/rfc7616>.
[RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", [RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme",
RFC 7617, DOI 10.17487/RFC7617, September 2015, RFC 7617, DOI 10.17487/RFC7617, September 2015,
<https://www.rfc-editor.org/info/rfc7617>. <https://www.rfc-editor.org/info/rfc7617>.
[RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP
Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
April 2016, <https://www.rfc-editor.org/info/rfc7838>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8187] Reschke, J., "Indicating Character Encoding and Language [RFC8187] Reschke, J., "Indicating Character Encoding and Language
for HTTP Header Field Parameters", RFC 8187, for HTTP Header Field Parameters", RFC 8187,
DOI 10.17487/RFC8187, September 2017, DOI 10.17487/RFC8187, September 2017,
<https://www.rfc-editor.org/info/rfc8187>. <https://www.rfc-editor.org/info/rfc8187>.
[RFC8246] McManus, P., "HTTP Immutable Responses", RFC 8246, [RFC8246] McManus, P., "HTTP Immutable Responses", RFC 8246,
DOI 10.17487/RFC8246, September 2017, DOI 10.17487/RFC8246, September 2017,
<https://www.rfc-editor.org/info/rfc8246>. <https://www.rfc-editor.org/info/rfc8246>.
[RFC8288] Nottingham, M., "Web Linking", RFC 8288, [RFC8288] Nottingham, M., "Web Linking", RFC 8288,
DOI 10.17487/RFC8288, October 2017, DOI 10.17487/RFC8288, October 2017,
<https://www.rfc-editor.org/info/rfc8288>. <https://www.rfc-editor.org/info/rfc8288>.
[RFC8336] Nottingham, M. and E. Nygren, "The ORIGIN HTTP/2 Frame",
RFC 8336, DOI 10.17487/RFC8336, March 2018,
<https://www.rfc-editor.org/info/rfc8336>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[Sniffing] [Sniffing]
WHATWG, "MIME Sniffing", WHATWG, "MIME Sniffing",
<https://mimesniff.spec.whatwg.org>. <https://mimesniff.spec.whatwg.org>.
Appendix A. Collected ABNF Appendix A. Collected ABNF
In the collected ABNF below, list rules are expanded as per In the collected ABNF below, list rules are expanded as per
Section 11. Section 12.
Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [ Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
OWS ( media-range [ accept-params ] ) ] ) ] OWS ( media-range [ accept-params ] ) ] ) ]
Accept-Charset = *( "," OWS ) ( ( charset / "*" ) [ weight ] ) *( OWS Accept-Charset = *( "," OWS ) ( ( charset / "*" ) [ weight ] ) *( OWS
"," [ OWS ( ( charset / "*" ) [ weight ] ) ] ) "," [ OWS ( ( charset / "*" ) [ weight ] ) ] )
Accept-Encoding = [ ( "," / ( codings [ weight ] ) ) *( OWS "," [ OWS Accept-Encoding = [ ( "," / ( codings [ weight ] ) ) *( OWS "," [ OWS
( codings [ weight ] ) ] ) ] ( codings [ weight ] ) ] ) ]
Accept-Language = *( "," OWS ) ( language-range [ weight ] ) *( OWS Accept-Language = *( "," OWS ) ( language-range [ weight ] ) *( OWS
"," [ OWS ( language-range [ weight ] ) ] ) "," [ OWS ( language-range [ weight ] ) ] )
Accept-Ranges = acceptable-ranges Accept-Ranges = acceptable-ranges
skipping to change at page 172, line 31 skipping to change at page 177, line 31
Authorization = credentials Authorization = credentials
BWS = OWS BWS = OWS
Content-Encoding = [ content-coding ] *( OWS "," OWS [ content-coding Content-Encoding = [ content-coding ] *( OWS "," OWS [ content-coding
] ) ] )
Content-Language = [ language-tag ] *( OWS "," OWS [ language-tag ] Content-Language = [ language-tag ] *( OWS "," OWS [ language-tag ]
) )
Content-Length = 1*DIGIT Content-Length = 1*DIGIT
Content-Location = absolute-URI / partial-URI Content-Location = absolute-URI / partial-URI
Content-Range = byte-content-range / other-content-range Content-Range = range-unit SP ( range-resp / unsatisfied-range )
Content-Type = media-type Content-Type = media-type
Date = HTTP-date Date = HTTP-date
ETag = entity-tag ETag = entity-tag
Expect = "100-continue" Expect = "100-continue"
From = mailbox From = mailbox
GMT = %x47.4D.54 ; GMT GMT = %x47.4D.54 ; GMT
skipping to change at page 173, line 17 skipping to change at page 178, line 17
Max-Forwards = 1*DIGIT Max-Forwards = 1*DIGIT
OWS = *( SP / HTAB ) OWS = *( SP / HTAB )
Proxy-Authenticate = [ challenge ] *( OWS "," OWS [ challenge ] ) Proxy-Authenticate = [ challenge ] *( OWS "," OWS [ challenge ] )
Proxy-Authentication-Info = [ auth-param ] *( OWS "," OWS [ Proxy-Authentication-Info = [ auth-param ] *( OWS "," OWS [
auth-param ] ) auth-param ] )
Proxy-Authorization = credentials Proxy-Authorization = credentials
RWS = 1*( SP / HTAB ) RWS = 1*( SP / HTAB )
Range = byte-ranges-specifier / other-ranges-specifier Range = ranges-specifier
Referer = absolute-URI / partial-URI Referer = absolute-URI / partial-URI
Retry-After = HTTP-date / delay-seconds Retry-After = HTTP-date / delay-seconds
Server = product *( RWS ( product / comment ) ) Server = product *( RWS ( product / comment ) )
Trailer = [ field-name ] *( OWS "," OWS [ field-name ] ) Trailer = [ field-name ] *( OWS "," OWS [ field-name ] )
URI-reference = <URI-reference, see [RFC3986], Section 4.1> URI-reference = <URI-reference, see [RFC3986], Section 4.1>
User-Agent = product *( RWS ( product / comment ) ) User-Agent = product *( RWS ( product / comment ) )
skipping to change at page 173, line 46 skipping to change at page 178, line 46
absolute-path = 1*( "/" segment ) absolute-path = 1*( "/" segment )
accept-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ] accept-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ]
accept-params = weight *accept-ext accept-params = weight *accept-ext
acceptable-ranges = ( [ range-unit ] *( OWS "," OWS [ range-unit ] ) acceptable-ranges = ( [ range-unit ] *( OWS "," OWS [ range-unit ] )
) / "none" ) / "none"
asctime-date = day-name SP date3 SP time-of-day SP year asctime-date = day-name SP date3 SP time-of-day SP year
auth-param = token BWS "=" BWS ( token / quoted-string ) auth-param = token BWS "=" BWS ( token / quoted-string )
auth-scheme = token auth-scheme = token
authority = <authority, see [RFC3986], Section 3.2> authority = <authority, see [RFC3986], Section 3.2>
byte-content-range = bytes-unit SP ( byte-range-resp /
unsatisfied-range )
byte-range = first-byte-pos "-" last-byte-pos
byte-range-resp = byte-range "/" ( complete-length / "*" )
byte-range-set = *( "," OWS ) ( byte-range-spec /
suffix-byte-range-spec ) *( OWS "," [ OWS ( byte-range-spec /
suffix-byte-range-spec ) ] )
byte-range-spec = first-byte-pos "-" [ last-byte-pos ]
byte-ranges-specifier = bytes-unit "=" byte-range-set
bytes-unit = "bytes"
challenge = auth-scheme [ 1*SP ( token68 / ( [ auth-param ] *( OWS challenge = auth-scheme [ 1*SP ( token68 / ( [ auth-param ] *( OWS
"," OWS [ auth-param ] ) ) ) ] "," OWS [ auth-param ] ) ) ) ]
charset = token charset = token
codings = content-coding / "identity" / "*" codings = content-coding / "identity" / "*"
comment = "(" *( ctext / quoted-pair / comment ) ")" comment = "(" *( ctext / quoted-pair / comment ) ")"
complete-length = 1*DIGIT complete-length = 1*DIGIT
content-coding = token content-coding = token
credentials = auth-scheme [ 1*SP ( token68 / ( [ auth-param ] *( OWS credentials = auth-scheme [ 1*SP ( token68 / ( [ auth-param ] *( OWS
"," OWS [ auth-param ] ) ) ) ] "," OWS [ auth-param ] ) ) ) ]
ctext = HTAB / SP / %x21-27 ; '!'-''' ctext = HTAB / SP / %x21-27 ; '!'-'''
skipping to change at page 175, line 4 skipping to change at page 179, line 41
entity-tag = [ weak ] opaque-tag entity-tag = [ weak ] opaque-tag
etagc = "!" / %x23-7E ; '#'-'~' etagc = "!" / %x23-7E ; '#'-'~'
/ obs-text / obs-text
field-content = field-vchar [ 1*( SP / HTAB / field-vchar ) field-content = field-vchar [ 1*( SP / HTAB / field-vchar )
field-vchar ] field-vchar ]
field-name = token field-name = token
field-value = *( field-content / obs-fold ) field-value = *( field-content / obs-fold )
field-vchar = VCHAR / obs-text field-vchar = VCHAR / obs-text
first-byte-pos = 1*DIGIT first-pos = 1*DIGIT
hour = 2DIGIT hour = 2DIGIT
http-URI = "http://" authority path-abempty [ "?" query ] http-URI = "http://" authority path-abempty [ "?" query ]
https-URI = "https://" authority path-abempty [ "?" query ] https-URI = "https://" authority path-abempty [ "?" query ]
incl-range = first-pos "-" last-pos
int-range = first-pos "-" [ last-pos ]
language-range = <language-range, see [RFC4647], Section 2.1> language-range = <language-range, see [RFC4647], Section 2.1>
language-tag = <Language-Tag, see [RFC5646], Section 2.1> language-tag = <Language-Tag, see [RFC5646], Section 2.1>
last-byte-pos = 1*DIGIT last-pos = 1*DIGIT
mailbox = <mailbox, see [RFC5322], Section 3.4> mailbox = <mailbox, see [RFC5322], Section 3.4>
media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS
";" OWS parameter ) ";" OWS parameter )
media-type = type "/" subtype *( OWS ";" OWS parameter ) media-type = type "/" subtype *( OWS ";" OWS parameter )
method = token method = token
minute = 2DIGIT minute = 2DIGIT
month = %x4A.61.6E ; Jan month = %x4A.61.6E ; Jan
/ %x46.65.62 ; Feb / %x46.65.62 ; Feb
/ %x4D.61.72 ; Mar / %x4D.61.72 ; Mar
skipping to change at page 175, line 37 skipping to change at page 180, line 29
/ %x41.75.67 ; Aug / %x41.75.67 ; Aug
/ %x53.65.70 ; Sep / %x53.65.70 ; Sep
/ %x4F.63.74 ; Oct / %x4F.63.74 ; Oct
/ %x4E.6F.76 ; Nov / %x4E.6F.76 ; Nov
/ %x44.65.63 ; Dec / %x44.65.63 ; Dec
obs-date = rfc850-date / asctime-date obs-date = rfc850-date / asctime-date
obs-fold = <obs-fold, see [Messaging], Section 5.2> obs-fold = <obs-fold, see [Messaging], Section 5.2>
obs-text = %x80-FF obs-text = %x80-FF
opaque-tag = DQUOTE *etagc DQUOTE opaque-tag = DQUOTE *etagc DQUOTE
other-content-range = other-range-unit SP other-range-resp other-range = 1*( %x21-2B ; '!'-'+'
other-range-resp = *VCHAR / %x2D-7E ; '-'-'~'
other-range-set = 1*VCHAR )
other-range-unit = token
other-ranges-specifier = other-range-unit "=" other-range-set
parameter = parameter-name "=" parameter-value parameter = parameter-name "=" parameter-value
parameter-name = token parameter-name = token
parameter-value = ( token / quoted-string ) parameter-value = ( token / quoted-string )
partial-URI = relative-part [ "?" query ] partial-URI = relative-part [ "?" query ]
path-abempty = <path-abempty, see [RFC3986], Section 3.3> path-abempty = <path-abempty, see [RFC3986], Section 3.3>
port = <port, see [RFC3986], Section 3.2.3> port = <port, see [RFC3986], Section 3.2.3>
product = token [ "/" product-version ] product = token [ "/" product-version ]
product-version = token product-version = token
protocol-name = <protocol-name, see [Messaging], Section 9.8> protocol-name = <protocol-name, see [Messaging], Section 9.8>
protocol-version = <protocol-version, see [Messaging], Section 9.8> protocol-version = <protocol-version, see [Messaging], Section 9.8>
pseudonym = token pseudonym = token
qdtext = HTAB / SP / "!" / %x23-5B ; '#'-'[' qdtext = HTAB / SP / "!" / %x23-5B ; '#'-'['
/ %x5D-7E ; ']'-'~' / %x5D-7E ; ']'-'~'
/ obs-text / obs-text
query = <query, see [RFC3986], Section 3.4> query = <query, see [RFC3986], Section 3.4>
quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text ) quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] ) qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
range-resp = incl-range "/" ( complete-length / "*" )
range-unit = bytes-unit / other-range-unit range-set = [ range-spec ] *( OWS "," OWS [ range-spec ] )
range-spec = int-range / suffix-range / other-range
range-unit = token
ranges-specifier = range-unit "=" range-set
received-by = ( uri-host [ ":" port ] ) / pseudonym received-by = ( uri-host [ ":" port ] ) / pseudonym
received-protocol = [ protocol-name "/" ] protocol-version received-protocol = [ protocol-name "/" ] protocol-version
relative-part = <relative-part, see [RFC3986], Section 4.2> relative-part = <relative-part, see [RFC3986], Section 4.2>
request-target = <request-target, see [Messaging], Section 3.2> request-target = <request-target, see [Messaging], Section 3.2>
rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT
second = 2DIGIT second = 2DIGIT
segment = <segment, see [RFC3986], Section 3.3> segment = <segment, see [RFC3986], Section 3.3>
subtype = token subtype = token
suffix-byte-range-spec = "-" suffix-length
suffix-length = 1*DIGIT suffix-length = 1*DIGIT
suffix-range = "-" suffix-length
tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." / tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." /
"^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA
time-of-day = hour ":" minute ":" second time-of-day = hour ":" minute ":" second
token = 1*tchar token = 1*tchar
token68 = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" ) token68 = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" )
*"=" *"="
type = token type = token
unsatisfied-range = "*/" complete-length unsatisfied-range = "*/" complete-length
uri-host = <host, see [RFC3986], Section 3.2.2> uri-host = <host, see [RFC3986], Section 3.2.2>
weak = %x57.2F ; W/ weak = %x57.2F ; W/
weight = OWS ";" OWS "q=" qvalue weight = OWS ";" OWS "q=" qvalue
year = 4DIGIT year = 4DIGIT
Appendix B. Changes from RFC 7230 Appendix B. Changes from RFC 7230
Most of the sections introducing HTTP's design goals, history, The sections introducing HTTP's design goals, history, architecture,
architecture, conformance criteria, protocol versioning, URIs, conformance criteria, protocol versioning, URIs, message routing, and
message routing, and header field values have been moved here header fields have been moved here (without substantive change).
(without substantive change).
Furthermore: Trailer field semantics now transcend the specifics of chunked
encoding. Use of trailer fields has been further limited to only
allow generation as a trailer field when the sender knows the field
defines that usage and to only allow merging into the header section
if the recipient knows the corresponding field definition permits and
defines how to merge. In all other cases, implementations are
encouraged to either store the trailer fields separately or discard
them instead of merging (Section 4.3.2).
Add status code 308 (previously defined in [RFC7538]) so that it's Added status code 308 (previously defined in [RFC7538]) so that it's
defined closer to status codes 301, 302, and 307. (Section 9.4.9) defined closer to status codes 301, 302, and 307 (Section 9.4.9).
Add status code 422 (previously defined in Section 11.2 of [RFC4918]) Added status code 422 (previously defined in Section 11.2 of
because of it's general applicability. (Section 9.5.20) [RFC4918]) because of its general applicability (Section 9.5.20).
Appendix C. Changes from RFC 7231 Appendix C. Changes from RFC 2818
None yet. None yet.
Appendix D. Changes from RFC 7232 Appendix D. Changes from RFC 7231
None yet. Restrictions on client retries have been loosened, to reflect
implementation behavior. (Section 7.2.2)
Appendix E. Changes from RFC 7233 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
recommended. (Section 2.5)
Clarified that request bodies on GET are not interoperable.
(Section 7.3.1)
Appendix E. Changes from RFC 7232
None yet. None yet.
Appendix F. Changes from RFC 7235 Appendix F. Changes from RFC 7233
Refactored the range-unit and ranges-specifier grammars to simplify
and reduce artificial distinctions between bytes and other
(extension) range units, removing the overlapping grammar of other-
range-unit by defining range units generically as a token and placing
extensions within the scope of a range-spec (other-range). This
disambiguates the role of list syntax (commas) in all range sets,
including extension range units, for indicating a range-set of more
than one range. Moving the extension grammar into range specifiers
also allows protocol specific to byte ranges to be specified
separately.
Appendix G. Changes from RFC 7235
None yet. None yet.
Appendix G. Changes from RFC 7538 Appendix H. Changes from RFC 7538
None yet. None yet.
Appendix H. Changes from RFC 7615 Appendix I. Changes from RFC 7615
None yet. None yet.
Appendix I. Change Log Appendix J. Change Log
This section is to be removed before publishing as an RFC. This section is to be removed before publishing as an RFC.
I.1. Between RFC723x and draft 00 J.1. Between RFC723x and draft 00
The changes were purely editorial: The changes were purely editorial:
o Change boilerplate and abstract to indicate the "draft" status, o Change boilerplate and abstract to indicate the "draft" status,
and update references to ancestor specifications. and update references to ancestor specifications.
o Remove version "1.1" from document title, indicating that this o Remove version "1.1" from document title, indicating that this
specification applies to all HTTP versions. specification applies to all HTTP versions.
o Adjust historical notes. o Adjust historical notes.
o Update links to sibling specifications. o Update links to sibling specifications.
o Replace sections listing changes from RFC 2616 by new empty o Replace sections listing changes from RFC 2616 by new empty
sections referring to RFC 723x. sections referring to RFC 723x.
o Remove acknowledgements specific to RFC 723x. o Remove acknowledgements specific to RFC 723x.
o Move "Acknowledgements" to the very end and make them unnumbered. o Move "Acknowledgements" to the very end and make them unnumbered.
I.2. Since draft-ietf-httpbis-semantics-00 J.2. Since draft-ietf-httpbis-semantics-00
The changes in this draft are editorial, with respect to HTTP as a The changes in this draft are editorial, with respect to HTTP as a
whole, to merge core HTTP semantics into this document: whole, to merge core HTTP semantics into this document:
o Merged introduction, architecture, conformance, and ABNF o Merged introduction, architecture, conformance, and ABNF
extensions from RFC 7230 (Messaging). extensions from RFC 7230 (Messaging).
o Rearranged architecture to extract conformance, http(s) schemes, o Rearranged architecture to extract conformance, http(s) schemes,
and protocol versioning into a separate major section. and protocol versioning into a separate major section.
skipping to change at page 178, line 37 skipping to change at page 184, line 14
o Merged entire content of RFC 7233 (Range Requests). o Merged entire content of RFC 7233 (Range Requests).
o Merged entire content of RFC 7235 (Auth Framework). o Merged entire content of RFC 7235 (Auth Framework).
o Moved all extensibility tips, registration procedures, and o Moved all extensibility tips, registration procedures, and
registry tables from the IANA considerations to normative registry tables from the IANA considerations to normative
sections, reducing the IANA considerations to just instructions sections, reducing the IANA considerations to just instructions
that will be removed prior to publication as an RFC. that will be removed prior to publication as an RFC.
I.3. Since draft-ietf-httpbis-semantics-01 J.3. Since draft-ietf-httpbis-semantics-01
o Improve [Welch] citation (<https://github.com/httpwg/http-core/ o Improve [Welch] citation (<https://github.com/httpwg/http-core/
issues/63>) issues/63>)
o Remove HTTP/1.1-ism about Range Requests o Remove HTTP/1.1-ism about Range Requests
(<https://github.com/httpwg/http-core/issues/71>) (<https://github.com/httpwg/http-core/issues/71>)
o Cite RFC 8126 instead of RFC 5226 (<https://github.com/httpwg/ o Cite RFC 8126 instead of RFC 5226 (<https://github.com/httpwg/
http-core/issues/75>) http-core/issues/75>)
skipping to change at page 179, line 29 skipping to change at page 185, line 9
<https://www.rfc-editor.org/errata/eid4664>) <https://www.rfc-editor.org/errata/eid4664>)
o Resolved erratum 4072, no change needed here o Resolved erratum 4072, no change needed here
(<https://github.com/httpwg/http-core/issues/84>, (<https://github.com/httpwg/http-core/issues/84>,
<https://www.rfc-editor.org/errata/eid4072>) <https://www.rfc-editor.org/errata/eid4072>)
o Clarify DELETE status code suggestions o Clarify DELETE status code suggestions
(<https://github.com/httpwg/http-core/issues/85>, (<https://github.com/httpwg/http-core/issues/85>,
<https://www.rfc-editor.org/errata/eid4436>) <https://www.rfc-editor.org/errata/eid4436>)
o In Section 6.3.3, fix ABNF for "other-range-resp" to use VCHAR o In Section 6.3.4, fix ABNF for "other-range-resp" to use VCHAR
instead of CHAR (<https://github.com/httpwg/http-core/issues/86>, instead of CHAR (<https://github.com/httpwg/http-core/issues/86>,
<https://www.rfc-editor.org/errata/eid4707>) <https://www.rfc-editor.org/errata/eid4707>)
o Resolved erratum 5162, no change needed here o Resolved erratum 5162, no change needed here
(<https://github.com/httpwg/http-core/issues/89>, (<https://github.com/httpwg/http-core/issues/89>,
<https://www.rfc-editor.org/errata/eid5162>) <https://www.rfc-editor.org/errata/eid5162>)
o Replace "response code" with "response status code" and "status- o Replace "response code" with "response status code" and "status-
code" (the ABNF production name from the HTTP/1.1 message format) code" (the ABNF production name from the HTTP/1.1 message format)
by "status code" (<https://github.com/httpwg/http-core/issues/94>, by "status code" (<https://github.com/httpwg/http-core/issues/94>,
<https://www.rfc-editor.org/errata/eid4050>) <https://www.rfc-editor.org/errata/eid4050>)
o Added a missing word in Section 9.4 (<https://github.com/httpwg/ o Added a missing word in Section 9.4 (<https://github.com/httpwg/
http-core/issues/98>, <https://www.rfc-editor.org/errata/eid4452>) http-core/issues/98>, <https://www.rfc-editor.org/errata/eid4452>)
o In Section 11, fixed an example that had trailing whitespace where o In Section 12, fixed an example that had trailing whitespace where
it shouldn't (<https://github.com/httpwg/http-core/issues/104>, it shouldn't (<https://github.com/httpwg/http-core/issues/104>,
<https://www.rfc-editor.org/errata/eid4169>) <https://www.rfc-editor.org/errata/eid4169>)
o In Section 9.3.7, remove words that were potentially misleading o In Section 9.3.7, remove words that were potentially misleading
with respect to the relation to the requested ranges with respect to the relation to the requested ranges
(<https://github.com/httpwg/http-core/issues/102>, (<https://github.com/httpwg/http-core/issues/102>,
<https://www.rfc-editor.org/errata/eid4358>) <https://www.rfc-editor.org/errata/eid4358>)
I.4. Since draft-ietf-httpbis-semantics-02 J.4. Since draft-ietf-httpbis-semantics-02
o Included (Proxy-)Auth-Info header field definition from RFC 7615 o Included (Proxy-)Auth-Info header field definition from RFC 7615
(<https://github.com/httpwg/http-core/issues/9>) (<https://github.com/httpwg/http-core/issues/9>)
o In Section 7.3.3, clarify POST caching o In Section 7.3.3, clarify POST caching
(<https://github.com/httpwg/http-core/issues/17>) (<https://github.com/httpwg/http-core/issues/17>)
o Add Section 9.5.19 to reserve the 418 status code o Add Section 9.5.19 to reserve the 418 status code
(<https://github.com/httpwg/http-core/issues/43>) (<https://github.com/httpwg/http-core/issues/43>)
skipping to change at page 180, line 46 skipping to change at page 186, line 27
issues/123>) issues/123>)
o In Section 9.5.17, fixed prose about byte range comparison o In Section 9.5.17, fixed prose about byte range comparison
(<https://github.com/httpwg/http-core/issues/135>, (<https://github.com/httpwg/http-core/issues/135>,
<https://www.rfc-editor.org/errata/eid5474>) <https://www.rfc-editor.org/errata/eid5474>)
o In Section 2.1, explain that request/response correlation is o In Section 2.1, explain that request/response correlation is
version specific (<https://github.com/httpwg/http-core/ version specific (<https://github.com/httpwg/http-core/
issues/145>) issues/145>)
I.5. Since draft-ietf-httpbis-semantics-03 J.5. Since draft-ietf-httpbis-semantics-03
o In Section 9.4.9, include status code 308 from RFC 7538 o In Section 9.4.9, include status code 308 from RFC 7538
(<https://github.com/httpwg/http-core/issues/3>) (<https://github.com/httpwg/http-core/issues/3>)
o In Section 6.1.1, clarify that the charset parameter value is o In Section 6.1.1, clarify that the charset parameter value is
case-insensitive due to the definition in RFC 2046 case-insensitive due to the definition in RFC 2046
(<https://github.com/httpwg/http-core/issues/13>) (<https://github.com/httpwg/http-core/issues/13>)
o Define a separate registry for HTTP header field names o Define a separate registry for HTTP header field names
(<https://github.com/httpwg/http-core/issues/42>) (<https://github.com/httpwg/http-core/issues/42>)
skipping to change at page 181, line 24 skipping to change at page 186, line 51
o Deprecate Accept-Charset (<https://github.com/httpwg/http-core/ o Deprecate Accept-Charset (<https://github.com/httpwg/http-core/
issues/61>) issues/61>)
o In Section 8.2.1, mention Cache-Control: immutable o In Section 8.2.1, mention Cache-Control: immutable
(<https://github.com/httpwg/http-core/issues/69>) (<https://github.com/httpwg/http-core/issues/69>)
o In Section 4.2.1, clarify when header field combination is allowed o In Section 4.2.1, clarify when header field combination is allowed
(<https://github.com/httpwg/http-core/issues/74>) (<https://github.com/httpwg/http-core/issues/74>)
o In Section 13.4, instruct IANA to mark Content-MD5 as obsolete o In Section 14.4, instruct IANA to mark Content-MD5 as obsolete
(<https://github.com/httpwg/http-core/issues/93>) (<https://github.com/httpwg/http-core/issues/93>)
o Use RFC 7405 ABNF notation for case-sensitive string constants o Use RFC 7405 ABNF notation for case-sensitive string constants
(<https://github.com/httpwg/http-core/issues/133>) (<https://github.com/httpwg/http-core/issues/133>)
o Rework Section 2.1 to be more version-independent o Rework Section 2.1 to be more version-independent
(<https://github.com/httpwg/http-core/issues/142>) (<https://github.com/httpwg/http-core/issues/142>)
o In Section 7.3.5, clarify that DELETE needs to be successful to o In Section 7.3.5, clarify that DELETE needs to be successful to
invalidate cache (<https://github.com/httpwg/http-core/ invalidate cache (<https://github.com/httpwg/http-core/
issues/167>, <https://www.rfc-editor.org/errata/eid5541>) issues/167>, <https://www.rfc-editor.org/errata/eid5541>)
I.6. Since draft-ietf-httpbis-semantics-04 J.6. Since draft-ietf-httpbis-semantics-04
o In Section 4.2, fix field-content ABNF o In Section 4.2, fix field-content ABNF
(<https://github.com/httpwg/http-core/issues/19>, (<https://github.com/httpwg/http-core/issues/19>,
<https://www.rfc-editor.org/errata/eid4189>) <https://www.rfc-editor.org/errata/eid4189>)
o Move Section 4.2.3.4 into its own section o Move Section 4.2.3.4 into its own section
(<https://github.com/httpwg/http-core/issues/45>) (<https://github.com/httpwg/http-core/issues/45>)
o In Section 6.2.1, reference MIME Sniffing o In Section 6.2.1, reference MIME Sniffing
(<https://github.com/httpwg/http-core/issues/51>) (<https://github.com/httpwg/http-core/issues/51>)
o In Section 11, simplify the #rule mapping for recipients o In Section 12, simplify the #rule mapping for recipients
(<https://github.com/httpwg/http-core/issues/164>, (<https://github.com/httpwg/http-core/issues/164>,
<https://www.rfc-editor.org/errata/eid5257>) <https://www.rfc-editor.org/errata/eid5257>)
o In Section 7.3.7, remove misleading text about "extension" of HTTP o In Section 7.3.7, remove misleading text about "extension" of HTTP
is needed to define method payloads (<https://github.com/httpwg/ is needed to define method payloads (<https://github.com/httpwg/
http-core/issues/204>) http-core/issues/204>)
o Fix editorial issue in Section 6 (<https://github.com/httpwg/http- o Fix editorial issue in Section 6 (<https://github.com/httpwg/http-
core/issues/223>) core/issues/223>)
o In Section 9.5.20, rephrase language not to use "entity" anymore, o In Section 9.5.20, rephrase language not to use "entity" anymore,
and also avoid lowercase "may" (<https://github.com/httpwg/http- and also avoid lowercase "may" (<https://github.com/httpwg/http-
core/issues/224>) core/issues/224>)
o Move discussion of retries from [Messaging] into Section 7.2.2 o Move discussion of retries from [Messaging] into Section 7.2.2
(<https://github.com/httpwg/http-core/issues/230>) (<https://github.com/httpwg/http-core/issues/230>)
J.7. Since draft-ietf-httpbis-semantics-05
o Moved transport-independent part of the description of trailers
into Section 4.3 (<https://github.com/httpwg/http-core/issues/16>)
o Loosen requirements on retries based upon implementation behavior
(<https://github.com/httpwg/http-core/issues/27>)
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>)
o In Section 4.4, revise guidelines for new header field names
(<https://github.com/httpwg/http-core/issues/47>)
o In Section 7.2.3, remove concept of "cacheable methods" in favor
of prose (<https://github.com/httpwg/http-core/issues/54>)
o In Section 13.1, mention that the concept of authority can be
modified by protocol extensions (<https://github.com/httpwg/http-
core/issues/143>)
o Create new subsection on payload body in Section 6.3.3, taken from
portions of message body (<https://github.com/httpwg/http-core/
issues/159>)
o Moved definition of "Whitespace" into new container "Generic
Syntax" (Section 11) (<https://github.com/httpwg/http-core/
issues/162>)
o In Section 2.5, recommend minimum URI size support for
implementations (<https://github.com/httpwg/http-core/issues/169>)
o In Section 6.1.4, refactored the range-unit and ranges-specifier
grammars (<https://github.com/httpwg/http-core/issues/196>)
o In Section 7.3.1, caution against a request body more strongly
(<https://github.com/httpwg/http-core/issues/202>)
o Reorganized text in Section 4.4 (<https://github.com/httpwg/http-
core/issues/214>)
o In Section 9.5.4, replace "authorize" with "fulfill"
(<https://github.com/httpwg/http-core/issues/218>)
o In Section 7.3.7, removed a misleading statement about Content-
Length (<https://github.com/httpwg/http-core/issues/235>,
<https://www.rfc-editor.org/errata/eid5806>)
o In Section 13.1, add text from RFC 2818
(<https://github.com/httpwg/http-core/issues/236>)
o Changed "cacheable by default" to "heuristically cacheable"
throughout (<https://github.com/httpwg/http-core/issues/242>)
Index Index
1 1
100 Continue (status code) 110 100 Continue (status code) 114
100-continue (expect value) 77 100-continue (expect value) 81
101 Switching Protocols (status code) 110 101 Switching Protocols (status code) 114
1xx Informational (status code class) 109 1xx Informational (status code class) 113
2 2
200 OK (status code) 110 200 OK (status code) 114
201 Created (status code) 111 201 Created (status code) 115
202 Accepted (status code) 111 202 Accepted (status code) 115
203 Non-Authoritative Information (status code) 112 203 Non-Authoritative Information (status code) 116
204 No Content (status code) 112 204 No Content (status code) 116
205 Reset Content (status code) 113 205 Reset Content (status code) 117
206 Partial Content (status code) 113 206 Partial Content (status code) 117
2xx Successful (status code class) 110 2xx Successful (status code class) 114
3 3
300 Multiple Choices (status code) 118 300 Multiple Choices (status code) 122
301 Moved Permanently (status code) 119 301 Moved Permanently (status code) 123
302 Found (status code) 119 302 Found (status code) 123
303 See Other (status code) 120 303 See Other (status code) 124
304 Not Modified (status code) 120 304 Not Modified (status code) 124
305 Use Proxy (status code) 121 305 Use Proxy (status code) 125
306 (Unused) (status code) 121 306 (Unused) (status code) 125
307 Temporary Redirect (status code) 121 307 Temporary Redirect (status code) 125
308 Permanent Redirect (status code) 122 308 Permanent Redirect (status code) 126
3xx Redirection (status code class) 116 3xx Redirection (status code class) 120
4 4
400 Bad Request (status code) 122 400 Bad Request (status code) 126
401 Unauthorized (status code) 122 401 Unauthorized (status code) 126
402 Payment Required (status code) 123 402 Payment Required (status code) 127
403 Forbidden (status code) 123 403 Forbidden (status code) 127
404 Not Found (status code) 123 404 Not Found (status code) 127
405 Method Not Allowed (status code) 124 405 Method Not Allowed (status code) 128
406 Not Acceptable (status code) 124 406 Not Acceptable (status code) 128
407 Proxy Authentication Required (status code) 124 407 Proxy Authentication Required (status code) 128
408 Request Timeout (status code) 124 408 Request Timeout (status code) 128
409 Conflict (status code) 125 409 Conflict (status code) 129
410 Gone (status code) 125 410 Gone (status code) 129
411 Length Required (status code) 125 411 Length Required (status code) 129
412 Precondition Failed (status code) 126 412 Precondition Failed (status code) 130
413 Payload Too Large (status code) 126 413 Payload Too Large (status code) 130
414 URI Too Long (status code) 126 414 URI Too Long (status code) 130
415 Unsupported Media Type (status code) 126 415 Unsupported Media Type (status code) 130
416 Range Not Satisfiable (status code) 127 416 Range Not Satisfiable (status code) 131
417 Expectation Failed (status code) 127 417 Expectation Failed (status code) 131
418 (Unused) (status code) 127 418 (Unused) (status code) 131
422 Unprocessable Payload (status code) 128 422 Unprocessable Payload (status code) 132
426 Upgrade Required (status code) 128 426 Upgrade Required (status code) 132
4xx Client Error (status code class) 122 4xx Client Error (status code class) 126
5 5
500 Internal Server Error (status code) 129 500 Internal Server Error (status code) 133
501 Not Implemented (status code) 129 501 Not Implemented (status code) 133
502 Bad Gateway (status code) 129 502 Bad Gateway (status code) 133
503 Service Unavailable (status code) 129 503 Service Unavailable (status code) 133
504 Gateway Timeout (status code) 129 504 Gateway Timeout (status code) 133
505 HTTP Version Not Supported (status code) 129 505 HTTP Version Not Supported (status code) 133
5xx Server Error (status code class) 128 5xx Server Error (status code class) 132
A A
Accept header field 93 Accept header field 97
Accept-Charset header field 95 Accept-Charset header field 99
Accept-Encoding header field 96 Accept-Encoding header field 100
Accept-Language header field 97 Accept-Language header field 101
Accept-Ranges header field 150 Accept-Ranges header field 154
Allow header field 150 Allow header field 154
Authentication-Info header field 148 Authentication-Info header field 152
Authorization header field 101 Authorization header field 105
accelerator 13 accelerator 13
authoritative response 153 authoritative response 158
B B
browser 10 browser 10
C C
CONNECT method 72 CONNECT method 76
Canonical Root URI 100 Canonical Root URI 104
Content-Encoding header field 49 Content-Encoding header field 52
Content-Language header field 50 Content-Language header field 53
Content-Length header field 50 Content-Length header field 54
Content-Location header field 52 Content-Location header field 55
Content-MD5 header field 163 Content-MD5 header field 168
Content-Range header field 55 Content-Range header field 59
Content-Type header field 48 Content-Type header field 51
cache 14 cache 14
cacheable 14, 66 cacheable 14
captive portal 13 captive portal 14
client 10 client 10
compress (Coding Format) 43 compress (Coding Format) 45
compress (content coding) 42 compress (content coding) 44
conditional request 80 conditional request 84
connection 10 connection 10
content coding 42 content coding 44
content negotiation 8 content negotiation 9
D D
DELETE method 71 DELETE method 75
Date header field 134 Date header field 138
Delimiters 29 Delimiters 30
deflate (Coding Format) 43 deflate (Coding Format) 45
deflate (content coding) 42 deflate (content coding) 44
downstream 12 downstream 12
E E
ETag header field 142 ETag header field 146
Expect header field 77 Expect header field 81
effective request URI 34 effective request URI 36
F F
Fragment Identifiers 18 Fragment Identifiers 20
From header field 104 From header field 108
G G
GET method 66 GET method 70
Grammar Grammar
absolute-path 15 absolute-path 15
absolute-URI 15 absolute-URI 15
Accept 93 Accept 97
Accept-Charset 95 Accept-Charset 99
Accept-Encoding 96 Accept-Encoding 100
accept-ext 93 accept-ext 97
Accept-Language 97 Accept-Language 101
accept-params 93 accept-params 97
Accept-Ranges 150 Accept-Ranges 154
acceptable-ranges 150 acceptable-ranges 154
Allow 150 Allow 154
ALPHA 9 ALPHA 9
asctime-date 133 asctime-date 137
auth-param 99 auth-param 103
auth-scheme 99 auth-scheme 103
Authentication-Info 148 Authentication-Info 152
authority 15 authority 15
Authorization 101 Authorization 105
BWS 32 BWS 156
byte-content-range 56 challenge 103
byte-range 56 charset 43
byte-range-resp 56 codings 100
byte-range-set 45 comment 31
byte-range-spec 45 complete-length 60
byte-ranges-specifier 45 content-coding 44
bytes-unit 44-45 Content-Encoding 52
challenge 99 Content-Language 53
charset 40 Content-Length 54
codings 96 Content-Location 55
comment 30 Content-Range 60
complete-length 56 Content-Type 51
content-coding 42
Content-Encoding 49
Content-Language 50
Content-Length 50
Content-Location 52
Content-Range 56
Content-Type 48
CR 9 CR 9
credentials 100 credentials 104
CRLF 9 CRLF 9
ctext 30 ctext 31
CTL 9 CTL 9
Date 134 Date 138
date1 133 date1 137
day 133 day 137
day-name 133 day-name 137
day-name-l 133 day-name-l 137
delay-seconds 136 delay-seconds 140
DIGIT 9 DIGIT 9
DQUOTE 9 DQUOTE 9
entity-tag 143 entity-tag 147
ETag 143 ETag 147
etagc 143 etagc 147
Expect 77 Expect 81
field-content 28 field-content 28
field-name 23, 32 field-name 25, 33
field-value 28 field-value 28
field-vchar 28 field-vchar 28
first-byte-pos 45 first-pos 48, 60
From 104 From 108
GMT 133 GMT 137
HEXDIG 9 HEXDIG 9
Host 34 Host 37
hour 133 hour 137
HTAB 9 HTAB 9
HTTP-date 132 HTTP-date 136
http-URI 16 http-URI 16
https-URI 18 https-URI 18
If-Match 84 If-Match 88
If-Modified-Since 86 If-Modified-Since 90
If-None-Match 85 If-None-Match 89
If-Range 89 If-Range 93
If-Unmodified-Since 87 If-Unmodified-Since 91
IMF-fixdate 133 IMF-fixdate 137
language-range 97 incl-range 60
language-tag 44 int-range 48
last-byte-pos 45 language-range 101
Last-Modified 140 language-tag 46
Last-Modified 144
last-pos 48, 60
LF 9 LF 9
Location 135 Location 139
Max-Forwards 79 Max-Forwards 83
media-range 93 media-range 97
media-type 40 media-type 42
method 62 method 66
minute 133 minute 137
month 133 month 137
obs-date 133 obs-date 137
obs-text 30 obs-text 30
OCTET 9 OCTET 9
opaque-tag 143 opaque-tag 147
other-content-range 56 other-range 48
other-range-resp 56 OWS 156
other-range-unit 44, 47 parameter 31
OWS 32 parameter-name 31
parameter 30 parameter-value 31
parameter-name 30
parameter-value 30
partial-URI 15 partial-URI 15
port 15 port 15
product 106 product 110
product-version 106 product-version 110
protocol-name 36 protocol-name 39
protocol-version 36 protocol-version 39
Proxy-Authenticate 148 Proxy-Authenticate 152
Proxy-Authentication-Info 149 Proxy-Authentication-Info 153
Proxy-Authorization 101 Proxy-Authorization 105
pseudonym 36 pseudonym 39
qdtext 30 qdtext 30
query 15 query 15
quoted-pair 30 quoted-pair 31
quoted-string 30 quoted-string 30
qvalue 93 qvalue 97
Range 90 Range 94
range-unit 44 range-resp 60
ranges-specifier 45 range-set 48
received-by 36 range-spec 48
received-protocol 36 range-unit 47
Referer 105 ranges-specifier 48
Retry-After 136 received-by 39
rfc850-date 133 received-protocol 39
RWS 32 Referer 109
second 133 Retry-After 140
rfc850-date 137
RWS 156
second 137
segment 15 segment 15
Server 151 Server 155
SP 9 SP 9
subtype 40 subtype 42
suffix-byte-range-spec 46 suffix-length 48
suffix-length 46 suffix-range 48
tchar 29 tchar 30
time-of-day 133 time-of-day 137
token 29 token 30
token68 99 token68 103
Trailer 32 Trailer 33
type 40 type 42
unsatisfied-range 56 unsatisfied-range 60
uri-host 15 uri-host 15
URI-reference 15 URI-reference 15
User-Agent 106 User-Agent 110
Vary 137 Vary 141
VCHAR 9 VCHAR 9
Via 36 Via 39
weak 143 weak 147
weight 93 weight 97
WWW-Authenticate 147 WWW-Authenticate 151
year 133 year 137
gateway 13 gateway 13
gzip (Coding Format) 43 gzip (Coding Format) 45
gzip (content coding) 42 gzip (content coding) 44
H H
HEAD method 67 HEAD method 71
Host header field 34 Host header field 37
http URI scheme 16 http URI scheme 16
https URI scheme 17 https URI scheme 18
I I
If-Match header field 84 If-Match header field 88
If-Modified-Since header field 86 If-Modified-Since header field 90
If-None-Match header field 85 If-None-Match header field 89
If-Range header field 88 If-Range header field 93
If-Unmodified-Since header field 87 If-Unmodified-Since header field 91
idempotent 65 idempotent 69
inbound 12 inbound 12
interception proxy 13 interception proxy 14
intermediary 12 intermediary 12
L L
Last-Modified header field 140 Last-Modified header field 144
Location header field 135 Location header field 139
M M
Max-Forwards header field 79 Max-Forwards header field 83
Media Type Media Type
multipart/byteranges 57 multipart/byteranges 61
multipart/x-byteranges 58 multipart/x-byteranges 62
message 11 message 11
metadata 138 metadata 142
multipart/byteranges Media Type 57 multipart/byteranges Media Type 61
multipart/x-byteranges Media Type 58 multipart/x-byteranges Media Type 62
N N
non-transforming proxy 38 non-transforming proxy 40
O O
OPTIONS method 73 OPTIONS method 78
origin server 10 origin server 10
outbound 12 outbound 12
P P
POST method 67 POST method 72
PUT method 68 PUT method 73
Protection Space 100 Protection Space 104
Proxy-Authenticate header field 148 Proxy-Authenticate header field 152
Proxy-Authentication-Info header field 149 Proxy-Authentication-Info header field 153
Proxy-Authorization header field 101 Proxy-Authorization header field 105
payload 54 payload 57
phishing 153 phishing 158
proxy 12 proxy 13
R R
Range header field 90 Range header field 94
Realm 100 Realm 104
Referer header field 105 Referer header field 109
Retry-After header field 136 Retry-After header field 140
recipient 10 recipient 10
representation 39 representation 41
request 11 request 11
resource 15 resource 15
response 11 response 11
reverse proxy 13 reverse proxy 13
S S
Server header field 151 Server header field 155
Status Codes Classes Status Codes Classes
1xx Informational 109 1xx Informational 113
2xx Successful 110 2xx Successful 114
3xx Redirection 116 3xx Redirection 120
4xx Client Error 122 4xx Client Error 126
5xx Server Error 128 5xx Server Error 132
safe 64 safe 68
selected representation 39, 80, 138 selected representation 41, 84, 142
sender 10 sender 10
server 10 server 10
spider 10 spider 10
T T
TRACE method 74 TRACE method 79
Trailer header field 32 Trailer header field 33
target URI 33 target URI 35
target resource 33 target resource 35
transforming proxy 38 trailer fields 32
transparent proxy 13 trailers 32
transforming proxy 40
transparent proxy 14
tunnel 13 tunnel 13
U U
URI scheme URI scheme
http 16 http 16
https 17 https 18
User-Agent header field 106 User-Agent header field 110
upstream 12 upstream 12
user agent 10 user agent 10
V V
Vary header field 137 Vary header field 141
Via header field 36 Via header field 39
validator 138 validator 142
strong 139 strong 143
weak 139 weak 143
W W
WWW-Authenticate header field 147 WWW-Authenticate header field 151
X X
x-compress (content coding) 42 x-compress (content coding) 44
x-gzip (content coding) 42 x-gzip (content coding) 44
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, and RFC contributions that went into RFC 1945, RFC 2068, RFC 2145, RFC 2616,
2616, including substantial contributions made by the previous and RFC 2818, including substantial contributions made by the
authors, editors, and Working Group Chairs: Tim Berners-Lee, Ari previous authors, editors, and Working Group Chairs: Tim Berners-Lee,
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, and Yves Lafon. Jeffrey C. Mogul, Larry Masinter, Paul J. Leach, Eric Rescorla, and
Yves Lafon.
See Section 10 of [RFC7230] for further acknowledgements from prior See Section 10 of [RFC7230] for further acknowledgements from prior
revisions. revisions.
In addition, this document has reincorporated the HTTP Authentication In addition, this document has reincorporated the HTTP Authentication
Framework, previously defined in RFC 7235 and RFC 2617. We thank Framework, previously defined in RFC 7235 and RFC 2617. We thank
John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott
D. Lawrence, Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart D. Lawrence, Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart
for their work on that specification. See Section 6 of [RFC2617] for for their work on that specification. See Section 6 of [RFC2617] for
further acknowledgements. further acknowledgements.
[[newacks: New acks to be added here.]] [[newacks: New acks to be added here.]]
Authors' Addresses Authors' Addresses
Roy T. Fielding (editor) Roy T. Fielding (editor)
Adobe Adobe
345 Park Ave 345 Park Ave
San Jose, CA 95110 San Jose, CA 95110
USA United States of America
EMail: fielding@gbiv.com EMail: fielding@gbiv.com
URI: https://roy.gbiv.com/ URI: https://roy.gbiv.com/
Mark Nottingham (editor) Mark Nottingham (editor)
Fastly Fastly
EMail: mnot@mnot.net EMail: mnot@mnot.net
URI: https://www.mnot.net/ URI: https://www.mnot.net/
Julian F. Reschke (editor) Julian F. Reschke (editor)
greenbytes GmbH greenbytes GmbH
Hafenweg 16 Hafenweg 16
Muenster, NW 48155 Muenster 48155
Germany Germany
EMail: julian.reschke@greenbytes.de EMail: julian.reschke@greenbytes.de
URI: https://greenbytes.de/tech/webdav/ URI: https://greenbytes.de/tech/webdav/
 End of changes. 266 change blocks. 
959 lines changed or deleted 1304 lines changed or added

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