draft-ietf-httpbis-semantics-04.txt   draft-ietf-httpbis-semantics-05.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 7230,7231,7232,7233,7235,7538 Fastly
,7615 (if approved) J. Reschke, Ed. ,7615 (if approved) J. Reschke, Ed.
Intended status: Standards Track greenbytes Intended status: Standards Track greenbytes
Expires: September 10, 2019 March 9, 2019 Expires: January 9, 2020 July 8, 2019
HTTP Semantics HTTP Semantics
draft-ietf-httpbis-semantics-04 draft-ietf-httpbis-semantics-05
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is a stateless application- The Hypertext Transfer Protocol (HTTP) is a stateless application-
level protocol for distributed, collaborative, hypertext information level protocol for distributed, collaborative, hypertext information
systems. This document defines the semantics of HTTP: its systems. This document defines the semantics of HTTP: its
architecture, terminology, the "http" and "https" Uniform Resource architecture, terminology, the "http" and "https" Uniform Resource
Identifier (URI) schemes, core request methods, request header Identifier (URI) schemes, core request methods, request header
fields, response status codes, response header fields, and content fields, response status codes, response header fields, and content
negotiation. negotiation.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
This note is to be removed before publishing as an RFC. This note is to be removed before publishing as an RFC.
Discussion of this draft takes place on the HTTP working group Discussion of this draft takes place on the HTTP working group
mailing list (ietf-http-wg@w3.org), which is archived at mailing list (ietf-http-wg@w3.org), which is archived at
<https://lists.w3.org/Archives/Public/ietf-http-wg/>. <https://lists.w3.org/Archives/Public/ietf-http-wg/>.
Working Group information can be found at <https://httpwg.org/>; Working Group information can be found at <https://httpwg.org/>;
source code and issues list for this draft can be found at source code and issues list for this draft can be found at
<https://github.com/httpwg/http-core>. <https://github.com/httpwg/http-core>.
The changes in this draft are summarized in Appendix I.5. The changes in this draft are summarized in Appendix I.6.
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 September 10, 2019. This Internet-Draft will expire on January 9, 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 48 skipping to change at page 2, line 48
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 . . . . . . . . . . . . . . 14 2.4. Uniform Resource Identifiers . . . . . . . . . . . . . . 15
2.5. Resources . . . . . . . . . . . . . . . . . . . . . . . . 15 2.5. Resources . . . . . . . . . . . . . . . . . . . . . . . . 15
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 . . . . . . . . . . . . . . . . . . 17
2.5.3. Fragment Identifiers on http(s) URI References . . . 18 2.5.3. Fragment Identifiers on http(s) URI References . . . 18
2.5.4. http and https URI Normalization and Comparison . . . 18 2.5.4. http and https URI Normalization and Comparison . . . 18
3. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 19 3. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1. Implementation Diversity . . . . . . . . . . . . . . . . 19 3.1. Implementation Diversity . . . . . . . . . . . . . . . . 19
3.2. Role-based Requirements . . . . . . . . . . . . . . . . . 19 3.2. Role-based Requirements . . . . . . . . . . . . . . . . . 20
3.3. Parsing Elements . . . . . . . . . . . . . . . . . . . . 20 3.3. Parsing Elements . . . . . . . . . . . . . . . . . . . . 20
3.4. Error Handling . . . . . . . . . . . . . . . . . . . . . 21 3.4. Error Handling . . . . . . . . . . . . . . . . . . . . . 21
3.5. Protocol Versioning . . . . . . . . . . . . . . . . . . . 21 3.5. Protocol Versioning . . . . . . . . . . . . . . . . . . . 21
4. Message Abstraction . . . . . . . . . . . . . . . . . . . . . 22 4. Message Abstraction . . . . . . . . . . . . . . . . . . . . . 23
4.1. Header Field Names . . . . . . . . . . . . . . . . . . . 22 4.1. Header Field Names . . . . . . . . . . . . . . . . . . . 23
4.1.1. Header Field Name Registry . . . . . . . . . . . . . 25 4.1.1. Header Field Name Registry . . . . . . . . . . . . . 25
4.1.2. Header Field Extensibility . . . . . . . . . . . . . 26 4.1.2. Header Field Extensibility . . . . . . . . . . . . . 26
4.1.3. Considerations for New Header Fields . . . . . . . . 26 4.1.3. Considerations for New Header Fields . . . . . . . . 26
4.2. Header Field Values . . . . . . . . . . . . . . . . . . . 27 4.2. Header Field Values . . . . . . . . . . . . . . . . . . . 27
4.2.1. Header Field Order . . . . . . . . . . . . . . . . . 28 4.2.1. Header Field Order . . . . . . . . . . . . . . . . . 28
4.2.2. Header Field Limits . . . . . . . . . . . . . . . . . 29 4.2.2. Header Field Limits . . . . . . . . . . . . . . . . . 29
4.2.3. Header Field Value Components . . . . . . . . . . . . 29 4.2.3. Header Field Value Components . . . . . . . . . . . . 29
4.2.4. Designing New Header Field Values . . . . . . . . . . 30 4.2.4. Designing New Header Field Values . . . . . . . . . . 31
4.3. Whitespace . . . . . . . . . . . . . . . . . . . . . . . 31 4.3. Whitespace . . . . . . . . . . . . . . . . . . . . . . . 32
4.4. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.4. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 32
5. Message Routing . . . . . . . . . . . . . . . . . . . . . . . 32 5. Message Routing . . . . . . . . . . . . . . . . . . . . . . . 33
5.1. Identifying a Target Resource . . . . . . . . . . . . . . 32 5.1. Identifying a Target Resource . . . . . . . . . . . . . . 33
5.2. Routing Inbound . . . . . . . . . . . . . . . . . . . . . 32 5.2. Routing Inbound . . . . . . . . . . . . . . . . . . . . . 33
5.3. Effective Request URI . . . . . . . . . . . . . . . . . . 33 5.3. Effective Request URI . . . . . . . . . . . . . . . . . . 34
5.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . 33 5.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.5. Message Forwarding . . . . . . . . . . . . . . . . . . . 35 5.5. Message Forwarding . . . . . . . . . . . . . . . . . . . 35
5.5.1. Via . . . . . . . . . . . . . . . . . . . . . . . . . 35 5.5.1. Via . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.5.2. Transformations . . . . . . . . . . . . . . . . . . . 37 5.5.2. Transformations . . . . . . . . . . . . . . . . . . . 38
6. Representations . . . . . . . . . . . . . . . . . . . . . . . 38 6. Representations . . . . . . . . . . . . . . . . . . . . . . . 39
6.1. Representation Data . . . . . . . . . . . . . . . . . . . 39 6.1. Representation Data . . . . . . . . . . . . . . . . . . . 39
6.1.1. Media Type . . . . . . . . . . . . . . . . . . . . . 39 6.1.1. Media Type . . . . . . . . . . . . . . . . . . . . . 40
6.1.2. Content Codings . . . . . . . . . . . . . . . . . . . 41 6.1.2. Content Codings . . . . . . . . . . . . . . . . . . . 42
6.1.3. Language Tags . . . . . . . . . . . . . . . . . . . . 43 6.1.3. Language Tags . . . . . . . . . . . . . . . . . . . . 44
6.1.4. Range Units . . . . . . . . . . . . . . . . . . . . . 44 6.1.4. Range Units . . . . . . . . . . . . . . . . . . . . . 44
6.2. Representation Metadata . . . . . . . . . . . . . . . . . 47 6.2. Representation Metadata . . . . . . . . . . . . . . . . . 47
6.2.1. Content-Type . . . . . . . . . . . . . . . . . . . . 47 6.2.1. Content-Type . . . . . . . . . . . . . . . . . . . . 48
6.2.2. Content-Encoding . . . . . . . . . . . . . . . . . . 48 6.2.2. Content-Encoding . . . . . . . . . . . . . . . . . . 49
6.2.3. Content-Language . . . . . . . . . . . . . . . . . . 49 6.2.3. Content-Language . . . . . . . . . . . . . . . . . . 50
6.2.4. Content-Length . . . . . . . . . . . . . . . . . . . 50 6.2.4. Content-Length . . . . . . . . . . . . . . . . . . . 50
6.2.5. Content-Location . . . . . . . . . . . . . . . . . . 51 6.2.5. Content-Location . . . . . . . . . . . . . . . . . . 52
6.3. Payload . . . . . . . . . . . . . . . . . . . . . . . . . 53 6.3. Payload . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.3.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 53 6.3.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 54
6.3.2. Identification . . . . . . . . . . . . . . . . . . . 54 6.3.2. Identification . . . . . . . . . . . . . . . . . . . 54
6.3.3. Content-Range . . . . . . . . . . . . . . . . . . . . 55 6.3.3. Content-Range . . . . . . . . . . . . . . . . . . . . 55
6.3.4. Media Type multipart/byteranges . . . . . . . . . . . 57 6.3.4. Media Type multipart/byteranges . . . . . . . . . . . 57
6.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 59 6.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 59
6.4.1. Proactive Negotiation . . . . . . . . . . . . . . . . 59 6.4.1. Proactive Negotiation . . . . . . . . . . . . . . . . 60
6.4.2. Reactive Negotiation . . . . . . . . . . . . . . . . 60 6.4.2. Reactive Negotiation . . . . . . . . . . . . . . . . 61
7. Request Methods . . . . . . . . . . . . . . . . . . . . . . . 61 7. Request Methods . . . . . . . . . . . . . . . . . . . . . . . 62
7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 61 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 62
7.2. Common Method Properties . . . . . . . . . . . . . . . . 63 7.2. Common Method Properties . . . . . . . . . . . . . . . . 64
7.2.1. Safe Methods . . . . . . . . . . . . . . . . . . . . 63 7.2.1. Safe Methods . . . . . . . . . . . . . . . . . . . . 64
7.2.2. Idempotent Methods . . . . . . . . . . . . . . . . . 64 7.2.2. Idempotent Methods . . . . . . . . . . . . . . . . . 65
7.2.3. Cacheable Methods . . . . . . . . . . . . . . . . . . 64 7.2.3. Cacheable Methods . . . . . . . . . . . . . . . . . . 66
7.3. Method Definitions . . . . . . . . . . . . . . . . . . . 65 7.3. Method Definitions . . . . . . . . . . . . . . . . . . . 66
7.3.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 65 7.3.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 66
7.3.2. HEAD . . . . . . . . . . . . . . . . . . . . . . . . 66 7.3.2. HEAD . . . . . . . . . . . . . . . . . . . . . . . . 67
7.3.3. POST . . . . . . . . . . . . . . . . . . . . . . . . 66 7.3.3. POST . . . . . . . . . . . . . . . . . . . . . . . . 67
7.3.4. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 67 7.3.4. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 68
7.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . 70 7.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . 71
7.3.6. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 71 7.3.6. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 72
7.3.7. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 72 7.3.7. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 73
7.3.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . 73 7.3.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . 74
7.4. Method Extensibility . . . . . . . . . . . . . . . . . . 74 7.4. Method Extensibility . . . . . . . . . . . . . . . . . . 75
7.4.1. Method Registry . . . . . . . . . . . . . . . . . . . 74 7.4.1. Method Registry . . . . . . . . . . . . . . . . . . . 75
7.4.2. Considerations for New Methods . . . . . . . . . . . 74 7.4.2. Considerations for New Methods . . . . . . . . . . . 75
8. Request Header Fields . . . . . . . . . . . . . . . . . . . . 75 8. Request Header Fields . . . . . . . . . . . . . . . . . . . . 76
8.1. Controls . . . . . . . . . . . . . . . . . . . . . . . . 75 8.1. Controls . . . . . . . . . . . . . . . . . . . . . . . . 76
8.1.1. Expect . . . . . . . . . . . . . . . . . . . . . . . 76 8.1.1. Expect . . . . . . . . . . . . . . . . . . . . . . . 77
8.1.2. Max-Forwards . . . . . . . . . . . . . . . . . . . . 78 8.1.2. Max-Forwards . . . . . . . . . . . . . . . . . . . . 79
8.2. Preconditions . . . . . . . . . . . . . . . . . . . . . . 79 8.2. Preconditions . . . . . . . . . . . . . . . . . . . . . . 80
8.2.1. Evaluation . . . . . . . . . . . . . . . . . . . . . 80 8.2.1. Evaluation . . . . . . . . . . . . . . . . . . . . . 81
8.2.2. Precedence . . . . . . . . . . . . . . . . . . . . . 81 8.2.2. Precedence . . . . . . . . . . . . . . . . . . . . . 82
8.2.3. If-Match . . . . . . . . . . . . . . . . . . . . . . 83 8.2.3. If-Match . . . . . . . . . . . . . . . . . . . . . . 84
8.2.4. If-None-Match . . . . . . . . . . . . . . . . . . . . 84 8.2.4. If-None-Match . . . . . . . . . . . . . . . . . . . . 85
8.2.5. If-Modified-Since . . . . . . . . . . . . . . . . . . 85 8.2.5. If-Modified-Since . . . . . . . . . . . . . . . . . . 86
8.2.6. If-Unmodified-Since . . . . . . . . . . . . . . . . . 86 8.2.6. If-Unmodified-Since . . . . . . . . . . . . . . . . . 87
8.2.7. If-Range . . . . . . . . . . . . . . . . . . . . . . 87 8.2.7. If-Range . . . . . . . . . . . . . . . . . . . . . . 88
8.3. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 89 8.3. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 90
8.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 90 8.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 91
8.4.1. Quality Values . . . . . . . . . . . . . . . . . . . 91 8.4.1. Quality Values . . . . . . . . . . . . . . . . . . . 92
8.4.2. Accept . . . . . . . . . . . . . . . . . . . . . . . 92 8.4.2. Accept . . . . . . . . . . . . . . . . . . . . . . . 93
8.4.3. Accept-Charset . . . . . . . . . . . . . . . . . . . 94 8.4.3. Accept-Charset . . . . . . . . . . . . . . . . . . . 95
8.4.4. Accept-Encoding . . . . . . . . . . . . . . . . . . . 95 8.4.4. Accept-Encoding . . . . . . . . . . . . . . . . . . . 96
8.4.5. Accept-Language . . . . . . . . . . . . . . . . . . . 96 8.4.5. Accept-Language . . . . . . . . . . . . . . . . . . . 97
8.5. Authentication Credentials . . . . . . . . . . . . . . . 97 8.5. Authentication Credentials . . . . . . . . . . . . . . . 98
8.5.1. Challenge and Response . . . . . . . . . . . . . . . 97 8.5.1. Challenge and Response . . . . . . . . . . . . . . . 98
8.5.2. Protection Space (Realm) . . . . . . . . . . . . . . 99 8.5.2. Protection Space (Realm) . . . . . . . . . . . . . . 100
8.5.3. Authorization . . . . . . . . . . . . . . . . . . . . 100 8.5.3. Authorization . . . . . . . . . . . . . . . . . . . . 101
8.5.4. Proxy-Authorization . . . . . . . . . . . . . . . . . 100 8.5.4. Proxy-Authorization . . . . . . . . . . . . . . . . . 101
8.5.5. Authentication Scheme Extensibility . . . . . . . . . 101 8.5.5. Authentication Scheme Extensibility . . . . . . . . . 102
8.6. Request Context . . . . . . . . . . . . . . . . . . . . . 103 8.6. Request Context . . . . . . . . . . . . . . . . . . . . . 104
8.6.1. From . . . . . . . . . . . . . . . . . . . . . . . . 103 8.6.1. From . . . . . . . . . . . . . . . . . . . . . . . . 104
8.6.2. Referer . . . . . . . . . . . . . . . . . . . . . . . 104 8.6.2. Referer . . . . . . . . . . . . . . . . . . . . . . . 105
8.6.3. User-Agent . . . . . . . . . . . . . . . . . . . . . 105 8.6.3. User-Agent . . . . . . . . . . . . . . . . . . . . . 106
9. Response Status Codes . . . . . . . . . . . . . . . . . . . . 106 9. Response Status Codes . . . . . . . . . . . . . . . . . . . . 107
9.1. Overview of Status Codes . . . . . . . . . . . . . . . . 107 9.1. Overview of Status Codes . . . . . . . . . . . . . . . . 108
9.2. Informational 1xx . . . . . . . . . . . . . . . . . . . . 108 9.2. Informational 1xx . . . . . . . . . . . . . . . . . . . . 109
9.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 108 9.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 110
9.2.2. 101 Switching Protocols . . . . . . . . . . . . . . . 109 9.2.2. 101 Switching Protocols . . . . . . . . . . . . . . . 110
9.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . 109 9.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . 110
9.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 109 9.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 110
9.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 110 9.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 111
9.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . 110 9.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . 111
9.3.4. 203 Non-Authoritative Information . . . . . . . . . . 111 9.3.4. 203 Non-Authoritative Information . . . . . . . . . . 112
9.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . 111 9.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . 112
9.3.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 112 9.3.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 113
9.3.7. 206 Partial Content . . . . . . . . . . . . . . . . . 112 9.3.7. 206 Partial Content . . . . . . . . . . . . . . . . . 113
9.4. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 115 9.4. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 116
9.4.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 117 9.4.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 118
9.4.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 118 9.4.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 119
9.4.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 118 9.4.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 119
9.4.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 119 9.4.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 120
9.4.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 119 9.4.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 120
9.4.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 120 9.4.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 121
9.4.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . 120 9.4.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . 121
9.4.8. 307 Temporary Redirect . . . . . . . . . . . . . . . 120 9.4.8. 307 Temporary Redirect . . . . . . . . . . . . . . . 121
9.4.9. 308 Permanent Redirect . . . . . . . . . . . . . . . 121 9.4.9. 308 Permanent Redirect . . . . . . . . . . . . . . . 122
9.5. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 121 9.5. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 122
9.5.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 121 9.5.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 122
9.5.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 121 9.5.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 122
9.5.3. 402 Payment Required . . . . . . . . . . . . . . . . 122 9.5.3. 402 Payment Required . . . . . . . . . . . . . . . . 123
9.5.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 122 9.5.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 123
9.5.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 122 9.5.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 123
9.5.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 123 9.5.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 124
9.5.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 123 9.5.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 124
9.5.8. 407 Proxy Authentication Required . . . . . . . . . . 123 9.5.8. 407 Proxy Authentication Required . . . . . . . . . . 124
9.5.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 123 9.5.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 124
9.5.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . 124 9.5.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . 125
9.5.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 124 9.5.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 125
9.5.12. 411 Length Required . . . . . . . . . . . . . . . . . 124 9.5.12. 411 Length Required . . . . . . . . . . . . . . . . . 125
9.5.13. 412 Precondition Failed . . . . . . . . . . . . . . . 125 9.5.13. 412 Precondition Failed . . . . . . . . . . . . . . . 126
9.5.14. 413 Payload Too Large . . . . . . . . . . . . . . . . 125 9.5.14. 413 Payload Too Large . . . . . . . . . . . . . . . . 126
9.5.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . 125 9.5.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . 126
9.5.16. 415 Unsupported Media Type . . . . . . . . . . . . . 125 9.5.16. 415 Unsupported Media Type . . . . . . . . . . . . . 126
9.5.17. 416 Range Not Satisfiable . . . . . . . . . . . . . . 126 9.5.17. 416 Range Not Satisfiable . . . . . . . . . . . . . . 127
9.5.18. 417 Expectation Failed . . . . . . . . . . . . . . . 126 9.5.18. 417 Expectation Failed . . . . . . . . . . . . . . . 127
9.5.19. 418 (Unused) . . . . . . . . . . . . . . . . . . . . 126 9.5.19. 418 (Unused) . . . . . . . . . . . . . . . . . . . . 127
9.5.20. 422 Unprocessable Entity . . . . . . . . . . . . . . 127 9.5.20. 422 Unprocessable Payload . . . . . . . . . . . . . . 128
9.5.21. 426 Upgrade Required . . . . . . . . . . . . . . . . 127 9.5.21. 426 Upgrade Required . . . . . . . . . . . . . . . . 128
9.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 127 9.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 128
9.6.1. 500 Internal Server Error . . . . . . . . . . . . . . 128 9.6.1. 500 Internal Server Error . . . . . . . . . . . . . . 129
9.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 128 9.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 129
9.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 128 9.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 129
9.6.4. 503 Service Unavailable . . . . . . . . . . . . . . . 128 9.6.4. 503 Service Unavailable . . . . . . . . . . . . . . . 129
9.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 128 9.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 129
9.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . 128 9.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . 129
9.7. Status Code Extensibility . . . . . . . . . . . . . . . . 129 9.7. Status Code Extensibility . . . . . . . . . . . . . . . . 130
9.7.1. Status Code Registry . . . . . . . . . . . . . . . . 129 9.7.1. Status Code Registry . . . . . . . . . . . . . . . . 130
9.7.2. Considerations for New Status Codes . . . . . . . . . 129 9.7.2. Considerations for New Status Codes . . . . . . . . . 130
10. Response Header Fields . . . . . . . . . . . . . . . . . . . 130 10. Response Header Fields . . . . . . . . . . . . . . . . . . . 131
10.1. Control Data . . . . . . . . . . . . . . . . . . . . . . 130 10.1. Control Data . . . . . . . . . . . . . . . . . . . . . . 131
10.1.1. Origination Date . . . . . . . . . . . . . . . . . . 131 10.1.1. Origination Date . . . . . . . . . . . . . . . . . . 132
10.1.2. Location . . . . . . . . . . . . . . . . . . . . . . 134 10.1.2. Location . . . . . . . . . . . . . . . . . . . . . . 135
10.1.3. Retry-After . . . . . . . . . . . . . . . . . . . . 135 10.1.3. Retry-After . . . . . . . . . . . . . . . . . . . . 136
10.1.4. Vary . . . . . . . . . . . . . . . . . . . . . . . . 136 10.1.4. Vary . . . . . . . . . . . . . . . . . . . . . . . . 137
10.2. Validators . . . . . . . . . . . . . . . . . . . . . . . 137 10.2. Validators . . . . . . . . . . . . . . . . . . . . . . . 138
10.2.1. Weak versus Strong . . . . . . . . . . . . . . . . . 138 10.2.1. Weak versus Strong . . . . . . . . . . . . . . . . . 139
10.2.2. Last-Modified . . . . . . . . . . . . . . . . . . . 139 10.2.2. Last-Modified . . . . . . . . . . . . . . . . . . . 140
10.2.3. ETag . . . . . . . . . . . . . . . . . . . . . . . . 141 10.2.3. ETag . . . . . . . . . . . . . . . . . . . . . . . . 142
10.2.4. When to Use Entity-Tags and Last-Modified Dates . . 145 10.2.4. When to Use Entity-Tags and Last-Modified Dates . . 146
10.3. Authentication Challenges . . . . . . . . . . . . . . . 145 10.3. Authentication Challenges . . . . . . . . . . . . . . . 146
10.3.1. WWW-Authenticate . . . . . . . . . . . . . . . . . . 146 10.3.1. WWW-Authenticate . . . . . . . . . . . . . . . . . . 147
10.3.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . 147 10.3.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . 148
10.3.3. Authentication-Info . . . . . . . . . . . . . . . . 147 10.3.3. Authentication-Info . . . . . . . . . . . . . . . . 148
10.3.4. Proxy-Authentication-Info . . . . . . . . . . . . . 148 10.3.4. Proxy-Authentication-Info . . . . . . . . . . . . . 149
10.4. Response Context . . . . . . . . . . . . . . . . . . . . 149 10.4. Response Context . . . . . . . . . . . . . . . . . . . . 150
10.4.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . 149 10.4.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . 150
10.4.2. Allow . . . . . . . . . . . . . . . . . . . . . . . 149 10.4.2. Allow . . . . . . . . . . . . . . . . . . . . . . . 150
10.4.3. Server . . . . . . . . . . . . . . . . . . . . . . . 150 10.4.3. Server . . . . . . . . . . . . . . . . . . . . . . . 151
11. ABNF List Extension: #rule . . . . . . . . . . . . . . . . . 151 11. ABNF List Extension: #rule . . . . . . . . . . . . . . . . . 152
12. Security Considerations . . . . . . . . . . . . . . . . . . . 152 11.1. Sender Requirements . . . . . . . . . . . . . . . . . . 152
12.1. Establishing Authority . . . . . . . . . . . . . . . . . 152 11.2. Recipient Requirements . . . . . . . . . . . . . . . . . 152
12.2. Risks of Intermediaries . . . . . . . . . . . . . . . . 153 12. Security Considerations . . . . . . . . . . . . . . . . . . . 153
12.3. Attacks Based on File and Path Names . . . . . . . . . . 154 12.1. Establishing Authority . . . . . . . . . . . . . . . . . 153
12.4. Attacks Based on Command, Code, or Query Injection . . . 154 12.2. Risks of Intermediaries . . . . . . . . . . . . . . . . 154
12.5. Attacks via Protocol Element Length . . . . . . . . . . 155 12.3. Attacks Based on File and Path Names . . . . . . . . . . 155
12.6. Disclosure of Personal Information . . . . . . . . . . . 155 12.4. Attacks Based on Command, Code, or Query Injection . . . 155
12.7. Privacy of Server Log Information . . . . . . . . . . . 155 12.5. Attacks via Protocol Element Length . . . . . . . . . . 156
12.8. Disclosure of Sensitive Information in URIs . . . . . . 156 12.6. Disclosure of Personal Information . . . . . . . . . . . 156
12.9. Disclosure of Fragment after Redirects . . . . . . . . . 156 12.7. Privacy of Server Log Information . . . . . . . . . . . 157
12.10. Disclosure of Product Information . . . . . . . . . . . 157 12.8. Disclosure of Sensitive Information in URIs . . . . . . 157
12.11. Browser Fingerprinting . . . . . . . . . . . . . . . . . 157 12.9. Disclosure of Fragment after Redirects . . . . . . . . . 158
12.12. Validator Retention . . . . . . . . . . . . . . . . . . 158 12.10. Disclosure of Product Information . . . . . . . . . . . 158
12.13. Denial-of-Service Attacks Using Range . . . . . . . . . 159 12.11. Browser Fingerprinting . . . . . . . . . . . . . . . . . 158
12.14. Authentication Considerations . . . . . . . . . . . . . 159 12.12. Validator Retention . . . . . . . . . . . . . . . . . . 159
12.14.1. Confidentiality of Credentials . . . . . . . . . . 159 12.13. Denial-of-Service Attacks Using Range . . . . . . . . . 160
12.14.2. Credentials and Idle Clients . . . . . . . . . . . 160 12.14. Authentication Considerations . . . . . . . . . . . . . 160
12.14.3. Protection Spaces . . . . . . . . . . . . . . . . . 160 12.14.1. Confidentiality of Credentials . . . . . . . . . . 160
12.14.4. Additional Response Header Fields . . . . . . . . . 161 12.14.2. Credentials and Idle Clients . . . . . . . . . . . 161
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 161 12.14.3. Protection Spaces . . . . . . . . . . . . . . . . . 161
13.1. URI Scheme Registration . . . . . . . . . . . . . . . . 161 12.14.4. Additional Response Header Fields . . . . . . . . . 162
13.2. Method Registration . . . . . . . . . . . . . . . . . . 161 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 162
13.3. Status Code Registration . . . . . . . . . . . . . . . . 161 13.1. URI Scheme Registration . . . . . . . . . . . . . . . . 162
13.4. Header Field Registration . . . . . . . . . . . . . . . 162 13.2. Method Registration . . . . . . . . . . . . . . . . . . 162
13.5. Authentication Scheme Registration . . . . . . . . . . . 162 13.3. Status Code Registration . . . . . . . . . . . . . . . . 162
13.4. Header Field Registration . . . . . . . . . . . . . . . 163
13.5. Authentication Scheme Registration . . . . . . . . . . . 163
13.6. Content Coding Registration . . . . . . . . . . . . . . 163 13.6. Content Coding Registration . . . . . . . . . . . . . . 163
13.7. Range Unit Registration . . . . . . . . . . . . . . . . 163 13.7. Range Unit Registration . . . . . . . . . . . . . . . . 164
13.8. Media Type Registration . . . . . . . . . . . . . . . . 163 13.8. Media Type Registration . . . . . . . . . . . . . . . . 164
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 163 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 164
14.1. Normative References . . . . . . . . . . . . . . . . . . 163 14.1. Normative References . . . . . . . . . . . . . . . . . . 164
14.2. Informative References . . . . . . . . . . . . . . . . . 165 14.2. Informative References . . . . . . . . . . . . . . . . . 166
Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 171 Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 172
Appendix B. Changes from RFC 7230 . . . . . . . . . . . . . . . 175 Appendix B. Changes from RFC 7230 . . . . . . . . . . . . . . . 176
Appendix C. Changes from RFC 7231 . . . . . . . . . . . . . . . 176 Appendix C. Changes from RFC 7231 . . . . . . . . . . . . . . . 177
Appendix D. Changes from RFC 7232 . . . . . . . . . . . . . . . 176 Appendix D. Changes from RFC 7232 . . . . . . . . . . . . . . . 177
Appendix E. Changes from RFC 7233 . . . . . . . . . . . . . . . 176 Appendix E. Changes from RFC 7233 . . . . . . . . . . . . . . . 177
Appendix F. Changes from RFC 7235 . . . . . . . . . . . . . . . 176 Appendix F. Changes from RFC 7235 . . . . . . . . . . . . . . . 177
Appendix G. Changes from RFC 7538 . . . . . . . . . . . . . . . 176 Appendix G. Changes from RFC 7538 . . . . . . . . . . . . . . . 177
Appendix H. Changes from RFC 7615 . . . . . . . . . . . . . . . 176 Appendix H. Changes from RFC 7615 . . . . . . . . . . . . . . . 177
Appendix I. Change Log . . . . . . . . . . . . . . . . . . . . . 176 Appendix I. Change Log . . . . . . . . . . . . . . . . . . . . . 177
I.1. Between RFC723x and draft 00 . . . . . . . . . . . . . . 176 I.1. Between RFC723x and draft 00 . . . . . . . . . . . . . . 177
I.2. Since draft-ietf-httpbis-semantics-00 . . . . . . . . . . 177 I.2. Since draft-ietf-httpbis-semantics-00 . . . . . . . . . . 178
I.3. Since draft-ietf-httpbis-semantics-01 . . . . . . . . . . 177 I.3. Since draft-ietf-httpbis-semantics-01 . . . . . . . . . . 178
I.4. Since draft-ietf-httpbis-semantics-02 . . . . . . . . . . 179 I.4. Since draft-ietf-httpbis-semantics-02 . . . . . . . . . . 180
I.5. Since draft-ietf-httpbis-semantics-03 . . . . . . . . . . 180 I.5. Since draft-ietf-httpbis-semantics-03 . . . . . . . . . . 180
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 I.6. Since draft-ietf-httpbis-semantics-04 . . . . . . . . . . 181
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 188 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 189 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 190
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 190
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 47 skipping to change at page 9, line 49
As a convention, ABNF rule names prefixed with "obs-" denote As a convention, ABNF rule names prefixed with "obs-" denote
"obsolete" grammar rules that appear for historical reasons. "obsolete" grammar rules that appear for historical reasons.
The following core rules are included by reference, as defined in The following core rules are included by reference, as defined in
Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return),
CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double
quote), HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF quote), HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF
(line feed), OCTET (any 8-bit sequence of data), SP (space), and (line feed), OCTET (any 8-bit sequence of data), SP (space), and
VCHAR (any visible US-ASCII character). VCHAR (any visible US-ASCII character).
Section 4.2.3 defines some generic syntactic components for header
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.8>
protocol-version = <protocol-version, see [Messaging], Section 9.8> protocol-version = <protocol-version, see [Messaging], Section 9.8>
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].
skipping to change at page 25, line 5 skipping to change at page 24, line 49
| 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.4 |
| 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
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.1.3 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
skipping to change at page 28, line 6 skipping to change at page 28, line 6
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 )
field-content = field-vchar [ 1*( SP / HTAB ) field-vchar ] field-content = field-vchar
[ 1*( SP / HTAB / field-vchar ) field-vchar ]
field-vchar = VCHAR / obs-text field-vchar = VCHAR / obs-text
Historically, HTTP header field values could be extended over Historically, HTTP header field values could be extended over
multiple lines by preceding each extra line with at least one space multiple lines by preceding each extra line with at least one space
or horizontal tab (obs-fold). [[CREF1: This document assumes that or horizontal tab (obs-fold). [[CREF1: This document assumes that
any such obs-fold has been replaced with one or more SP octets prior any such obs-fold has been replaced with one or more SP octets prior
to interpreting the field value, as described in Section 5.2 of to interpreting the field value, as described in Section 5.2 of
[Messaging].]] [Messaging].]]
Historically, HTTP has allowed field content with text in the Historically, HTTP has allowed field content with text in the
skipping to change at page 29, line 34 skipping to change at page 29, line 34
increase the server's vulnerability to request smuggling attacks increase the server's vulnerability to request smuggling attacks
(Section 11.2 of [Messaging]). (Section 11.2 of [Messaging]).
A client MAY discard or truncate received header fields that are A client MAY discard or truncate received header fields that are
larger than the client wishes to process if the field semantics are larger than the client wishes to process if the field semantics are
such that the dropped value(s) can be safely ignored without changing such that the dropped value(s) can be safely ignored without changing
the message framing or response semantics. the message framing or response semantics.
4.2.3. Header Field Value Components 4.2.3. Header Field Value Components
Most HTTP header field values are defined using common syntax Many HTTP header field values are defined using common syntax
components (token, quoted-string, and comment) separated by components, separated by whitespace or specific delimiting
whitespace or specific delimiting characters. Delimiters are chosen characters. Delimiters are chosen from the set of US-ASCII visual
from the set of US-ASCII visual characters not allowed in a token characters not allowed in a token (DQUOTE and "(),/:;<=>?@[\]{}").
(DQUOTE and "(),/:;<=>?@[\]{}").
4.2.3.1. Tokens
Tokens are short textual identifiers that do not include whitespace
or delimiters.
token = 1*tchar token = 1*tchar
tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*"
/ "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
/ DIGIT / ALPHA / DIGIT / ALPHA
; any VCHAR, except delimiters ; any VCHAR, except delimiters
4.2.3.2. Quoted Strings
A string of text is parsed as a single value if it is quoted using A string of text is parsed as a single value if it is quoted using
double-quote marks. double-quote marks.
quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
qdtext = HTAB / SP / %x21 / %x23-5B / %x5D-7E / obs-text qdtext = HTAB / SP / %x21 / %x23-5B / %x5D-7E / obs-text
obs-text = %x80-FF obs-text = %x80-FF
Comments can be included in some HTTP header fields by surrounding
the comment text with parentheses. Comments are only allowed in
fields containing "comment" as part of their field value definition.
comment = "(" *( ctext / quoted-pair / comment ) ")"
ctext = HTAB / SP / %x21-27 / %x2A-5B / %x5D-7E / obs-text
The backslash octet ("\") can be used as a single-octet quoting The backslash octet ("\") can be used as a single-octet quoting
mechanism within quoted-string and comment constructs. Recipients mechanism within quoted-string and comment constructs. Recipients
that process the value of a quoted-string MUST handle a quoted-pair that process the value of a quoted-string MUST handle a quoted-pair
as if it were replaced by the octet following the backslash. as if it were replaced by the octet following the backslash.
quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text ) quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
A sender SHOULD NOT generate a quoted-pair in a quoted-string except A sender SHOULD NOT generate a quoted-pair in a quoted-string except
where necessary to quote DQUOTE and backslash octets occurring within where necessary to quote DQUOTE and backslash octets occurring within
that string. A sender SHOULD NOT generate a quoted-pair in a comment that string. A sender SHOULD NOT generate a quoted-pair in a comment
except where necessary to quote parentheses ["(" and ")"] and except where necessary to quote parentheses ["(" and ")"] and
backslash octets occurring within that comment. backslash octets occurring within that comment.
4.2.3.3. Comments
Comments can be included in some HTTP header fields by surrounding
the comment text with parentheses. Comments are only allowed in
fields containing "comment" as part of their field value definition.
comment = "(" *( ctext / quoted-pair / comment ) ")"
ctext = HTAB / SP / %x21-27 / %x2A-5B / %x5D-7E / obs-text
4.2.3.4. Parameters
A parameter is a name=value pair that is often defined within header
field values as a common syntax for appending auxiliary information
to an item. Each parameter is usually delimited by an immediately
preceding semicolon.
parameter = parameter-name "=" parameter-value
parameter-name = token
parameter-value = ( token / quoted-string )
Parameter names are case-insensitive. Parameter values might or
might not be case-sensitive, depending on the semantics of the
parameter name. Examples of parameters and some equivalent forms can
be seen in media types (Section 6.1.1) and the Accept header field
(Section 8.4.2).
A parameter value that matches the token production can be
transmitted either as a token or within a quoted-string. The quoted
and unquoted values are equivalent.
Note: Parameters do not allow whitespace (not even "bad"
whitespace) around the "=" character.
4.2.4. Designing New Header Field Values 4.2.4. Designing New Header Field Values
New header field values typically have their syntax defined using New header field values typically have their syntax defined using
ABNF ([RFC5234]), using the extension defined in Section 11 as ABNF ([RFC5234]), using the extension defined in Section 11 as
necessary, and are usually constrained to the range of US-ASCII necessary, and are usually constrained to the range of US-ASCII
characters. Header fields needing a greater range of characters can characters. Header fields needing a greater range of characters can
use an encoding such as the one defined in [RFC8187]. 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
skipping to change at page 31, line 5 skipping to change at page 31, line 41
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",
"http://without-a-comma.example.com/" "http://without-a-comma.example.com/"
Example-Date-Field: "Sat, 04 May 1996", "Wed, 14 Sep 2005" Example-Date-Field: "Sat, 04 May 1996", "Wed, 14 Sep 2005"
Note that double-quote delimiters almost always are used with the Note that double-quote delimiters almost always are used with the
quoted-string production; using a different syntax inside double- quoted-string production; using a different syntax inside double-
quotes will likely cause unnecessary confusion. quotes will likely cause unnecessary confusion.
Many header fields use a format including (case-insensitively) named Many header fields (such as Content-Type, defined in Section 6.2.1)
parameters (for instance, Content-Type, defined in Section 6.2.1). use a common syntax for parameters that allows both unquoted (token)
Allowing both unquoted (token) and quoted (quoted-string) syntax for and quoted (quoted-string) syntax for a parameter value
the parameter value enables recipients to use existing parser (Section 4.2.3.4). Use of common syntax allows recipients to reuse
components. When allowing both forms, the meaning of a parameter existing parser components. When allowing both forms, the meaning of
value ought to be independent of the syntax used for it (for an a parameter value ought to be the same whether it was received as a
example, see the notes on parameter handling for media types in token or a quoted string.
Section 6.1.1).
4.3. Whitespace 4.3. Whitespace
This specification uses three rules to denote the use of linear This specification uses three rules to denote the use of linear
whitespace: OWS (optional whitespace), RWS (required whitespace), and whitespace: OWS (optional whitespace), RWS (required whitespace), and
BWS ("bad" whitespace). BWS ("bad" whitespace).
The OWS rule is used where zero or more linear whitespace octets The OWS rule is used where zero or more linear whitespace octets
might appear. For protocol elements where optional whitespace is might appear. For protocol elements where optional whitespace is
preferred to improve readability, a sender SHOULD generate the preferred to improve readability, a sender SHOULD generate the
skipping to change at page 38, line 48 skipping to change at page 39, line 39
resource, in a format that can be readily communicated via the resource, in a format that can be readily communicated via the
protocol, and that consists of a set of representation metadata and a protocol, and that consists of a set of representation metadata and a
potentially unbounded stream of representation data. potentially unbounded stream of representation data.
An origin server might be provided with, or be capable of generating, An origin server might be provided with, or be capable of generating,
multiple representations that are each intended to reflect the multiple representations that are each intended to reflect the
current state of a target resource. In such cases, some algorithm is current state of a target resource. In such cases, some algorithm is
used by the origin server to select one of those representations as used by the origin server to select one of those representations as
most applicable to a given request, usually based on content most applicable to a given request, usually based on content
negotiation. This "selected representation" is used to provide the negotiation. This "selected representation" is used to provide the
data and metadata for evaluating conditional requests Section 8.2 and data and metadata for evaluating conditional requests (Section 8.2)
constructing the payload for 200 (OK) and 304 (Not Modified) and constructing the payload for 200 (OK) and 304 (Not Modified)
responses to GET (Section 7.3.1). responses to GET (Section 7.3.1).
6.1. Representation Data 6.1. Representation Data
The representation data associated with an HTTP message is either The representation data associated with an HTTP message is either
provided as the payload body of the message or referred to by the provided as the payload body of the message or referred to by the
message semantics and the effective request URI. The representation message semantics and the effective request URI. The representation
data is in a format and encoding defined by the representation data is in a format and encoding defined by the representation
metadata header fields. metadata header fields.
skipping to change at page 39, line 31 skipping to change at page 40, line 23
HTTP uses media types [RFC2046] in the Content-Type (Section 6.2.1) HTTP uses media types [RFC2046] in the Content-Type (Section 6.2.1)
and Accept (Section 8.4.2) header fields in order to provide open and and Accept (Section 8.4.2) header fields in order to provide open and
extensible data typing and type negotiation. Media types define both extensible data typing and type negotiation. Media types define both
a data format and various processing models: how to process that data a data format and various processing models: how to process that data
in accordance with each context in which it is received. in accordance with each context in which it is received.
media-type = type "/" subtype *( OWS ";" OWS parameter ) media-type = type "/" subtype *( OWS ";" OWS parameter )
type = token type = token
subtype = token subtype = token
The type/subtype MAY be followed by parameters in the form of The type and subtype tokens are case-insensitive.
name=value pairs.
parameter = token "=" ( token / quoted-string )
The type, subtype, and parameter name tokens are case-insensitive.
Parameter values might or might not be case-sensitive, depending on
the semantics of the parameter name. The presence or absence of a
parameter might be significant to the processing of a media-type,
depending on its definition within the media type registry.
A parameter value that matches the token production can be The type/subtype MAY be followed by semicolon-delimited parameters
transmitted either as a token or within a quoted-string. The quoted (Section 4.2.3.4) in the form of name=value pairs. The presence or
and unquoted values are equivalent. absence of a parameter might be significant to the processing of a
media type, depending on its definition within the media type
registry. Parameter values might or might not be case-sensitive,
depending on the semantics of the parameter name.
For example, the following examples are all equivalent, but the first For example, the following media types are equivalent in describing
is preferred for consistency: HTML text data encoded in the UTF-8 character encoding scheme, but
the first is preferred for consistency (the "charset" parameter value
is defined as being case-insensitive in [RFC2046], Section 4.1.2):
text/html;charset=utf-8 text/html;charset=utf-8
Text/HTML;Charset="utf-8" Text/HTML;Charset="utf-8"
text/html; charset="utf-8" text/html; charset="utf-8"
Furthermore, the example below is equivalent as well, as the
"charset" parameter value is defined as case-insensitive ([RFC2046],
Section 4.1.2):
text/html;charset=UTF-8 text/html;charset=UTF-8
Media types ought to be registered with IANA according to the Media types ought to be registered with IANA according to the
procedures defined in [BCP13]. procedures defined in [BCP13].
Note: Unlike some similar constructs in other header fields, media
type parameters do not allow whitespace (even "bad" whitespace)
around the "=" character.
6.1.1.1. Charset 6.1.1.1. Charset
HTTP uses charset names to indicate or negotiate the character HTTP uses charset names to indicate or negotiate the character
encoding scheme of a textual representation [RFC6365]. A charset is encoding scheme of a textual representation [RFC6365]. A charset is
identified by a case-insensitive token. identified by a case-insensitive token.
charset = token charset = token
Charset names ought to be registered in the IANA "Character Sets" Charset names ought to be registered in the IANA "Character Sets"
registry (<https://www.iana.org/assignments/character-sets>) registry (<https://www.iana.org/assignments/character-sets>)
according to the procedures defined in Section 2 of [RFC2978]. according to the procedures defined in Section 2 of [RFC2978].
Note: in practice, charset names are furthermore restricted by the Note: In theory, charset names are defined by the "mime-charset"
"mime-charset" ABNF rule defined in Section 2.3 of [RFC2978] (as ABNF rule defined in Section 2.3 of [RFC2978] (as corrected in
corrected in [Err1912]). However, that rule allows two characters [Err1912]). That rule allows two characters that are not included
not included in "token" ("{" and "}"), but at the time of this in "token" ("{" and "}"), but no charset name registered at the
writing no character set using these was registered (see time of this writing includes braces (see [Err5433]).
[Err5433]).
6.1.1.2. Canonicalization and Text Defaults 6.1.1.2. Canonicalization and Text Defaults
Media types are registered with a canonical form in order to be Media types are registered with a canonical form in order to be
interoperable among systems with varying native encoding formats. interoperable among systems with varying native encoding formats.
Representations selected or transferred via HTTP ought to be in Representations selected or transferred via HTTP ought to be in
canonical form, for many of the same reasons described by the canonical form, for many of the same reasons described by the
Multipurpose Internet Mail Extensions (MIME) [RFC2045]. However, the Multipurpose Internet Mail Extensions (MIME) [RFC2045]. However, the
performance characteristics of email deployments (i.e., store and performance characteristics of email deployments (i.e., store and
forward messages to peers) are significantly different from those forward messages to peers) are significantly different from those
skipping to change at page 42, line 23 skipping to change at page 42, line 49
| gzip | GZIP file format [RFC1952] | Section | | gzip | GZIP file format [RFC1952] | Section |
| | | 6.1.2.3 | | | | 6.1.2.3 |
| identity | Reserved (synonym for "no encoding" in | Section | | identity | Reserved (synonym for "no encoding" in | Section |
| | Accept-Encoding) | 8.4.4 | | | Accept-Encoding) | 8.4.4 |
| x-compress | Deprecated (alias for compress) | Section | | x-compress | Deprecated (alias for compress) | Section |
| | | 6.1.2.1 | | | | 6.1.2.1 |
| x-gzip | Deprecated (alias for gzip) | Section | | x-gzip | Deprecated (alias for gzip) | Section |
| | | 6.1.2.3 | | | | 6.1.2.3 |
+------------+------------------------------------------+-----------+ +------------+------------------------------------------+-----------+
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".
6.1.2.2. Deflate Coding 6.1.2.2. Deflate Coding
The "deflate" coding is a "zlib" data format [RFC1950] containing a The "deflate" coding is a "zlib" data format [RFC1950] containing a
skipping to change at page 44, line 32 skipping to change at page 45, line 15
+-------------+---------------------------------------+-------------+ +-------------+---------------------------------------+-------------+
| Range Unit | Description | Reference | | Range Unit | Description | Reference |
| Name | | | | Name | | |
+-------------+---------------------------------------+-------------+ +-------------+---------------------------------------+-------------+
| bytes | a range of octets | Section | | bytes | a range of octets | Section |
| | | 6.1.4.1 | | | | 6.1.4.1 |
| none | reserved as keyword, indicating no | Section | | none | reserved as keyword, indicating no | Section |
| | ranges are supported | 10.4.1 | | | ranges are supported | 10.4.1 |
+-------------+---------------------------------------+-------------+ +-------------+---------------------------------------+-------------+
Table 3
6.1.4.1. Byte Ranges 6.1.4.1. Byte Ranges
Since representation data is transferred in payloads as a sequence of Since representation data is transferred in payloads as a sequence of
octets, a byte range is a meaningful substructure for any octets, a byte range is a meaningful substructure for any
representation transferable over HTTP (Section 6). The "bytes" range representation transferable over HTTP (Section 6). The "bytes" range
unit is defined for expressing subranges of the data's octet unit is defined for expressing subranges of the data's octet
sequence. sequence.
bytes-unit = "bytes" bytes-unit = "bytes"
skipping to change at page 48, line 7 skipping to change at page 48, line 42
A sender that generates a message containing a payload body SHOULD A sender that generates a message containing a payload body SHOULD
generate a Content-Type header field in that message unless the generate a Content-Type header field in that message unless the
intended media type of the enclosed representation is unknown to the intended media type of the enclosed representation is unknown to the
sender. If a Content-Type header field is not present, the recipient sender. If a Content-Type header field is not present, the recipient
MAY either assume a media type of "application/octet-stream" MAY either assume a media type of "application/octet-stream"
([RFC2046], Section 4.5.1) or examine the data to determine its type. ([RFC2046], Section 4.5.1) or examine the data to determine its type.
In practice, resource owners do not always properly configure their In practice, resource owners do not always properly configure their
origin server to provide the correct Content-Type for a given origin server to provide the correct Content-Type for a given
representation, with the result that some clients will examine a representation. Some user agents examine a payload's content and, in
payload's content and override the specified type. Clients that do certain cases, override the received type (for example, see
so risk drawing incorrect conclusions, which might expose additional [Sniffing]). This "MIME sniffing" risks drawing incorrect
conclusions about the data, which might expose the user to additional
security risks (e.g., "privilege escalation"). Furthermore, it is security risks (e.g., "privilege escalation"). Furthermore, it is
impossible to determine the sender's intent by examining the data impossible to determine the sender's intended processing model by
format: many data formats match multiple media types that differ only examining the data format: many data formats match multiple media
in processing semantics. Implementers are encouraged to provide a types that differ only in processing semantics. Implementers are
means of disabling such "content sniffing" when it is used. encouraged to provide a means to disable such sniffing.
6.2.2. Content-Encoding 6.2.2. Content-Encoding
The "Content-Encoding" header field indicates what content codings The "Content-Encoding" header field indicates what content codings
have been applied to the representation, beyond those inherent in the have been applied to the representation, beyond those inherent in the
media type, and thus what decoding mechanisms have to be applied in media type, and thus what decoding mechanisms have to be applied in
order to obtain data in the media type referenced by the Content-Type order to obtain data in the media type referenced by the Content-Type
header field. Content-Encoding is primarily used to allow a header field. Content-Encoding is primarily used to allow a
representation's data to be compressed without losing the identity of representation's data to be compressed without losing the identity of
its underlying media type. its underlying media type.
skipping to change at page 62, line 47 skipping to change at page 63, line 36
| DELETE | Remove all current representations of the | 7.3.5 | | DELETE | Remove all current representations of the | 7.3.5 |
| | target resource. | | | | target resource. | |
| CONNECT | Establish a tunnel to the server identified by | 7.3.6 | | CONNECT | Establish a tunnel to the server identified by | 7.3.6 |
| | the target resource. | | | | the target resource. | |
| OPTIONS | Describe the communication options for the | 7.3.7 | | OPTIONS | Describe the communication options for the | 7.3.7 |
| | target resource. | | | | target resource. | |
| TRACE | Perform a message loop-back test along the path | 7.3.8 | | TRACE | Perform a message loop-back test along the path | 7.3.8 |
| | to the target resource. | | | | to the target resource. | |
+---------+-------------------------------------------------+-------+ +---------+-------------------------------------------------+-------+
Table 4
All general-purpose servers MUST support the methods GET and HEAD. All general-purpose servers MUST support the methods GET and HEAD.
All other methods are OPTIONAL. All other methods are OPTIONAL.
The set of methods allowed by a target resource can be listed in an The set of methods allowed by a target resource can be listed in an
Allow header field (Section 10.4.2). However, the set of allowed Allow header field (Section 10.4.2). However, the set of allowed
methods can change dynamically. When a request method is received methods can change dynamically. When a request method is received
that is unrecognized or not implemented by an origin server, the that is unrecognized or not implemented by an origin server, the
origin server SHOULD respond with the 501 (Not Implemented) status origin server SHOULD respond with the 501 (Not Implemented) status
code. When a request method is received that is known by an origin code. When a request method is received that is known by an origin
server but not allowed for the target resource, the origin server server but not allowed for the target resource, the origin server
skipping to change at page 63, line 25 skipping to change at page 64, line 20
| CONNECT | no | no | Section 7.3.6 | | CONNECT | no | no | Section 7.3.6 |
| DELETE | no | yes | Section 7.3.5 | | DELETE | no | yes | Section 7.3.5 |
| GET | yes | yes | Section 7.3.1 | | GET | yes | yes | Section 7.3.1 |
| HEAD | yes | yes | Section 7.3.2 | | HEAD | yes | yes | Section 7.3.2 |
| OPTIONS | yes | yes | Section 7.3.7 | | OPTIONS | yes | yes | Section 7.3.7 |
| POST | no | no | Section 7.3.3 | | POST | no | no | Section 7.3.3 |
| PUT | no | yes | Section 7.3.4 | | PUT | no | yes | Section 7.3.4 |
| TRACE | yes | yes | Section 7.3.8 | | TRACE | yes | yes | Section 7.3.8 |
+---------+------+------------+----------------+ +---------+------+------------+----------------+
Table 5
7.2.1. Safe Methods 7.2.1. Safe Methods
Request methods are considered "safe" if their defined semantics are Request methods are considered "safe" if their defined semantics are
essentially read-only; i.e., the client does not request, and does essentially read-only; i.e., the client does not request, and does
not expect, any state change on the origin server as a result of not expect, any state change on the origin server as a result of
applying a safe method to a target resource. Likewise, reasonable applying a safe method to a target resource. Likewise, reasonable
use of a safe method is not expected to cause any harm, loss of use of a safe method is not expected to cause any harm, loss of
property, or unusual burden on the origin server. property, or unusual burden on the origin server.
This definition of safe methods does not prevent an implementation This definition of safe methods does not prevent an implementation
skipping to change at page 64, line 47 skipping to change at page 65, 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-
idempotent method unless it has some means to know that the request
semantics are actually idempotent, regardless of the method, or some
means to detect that the original request was never applied. 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 proxy MUST NOT automatically retry non-idempotent requests.
A client SHOULD NOT automatically retry a failed automatic retry.
7.2.3. Cacheable Methods 7.2.3. Cacheable Methods
Request methods can be defined as "cacheable" to indicate that Request methods can be defined as "cacheable" to indicate that
responses to them are allowed to be stored for future reuse; for responses to them are allowed to be stored for future reuse; for
specific requirements see [Caching]. In general, safe methods that specific requirements see [Caching]. In general, safe methods that
do not depend on a current or authoritative response are defined as do not depend on a current or authoritative response are defined as
cacheable; this specification defines GET, HEAD, and POST as cacheable; this specification defines GET, HEAD, and POST as
cacheable, although the overwhelming majority of cache cacheable, although the overwhelming majority of cache
implementations only support GET and HEAD. implementations only support GET and HEAD.
skipping to change at page 73, line 28 skipping to change at page 74, line 33
payload body is to be sent in the response. 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. Although this specification does not representation media type. Note that this specification does not
define any use for such a payload, future extensions to HTTP might define any use for such a payload.
use the OPTIONS body to make more detailed queries about the target
resource.
Responses to the OPTIONS method are not cacheable. Responses to the OPTIONS method are not cacheable.
7.3.8. TRACE 7.3.8. TRACE
The TRACE method requests a remote, application-level loop-back of The TRACE method requests a remote, application-level loop-back of
the request message. The final recipient of the request SHOULD the request message. The final recipient of the request SHOULD
reflect the message received, excluding some fields described below, reflect the message received, excluding some fields described below,
back to the client as the message body of a 200 (OK) response with a back to the client as the message body of a 200 (OK) response with a
Content-Type of "message/http" (Section 10.1 of [Messaging]). The Content-Type of "message/http" (Section 10.1 of [Messaging]). The
skipping to change at page 108, line 15 skipping to change at page 109, line 15
| 409 | Conflict | Section 9.5.10 | | 409 | Conflict | Section 9.5.10 |
| 410 | Gone | Section 9.5.11 | | 410 | Gone | Section 9.5.11 |
| 411 | Length Required | Section 9.5.12 | | 411 | Length Required | Section 9.5.12 |
| 412 | Precondition Failed | Section 9.5.13 | | 412 | Precondition Failed | Section 9.5.13 |
| 413 | Payload Too Large | Section 9.5.14 | | 413 | Payload Too Large | Section 9.5.14 |
| 414 | URI Too Long | Section 9.5.15 | | 414 | URI Too Long | Section 9.5.15 |
| 415 | Unsupported Media Type | Section 9.5.16 | | 415 | Unsupported Media Type | Section 9.5.16 |
| 416 | Range Not Satisfiable | Section 9.5.17 | | 416 | Range Not Satisfiable | Section 9.5.17 |
| 417 | Expectation Failed | Section 9.5.18 | | 417 | Expectation Failed | Section 9.5.18 |
| 418 | (Unused) | Section 9.5.19 | | 418 | (Unused) | Section 9.5.19 |
| 422 | Unprocessable Entity | Section 9.5.20 | | 422 | Unprocessable Payload | Section 9.5.20 |
| 426 | Upgrade Required | Section 9.5.21 | | 426 | Upgrade Required | Section 9.5.21 |
| 500 | Internal Server Error | Section 9.6.1 | | 500 | Internal Server Error | Section 9.6.1 |
| 501 | Not Implemented | Section 9.6.2 | | 501 | Not Implemented | Section 9.6.2 |
| 502 | Bad Gateway | Section 9.6.3 | | 502 | Bad Gateway | Section 9.6.3 |
| 503 | Service Unavailable | Section 9.6.4 | | 503 | Service Unavailable | Section 9.6.4 |
| 504 | Gateway Timeout | Section 9.6.5 | | 504 | Gateway Timeout | Section 9.6.5 |
| 505 | HTTP Version Not Supported | Section 9.6.6 | | 505 | HTTP Version Not Supported | Section 9.6.6 |
+-------+-------------------------------+-----------------+ +-------+-------------------------------+-----------------+
Table 6
Note that this list is not exhaustive -- it does not include Note that this list is not exhaustive -- it does not include
extension status codes defined in other specifications (Section 9.7). extension status codes defined in other specifications (Section 9.7).
9.2. Informational 1xx 9.2. Informational 1xx
The 1xx (Informational) class of status code indicates an interim The 1xx (Informational) class of status code indicates an interim
response for communicating connection status or request progress response for communicating connection status or request progress
prior to completing the requested action and sending a final prior to completing the requested action and sending a final
response. 1xx responses are terminated by the first empty line after response. 1xx responses are terminated by the first empty line after
the status-line (the empty line signaling the end of the header the status-line (the empty line signaling the end of the header
skipping to change at page 127, line 8 skipping to change at page 128, line 8
418 status code. In the intervening years, this status code has been 418 status code. In the intervening years, this status code has been
widely implemented as an "Easter Egg", and therefore is effectively widely implemented as an "Easter Egg", and therefore is effectively
consumed by this use. consumed by this use.
Therefore, the 418 status code is reserved in the IANA HTTP Status Therefore, the 418 status code is reserved in the IANA HTTP Status
Code registry. This indicates that the status code cannot be Code registry. This indicates that the status code cannot be
assigned to other applications currently. If future circumstances assigned to other applications currently. If future circumstances
require its use (e.g., exhaustion of 4NN status codes), it can be re- require its use (e.g., exhaustion of 4NN status codes), it can be re-
assigned to another use. assigned to another use.
9.5.20. 422 Unprocessable Entity 9.5.20. 422 Unprocessable Payload
The 422 (Unprocessable Entity) status code indicates that the server The 422 (Unprocessable Payload) status code indicates that the server
understands the content type of the request entity (hence a 415 understands the content type of the request payload (hence a 415
(Unsupported Media Type) status code is inappropriate), and the (Unsupported Media Type) status code is inappropriate), and the
syntax of the request entity is correct but was unable to process the syntax of the request payload is correct, but was unable to process
contained instructions. For example, this error condition may occur the contained instructions. For example, this status code can be
if an XML request body contains well-formed (i.e., syntactically sent if an XML request payload contains well-formed (i.e.,
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.8 of
[Messaging]). [Messaging]).
skipping to change at page 151, line 15 skipping to change at page 152, line 15
11. ABNF List Extension: #rule 11. 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
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 )
For compatibility with legacy list rules, a recipient MUST parse and 11.2. Recipient Requirements
ignore a reasonable number of empty list elements: enough to handle
common mistakes by senders that merge values, but not so much that
they could be used as a denial-of-service mechanism. In other words,
a recipient MUST accept lists that satisfy the following syntax:
#element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ] Empty elements do not contribute to the count of elements present. A
recipient MUST parse and ignore a reasonable number of empty list
elements: enough to handle common mistakes by senders that merge
values, but not so much that they could be used as a denial-of-
service mechanism. In other words, a recipient MUST accept lists
that satisfy the following syntax:
1#element => *( "," OWS ) element *( OWS "," [ OWS element ] ) #element => [ element ] *( OWS "," OWS [ element ] )
Note that because of the potential presence of empty list elements,
the RFC 5234 ABNF cannot enforce the cardinality of list elements,
and consequently all cases are mapped is if there was no cardinality
specified.
Empty elements do not contribute to the count of elements present.
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
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,"
skipping to change at page 162, line 18 skipping to change at page 163, line 18
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
'informational' are to have a status of 'permanent'. 'informational' are to have a status of 'permanent'.
3. Entries with a status of 'deprecated' are to have a status of 3. Provisional entries without a status are to have a status of
'obsoleted'.
4. Provisional entries without a status are to have a status of
'provisional'. 'provisional'.
5. Permanent entries without a status (after confirmation that the 4. Permanent entries without a status (after confirmation that the
registration document did not define one) will have a status of registration document did not define one) will have a status of
'provisional'. The Expert(s) can choose to update their status 'provisional'. The Expert(s) can choose to update their status
if there is evidence that another is more appropriate. if there is evidence that another is more appropriate.
Please annotate the Permanent and Provisional Message Header Please annotate the Permanent and Provisional Message Header
registries to indicate that HTTP header field registrations have registries to indicate that HTTP header field registrations have
moved, with an appropriate link. moved, with an appropriate link.
After that is complete, please update the new registry with the After that is complete, please update the new registry with the
header field names listed in the table of Section 4.1. header field names listed in the table of Section 4.1.
skipping to change at page 163, line 31 skipping to change at page 164, line 24
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.4 for the media type "multipart/
byteranges". byteranges".
14. References 14. References
14.1. Normative References 14.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-04 (work in Ed., "HTTP Caching", draft-ietf-httpbis-cache-05 (work in
progress), March 2019. progress), July 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-04 Ed., "HTTP/1.1 Messaging", draft-ietf-httpbis-messaging-05
(work in progress), March 2019. (work in progress), July 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 171, line 5 skipping to change at page 171, line 9
<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>.
[Sniffing]
WHATWG, "MIME Sniffing",
<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 11.
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
Allow = [ ( "," / method ) *( OWS "," [ OWS method ] ) ] Allow = [ method ] *( OWS "," OWS [ method ] )
Authentication-Info = [ ( "," / auth-param ) *( OWS "," [ OWS Authentication-Info = [ auth-param ] *( OWS "," OWS [ auth-param ] )
auth-param ] ) ]
Authorization = credentials Authorization = credentials
BWS = OWS BWS = OWS
Content-Encoding = *( "," OWS ) content-coding *( OWS "," [ OWS Content-Encoding = [ content-coding ] *( OWS "," OWS [ content-coding
content-coding ] ) ] )
Content-Language = *( "," OWS ) language-tag *( OWS "," [ OWS Content-Language = [ language-tag ] *( OWS "," OWS [ language-tag ]
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 = byte-content-range / other-content-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
HTTP-date = IMF-fixdate / obs-date HTTP-date = IMF-fixdate / obs-date
Host = uri-host [ ":" port ] Host = uri-host [ ":" port ]
IMF-fixdate = day-name "," SP date1 SP time-of-day SP GMT IMF-fixdate = day-name "," SP date1 SP time-of-day SP GMT
If-Match = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS If-Match = "*" / ( [ entity-tag ] *( OWS "," OWS [ entity-tag ] ) )
entity-tag ] ) )
If-Modified-Since = HTTP-date If-Modified-Since = HTTP-date
If-None-Match = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS If-None-Match = "*" / ( [ entity-tag ] *( OWS "," OWS [ entity-tag ]
entity-tag ] ) ) ) )
If-Range = entity-tag / HTTP-date If-Range = entity-tag / HTTP-date
If-Unmodified-Since = HTTP-date If-Unmodified-Since = HTTP-date
Last-Modified = HTTP-date Last-Modified = HTTP-date
Location = URI-reference Location = URI-reference
Max-Forwards = 1*DIGIT Max-Forwards = 1*DIGIT
OWS = *( SP / HTAB ) OWS = *( SP / HTAB )
Proxy-Authenticate = *( "," OWS ) challenge *( OWS "," [ OWS Proxy-Authenticate = [ challenge ] *( OWS "," OWS [ challenge ] )
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 = byte-ranges-specifier / other-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 = *( "," OWS ) 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 ) )
Vary = "*" / ( *( "," OWS ) field-name *( OWS "," [ OWS field-name ] Vary = "*" / ( [ field-name ] *( OWS "," OWS [ field-name ] ) )
) )
Via = *( "," OWS ) ( received-protocol RWS received-by [ RWS comment Via = *( "," OWS ) ( received-protocol RWS received-by [ RWS comment
] ) *( OWS "," [ OWS ( received-protocol RWS received-by [ RWS ] ) *( OWS "," [ OWS ( received-protocol RWS received-by [ RWS
comment ] ) ] ) comment ] ) ] )
WWW-Authenticate = *( "," OWS ) challenge *( OWS "," [ OWS challenge WWW-Authenticate = [ challenge ] *( OWS "," OWS [ challenge ] )
] )
absolute-URI = <absolute-URI, see [RFC3986], Section 4.3> absolute-URI = <absolute-URI, see [RFC3986], Section 4.3>
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 = ( *( "," OWS ) range-unit *( OWS "," [ OWS acceptable-ranges = ( [ range-unit ] *( OWS "," OWS [ range-unit ] )
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 / byte-content-range = bytes-unit SP ( byte-range-resp /
unsatisfied-range ) unsatisfied-range )
byte-range = first-byte-pos "-" last-byte-pos byte-range = first-byte-pos "-" last-byte-pos
byte-range-resp = byte-range "/" ( complete-length / "*" ) byte-range-resp = byte-range "/" ( complete-length / "*" )
byte-range-set = *( "," OWS ) ( byte-range-spec / byte-range-set = *( "," OWS ) ( byte-range-spec /
suffix-byte-range-spec ) *( OWS "," [ OWS ( byte-range-spec / suffix-byte-range-spec ) *( OWS "," [ OWS ( byte-range-spec /
suffix-byte-range-spec ) ] ) suffix-byte-range-spec ) ] )
byte-range-spec = first-byte-pos "-" [ last-byte-pos ] byte-range-spec = first-byte-pos "-" [ last-byte-pos ]
byte-ranges-specifier = bytes-unit "=" byte-range-set byte-ranges-specifier = bytes-unit "=" byte-range-set
bytes-unit = "bytes" bytes-unit = "bytes"
challenge = auth-scheme [ 1*SP ( token68 / [ ( "," / auth-param ) *( challenge = auth-scheme [ 1*SP ( token68 / ( [ auth-param ] *( OWS
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 ) credentials = auth-scheme [ 1*SP ( token68 / ( [ auth-param ] *( OWS
*( OWS "," [ OWS auth-param ] ) ] ) ] "," OWS [ auth-param ] ) ) ) ]
ctext = HTAB / SP / %x21-27 ; '!'-''' ctext = HTAB / SP / %x21-27 ; '!'-'''
/ %x2A-5B ; '*'-'[' / %x2A-5B ; '*'-'['
/ %x5D-7E ; ']'-'~' / %x5D-7E ; ']'-'~'
/ obs-text / obs-text
date1 = day SP month SP year date1 = day SP month SP year
date2 = day "-" month "-" 2DIGIT date2 = day "-" month "-" 2DIGIT
date3 = month SP ( 2DIGIT / ( SP DIGIT ) ) date3 = month SP ( 2DIGIT / ( SP DIGIT ) )
day = 2DIGIT day = 2DIGIT
day-name = %x4D.6F.6E ; Mon day-name = %x4D.6F.6E ; Mon
skipping to change at page 174, line 5 skipping to change at page 174, line 47
/ %x54.68.75.72.73.64.61.79 ; Thursday / %x54.68.75.72.73.64.61.79 ; Thursday
/ %x46.72.69.64.61.79 ; Friday / %x46.72.69.64.61.79 ; Friday
/ %x53.61.74.75.72.64.61.79 ; Saturday / %x53.61.74.75.72.64.61.79 ; Saturday
/ %x53.75.6E.64.61.79 ; Sunday / %x53.75.6E.64.61.79 ; Sunday
delay-seconds = 1*DIGIT delay-seconds = 1*DIGIT
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-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-byte-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 ]
language-range = <language-range, see [RFC4647], Section 2.1> language-range = <language-range, see [RFC4647], Section 2.1>
skipping to change at page 174, line 48 skipping to change at page 175, line 43
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-content-range = other-range-unit SP other-range-resp
other-range-resp = *VCHAR other-range-resp = *VCHAR
other-range-set = 1*VCHAR other-range-set = 1*VCHAR
other-range-unit = token other-range-unit = token
other-ranges-specifier = other-range-unit "=" other-range-set other-ranges-specifier = other-range-unit "=" other-range-set
parameter = token "=" ( token / quoted-string ) parameter = parameter-name "=" parameter-value
parameter-name = token
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 ; '#'-'['
skipping to change at page 180, line 42 skipping to change at page 181, line 37
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
o In Section 4.2, fix field-content ABNF
(<https://github.com/httpwg/http-core/issues/19>,
<https://www.rfc-editor.org/errata/eid4189>)
o Move Section 4.2.3.4 into its own section
(<https://github.com/httpwg/http-core/issues/45>)
o In Section 6.2.1, reference MIME Sniffing
(<https://github.com/httpwg/http-core/issues/51>)
o In Section 11, simplify the #rule mapping for recipients
(<https://github.com/httpwg/http-core/issues/164>,
<https://www.rfc-editor.org/errata/eid5257>)
o In Section 7.3.7, remove misleading text about "extension" of HTTP
is needed to define method payloads (<https://github.com/httpwg/
http-core/issues/204>)
o Fix editorial issue in Section 6 (<https://github.com/httpwg/http-
core/issues/223>)
o In Section 9.5.20, rephrase language not to use "entity" anymore,
and also avoid lowercase "may" (<https://github.com/httpwg/http-
core/issues/224>)
o Move discussion of retries from [Messaging] into Section 7.2.2
(<https://github.com/httpwg/http-core/issues/230>)
Index Index
1 1
100 Continue (status code) 108 100 Continue (status code) 110
100-continue (expect value) 76 100-continue (expect value) 77
101 Switching Protocols (status code) 109 101 Switching Protocols (status code) 110
1xx Informational (status code class) 108 1xx Informational (status code class) 109
2 2
200 OK (status code) 109 200 OK (status code) 110
201 Created (status code) 110 201 Created (status code) 111
202 Accepted (status code) 110 202 Accepted (status code) 111
203 Non-Authoritative Information (status code) 111 203 Non-Authoritative Information (status code) 112
204 No Content (status code) 111 204 No Content (status code) 112
205 Reset Content (status code) 112 205 Reset Content (status code) 113
206 Partial Content (status code) 112 206 Partial Content (status code) 113
2xx Successful (status code class) 109 2xx Successful (status code class) 110
3 3
300 Multiple Choices (status code) 117 300 Multiple Choices (status code) 118
301 Moved Permanently (status code) 118 301 Moved Permanently (status code) 119
302 Found (status code) 118 302 Found (status code) 119
303 See Other (status code) 119 303 See Other (status code) 120
304 Not Modified (status code) 119 304 Not Modified (status code) 120
305 Use Proxy (status code) 120 305 Use Proxy (status code) 121
306 (Unused) (status code) 120 306 (Unused) (status code) 121
307 Temporary Redirect (status code) 120 307 Temporary Redirect (status code) 121
308 Permanent Redirect (status code) 121 308 Permanent Redirect (status code) 122
3xx Redirection (status code class) 115 3xx Redirection (status code class) 116
4 4
400 Bad Request (status code) 121 400 Bad Request (status code) 122
401 Unauthorized (status code) 121 401 Unauthorized (status code) 122
402 Payment Required (status code) 122 402 Payment Required (status code) 123
403 Forbidden (status code) 122 403 Forbidden (status code) 123
404 Not Found (status code) 122 404 Not Found (status code) 123
405 Method Not Allowed (status code) 123 405 Method Not Allowed (status code) 124
406 Not Acceptable (status code) 123 406 Not Acceptable (status code) 124
407 Proxy Authentication Required (status code) 123 407 Proxy Authentication Required (status code) 124
408 Request Timeout (status code) 123 408 Request Timeout (status code) 124
409 Conflict (status code) 124 409 Conflict (status code) 125
410 Gone (status code) 124 410 Gone (status code) 125
411 Length Required (status code) 124 411 Length Required (status code) 125
412 Precondition Failed (status code) 125 412 Precondition Failed (status code) 126
413 Payload Too Large (status code) 125 413 Payload Too Large (status code) 126
414 URI Too Long (status code) 125 414 URI Too Long (status code) 126
415 Unsupported Media Type (status code) 125 415 Unsupported Media Type (status code) 126
416 Range Not Satisfiable (status code) 126 416 Range Not Satisfiable (status code) 127
417 Expectation Failed (status code) 126 417 Expectation Failed (status code) 127
418 (Unused) (status code) 126 418 (Unused) (status code) 127
422 Unprocessable Entity (status code) 127 422 Unprocessable Payload (status code) 128
426 Upgrade Required (status code) 127 426 Upgrade Required (status code) 128
4xx Client Error (status code class) 121 4xx Client Error (status code class) 122
5 5
500 Internal Server Error (status code) 128 500 Internal Server Error (status code) 129
501 Not Implemented (status code) 128 501 Not Implemented (status code) 129
502 Bad Gateway (status code) 128 502 Bad Gateway (status code) 129
503 Service Unavailable (status code) 128 503 Service Unavailable (status code) 129
504 Gateway Timeout (status code) 128 504 Gateway Timeout (status code) 129
505 HTTP Version Not Supported (status code) 128 505 HTTP Version Not Supported (status code) 129
5xx Server Error (status code class) 127 5xx Server Error (status code class) 128
A A
Accept header field 92 Accept header field 93
Accept-Charset header field 94 Accept-Charset header field 95
Accept-Encoding header field 95 Accept-Encoding header field 96
Accept-Language header field 96 Accept-Language header field 97
Accept-Ranges header field 149 Accept-Ranges header field 150
Allow header field 149 Allow header field 150
Authentication-Info header field 147 Authentication-Info header field 148
Authorization header field 100 Authorization header field 101
accelerator 12 accelerator 13
authoritative response 152 authoritative response 153
B B
browser 10 browser 10
C C
CONNECT method 71 CONNECT method 72
Canonical Root URI 99 Canonical Root URI 100
Content-Encoding header field 48 Content-Encoding header field 49
Content-Language header field 49 Content-Language header field 50
Content-Length header field 50 Content-Length header field 50
Content-Location header field 51 Content-Location header field 52
Content-MD5 header field 162 Content-MD5 header field 163
Content-Range header field 55 Content-Range header field 55
Content-Type header field 47 Content-Type header field 48
cache 14 cache 14
cacheable 14, 64 cacheable 14, 66
captive portal 13 captive portal 13
client 10 client 10
compress (Coding Format) 42 compress (Coding Format) 43
compress (content coding) 41 compress (content coding) 42
conditional request 79 conditional request 80
connection 10 connection 10
content coding 41 content coding 42
content negotiation 8 content negotiation 8
D D
DELETE method 70 DELETE method 71
Date header field 133 Date header field 134
Delimiters 29 Delimiters 29
deflate (Coding Format) 42 deflate (Coding Format) 43
deflate (content coding) 41 deflate (content coding) 42
downstream 12 downstream 12
E E
ETag header field 141 ETag header field 142
Expect header field 76 Expect header field 77
effective request URI 33 effective request URI 34
F F
Fragment Identifiers 18 Fragment Identifiers 18
From header field 103 From header field 104
G G
GET method 65 GET method 66
Grammar Grammar
absolute-path 15 absolute-path 15
absolute-URI 15 absolute-URI 15
Accept 92 Accept 93
Accept-Charset 94 Accept-Charset 95
Accept-Encoding 95 Accept-Encoding 96
accept-ext 92 accept-ext 93
Accept-Language 96 Accept-Language 97
accept-params 92 accept-params 93
Accept-Ranges 149 Accept-Ranges 150
acceptable-ranges 149 acceptable-ranges 150
Allow 149 Allow 150
ALPHA 9 ALPHA 9
asctime-date 132 asctime-date 133
auth-param 98 auth-param 99
auth-scheme 98 auth-scheme 99
Authentication-Info 147 Authentication-Info 148
authority 15 authority 15
Authorization 100 Authorization 101
BWS 31 BWS 32
byte-content-range 55 byte-content-range 56
byte-range 55 byte-range 56
byte-range-resp 55 byte-range-resp 56
byte-range-set 44 byte-range-set 45
byte-range-spec 44 byte-range-spec 45
byte-ranges-specifier 44 byte-ranges-specifier 45
bytes-unit 44 bytes-unit 44-45
challenge 98 challenge 99
charset 40 charset 40
codings 95 codings 96
comment 30 comment 30
complete-length 55 complete-length 56
content-coding 41 content-coding 42
Content-Encoding 48 Content-Encoding 49
Content-Language 49 Content-Language 50
Content-Length 50 Content-Length 50
Content-Location 51 Content-Location 52
Content-Range 55 Content-Range 56
Content-Type 47 Content-Type 48
CR 9 CR 9
credentials 99 credentials 100
CRLF 9 CRLF 9
ctext 30 ctext 30
CTL 9 CTL 9
Date 133 Date 134
date1 132 date1 133
day 132 day 133
day-name 132 day-name 133
day-name-l 132 day-name-l 133
delay-seconds 135 delay-seconds 136
DIGIT 9 DIGIT 9
DQUOTE 9 DQUOTE 9
entity-tag 142 entity-tag 143
ETag 142 ETag 143
etagc 142 etagc 143
Expect 76 Expect 77
field-content 28 field-content 28
field-name 23, 31 field-name 23, 32
field-value 28 field-value 28
field-vchar 28 field-vchar 28
first-byte-pos 44 first-byte-pos 45
From 103 From 104
GMT 132 GMT 133
HEXDIG 9 HEXDIG 9
Host 34 Host 34
hour 132 hour 133
HTAB 9 HTAB 9
HTTP-date 131 HTTP-date 132
http-URI 16 http-URI 16
https-URI 17 https-URI 18
If-Match 83 If-Match 84
If-Modified-Since 85 If-Modified-Since 86
If-None-Match 84 If-None-Match 85
If-Range 88 If-Range 89
If-Unmodified-Since 86 If-Unmodified-Since 87
IMF-fixdate 132 IMF-fixdate 133
language-range 96 language-range 97
language-tag 43 language-tag 44
last-byte-pos 44 last-byte-pos 45
Last-Modified 139 Last-Modified 140
LF 9 LF 9
Location 134 Location 135
Max-Forwards 78 Max-Forwards 79
media-range 92 media-range 93
media-type 39 media-type 40
method 61 method 62
minute 132 minute 133
month 132 month 133
obs-date 132 obs-date 133
obs-text 29 obs-text 30
OCTET 9 OCTET 9
opaque-tag 142 opaque-tag 143
other-content-range 55 other-content-range 56
other-range-resp 55 other-range-resp 56
other-range-unit 44, 46 other-range-unit 44, 47
OWS 31 OWS 32
parameter 39 parameter 30
parameter-name 30
parameter-value 30
partial-URI 15 partial-URI 15
port 15 port 15
product 105 product 106
product-version 105 product-version 106
protocol-name 35 protocol-name 36
protocol-version 35 protocol-version 36
Proxy-Authenticate 147 Proxy-Authenticate 148
Proxy-Authentication-Info 148 Proxy-Authentication-Info 149
Proxy-Authorization 100 Proxy-Authorization 101
pseudonym 35 pseudonym 36
qdtext 29 qdtext 30
query 15 query 15
quoted-pair 30 quoted-pair 30
quoted-string 29 quoted-string 30
qvalue 92 qvalue 93
Range 89 Range 90
range-unit 44 range-unit 44
ranges-specifier 44 ranges-specifier 45
received-by 35 received-by 36
received-protocol 35 received-protocol 36
Referer 104 Referer 105
Retry-After 135 Retry-After 136
rfc850-date 132 rfc850-date 133
RWS 31 RWS 32
second 132 second 133
segment 15 segment 15
Server 150 Server 151
SP 9 SP 9
subtype 39 subtype 40
suffix-byte-range-spec 45 suffix-byte-range-spec 46
suffix-length 45 suffix-length 46
tchar 29 tchar 29
time-of-day 132 time-of-day 133
token 29 token 29
token68 98 token68 99
Trailer 31 Trailer 32
type 39 type 40
unsatisfied-range 55 unsatisfied-range 56
uri-host 15 uri-host 15
URI-reference 15 URI-reference 15
User-Agent 105 User-Agent 106
Vary 136 Vary 137
VCHAR 9 VCHAR 9
Via 35 Via 36
weak 142 weak 143
weight 92 weight 93
WWW-Authenticate 146 WWW-Authenticate 147
year 132 year 133
gateway 12 gateway 13
gzip (Coding Format) 42 gzip (Coding Format) 43
gzip (content coding) 41 gzip (content coding) 42
H H
HEAD method 66 HEAD method 67
Host header field 33 Host header field 34
http URI scheme 16 http URI scheme 16
https URI scheme 17 https URI scheme 17
I I
If-Match header field 83 If-Match header field 84
If-Modified-Since header field 85 If-Modified-Since header field 86
If-None-Match header field 84 If-None-Match header field 85
If-Range header field 87 If-Range header field 88
If-Unmodified-Since header field 86 If-Unmodified-Since header field 87
idempotent 64 idempotent 65
inbound 12 inbound 12
interception proxy 13 interception proxy 13
intermediary 12 intermediary 12
L L
Last-Modified header field 139 Last-Modified header field 140
Location header field 134 Location header field 135
M M
Max-Forwards header field 78 Max-Forwards header field 79
Media Type Media Type
multipart/byteranges 57 multipart/byteranges 57
multipart/x-byteranges 57 multipart/x-byteranges 58
message 10 message 11
metadata 137 metadata 138
multipart/byteranges Media Type 57 multipart/byteranges Media Type 57
multipart/x-byteranges Media Type 57 multipart/x-byteranges Media Type 58
N N
non-transforming proxy 37 non-transforming proxy 38
O O
OPTIONS method 72 OPTIONS method 73
origin server 10 origin server 10
outbound 12 outbound 12
P P
POST method 66 POST method 67
PUT method 67 PUT method 68
Protection Space 99 Protection Space 100
Proxy-Authenticate header field 147 Proxy-Authenticate header field 148
Proxy-Authentication-Info header field 148 Proxy-Authentication-Info header field 149
Proxy-Authorization header field 100 Proxy-Authorization header field 101
payload 53 payload 54
phishing 152 phishing 153
proxy 12 proxy 12
R R
Range header field 89 Range header field 90
Realm 99 Realm 100
Referer header field 104 Referer header field 105
Retry-After header field 135 Retry-After header field 136
recipient 10 recipient 10
representation 38 representation 39
request 10 request 11
resource 14 resource 15
response 10 response 11
reverse proxy 12 reverse proxy 13
S S
Server header field 150 Server header field 151
Status Codes Classes Status Codes Classes
1xx Informational 108 1xx Informational 109
2xx Successful 109 2xx Successful 110
3xx Redirection 115 3xx Redirection 116
4xx Client Error 121 4xx Client Error 122
5xx Server Error 127 5xx Server Error 128
safe 63 safe 64
selected representation 38, 79, 137 selected representation 39, 80, 138
sender 10 sender 10
server 10 server 10
spider 10 spider 10
T T
TRACE method 73 TRACE method 74
Trailer header field 31 Trailer header field 32
target URI 32 target URI 33
target resource 32 target resource 33
transforming proxy 37 transforming proxy 38
transparent proxy 13 transparent proxy 13
tunnel 13 tunnel 13
U U
URI scheme URI scheme
http 16 http 16
https 17 https 17
User-Agent header field 105 User-Agent header field 106
upstream 12 upstream 12
user agent 10 user agent 10
V V
Vary header field 136 Vary header field 137
Via header field 35 Via header field 36
validator 137 validator 138
strong 138 strong 139
weak 138 weak 139
W W
WWW-Authenticate header field 146 WWW-Authenticate header field 147
X X
x-compress (content coding) 41 x-compress (content coding) 42
x-gzip (content coding) 41 x-gzip (content coding) 42
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, and RFC
2616, including substantial contributions made by the previous 2616, including substantial contributions made by the previous
authors, editors, and Working Group Chairs: Tim Berners-Lee, Ari authors, editors, and Working Group Chairs: Tim Berners-Lee, Ari
Luotonen, Roy T. Fielding, Henrik Frystyk Nielsen, Jim Gettys, 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, and Yves Lafon.
 End of changes. 129 change blocks. 
569 lines changed or deleted 658 lines changed or added

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