draft-ietf-httpbis-semantics-04.txt   draft-ietf-httpbis-semantics-latest.txt 
HTTP Working Group R. Fielding, Ed. HTTP Working Group R. Fielding, Ed.
Internet-Draft Adobe Internet-Draft Adobe
Obsoletes: M. Nottingham, Ed. Obsoletes: M. Nottingham, Ed.
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: October 16, 2019 April 14, 2019
HTTP Semantics HTTP Semantics
draft-ietf-httpbis-semantics-04 draft-ietf-httpbis-semantics-latest
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is a stateless application- The Hypertext Transfer Protocol (HTTP) is a stateless application-
level protocol for distributed, collaborative, hypertext information level protocol for distributed, collaborative, hypertext information
systems. This document defines the semantics of HTTP: its systems. This document defines the semantics of HTTP: its
architecture, terminology, the "http" and "https" Uniform Resource architecture, terminology, the "http" and "https" Uniform Resource
Identifier (URI) schemes, core request methods, request header Identifier (URI) schemes, core request methods, request header
fields, response status codes, response header fields, and content fields, response status codes, response header fields, and content
negotiation. negotiation.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
This note is to be removed before publishing as an RFC. This note is to be removed before publishing as an RFC.
Discussion of this draft takes place on the HTTP working group Discussion of this draft takes place on the HTTP working group
mailing list (ietf-http-wg@w3.org), which is archived at mailing list (ietf-http-wg@w3.org), which is archived at
<https://lists.w3.org/Archives/Public/ietf-http-wg/>. <https://lists.w3.org/Archives/Public/ietf-http-wg/>.
Working Group information can be found at <https://httpwg.org/>; Working Group information can be found at <https://httpwg.org/>;
source code and issues list for this draft can be found at source code and issues list for this draft can be found at
<https://github.com/httpwg/http-core>. <https://github.com/httpwg/http-core>.
The changes in this draft are summarized in Appendix 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 October 16, 2019.
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 . . . . . . . . . . . . . . . . . . 65
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 . . . . . . . . . . . . . . . . . . . . . . . . 66
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 . . . . . . . . . . . . . . . . . . . . . . . 70
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 . . . . . . . . . . . . . . . . . . . . . . . 76
8.1.2. Max-Forwards . . . . . . . . . . . . . . . . . . . . 78 8.1.2. Max-Forwards . . . . . . . . . . . . . . . . . . . . 79
8.2. Preconditions . . . . . . . . . . . . . . . . . . . . . . 79 8.2. Preconditions . . . . . . . . . . . . . . . . . . . . . . 79
8.2.1. Evaluation . . . . . . . . . . . . . . . . . . . . . 80 8.2.1. Evaluation . . . . . . . . . . . . . . . . . . . . . 80
8.2.2. Precedence . . . . . . . . . . . . . . . . . . . . . 81 8.2.2. Precedence . . . . . . . . . . . . . . . . . . . . . 81
8.2.3. If-Match . . . . . . . . . . . . . . . . . . . . . . 83 8.2.3. If-Match . . . . . . . . . . . . . . . . . . . . . . 83
8.2.4. If-None-Match . . . . . . . . . . . . . . . . . . . . 84 8.2.4. If-None-Match . . . . . . . . . . . . . . . . . . . . 84
8.2.5. If-Modified-Since . . . . . . . . . . . . . . . . . . 85 8.2.5. If-Modified-Since . . . . . . . . . . . . . . . . . . 85
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 89
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 . . . . . . . . . . . . . . . . . . . . . . . 92
8.4.3. Accept-Charset . . . . . . . . . . . . . . . . . . . 94 8.4.3. Accept-Charset . . . . . . . . . . . . . . . . . . . 94
8.4.4. Accept-Encoding . . . . . . . . . . . . . . . . . . . 95 8.4.4. Accept-Encoding . . . . . . . . . . . . . . . . . . . 95
8.4.5. Accept-Language . . . . . . . . . . . . . . . . . . . 96 8.4.5. Accept-Language . . . . . . . . . . . . . . . . . . . 96
8.5. Authentication Credentials . . . . . . . . . . . . . . . 97 8.5. Authentication Credentials . . . . . . . . . . . . . . . 97
8.5.1. Challenge and Response . . . . . . . . . . . . . . . 97 8.5.1. Challenge and Response . . . . . . . . . . . . . . . 97
8.5.2. Protection Space (Realm) . . . . . . . . . . . . . . 99 8.5.2. Protection Space (Realm) . . . . . . . . . . . . . . 99
8.5.3. Authorization . . . . . . . . . . . . . . . . . . . . 100 8.5.3. Authorization . . . . . . . . . . . . . . . . . . . . 100
8.5.4. Proxy-Authorization . . . . . . . . . . . . . . . . . 100 8.5.4. Proxy-Authorization . . . . . . . . . . . . . . . . . 100
8.5.5. Authentication Scheme Extensibility . . . . . . . . . 101 8.5.5. Authentication Scheme Extensibility . . . . . . . . . 101
8.6. Request Context . . . . . . . . . . . . . . . . . . . . . 103 8.6. Request Context . . . . . . . . . . . . . . . . . . . . . 103
8.6.1. From . . . . . . . . . . . . . . . . . . . . . . . . 103 8.6.1. From . . . . . . . . . . . . . . . . . . . . . . . . 103
8.6.2. Referer . . . . . . . . . . . . . . . . . . . . . . . 104 8.6.2. Referer . . . . . . . . . . . . . . . . . . . . . . . 104
8.6.3. User-Agent . . . . . . . . . . . . . . . . . . . . . 105 8.6.3. User-Agent . . . . . . . . . . . . . . . . . . . . . 105
9. Response Status Codes . . . . . . . . . . . . . . . . . . . . 106 9. Response Status Codes . . . . . . . . . . . . . . . . . . . . 106
9.1. Overview of Status Codes . . . . . . . . . . . . . . . . 107 9.1. Overview of Status Codes . . . . . . . . . . . . . . . . 107
9.2. Informational 1xx . . . . . . . . . . . . . . . . . . . . 108 9.2. Informational 1xx . . . . . . . . . . . . . . . . . . . . 108
9.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 108 9.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 109
9.2.2. 101 Switching Protocols . . . . . . . . . . . . . . . 109 9.2.2. 101 Switching Protocols . . . . . . . . . . . . . . . 109
9.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . 109 9.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . 109
9.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 109 9.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 109
9.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 110 9.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 110
9.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . 110 9.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . 110
9.3.4. 203 Non-Authoritative Information . . . . . . . . . . 111 9.3.4. 203 Non-Authoritative Information . . . . . . . . . . 111
9.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . 111 9.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . 111
9.3.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 112 9.3.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 112
9.3.7. 206 Partial Content . . . . . . . . . . . . . . . . . 112 9.3.7. 206 Partial Content . . . . . . . . . . . . . . . . . 112
9.4. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 115 9.4. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 115
skipping to change at page 6, line 30 skipping to change at page 6, line 30
10.3. Authentication Challenges . . . . . . . . . . . . . . . 145 10.3. Authentication Challenges . . . . . . . . . . . . . . . 145
10.3.1. WWW-Authenticate . . . . . . . . . . . . . . . . . . 146 10.3.1. WWW-Authenticate . . . . . . . . . . . . . . . . . . 146
10.3.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . 147 10.3.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . 147
10.3.3. Authentication-Info . . . . . . . . . . . . . . . . 147 10.3.3. Authentication-Info . . . . . . . . . . . . . . . . 147
10.3.4. Proxy-Authentication-Info . . . . . . . . . . . . . 148 10.3.4. Proxy-Authentication-Info . . . . . . . . . . . . . 148
10.4. Response Context . . . . . . . . . . . . . . . . . . . . 149 10.4. Response Context . . . . . . . . . . . . . . . . . . . . 149
10.4.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . 149 10.4.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . 149
10.4.2. Allow . . . . . . . . . . . . . . . . . . . . . . . 149 10.4.2. Allow . . . . . . . . . . . . . . . . . . . . . . . 149
10.4.3. Server . . . . . . . . . . . . . . . . . . . . . . . 150 10.4.3. Server . . . . . . . . . . . . . . . . . . . . . . . 150
11. ABNF List Extension: #rule . . . . . . . . . . . . . . . . . 151 11. ABNF List Extension: #rule . . . . . . . . . . . . . . . . . 151
11.1. Sender Requirements . . . . . . . . . . . . . . . . . . 151
11.2. Recipient Requirements . . . . . . . . . . . . . . . . . 151
12. Security Considerations . . . . . . . . . . . . . . . . . . . 152 12. Security Considerations . . . . . . . . . . . . . . . . . . . 152
12.1. Establishing Authority . . . . . . . . . . . . . . . . . 152 12.1. Establishing Authority . . . . . . . . . . . . . . . . . 152
12.2. Risks of Intermediaries . . . . . . . . . . . . . . . . 153 12.2. Risks of Intermediaries . . . . . . . . . . . . . . . . 153
12.3. Attacks Based on File and Path Names . . . . . . . . . . 154 12.3. Attacks Based on File and Path Names . . . . . . . . . . 154
12.4. Attacks Based on Command, Code, or Query Injection . . . 154 12.4. Attacks Based on Command, Code, or Query Injection . . . 154
12.5. Attacks via Protocol Element Length . . . . . . . . . . 155 12.5. Attacks via Protocol Element Length . . . . . . . . . . 155
12.6. Disclosure of Personal Information . . . . . . . . . . . 155 12.6. Disclosure of Personal Information . . . . . . . . . . . 155
12.7. Privacy of Server Log Information . . . . . . . . . . . 155 12.7. Privacy of Server Log Information . . . . . . . . . . . 156
12.8. Disclosure of Sensitive Information in URIs . . . . . . 156 12.8. Disclosure of Sensitive Information in URIs . . . . . . 156
12.9. Disclosure of Fragment after Redirects . . . . . . . . . 156 12.9. Disclosure of Fragment after Redirects . . . . . . . . . 157
12.10. Disclosure of Product Information . . . . . . . . . . . 157 12.10. Disclosure of Product Information . . . . . . . . . . . 157
12.11. Browser Fingerprinting . . . . . . . . . . . . . . . . . 157 12.11. Browser Fingerprinting . . . . . . . . . . . . . . . . . 157
12.12. Validator Retention . . . . . . . . . . . . . . . . . . 158 12.12. Validator Retention . . . . . . . . . . . . . . . . . . 158
12.13. Denial-of-Service Attacks Using Range . . . . . . . . . 159 12.13. Denial-of-Service Attacks Using Range . . . . . . . . . 159
12.14. Authentication Considerations . . . . . . . . . . . . . 159 12.14. Authentication Considerations . . . . . . . . . . . . . 159
12.14.1. Confidentiality of Credentials . . . . . . . . . . 159 12.14.1. Confidentiality of Credentials . . . . . . . . . . 159
12.14.2. Credentials and Idle Clients . . . . . . . . . . . 160 12.14.2. Credentials and Idle Clients . . . . . . . . . . . 160
12.14.3. Protection Spaces . . . . . . . . . . . . . . . . . 160 12.14.3. Protection Spaces . . . . . . . . . . . . . . . . . 160
12.14.4. Additional Response Header Fields . . . . . . . . . 161 12.14.4. Additional Response Header Fields . . . . . . . . . 161
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 161 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 161
13.1. URI Scheme Registration . . . . . . . . . . . . . . . . 161 13.1. URI Scheme Registration . . . . . . . . . . . . . . . . 161
13.2. Method Registration . . . . . . . . . . . . . . . . . . 161 13.2. Method Registration . . . . . . . . . . . . . . . . . . 161
13.3. Status Code Registration . . . . . . . . . . . . . . . . 161 13.3. Status Code Registration . . . . . . . . . . . . . . . . 161
13.4. Header Field Registration . . . . . . . . . . . . . . . 162 13.4. Header Field Registration . . . . . . . . . . . . . . . 162
13.5. Authentication Scheme Registration . . . . . . . . . . . 162 13.5. Authentication Scheme Registration . . . . . . . . . . . 162
13.6. Content Coding Registration . . . . . . . . . . . . . . 163 13.6. Content Coding Registration . . . . . . . . . . . . . . 162
13.7. Range Unit Registration . . . . . . . . . . . . . . . . 163 13.7. Range Unit Registration . . . . . . . . . . . . . . . . 163
13.8. Media Type Registration . . . . . . . . . . . . . . . . 163 13.8. Media Type Registration . . . . . . . . . . . . . . . . 163
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 163 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 163
14.1. Normative References . . . . . . . . . . . . . . . . . . 163 14.1. Normative References . . . . . . . . . . . . . . . . . . 163
14.2. Informative References . . . . . . . . . . . . . . . . . 165 14.2. Informative References . . . . . . . . . . . . . . . . . 165
Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 171 Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 171
Appendix B. Changes from RFC 7230 . . . . . . . . . . . . . . . 175 Appendix B. Changes from RFC 7230 . . . . . . . . . . . . . . . 175
Appendix C. Changes from RFC 7231 . . . . . . . . . . . . . . . 176 Appendix C. Changes from RFC 7231 . . . . . . . . . . . . . . . 176
Appendix D. Changes from RFC 7232 . . . . . . . . . . . . . . . 176 Appendix D. Changes from RFC 7232 . . . . . . . . . . . . . . . 176
Appendix E. Changes from RFC 7233 . . . . . . . . . . . . . . . 176 Appendix E. Changes from RFC 7233 . . . . . . . . . . . . . . . 176
Appendix F. Changes from RFC 7235 . . . . . . . . . . . . . . . 176 Appendix F. Changes from RFC 7235 . . . . . . . . . . . . . . . 176
Appendix G. Changes from RFC 7538 . . . . . . . . . . . . . . . 176 Appendix G. Changes from RFC 7538 . . . . . . . . . . . . . . . 176
Appendix H. Changes from RFC 7615 . . . . . . . . . . . . . . . 176 Appendix H. Changes from RFC 7615 . . . . . . . . . . . . . . . 176
Appendix I. Change Log . . . . . . . . . . . . . . . . . . . . . 176 Appendix I. Change Log . . . . . . . . . . . . . . . . . . . . . 176
I.1. Between RFC723x and draft 00 . . . . . . . . . . . . . . 176 I.1. Between RFC723x and draft 00 . . . . . . . . . . . . . . 176
I.2. Since draft-ietf-httpbis-semantics-00 . . . . . . . . . . 177 I.2. Since draft-ietf-httpbis-semantics-00 . . . . . . . . . . 177
I.3. Since draft-ietf-httpbis-semantics-01 . . . . . . . . . . 177 I.3. Since draft-ietf-httpbis-semantics-01 . . . . . . . . . . 177
I.4. Since draft-ietf-httpbis-semantics-02 . . . . . . . . . . 179 I.4. Since draft-ietf-httpbis-semantics-02 . . . . . . . . . . 179
I.5. Since draft-ietf-httpbis-semantics-03 . . . . . . . . . . 180 I.5. Since draft-ietf-httpbis-semantics-03 . . . . . . . . . . 179
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 I.6. Since draft-ietf-httpbis-semantics-04 . . . . . . . . . . 180
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 188 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 189
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 189 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 189
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:
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 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 73, line 28 skipping to change at page 74, line 16
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 25 skipping to change at page 108, line 25
| 422 | Unprocessable Entity | Section 9.5.20 | | 422 | Unprocessable Entity | 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 151, line 15 skipping to change at page 151, 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 162, 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 32 skipping to change at page 163, line 25
<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-latest (work Ed., "HTTP Caching", draft-ietf-httpbis-cache-latest (work
in progress), March 2019. in progress), April 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- Ed., "HTTP/1.1 Messaging", draft-ietf-httpbis-messaging-
latest (work in progress), March 2019. latest (work in progress), April 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 170, 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 173, 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 174, 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 180, 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>)
Index Index
1 1
100 Continue (status code) 108 100 Continue (status code) 109
100-continue (expect value) 76 100-continue (expect value) 76
101 Switching Protocols (status code) 109 101 Switching Protocols (status code) 109
1xx Informational (status code class) 108 1xx Informational (status code class) 108
2 2
200 OK (status code) 109 200 OK (status code) 109
201 Created (status code) 110 201 Created (status code) 110
202 Accepted (status code) 110 202 Accepted (status code) 110
203 Non-Authoritative Information (status code) 111 203 Non-Authoritative Information (status code) 111
204 No Content (status code) 111 204 No Content (status code) 111
skipping to change at page 182, line 17 skipping to change at page 182, line 32
A A
Accept header field 92 Accept header field 92
Accept-Charset header field 94 Accept-Charset header field 94
Accept-Encoding header field 95 Accept-Encoding header field 95
Accept-Language header field 96 Accept-Language header field 96
Accept-Ranges header field 149 Accept-Ranges header field 149
Allow header field 149 Allow header field 149
Authentication-Info header field 147 Authentication-Info header field 147
Authorization header field 100 Authorization header field 100
accelerator 12 accelerator 13
authoritative response 152 authoritative response 152
B B
browser 10 browser 10
C C
CONNECT method 71 CONNECT method 72
Canonical Root URI 99 Canonical Root URI 99
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 162
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, 65
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 79
connection 10 connection 10
content coding 41 content coding 42
content negotiation 8 content negotiation 8
D D
DELETE method 70 DELETE method 70
Date header field 133 Date header field 133
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 141
Expect header field 76 Expect header field 76
effective request URI 33 effective request URI 34
F F
Fragment Identifiers 18 Fragment Identifiers 18
From header field 103 From header field 103
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 92
Accept-Charset 94 Accept-Charset 94
Accept-Encoding 95 Accept-Encoding 95
accept-ext 92 accept-ext 92
Accept-Language 96 Accept-Language 96
accept-params 92 accept-params 92
Accept-Ranges 149 Accept-Ranges 149
acceptable-ranges 149 acceptable-ranges 149
Allow 149 Allow 149
ALPHA 9 ALPHA 9
asctime-date 132 asctime-date 132
auth-param 98 auth-param 98
auth-scheme 98 auth-scheme 98
Authentication-Info 147 Authentication-Info 147
authority 15 authority 15
Authorization 100 Authorization 100
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 98
charset 40 charset 40
codings 95 codings 95
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 99
CRLF 9 CRLF 9
ctext 30 ctext 30
CTL 9 CTL 9
Date 133 Date 133
date1 132 date1 132
day 132 day 132
day-name 132 day-name 132
day-name-l 132 day-name-l 132
delay-seconds 135 delay-seconds 135
DIGIT 9 DIGIT 9
DQUOTE 9 DQUOTE 9
entity-tag 142 entity-tag 142
ETag 142 ETag 142
etagc 142 etagc 142
Expect 76 Expect 76
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 103
GMT 132 GMT 132
HEXDIG 9 HEXDIG 9
Host 34 Host 34
hour 132 hour 132
HTAB 9 HTAB 9
HTTP-date 131 HTTP-date 131
http-URI 16 http-URI 16
https-URI 17 https-URI 18
If-Match 83 If-Match 83
If-Modified-Since 85 If-Modified-Since 85
If-None-Match 84 If-None-Match 84
If-Range 88 If-Range 88
If-Unmodified-Since 86 If-Unmodified-Since 87
IMF-fixdate 132 IMF-fixdate 132
language-range 96 language-range 96
language-tag 43 language-tag 44
last-byte-pos 44 last-byte-pos 45
Last-Modified 139 Last-Modified 139
LF 9 LF 9
Location 134 Location 134
Max-Forwards 78 Max-Forwards 79
media-range 92 media-range 92
media-type 39 media-type 40
method 61 method 62
minute 132 minute 132
month 132 month 132
obs-date 132 obs-date 132
obs-text 29 obs-text 30
OCTET 9 OCTET 9
opaque-tag 142 opaque-tag 142
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 105
product-version 105 product-version 105
protocol-name 35 protocol-name 36
protocol-version 35 protocol-version 36
Proxy-Authenticate 147 Proxy-Authenticate 147
Proxy-Authentication-Info 148 Proxy-Authentication-Info 148
Proxy-Authorization 100 Proxy-Authorization 100
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 92
Range 89 Range 89
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 104
Retry-After 135 Retry-After 135
rfc850-date 132 rfc850-date 132
RWS 31 RWS 32
second 132 second 132
segment 15 segment 15
Server 150 Server 150
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 132
token 29 token 29
token68 98 token68 98
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 105
Vary 136 Vary 136
VCHAR 9 VCHAR 9
Via 35 Via 36
weak 142 weak 142
weight 92 weight 92
WWW-Authenticate 146 WWW-Authenticate 146
year 132 year 132
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 66
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 83
If-Modified-Since header field 85 If-Modified-Since header field 85
If-None-Match header field 84 If-None-Match header field 84
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 139
Location header field 134 Location header field 134
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 137
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 99
Proxy-Authenticate header field 147 Proxy-Authenticate header field 147
Proxy-Authentication-Info header field 148 Proxy-Authentication-Info header field 148
Proxy-Authorization header field 100 Proxy-Authorization header field 100
payload 53 payload 54
phishing 152 phishing 152
proxy 12 proxy 12
R R
Range header field 89 Range header field 89
Realm 99 Realm 99
Referer header field 104 Referer header field 104
Retry-After header field 135 Retry-After header field 135
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 150
Status Codes Classes Status Codes Classes
1xx Informational 108 1xx Informational 108
2xx Successful 109 2xx Successful 109
3xx Redirection 115 3xx Redirection 115
4xx Client Error 121 4xx Client Error 121
5xx Server Error 127 5xx Server Error 127
safe 63 safe 64
selected representation 38, 79, 137 selected representation 39, 79, 137
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 105
upstream 12 upstream 12
user agent 10 user agent 10
V V
Vary header field 136 Vary header field 136
Via header field 35 Via header field 36
validator 137 validator 137
strong 138 strong 138
weak 138 weak 138
W W
WWW-Authenticate header field 146 WWW-Authenticate header field 146
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. 119 change blocks. 
259 lines changed or deleted 321 lines changed or added

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