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