draft-ietf-httpbis-semantics-09.txt   draft-ietf-httpbis-semantics-10.txt 
HTTP Working Group R. Fielding, Ed. HTTP Working Group R. Fielding, Ed.
Internet-Draft Adobe Internet-Draft Adobe
Obsoletes: 2818,7230,7231,7232,7233,7235 M. Nottingham, Ed. Obsoletes: 2818, 7230, 7231, 7232, 7233, 7235, M. Nottingham, Ed.
,7538,7615,7694 (if approved) Fastly 7538, 7615, 7694 (if approved) Fastly
Intended status: Standards Track J. Reschke, Ed. Intended status: Standards Track J. F. Reschke, Ed.
Expires: January 12, 2021 greenbytes Expires: January 13, 2021 greenbytes
July 11, 2020 July 12, 2020
HTTP Semantics HTTP Semantics
draft-ietf-httpbis-semantics-09 draft-ietf-httpbis-semantics-10
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 D.10. The changes in this draft are summarized in Appendix D.11.
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 12, 2021. This Internet-Draft will expire on January 13, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents (https://trustee.ietf.org/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Simplified BSD License.
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
skipping to change at page 2, line 47 skipping to change at page 2, line 46
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 9 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 9
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 10 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 10
1.2.1. Whitespace . . . . . . . . . . . . . . . . . . . . . 10 1.2.1. Whitespace . . . . . . . . . . . . . . . . . . . . . 10
2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 11 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 11 2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 11
2.2. Intermediaries . . . . . . . . . . . . . . . . . . . . . 13 2.2. Intermediaries . . . . . . . . . . . . . . . . . . . . . 14
2.3. Caches . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.3. Caches . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4. Uniform Resource Identifiers . . . . . . . . . . . . . . 16 2.4. Uniform Resource Identifiers . . . . . . . . . . . . . . 16
2.5. Resources . . . . . . . . . . . . . . . . . . . . . . . . 17 2.5. Resources . . . . . . . . . . . . . . . . . . . . . . . . 17
2.5.1. http URI Scheme . . . . . . . . . . . . . . . . . . . 18 2.5.1. http URI Scheme . . . . . . . . . . . . . . . . . . . 18
2.5.2. https URI Scheme . . . . . . . . . . . . . . . . . . 18 2.5.2. https URI Scheme . . . . . . . . . . . . . . . . . . 19
2.5.3. http and https URI Normalization and Comparison . . . 19 2.5.3. http and https URI Normalization and Comparison . . . 20
2.5.4. Deprecated userinfo . . . . . . . . . . . . . . . . . 20 2.5.4. Deprecated userinfo . . . . . . . . . . . . . . . . . 20
2.5.5. Fragment Identifiers on http(s) URI References . . . 20 2.5.5. Fragment Identifiers on http(s) URI References . . . 21
3. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 21 3. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1. Implementation Diversity . . . . . . . . . . . . . . . . 21 3.1. Implementation Diversity . . . . . . . . . . . . . . . . 21
3.2. Role-based Requirements . . . . . . . . . . . . . . . . . 21 3.2. Role-based Requirements . . . . . . . . . . . . . . . . . 22
3.3. Parsing Elements . . . . . . . . . . . . . . . . . . . . 22 3.3. Parsing Elements . . . . . . . . . . . . . . . . . . . . 23
3.4. Error Handling . . . . . . . . . . . . . . . . . . . . . 23 3.4. Error Handling . . . . . . . . . . . . . . . . . . . . . 23
4. Extending and Versioning HTTP . . . . . . . . . . . . . . . . 23 4. Extending and Versioning HTTP . . . . . . . . . . . . . . . . 24
4.1. Extending HTTP . . . . . . . . . . . . . . . . . . . . . 23 4.1. Extending HTTP . . . . . . . . . . . . . . . . . . . . . 24
4.2. Protocol Versioning . . . . . . . . . . . . . . . . . . . 24 4.2. Protocol Versioning . . . . . . . . . . . . . . . . . . . 25
5. Header and Trailer Fields . . . . . . . . . . . . . . . . . . 25 5. Header and Trailer Fields . . . . . . . . . . . . . . . . . . 26
5.1. Field Ordering and Combination . . . . . . . . . . . . . 26 5.1. Field Ordering and Combination . . . . . . . . . . . . . 27
5.2. Field Limits . . . . . . . . . . . . . . . . . . . . . . 27 5.2. Field Limits . . . . . . . . . . . . . . . . . . . . . . 28
5.3. Field Names . . . . . . . . . . . . . . . . . . . . . . . 28 5.3. Field Names . . . . . . . . . . . . . . . . . . . . . . . 28
5.3.1. Field Extensibility . . . . . . . . . . . . . . . . . 28 5.3.1. Field Extensibility . . . . . . . . . . . . . . . . . 29
5.3.2. Field Name Registry . . . . . . . . . . . . . . . . . 29 5.3.2. Field Name Registry . . . . . . . . . . . . . . . . . 30
5.4. Field Values . . . . . . . . . . . . . . . . . . . . . . 30 5.4. Field Values . . . . . . . . . . . . . . . . . . . . . . 31
5.4.1. Common Field Value Components . . . . . . . . . . . . 31 5.4.1. Common Field Value Components . . . . . . . . . . . . 32
5.5. ABNF List Extension: #rule . . . . . . . . . . . . . . . 35 5.5. ABNF List Extension: #rule . . . . . . . . . . . . . . . 36
5.5.1. Sender Requirements . . . . . . . . . . . . . . . . . 35 5.5.1. Sender Requirements . . . . . . . . . . . . . . . . . 36
5.5.2. Recipient Requirements . . . . . . . . . . . . . . . 36 5.5.2. Recipient Requirements . . . . . . . . . . . . . . . 37
5.6. Trailer Fields . . . . . . . . . . . . . . . . . . . . . 36 5.6. Trailer Fields . . . . . . . . . . . . . . . . . . . . . 37
5.6.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 36 5.6.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 38
5.6.2. Limitations . . . . . . . . . . . . . . . . . . . . . 37 5.6.2. Limitations . . . . . . . . . . . . . . . . . . . . . 38
5.6.3. Trailer . . . . . . . . . . . . . . . . . . . . . . . 37 5.6.3. Trailer . . . . . . . . . . . . . . . . . . . . . . . 39
5.7. Considerations for New HTTP Fields . . . . . . . . . . . 38 5.7. Considerations for New HTTP Fields . . . . . . . . . . . 39
5.8. Fields Defined In This Document . . . . . . . . . . . . . 39 5.8. Fields Defined In This Document . . . . . . . . . . . . . 40
6. Message Routing . . . . . . . . . . . . . . . . . . . . . . . 41 6. Message Routing . . . . . . . . . . . . . . . . . . . . . . . 42
6.1. Identifying a Target Resource . . . . . . . . . . . . . . 41 6.1. Identifying a Target Resource . . . . . . . . . . . . . . 42
6.2. Determining Origin . . . . . . . . . . . . . . . . . . . 42 6.2. Determining Origin . . . . . . . . . . . . . . . . . . . 43
6.3. Routing Inbound . . . . . . . . . . . . . . . . . . . . . 42 6.3. Routing Inbound . . . . . . . . . . . . . . . . . . . . . 43
6.4. Direct Authoritative Access . . . . . . . . . . . . . . . 43 6.4. Direct Authoritative Access . . . . . . . . . . . . . . . 44
6.4.1. http origins . . . . . . . . . . . . . . . . . . . . 43 6.4.1. http origins . . . . . . . . . . . . . . . . . . . . 44
6.4.2. https origins . . . . . . . . . . . . . . . . . . . . 44 6.4.2. https origins . . . . . . . . . . . . . . . . . . . . 45
6.4.3. Initiating HTTP Over TLS . . . . . . . . . . . . . . 45 6.4.3. Initiating HTTP Over TLS . . . . . . . . . . . . . . 46
6.5. Reconstructing the Target URI . . . . . . . . . . . . . . 47 6.5. Reconstructing the Target URI . . . . . . . . . . . . . . 48
6.6. Host . . . . . . . . . . . . . . . . . . . . . . . . . . 48 6.6. Host . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.7. Message Forwarding . . . . . . . . . . . . . . . . . . . 48 6.7. Message Forwarding . . . . . . . . . . . . . . . . . . . 50
6.7.1. Via . . . . . . . . . . . . . . . . . . . . . . . . . 49 6.7.1. Via . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.7.2. Transformations . . . . . . . . . . . . . . . . . . . 51 6.7.2. Transformations . . . . . . . . . . . . . . . . . . . 52
7. Representations . . . . . . . . . . . . . . . . . . . . . . . 52 7. Representations . . . . . . . . . . . . . . . . . . . . . . . 53
7.1. Representation Data . . . . . . . . . . . . . . . . . . . 52 7.1. Representation Data . . . . . . . . . . . . . . . . . . . 54
7.1.1. Media Type . . . . . . . . . . . . . . . . . . . . . 53 7.1.1. Media Type . . . . . . . . . . . . . . . . . . . . . 54
7.1.2. Content Codings . . . . . . . . . . . . . . . . . . . 55 7.1.2. Content Codings . . . . . . . . . . . . . . . . . . . 56
7.1.3. Language Tags . . . . . . . . . . . . . . . . . . . . 57 7.1.3. Language Tags . . . . . . . . . . . . . . . . . . . . 58
7.1.4. Range Units . . . . . . . . . . . . . . . . . . . . . 57 7.1.4. Range Units . . . . . . . . . . . . . . . . . . . . . 59
7.2. Representation Metadata . . . . . . . . . . . . . . . . . 61 7.2. Representation Metadata . . . . . . . . . . . . . . . . . 63
7.2.1. Content-Type . . . . . . . . . . . . . . . . . . . . 62 7.2.1. Content-Type . . . . . . . . . . . . . . . . . . . . 63
7.2.2. Content-Encoding . . . . . . . . . . . . . . . . . . 63 7.2.2. Content-Encoding . . . . . . . . . . . . . . . . . . 64
7.2.3. Content-Language . . . . . . . . . . . . . . . . . . 64 7.2.3. Content-Language . . . . . . . . . . . . . . . . . . 65
7.2.4. Content-Length . . . . . . . . . . . . . . . . . . . 64 7.2.4. Content-Length . . . . . . . . . . . . . . . . . . . 66
7.2.5. Content-Location . . . . . . . . . . . . . . . . . . 66 7.2.5. Content-Location . . . . . . . . . . . . . . . . . . 67
7.3. Payload . . . . . . . . . . . . . . . . . . . . . . . . . 68 7.3. Payload . . . . . . . . . . . . . . . . . . . . . . . . . 69
7.3.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 68 7.3.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 69
7.3.2. Identification . . . . . . . . . . . . . . . . . . . 68 7.3.2. Identification . . . . . . . . . . . . . . . . . . . 70
7.3.3. Payload Body . . . . . . . . . . . . . . . . . . . . 69 7.3.3. Payload Body . . . . . . . . . . . . . . . . . . . . 71
7.3.4. Content-Range . . . . . . . . . . . . . . . . . . . . 70 7.3.4. Content-Range . . . . . . . . . . . . . . . . . . . . 72
7.3.5. Media Type multipart/byteranges . . . . . . . . . . . 72 7.3.5. Media Type multipart/byteranges . . . . . . . . . . . 73
7.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 74 7.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 75
7.4.1. Proactive Negotiation . . . . . . . . . . . . . . . . 75 7.4.1. Proactive Negotiation . . . . . . . . . . . . . . . . 76
7.4.2. Reactive Negotiation . . . . . . . . . . . . . . . . 76 7.4.2. Reactive Negotiation . . . . . . . . . . . . . . . . 77
7.4.3. Request Payload Negotiation . . . . . . . . . . . . . 77 7.4.3. Request Payload Negotiation . . . . . . . . . . . . . 78
7.4.4. Quality Values . . . . . . . . . . . . . . . . . . . 77 7.4.4. Quality Values . . . . . . . . . . . . . . . . . . . 78
8. Request Methods . . . . . . . . . . . . . . . . . . . . . . . 77 8. Request Methods . . . . . . . . . . . . . . . . . . . . . . . 79
8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 77 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 79
8.2. Common Method Properties . . . . . . . . . . . . . . . . 79 8.2. Common Method Properties . . . . . . . . . . . . . . . . 80
8.2.1. Safe Methods . . . . . . . . . . . . . . . . . . . . 80 8.2.1. Safe Methods . . . . . . . . . . . . . . . . . . . . 81
8.2.2. Idempotent Methods . . . . . . . . . . . . . . . . . 81 8.2.2. Idempotent Methods . . . . . . . . . . . . . . . . . 82
8.2.3. Methods and Caching . . . . . . . . . . . . . . . . . 82 8.2.3. Methods and Caching . . . . . . . . . . . . . . . . . 83
8.3. Method Definitions . . . . . . . . . . . . . . . . . . . 82 8.3. Method Definitions . . . . . . . . . . . . . . . . . . . 83
8.3.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 82 8.3.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 83
8.3.2. HEAD . . . . . . . . . . . . . . . . . . . . . . . . 83 8.3.2. HEAD . . . . . . . . . . . . . . . . . . . . . . . . 84
8.3.3. POST . . . . . . . . . . . . . . . . . . . . . . . . 84 8.3.3. POST . . . . . . . . . . . . . . . . . . . . . . . . 84
8.3.4. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 85 8.3.4. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 85
8.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . 87 8.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . 88
8.3.6. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 88 8.3.6. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 89
8.3.7. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 90 8.3.7. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 91
8.3.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . 91 8.3.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . 92
8.4. Method Extensibility . . . . . . . . . . . . . . . . . . 91 8.4. Method Extensibility . . . . . . . . . . . . . . . . . . 92
8.4.1. Method Registry . . . . . . . . . . . . . . . . . . . 92 8.4.1. Method Registry . . . . . . . . . . . . . . . . . . . 92
8.4.2. Considerations for New Methods . . . . . . . . . . . 92 8.4.2. Considerations for New Methods . . . . . . . . . . . 93
9. Request Header Fields . . . . . . . . . . . . . . . . . . . . 93 9. Request Header Fields . . . . . . . . . . . . . . . . . . . . 94
9.1. Controls . . . . . . . . . . . . . . . . . . . . . . . . 93 9.1. Controls . . . . . . . . . . . . . . . . . . . . . . . . 94
9.1.1. Expect . . . . . . . . . . . . . . . . . . . . . . . 93 9.1.1. Expect . . . . . . . . . . . . . . . . . . . . . . . 94
9.1.2. Max-Forwards . . . . . . . . . . . . . . . . . . . . 96 9.1.2. Max-Forwards . . . . . . . . . . . . . . . . . . . . 97
9.2. Preconditions . . . . . . . . . . . . . . . . . . . . . . 96 9.2. Preconditions . . . . . . . . . . . . . . . . . . . . . . 97
9.2.1. Evaluation . . . . . . . . . . . . . . . . . . . . . 97 9.2.1. Evaluation . . . . . . . . . . . . . . . . . . . . . 98
9.2.2. Precedence . . . . . . . . . . . . . . . . . . . . . 98 9.2.2. Precedence . . . . . . . . . . . . . . . . . . . . . 99
9.2.3. If-Match . . . . . . . . . . . . . . . . . . . . . . 100 9.2.3. If-Match . . . . . . . . . . . . . . . . . . . . . . 101
9.2.4. If-None-Match . . . . . . . . . . . . . . . . . . . . 101 9.2.4. If-None-Match . . . . . . . . . . . . . . . . . . . . 102
9.2.5. If-Modified-Since . . . . . . . . . . . . . . . . . . 103 9.2.5. If-Modified-Since . . . . . . . . . . . . . . . . . . 103
9.2.6. If-Unmodified-Since . . . . . . . . . . . . . . . . . 104 9.2.6. If-Unmodified-Since . . . . . . . . . . . . . . . . . 105
9.2.7. If-Range . . . . . . . . . . . . . . . . . . . . . . 105 9.2.7. If-Range . . . . . . . . . . . . . . . . . . . . . . 106
9.3. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 106 9.3. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 107
9.4. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 108 9.4. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 109
9.4.1. Accept . . . . . . . . . . . . . . . . . . . . . . . 109 9.4.1. Accept . . . . . . . . . . . . . . . . . . . . . . . 110
9.4.2. Accept-Charset . . . . . . . . . . . . . . . . . . . 111 9.4.2. Accept-Charset . . . . . . . . . . . . . . . . . . . 112
9.4.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . 112 9.4.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . 113
9.4.4. Accept-Language . . . . . . . . . . . . . . . . . . . 114 9.4.4. Accept-Language . . . . . . . . . . . . . . . . . . . 115
9.5. Authentication Credentials . . . . . . . . . . . . . . . 115 9.5. Authentication Credentials . . . . . . . . . . . . . . . 116
9.5.1. Challenge and Response . . . . . . . . . . . . . . . 115 9.5.1. Challenge and Response . . . . . . . . . . . . . . . 116
9.5.2. Protection Space (Realm) . . . . . . . . . . . . . . 117 9.5.2. Protection Space (Realm) . . . . . . . . . . . . . . 118
9.5.3. Authorization . . . . . . . . . . . . . . . . . . . . 118 9.5.3. Authorization . . . . . . . . . . . . . . . . . . . . 119
9.5.4. Proxy-Authorization . . . . . . . . . . . . . . . . . 118 9.5.4. Proxy-Authorization . . . . . . . . . . . . . . . . . 119
9.5.5. Authentication Scheme Extensibility . . . . . . . . . 118 9.5.5. Authentication Scheme Extensibility . . . . . . . . . 120
9.6. Request Context . . . . . . . . . . . . . . . . . . . . . 121 9.6. Request Context . . . . . . . . . . . . . . . . . . . . . 122
9.6.1. From . . . . . . . . . . . . . . . . . . . . . . . . 121 9.6.1. From . . . . . . . . . . . . . . . . . . . . . . . . 122
9.6.2. Referer . . . . . . . . . . . . . . . . . . . . . . . 122 9.6.2. Referer . . . . . . . . . . . . . . . . . . . . . . . 123
9.6.3. User-Agent . . . . . . . . . . . . . . . . . . . . . 123 9.6.3. User-Agent . . . . . . . . . . . . . . . . . . . . . 124
10. Response Status Codes . . . . . . . . . . . . . . . . . . . . 124 10. Response Status Codes . . . . . . . . . . . . . . . . . . . . 125
10.1. Overview of Status Codes . . . . . . . . . . . . . . . . 125 10.1. Overview of Status Codes . . . . . . . . . . . . . . . . 126
10.2. Informational 1xx . . . . . . . . . . . . . . . . . . . 126 10.2. Informational 1xx . . . . . . . . . . . . . . . . . . . 127
10.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 127 10.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 127
10.2.2. 101 Switching Protocols . . . . . . . . . . . . . . 127 10.2.2. 101 Switching Protocols . . . . . . . . . . . . . . 128
10.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . 127 10.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . 128
10.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 127 10.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 128
10.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . 128 10.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . 129
10.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . 128 10.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . 129
10.3.4. 203 Non-Authoritative Information . . . . . . . . . 129 10.3.4. 203 Non-Authoritative Information . . . . . . . . . 130
10.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . 129 10.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . 130
10.3.6. 205 Reset Content . . . . . . . . . . . . . . . . . 130 10.3.6. 205 Reset Content . . . . . . . . . . . . . . . . . 131
10.3.7. 206 Partial Content . . . . . . . . . . . . . . . . 130 10.3.7. 206 Partial Content . . . . . . . . . . . . . . . . 131
10.4. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 133 10.4. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 135
10.4.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 135 10.4.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 136
10.4.2. 301 Moved Permanently . . . . . . . . . . . . . . . 136 10.4.2. 301 Moved Permanently . . . . . . . . . . . . . . . 137
10.4.3. 302 Found . . . . . . . . . . . . . . . . . . . . . 136 10.4.3. 302 Found . . . . . . . . . . . . . . . . . . . . . 137
10.4.4. 303 See Other . . . . . . . . . . . . . . . . . . . 137 10.4.4. 303 See Other . . . . . . . . . . . . . . . . . . . 138
10.4.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 137 10.4.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 138
10.4.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 138 10.4.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 139
10.4.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . 138 10.4.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . 139
10.4.8. 307 Temporary Redirect . . . . . . . . . . . . . . . 138 10.4.8. 307 Temporary Redirect . . . . . . . . . . . . . . . 139
10.4.9. 308 Permanent Redirect . . . . . . . . . . . . . . . 139 10.4.9. 308 Permanent Redirect . . . . . . . . . . . . . . . 140
10.5. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 139 10.5. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 140
10.5.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 139 10.5.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 140
10.5.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 139 10.5.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 140
10.5.3. 402 Payment Required . . . . . . . . . . . . . . . . 140 10.5.3. 402 Payment Required . . . . . . . . . . . . . . . . 141
10.5.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 140 10.5.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 141
10.5.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 140 10.5.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 141
10.5.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 141 10.5.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 142
10.5.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 141 10.5.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 142
10.5.8. 407 Proxy Authentication Required . . . . . . . . . 141 10.5.8. 407 Proxy Authentication Required . . . . . . . . . 142
10.5.9. 408 Request Timeout . . . . . . . . . . . . . . . . 141 10.5.9. 408 Request Timeout . . . . . . . . . . . . . . . . 142
10.5.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . 142 10.5.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . 143
10.5.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 142 10.5.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 143
10.5.12. 411 Length Required . . . . . . . . . . . . . . . . 142 10.5.12. 411 Length Required . . . . . . . . . . . . . . . . 143
10.5.13. 412 Precondition Failed . . . . . . . . . . . . . . 143 10.5.13. 412 Precondition Failed . . . . . . . . . . . . . . 144
10.5.14. 413 Payload Too Large . . . . . . . . . . . . . . . 143 10.5.14. 413 Payload Too Large . . . . . . . . . . . . . . . 144
10.5.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . 143 10.5.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . 144
10.5.16. 415 Unsupported Media Type . . . . . . . . . . . . . 143 10.5.16. 415 Unsupported Media Type . . . . . . . . . . . . . 144
10.5.17. 416 Range Not Satisfiable . . . . . . . . . . . . . 144 10.5.17. 416 Range Not Satisfiable . . . . . . . . . . . . . 145
10.5.18. 417 Expectation Failed . . . . . . . . . . . . . . . 144 10.5.18. 417 Expectation Failed . . . . . . . . . . . . . . . 145
10.5.19. 418 (Unused) . . . . . . . . . . . . . . . . . . . . 145 10.5.19. 418 (Unused) . . . . . . . . . . . . . . . . . . . . 146
10.5.20. 422 Unprocessable Payload . . . . . . . . . . . . . 145 10.5.20. 422 Unprocessable Payload . . . . . . . . . . . . . 146
10.5.21. 426 Upgrade Required . . . . . . . . . . . . . . . . 145 10.5.21. 426 Upgrade Required . . . . . . . . . . . . . . . . 146
10.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 145 10.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 147
10.6.1. 500 Internal Server Error . . . . . . . . . . . . . 146 10.6.1. 500 Internal Server Error . . . . . . . . . . . . . 147
10.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . 146 10.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . 147
10.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 146 10.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 147
10.6.4. 503 Service Unavailable . . . . . . . . . . . . . . 146 10.6.4. 503 Service Unavailable . . . . . . . . . . . . . . 147
10.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 146 10.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 148
10.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . 147 10.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . 148
10.7. Status Code Extensibility . . . . . . . . . . . . . . . 147 10.7. Status Code Extensibility . . . . . . . . . . . . . . . 148
10.7.1. Status Code Registry . . . . . . . . . . . . . . . . 147 10.7.1. Status Code Registry . . . . . . . . . . . . . . . . 148
10.7.2. Considerations for New Status Codes . . . . . . . . 147 10.7.2. Considerations for New Status Codes . . . . . . . . 149
11. Response Header Fields . . . . . . . . . . . . . . . . . . . 148 11. Response Header Fields . . . . . . . . . . . . . . . . . . . 150
11.1. Control Data . . . . . . . . . . . . . . . . . . . . . . 149 11.1. Control Data . . . . . . . . . . . . . . . . . . . . . . 150
11.1.1. Date . . . . . . . . . . . . . . . . . . . . . . . . 149 11.1.1. Date . . . . . . . . . . . . . . . . . . . . . . . . 150
11.1.2. Location . . . . . . . . . . . . . . . . . . . . . . 150 11.1.2. Location . . . . . . . . . . . . . . . . . . . . . . 151
11.1.3. Retry-After . . . . . . . . . . . . . . . . . . . . 151 11.1.3. Retry-After . . . . . . . . . . . . . . . . . . . . 153
11.1.4. Vary . . . . . . . . . . . . . . . . . . . . . . . . 152 11.1.4. Vary . . . . . . . . . . . . . . . . . . . . . . . . 153
11.2. Validators . . . . . . . . . . . . . . . . . . . . . . . 153 11.2. Validators . . . . . . . . . . . . . . . . . . . . . . . 154
11.2.1. Weak versus Strong . . . . . . . . . . . . . . . . . 154 11.2.1. Weak versus Strong . . . . . . . . . . . . . . . . . 155
11.2.2. Last-Modified . . . . . . . . . . . . . . . . . . . 155 11.2.2. Last-Modified . . . . . . . . . . . . . . . . . . . 157
11.2.3. ETag . . . . . . . . . . . . . . . . . . . . . . . . 157 11.2.3. ETag . . . . . . . . . . . . . . . . . . . . . . . . 159
11.2.4. When to Use Entity-Tags and Last-Modified Dates . . 161 11.2.4. When to Use Entity-Tags and Last-Modified Dates . . 162
11.3. Authentication Challenges . . . . . . . . . . . . . . . 161 11.3. Authentication Challenges . . . . . . . . . . . . . . . 163
11.3.1. WWW-Authenticate . . . . . . . . . . . . . . . . . . 162 11.3.1. WWW-Authenticate . . . . . . . . . . . . . . . . . . 163
11.3.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . 163 11.3.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . 164
11.3.3. Authentication-Info . . . . . . . . . . . . . . . . 163 11.3.3. Authentication-Info . . . . . . . . . . . . . . . . 165
11.3.4. Proxy-Authentication-Info . . . . . . . . . . . . . 164 11.3.4. Proxy-Authentication-Info . . . . . . . . . . . . . 166
11.4. Response Context . . . . . . . . . . . . . . . . . . . . 165 11.4. Response Context . . . . . . . . . . . . . . . . . . . . 166
11.4.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . 165 11.4.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . 166
11.4.2. Allow . . . . . . . . . . . . . . . . . . . . . . . 165 11.4.2. Allow . . . . . . . . . . . . . . . . . . . . . . . 167
11.4.3. Server . . . . . . . . . . . . . . . . . . . . . . . 166 11.4.3. Server . . . . . . . . . . . . . . . . . . . . . . . 167
12. Security Considerations . . . . . . . . . . . . . . . . . . . 167 12. Security Considerations . . . . . . . . . . . . . . . . . . . 168
12.1. Establishing Authority . . . . . . . . . . . . . . . . . 167 12.1. Establishing Authority . . . . . . . . . . . . . . . . . 168
12.2. Risks of Intermediaries . . . . . . . . . . . . . . . . 168 12.2. Risks of Intermediaries . . . . . . . . . . . . . . . . 169
12.3. Attacks Based on File and Path Names . . . . . . . . . . 169 12.3. Attacks Based on File and Path Names . . . . . . . . . . 170
12.4. Attacks Based on Command, Code, or Query Injection . . . 169 12.4. Attacks Based on Command, Code, or Query Injection . . . 171
12.5. Attacks via Protocol Element Length . . . . . . . . . . 170 12.5. Attacks via Protocol Element Length . . . . . . . . . . 171
12.6. Disclosure of Personal Information . . . . . . . . . . . 170 12.6. Disclosure of Personal Information . . . . . . . . . . . 172
12.7. Privacy of Server Log Information . . . . . . . . . . . 170 12.7. Privacy of Server Log Information . . . . . . . . . . . 172
12.8. Disclosure of Sensitive Information in URIs . . . . . . 171 12.8. Disclosure of Sensitive Information in URIs . . . . . . 173
12.9. Disclosure of Fragment after Redirects . . . . . . . . . 171 12.9. Disclosure of Fragment after Redirects . . . . . . . . . 173
12.10. Disclosure of Product Information . . . . . . . . . . . 172 12.10. Disclosure of Product Information . . . . . . . . . . . 173
12.11. Browser Fingerprinting . . . . . . . . . . . . . . . . . 172 12.11. Browser Fingerprinting . . . . . . . . . . . . . . . . . 174
12.12. Validator Retention . . . . . . . . . . . . . . . . . . 173 12.12. Validator Retention . . . . . . . . . . . . . . . . . . 175
12.13. Denial-of-Service Attacks Using Range . . . . . . . . . 174 12.13. Denial-of-Service Attacks Using Range . . . . . . . . . 175
12.14. Authentication Considerations . . . . . . . . . . . . . 174 12.14. Authentication Considerations . . . . . . . . . . . . . 176
12.14.1. Confidentiality of Credentials . . . . . . . . . . 174 12.14.1. Confidentiality of Credentials . . . . . . . . . . 176
12.14.2. Credentials and Idle Clients . . . . . . . . . . . 175 12.14.2. Credentials and Idle Clients . . . . . . . . . . . 176
12.14.3. Protection Spaces . . . . . . . . . . . . . . . . . 175 12.14.3. Protection Spaces . . . . . . . . . . . . . . . . . 177
12.14.4. Additional Response Fields . . . . . . . . . . . . 176 12.14.4. Additional Response Fields . . . . . . . . . . . . 177
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 176 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 177
13.1. URI Scheme Registration . . . . . . . . . . . . . . . . 176 13.1. URI Scheme Registration . . . . . . . . . . . . . . . . 178
13.2. Method Registration . . . . . . . . . . . . . . . . . . 176 13.2. Method Registration . . . . . . . . . . . . . . . . . . 178
13.3. Status Code Registration . . . . . . . . . . . . . . . . 176 13.3. Status Code Registration . . . . . . . . . . . . . . . . 178
13.4. HTTP Field Name Registration . . . . . . . . . . . . . . 177 13.4. HTTP Field Name Registration . . . . . . . . . . . . . . 178
13.5. Authentication Scheme Registration . . . . . . . . . . . 177 13.5. Authentication Scheme Registration . . . . . . . . . . . 179
13.6. Content Coding Registration . . . . . . . . . . . . . . 178 13.6. Content Coding Registration . . . . . . . . . . . . . . 179
13.7. Range Unit Registration . . . . . . . . . . . . . . . . 178 13.7. Range Unit Registration . . . . . . . . . . . . . . . . 180
13.8. Media Type Registration . . . . . . . . . . . . . . . . 178 13.8. Media Type Registration . . . . . . . . . . . . . . . . 180
13.9. Port Registration . . . . . . . . . . . . . . . . . . . 178 13.9. Port Registration . . . . . . . . . . . . . . . . . . . 180
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 178 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 180
14.1. Normative References . . . . . . . . . . . . . . . . . . 178 14.1. Normative References . . . . . . . . . . . . . . . . . . 180
14.2. Informative References . . . . . . . . . . . . . . . . . 180 14.2. Informative References . . . . . . . . . . . . . . . . . 182
Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 187 Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 188
Appendix B. Changes from previous RFCs . . . . . . . . . . . . . 191 Appendix B. Changes from previous RFCs . . . . . . . . . . . . . 192
B.1. Changes from RFC 2818 . . . . . . . . . . . . . . . . . . 191 B.1. Changes from RFC 2818 . . . . . . . . . . . . . . . . . . 192
B.2. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 191 B.2. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 192
B.3. Changes from RFC 7231 . . . . . . . . . . . . . . . . . . 192 B.3. Changes from RFC 7231 . . . . . . . . . . . . . . . . . . 193
B.4. Changes from RFC 7232 . . . . . . . . . . . . . . . . . . 193 B.4. Changes from RFC 7232 . . . . . . . . . . . . . . . . . . 194
B.5. Changes from RFC 7233 . . . . . . . . . . . . . . . . . . 193 B.5. Changes from RFC 7233 . . . . . . . . . . . . . . . . . . 194
B.6. Changes from RFC 7235 . . . . . . . . . . . . . . . . . . 193 B.6. Changes from RFC 7235 . . . . . . . . . . . . . . . . . . 194
B.7. Changes from RFC 7538 . . . . . . . . . . . . . . . . . . 193 B.7. Changes from RFC 7538 . . . . . . . . . . . . . . . . . . 194
B.8. Changes from RFC 7615 . . . . . . . . . . . . . . . . . . 193 B.8. Changes from RFC 7615 . . . . . . . . . . . . . . . . . . 194
Appendix C. Changes from RFC 7694 . . . . . . . . . . . . . . . 193 Appendix C. Changes from RFC 7694 . . . . . . . . . . . . . . . 195
Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 193 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 195
D.1. Between RFC723x and draft 00 . . . . . . . . . . . . . . 194 D.1. Between RFC723x and draft 00 . . . . . . . . . . . . . . 195
D.2. Since draft-ietf-httpbis-semantics-00 . . . . . . . . . . 194 D.2. Since draft-ietf-httpbis-semantics-00 . . . . . . . . . . 195
D.3. Since draft-ietf-httpbis-semantics-01 . . . . . . . . . . 195 D.3. Since draft-ietf-httpbis-semantics-01 . . . . . . . . . . 196
D.4. Since draft-ietf-httpbis-semantics-02 . . . . . . . . . . 196 D.4. Since draft-ietf-httpbis-semantics-02 . . . . . . . . . . 197
D.5. Since draft-ietf-httpbis-semantics-03 . . . . . . . . . . 197 D.5. Since draft-ietf-httpbis-semantics-03 . . . . . . . . . . 198
D.6. Since draft-ietf-httpbis-semantics-04 . . . . . . . . . . 198 D.6. Since draft-ietf-httpbis-semantics-04 . . . . . . . . . . 199
D.7. Since draft-ietf-httpbis-semantics-05 . . . . . . . . . . 198 D.7. Since draft-ietf-httpbis-semantics-05 . . . . . . . . . . 199
D.8. Since draft-ietf-httpbis-semantics-06 . . . . . . . . . . 199 D.8. Since draft-ietf-httpbis-semantics-06 . . . . . . . . . . 201
D.9. Since draft-ietf-httpbis-semantics-07 . . . . . . . . . . 201 D.9. Since draft-ietf-httpbis-semantics-07 . . . . . . . . . . 202
D.10. Since draft-ietf-httpbis-semantics-08 . . . . . . . . . . 202 D.10. Since draft-ietf-httpbis-semantics-08 . . . . . . . . . . 203
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 D.11. Since draft-ietf-httpbis-semantics-09 . . . . . . . . . . 204
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 213 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 205
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 214 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 205
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 12, line 21 skipping to change at page 12, line 30
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
Figure 1
Each major version of HTTP defines its own syntax for the inclusion Each major version of HTTP defines its own syntax for the inclusion
of information in messages. Nevertheless, a common abstraction is of information in messages. Nevertheless, a common abstraction is
that a message includes some form of envelope/framing, a potential that a message includes some form of envelope/framing, a potential
set of named fields up front (a header section), a potential body, set of named fields up front (a header section), a potential body,
and a potential following set of named fields (a trailer section). and a potential following set of named fields (a trailer section).
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 with a method (Section 8) and request target. The request message with a method (Section 8) and request target. The request
might also contain header fields for request modifiers, client might also contain header fields for request modifiers, client
information, and representation metadata (Section 5), a payload body information, and representation metadata (Section 5), a payload body
skipping to change at page 13, line 49 skipping to change at page 14, line 17
HTTP enables the use of intermediaries to satisfy requests through a HTTP enables the use of intermediaries to satisfy requests through a
chain of connections. There are three common forms of HTTP chain of connections. There are three common forms of HTTP
intermediary: proxy, gateway, and tunnel. In some cases, a single intermediary: proxy, gateway, and tunnel. In some cases, a single
intermediary might act as an origin server, proxy, gateway, or intermediary might act as an origin server, proxy, gateway, or
tunnel, switching behavior based on the nature of each request. tunnel, switching behavior based on the nature of each request.
> > > > > > > >
UA =========== A =========== B =========== C =========== O UA =========== A =========== B =========== C =========== O
< < < < < < < <
Figure 2
The figure above shows three intermediaries (A, B, and C) between the The figure above shows three intermediaries (A, B, and C) between the
user agent and origin server. A request or response message that user agent and origin server. A request or response message that
travels the whole chain will pass through four separate connections. travels the whole chain will pass through four separate connections.
Some HTTP communication options might apply only to the connection Some HTTP communication options might apply only to the connection
with the nearest, non-tunnel neighbor, only to the endpoints of the with the nearest, non-tunnel neighbor, only to the endpoints of the
chain, or to all connections along the chain. Although the diagram chain, or to all connections along the chain. Although the diagram
is linear, each participant might be engaged in multiple, is linear, each participant might be engaged in multiple,
simultaneous communications. For example, B might be receiving simultaneous communications. For example, B might be receiving
requests from many clients other than A, and/or forwarding requests requests from many clients other than A, and/or forwarding requests
to servers other than C, at the same time that it is handling A's to servers other than C, at the same time that it is handling A's
skipping to change at page 16, line 15 skipping to change at page 16, line 29
The effect of a cache is that the request/response chain is shortened The effect of a cache is that the request/response chain is shortened
if one of the participants along the chain has a cached response if one of the participants along the chain has a cached response
applicable to that request. The following illustrates the resulting applicable to that request. The following illustrates the resulting
chain if B has a cached copy of an earlier response from O (via C) chain if B has a cached copy of an earlier response from O (via C)
for a request that has not been cached by UA or A. for a request that has not been cached by UA or A.
> > > >
UA =========== A =========== B - - - - - - C - - - - - - O UA =========== A =========== B - - - - - - C - - - - - - O
< < < <
Figure 3
A response is "cacheable" if a cache is allowed to store a copy of A response is "cacheable" if a cache is allowed to store a copy of
the response message for use in answering subsequent requests. Even the response message for use in answering subsequent requests. Even
when a response is cacheable, there might be additional constraints when a response is cacheable, there might be additional constraints
placed by the client or by the origin server on when that cached placed by the client or by the origin server on when that cached
response can be used for a particular request. HTTP requirements for response can be used for a particular request. HTTP requirements for
cache behavior and cacheable responses are defined in Section 2 of cache behavior and cacheable responses are defined in Section 2 of
[Caching]. [Caching].
There is a wide variety of architectures and configurations of caches There is a wide variety of architectures and configurations of caches
deployed across the World Wide Web and inside large organizations. deployed across the World Wide Web and inside large organizations.
skipping to change at page 18, line 7 skipping to change at page 18, line 19
the method semantics and any semantic implied by the URI itself, as the method semantics and any semantic implied by the URI itself, as
described in Section 8.2.1, the method semantics take precedence. described in Section 8.2.1, the method semantics take precedence.
IANA maintains the registry of URI Schemes [BCP35] at IANA maintains the registry of URI Schemes [BCP35] at
<https://www.iana.org/assignments/uri-schemes/>. Although requests <https://www.iana.org/assignments/uri-schemes/>. Although requests
might target any URI scheme, the following schemes are inherent to might target any URI scheme, the following schemes are inherent to
HTTP servers: HTTP servers:
+------------+------------------------------------+---------------+ +------------+------------------------------------+---------------+
| URI Scheme | Description | Reference | | URI Scheme | Description | Reference |
+------------+------------------------------------+---------------+
| http | Hypertext Transfer Protocol | Section 2.5.1 | | http | Hypertext Transfer Protocol | Section 2.5.1 |
| https | Hypertext Transfer Protocol Secure | Section 2.5.2 | | https | Hypertext Transfer Protocol Secure | Section 2.5.2 |
+------------+------------------------------------+---------------+ +------------+------------------------------------+---------------+
Table 1
Note that the presence of an "http" or "https" URI does not imply Note that the presence of an "http" or "https" URI does not imply
that there is always an HTTP server at the identified origin that there is always an HTTP server at the identified origin
listening for connections. Anyone can mint a URI, whether or not a listening for connections. Anyone can mint a URI, whether or not a
server exists and whether or not that server currently maps that server exists and whether or not that server currently maps that
identifier to a resource. The delegated nature of registered names identifier to a resource. The delegated nature of registered names
and IP addresses creates a federated namespace whether or not an HTTP and IP addresses creates a federated namespace whether or not an HTTP
server is present. server is present.
2.5.1. http URI Scheme 2.5.1. http URI Scheme
skipping to change at page 20, line 44 skipping to change at page 21, line 15
2.5.5. Fragment Identifiers on http(s) URI References 2.5.5. Fragment Identifiers on http(s) URI References
Fragment identifiers allow for indirect identification of a secondary Fragment identifiers allow for indirect identification of a secondary
resource, independent of the URI scheme, as defined in Section 3.5 of resource, independent of the URI scheme, as defined in Section 3.5 of
[RFC3986]. Some protocol elements that refer to a URI allow [RFC3986]. Some protocol elements that refer to a URI allow
inclusion of a fragment, while others do not. They are distinguished inclusion of a fragment, while others do not. They are distinguished
by use of the ABNF rule for elements where fragment is allowed; by use of the ABNF rule for elements where fragment is allowed;
otherwise, a specific rule that excludes fragments is used (see otherwise, a specific rule that excludes fragments is used (see
Section 6.1). Section 6.1).
Note: the fragment identifier component is not part of the actual | *Note:* the fragment identifier component is not part of the
scheme definition for a URI scheme (see Section 4.3 of [RFC3986]), | actual scheme definition for a URI scheme (see Section 4.3 of
thus does not appear in the ABNF definitions for the "http" and | [RFC3986]), thus does not appear in the ABNF definitions for
"https" URI schemes above. | the "http" and "https" URI schemes above.
3. Conformance 3. Conformance
3.1. Implementation Diversity 3.1. Implementation Diversity
When considering the design of HTTP, it is easy to fall into a trap When considering the design of HTTP, it is easy to fall into a trap
of thinking that all user agents are general-purpose browsers and all of thinking that all user agents are general-purpose browsers and all
origin servers are large public websites. That is not the case in origin servers are large public websites. That is not the case in
practice. Common HTTP user agents include household appliances, practice. Common HTTP user agents include household appliances,
stereos, scales, firmware update scripts, command-line programs, stereos, scales, firmware update scripts, command-line programs,
skipping to change at page 23, line 12 skipping to change at page 23, line 40
its own resources needs to be able to parse and process those same its own resources needs to be able to parse and process those same
references when received as a target URI. references when received as a target URI.
3.4. Error Handling 3.4. Error Handling
A recipient MUST interpret a received protocol element according to A recipient MUST interpret a received protocol element according to
the semantics defined for it by this specification, including the semantics defined for it by this specification, including
extensions to this specification, unless the recipient has determined extensions to this specification, unless the recipient has determined
(through experience or configuration) that the sender incorrectly (through experience or configuration) that the sender incorrectly
implements what is implied by those semantics. For example, an implements what is implied by those semantics. For example, an
origin server might disregard the contents of a received Accept- origin server might disregard the contents of a received
Encoding header field if inspection of the User-Agent header field Accept-Encoding header field if inspection of the User-Agent header
indicates a specific implementation version that is known to fail on field indicates a specific implementation version that is known to
receipt of certain content codings. fail on receipt of certain content codings.
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.
skipping to change at page 27, line 22 skipping to change at page 28, line 19
This means that, aside from the well-known exception noted below, a This means that, aside from the well-known exception noted below, a
sender MUST NOT generate multiple field lines with the same name in a sender MUST NOT generate multiple field lines with the same name in a
message (whether in the headers or trailers), or append a field line message (whether in the headers or trailers), or append a field line
when a field line of the same name already exists in the message, when a field line of the same name already exists in the message,
unless that field's definition allows multiple field line values to unless that field's definition allows multiple field line values to
be recombined as a comma-separated list [i.e., at least one be recombined as a comma-separated list [i.e., at least one
alternative of the field's definition allows a comma-separated list, alternative of the field's definition allows a comma-separated list,
such as an ABNF rule of #(values) defined in Section 5.5]. such as an ABNF rule of #(values) defined in Section 5.5].
Note: In practice, the "Set-Cookie" header field ([RFC6265]) often | *Note:* In practice, the "Set-Cookie" header field ([RFC6265])
appears in a response message across multiple field lines and does | often appears in a response message across multiple field lines
not use the list syntax, violating the above requirements on | and does not use the list syntax, violating the above
multiple field lines with the same field name. Since it cannot be | requirements on multiple field lines with the same field name.
combined into a single field value, recipients ought to handle | Since it cannot be combined into a single field value,
"Set-Cookie" as a special case while processing fields. (See | recipients ought to handle "Set-Cookie" as a special case while
Appendix A.2.3 of [Kri2001] for details.) | processing fields. (See Appendix A.2.3 of [Kri2001] for
| details.)
5.2. Field Limits 5.2. Field Limits
HTTP does not place a predefined limit on the length of each field HTTP does not place a predefined limit on the length of each field
line, field value, or on the length of the header or trailer section line, field value, or on the length of the header or trailer section
as a whole, as described in Section 3. Various ad hoc limitations on as a whole, as described in Section 3. Various ad hoc limitations on
individual lengths are found in practice, often depending on the individual lengths are found in practice, often depending on the
specific field's semantics. specific field's semantics.
A server that receives a request header field line, field value, or A server that receives a request header field line, field value, or
skipping to change at page 30, line 13 skipping to change at page 31, line 13
Comments: Additional information, such as about reserved entries. Comments: Additional information, such as about reserved entries.
The Expert(s) can define additional fields to be collected in the The Expert(s) can define additional fields to be collected in the
registry, in consultation with the community. registry, in consultation with the community.
Standards-defined names have a status of "permanent". Other names Standards-defined names have a status of "permanent". Other names
can also be registered as permanent, if the Expert(s) find that they can also be registered as permanent, if the Expert(s) find that they
are in use, in consultation with the community. Other names should are in use, in consultation with the community. Other names should
be registered as "provisional". be registered as "provisional".
Provisional entries can be removed by the Expert(s) if -- in Provisional entries can be removed by the Expert(s) if - in
consultation with the community -- the Expert(s) find that they are consultation with the community - the Expert(s) find that they are
not in use. The Experts can change a provisional entry's status to not in use. The Experts can change a provisional entry's status to
permanent at any time. permanent at any time.
Note that names can be registered by third parties (including the Note that names can be registered by third parties (including the
Expert(s)), if the Expert(s) determines that an unregistered name is Expert(s)), if the Expert(s) determines that an unregistered name is
widely deployed and not likely to be registered in a timely manner widely deployed and not likely to be registered in a timely manner
otherwise. otherwise.
5.4. Field Values 5.4. Field Values
skipping to change at page 31, line 37 skipping to change at page 32, line 37
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.
Historically, HTTP field values could be extended over multiple lines Historically, HTTP field values could be extended over multiple lines
by preceding each extra line with at least one space or horizontal by preceding each extra line with at least one space or horizontal
tab (obs-fold). This document assumes that any such obsolete line tab (obs-fold). This document assumes that any such obsolete line
folding has been replaced with one or more SP octets prior to folding has been replaced with one or more SP octets prior to
interpreting the field value, as described in Section 5.2 of interpreting the field value, as described in Section 5.2 of
[Messaging]. [Messaging].
Note: This specification does not use ABNF rules to define each | *Note:* This specification does not use ABNF rules to define
"Field Name: Field Value" pair, as was done in earlier editions | each "Field Name: Field Value" pair, as was done in earlier
(published before [RFC7230]). Instead, ABNF rules are named | editions (published before [RFC7230]). Instead, ABNF rules are
according to each registered field name, wherein the rule defines | named according to each registered field name, wherein the rule
the valid grammar for that field's corresponding field values | defines the valid grammar for that field's corresponding field
(i.e., after the field value has been extracted by a generic field | values (i.e., after the field value has been extracted by a
parser). | generic field parser).
5.4.1. Common Field Value Components 5.4.1. Common Field Value Components
Many HTTP field values are defined using common syntax components, Many HTTP field values are defined using common syntax components,
separated by whitespace or specific delimiting characters. separated by whitespace or specific delimiting characters.
Delimiters are chosen from the set of US-ASCII visual characters not Delimiters are chosen from the set of US-ASCII visual characters not
allowed in a token (DQUOTE and "(),/:;<=>?@[\]{}"). allowed in a token (DQUOTE and "(),/:;<=>?@[\]{}").
5.4.1.1. Tokens 5.4.1.1. Tokens
skipping to change at page 33, line 21 skipping to change at page 34, line 26
Parameter names are case-insensitive. Parameter values might or Parameter names are case-insensitive. Parameter values might or
might not be case-sensitive, depending on the semantics of the might not be case-sensitive, depending on the semantics of the
parameter name. Examples of parameters and some equivalent forms can parameter name. Examples of parameters and some equivalent forms can
be seen in media types (Section 7.1.1) and the Accept header field be seen in media types (Section 7.1.1) and the Accept header field
(Section 9.4.1). (Section 9.4.1).
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.
5.4.1.5. Date/Time Formats 5.4.1.5. Date/Time Formats
Prior to 1995, there were three different formats commonly used by Prior to 1995, there were three different formats commonly used by
servers to communicate timestamps. For compatibility with old servers to communicate timestamps. For compatibility with old
implementations, all three are defined here. The preferred format is implementations, all three are defined here. The preferred format is
a fixed-length and single-zone subset of the date and time a fixed-length and single-zone subset of the date and time
specification used by the Internet Message Format [RFC5322]. specification used by the Internet Message Format [RFC5322].
HTTP-date = IMF-fixdate / obs-date HTTP-date = IMF-fixdate / obs-date
skipping to change at page 35, line 4 skipping to change at page 36, line 11
day-name-l = %s"Monday" / %s"Tuesday" / %s"Wednesday" day-name-l = %s"Monday" / %s"Tuesday" / %s"Wednesday"
/ %s"Thursday" / %s"Friday" / %s"Saturday" / %s"Sunday" / %s"Thursday" / %s"Friday" / %s"Saturday" / %s"Sunday"
asctime-date = day-name SP date3 SP time-of-day SP year asctime-date = day-name SP date3 SP time-of-day SP year
date3 = month SP ( 2DIGIT / ( SP 1DIGIT )) date3 = month SP ( 2DIGIT / ( SP 1DIGIT ))
; e.g., Jun 2 ; e.g., Jun 2
HTTP-date is case sensitive. A sender MUST NOT generate additional HTTP-date is case sensitive. A sender MUST NOT generate additional
whitespace in an HTTP-date beyond that specifically included as SP in whitespace in an HTTP-date beyond that specifically included as SP in
the grammar. The semantics of day-name, day, month, year, and time- the grammar. The semantics of day-name, day, month, year, and
of-day are the same as those defined for the Internet Message Format time-of-day are the same as those defined for the Internet Message
constructs with the corresponding name ([RFC5322], Section 3.3). Format constructs with the corresponding name ([RFC5322],
Section 3.3).
Recipients of a timestamp value in rfc850-date format, which uses a Recipients of a timestamp value in rfc850-date format, which uses a
two-digit year, MUST interpret a timestamp that appears to be more two-digit year, MUST interpret a timestamp that appears to be more
than 50 years in the future as representing the most recent year in than 50 years in the future as representing the most recent year in
the past that had the same last two digits. the past that had the same last two digits.
Recipients of timestamp values are encouraged to be robust in parsing Recipients of timestamp values are encouraged to be robust in parsing
timestamps unless otherwise restricted by the field definition. For timestamps unless otherwise restricted by the field definition. For
example, messages are occasionally forwarded over HTTP from a non- example, messages are occasionally forwarded over HTTP from a non-
HTTP source that might generate any of the date and time HTTP source that might generate any of the date and time
specifications defined by the Internet Message Format. specifications defined by the Internet Message Format.
Note: HTTP requirements for the date/time stamp format apply only | *Note:* HTTP requirements for the date/time stamp format apply
to their usage within the protocol stream. Implementations are | only to their usage within the protocol stream.
not required to use these formats for user presentation, request | Implementations are not required to use these formats for user
logging, etc. | presentation, request logging, etc.
5.5. ABNF List Extension: #rule 5.5. 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 list-based field values. readability in the definitions of some list-based 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).
skipping to change at page 40, line 5 skipping to change at page 41, line 5
o Whether the field ought to be preserved across redirects. o Whether the field ought to be preserved across redirects.
o Whether it introduces any additional security considerations, such o Whether it introduces any additional security considerations, such
as disclosure of privacy-related data. as disclosure of privacy-related data.
5.8. Fields Defined In This Document 5.8. Fields Defined In This Document
The following fields are defined by this document: The following fields are defined by this document:
+---------------------------+------------+-----------------+ +---------------------------+------------+----------------+
| Field Name | Status | Reference | | Field Name | Status | Reference |
+---------------------------+------------+-----------------+ | Accept | standard | Section 9.4.1 |
| Accept | standard | Section 9.4.1 | | Accept-Charset | deprecated | Section 9.4.2 |
| Accept-Charset | deprecated | Section 9.4.2 | | Accept-Encoding | standard | Section 9.4.3 |
| Accept-Encoding | standard | Section 9.4.3 | | Accept-Language | standard | Section 9.4.4 |
| Accept-Language | standard | Section 9.4.4 | | Accept-Ranges | standard | Section 11.4.1 |
| Accept-Ranges | standard | Section 11.4.1 | | Allow | standard | Section 11.4.2 |
| Allow | standard | Section 11.4.2 | | Authentication-Info | standard | Section 11.3.3 |
| Authentication-Info | standard | Section 11.3.3 | | Authorization | standard | Section 9.5.3 |
| Authorization | standard | Section 9.5.3 | | Content-Encoding | standard | Section 7.2.2 |
| Content-Encoding | standard | Section 7.2.2 | | Content-Language | standard | Section 7.2.3 |
| Content-Language | standard | Section 7.2.3 | | Content-Length | standard | Section 7.2.4 |
| Content-Length | standard | Section 7.2.4 | | Content-Location | standard | Section 7.2.5 |
| Content-Location | standard | Section 7.2.5 | | Content-Range | standard | Section 7.3.4 |
| Content-Range | standard | Section 7.3.4 | | Content-Type | standard | Section 7.2.1 |
| Content-Type | standard | Section 7.2.1 | | Date | standard | Section 11.1.1 |
| Date | standard | Section 11.1.1 | | ETag | standard | Section 11.2.3 |
| ETag | standard | Section 11.2.3 | | Expect | standard | Section 9.1.1 |
| Expect | standard | Section 9.1.1 | | From | standard | Section 9.6.1 |
| From | standard | Section 9.6.1 | | Host | standard | Section 6.6 |
| Host | standard | Section 6.6 | | If-Match | standard | Section 9.2.3 |
| If-Match | standard | Section 9.2.3 | | If-Modified-Since | standard | Section 9.2.5 |
| If-Modified-Since | standard | Section 9.2.5 | | If-None-Match | standard | Section 9.2.4 |
| If-None-Match | standard | Section 9.2.4 | | If-Range | standard | Section 9.2.7 |
| If-Range | standard | Section 9.2.7 | | If-Unmodified-Since | standard | Section 9.2.6 |
| If-Unmodified-Since | standard | Section 9.2.6 | | Last-Modified | standard | Section 11.2.2 |
| Last-Modified | standard | Section 11.2.2 | | Location | standard | Section 11.1.2 |
| Location | standard | Section 11.1.2 | | Max-Forwards | standard | Section 9.1.2 |
| Max-Forwards | standard | Section 9.1.2 | | Proxy-Authenticate | standard | Section 11.3.2 |
| Proxy-Authenticate | standard | Section 11.3.2 | | Proxy-Authentication-Info | standard | Section 11.3.4 |
| Proxy-Authentication-Info | standard | Section 11.3.4 | | Proxy-Authorization | standard | Section 9.5.4 |
| Proxy-Authorization | standard | Section 9.5.4 | | Range | standard | Section 9.3 |
| Range | standard | Section 9.3 | | Referer | standard | Section 9.6.2 |
| Referer | standard | Section 9.6.2 | | Retry-After | standard | Section 11.1.3 |
| Retry-After | standard | Section 11.1.3 | | Server | standard | Section 11.4.3 |
| Server | standard | Section 11.4.3 | | Trailer | standard | Section 5.6.3 |
| Trailer | standard | Section 5.6.3 | | User-Agent | standard | Section 9.6.3 |
| User-Agent | standard | Section 9.6.3 | | Vary | standard | Section 11.1.4 |
| Vary | standard | Section 11.1.4 | | Via | standard | Section 6.7.1 |
| Via | standard | Section 6.7.1 | | WWW-Authenticate | standard | Section 11.3.1 |
| WWW-Authenticate | standard | Section 11.3.1 | +---------------------------+------------+----------------+
+---------------------------+------------+-----------------+
Table 1 Table 2
Furthermore, the field name "*" is reserved, since using that name as Furthermore, the field name "*" is reserved, since using that name as
an HTTP header field might conflict with its special semantics in the an HTTP header field might conflict with its special semantics in the
Vary header field (Section 11.1.4). Vary header field (Section 11.1.4).
+------------+----------+--------------+-------------+ +------------+----------+-------------+------------+
| Field Name | Status | Reference | Comments | | Field Name | Status | Reference | Comments |
+------------+----------+--------------+-------------+ | * | standard | Section 5.8 | (reserved) |
| * | standard | Section 5.8 | (reserved) | +------------+----------+-------------+------------+
+------------+----------+--------------+-------------+
Table 3
6. Message Routing 6. Message Routing
HTTP request message routing is determined by each client based on HTTP request message routing is determined by each client based on
the target resource, the client's proxy configuration, and the target resource, the client's proxy configuration, and
establishment or reuse of an inbound connection. The corresponding establishment or reuse of an inbound connection. The corresponding
response routing follows the same connection chain back to the response routing follows the same connection chain back to the
client. client.
6.1. Identifying a Target Resource 6.1. Identifying a Target Resource
skipping to change at page 47, line 47 skipping to change at page 49, line 5
connection in which the request was received. For example, 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 Host header field differs such that the information within a received Host header field differs
from the host or port upon which the connection has been made. If from the host or port upon which the connection has been made. If
the connection is from a trusted gateway, that inconsistency might be the connection is from a trusted gateway, that inconsistency might be
expected; otherwise, it might indicate an attempt to bypass security expected; otherwise, it might indicate an attempt to bypass security
filters, trick the server into delivering non-public content, or filters, trick the server into delivering non-public content, or
poison a cache. See Section 12 for security considerations regarding poison a cache. See Section 12 for security considerations regarding
message routing. message routing.
Note: previous specifications defined the recomposed target URI as | *Note:* previous specifications defined the recomposed target
a distinct concept, the effective request URI. | URI as a distinct concept, the effective request URI.
6.6. Host 6.6. 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 53, line 51 skipping to change at page 55, line 17
HTTP uses charset names to indicate or negotiate the character HTTP uses charset names to indicate or negotiate the character
encoding scheme of a textual representation [RFC6365]. A charset is encoding scheme of a textual representation [RFC6365]. A charset is
identified by a case-insensitive token. identified by a case-insensitive token.
charset = token charset = token
Charset names ought to be registered in the IANA "Character Sets" Charset names ought to be registered in the IANA "Character Sets"
registry (<https://www.iana.org/assignments/character-sets>) registry (<https://www.iana.org/assignments/character-sets>)
according to the procedures defined in Section 2 of [RFC2978]. according to the procedures defined in Section 2 of [RFC2978].
Note: In theory, charset names are defined by the "mime-charset" | *Note:* In theory, charset names are defined by the "mime-
ABNF rule defined in Section 2.3 of [RFC2978] (as corrected in | charset" ABNF rule defined in Section 2.3 of [RFC2978] (as
| corrected in [Err1912]). That rule allows two characters that
[Err1912]). That rule allows two characters that are not included | are not included in "token" ("{" and "}"), but no charset name
in "token" ("{" and "}"), but no charset name registered at the | registered at the time of this writing includes braces (see
time of this writing includes braces (see [Err5433]). | [Err5433]).
7.1.1.2. Canonicalization and Text Defaults 7.1.1.2. Canonicalization and Text Defaults
Media types are registered with a canonical form in order to be Media types are registered with a canonical form in order to be
interoperable among systems with varying native encoding formats. interoperable among systems with varying native encoding formats.
Representations selected or transferred via HTTP ought to be in Representations selected or transferred via HTTP ought to be in
canonical form, for many of the same reasons described by the canonical form, for many of the same reasons described by the
Multipurpose Internet Mail Extensions (MIME) [RFC2045]. However, the Multipurpose Internet Mail Extensions (MIME) [RFC2045]. However, the
performance characteristics of email deployments (i.e., store and performance characteristics of email deployments (i.e., store and
forward messages to peers) are significantly different from those forward messages to peers) are significantly different from those
skipping to change at page 54, line 41 skipping to change at page 56, line 7
regarding line breaks applies only to text within a representation regarding line breaks applies only to text within a representation
that has been assigned a "text" media type; it does not apply to that has been assigned a "text" media type; it does not apply to
"multipart" types or HTTP elements outside the payload body (e.g., "multipart" types or HTTP elements outside the payload body (e.g.,
header fields). header fields).
If a representation is encoded with a content-coding, the underlying If a representation is encoded with a content-coding, the underlying
data ought to be in a form defined above prior to being encoded. data ought to be in a form defined above prior to being encoded.
7.1.1.3. Multipart Types 7.1.1.3. Multipart Types
MIME provides for a number of "multipart" types -- encapsulations of MIME provides for a number of "multipart" types - encapsulations of
one or more representations within a single message body. All one or more representations within a single message body. All
multipart types share a common syntax, as defined in Section 5.1.1 of multipart types share a common syntax, as defined in Section 5.1.1 of
[RFC2046], and include a boundary parameter as part of the media type [RFC2046], and include a boundary parameter as part of the media type
value. The message body is itself a protocol element; a sender MUST value. The message body is itself a protocol element; a sender MUST
generate only CRLF to represent line breaks between body parts. generate only CRLF to represent line breaks between body parts.
HTTP message framing does not use the multipart boundary as an HTTP message framing does not use the multipart boundary as an
indicator of message body length, though it might be used by indicator of message body length, though it might be used by
implementations that generate or process the payload. For example, implementations that generate or process the payload. For example,
the "multipart/form-data" type is often used for carrying form data the "multipart/form-data" type is often used for carrying form data
skipping to change at page 55, line 29 skipping to change at page 57, line 5
All content codings are case-insensitive and ought to be registered All content codings are case-insensitive and ought to be registered
within the "HTTP Content Coding Registry", as defined in within the "HTTP Content Coding Registry", as defined in
Section 7.1.2.4 Section 7.1.2.4
Content-coding values are used in the Accept-Encoding (Section 9.4.3) Content-coding values are used in the Accept-Encoding (Section 9.4.3)
and Content-Encoding (Section 7.2.2) header fields. and Content-Encoding (Section 7.2.2) header fields.
The following content-coding values are defined by this The following content-coding values are defined by this
specification: specification:
+------------+------------------------------------------+-----------+ +------------+-------------------------------+-----------+
| Name | Description | Reference | | Name | Description | Reference |
+------------+------------------------------------------+-----------+ | compress | UNIX "compress" data format | Section |
| compress | UNIX "compress" data format [Welch] | Section 7 | | | [Welch] | 7.1.2.1 |
| | | .1.2.1 | | deflate | "deflate" compressed data | Section |
| deflate | "deflate" compressed data ([RFC1951]) | Section 7 | | | ([RFC1951]) inside the "zlib" | 7.1.2.2 |
| | inside the "zlib" data format | .1.2.2 | | | data format ([RFC1950]) | |
| | ([RFC1950]) | | | gzip | GZIP file format [RFC1952] | Section |
| gzip | GZIP file format [RFC1952] | Section 7 | | | | 7.1.2.3 |
| | | .1.2.3 | | identity | Reserved | Section |
| identity | Reserved | Section 9 | | | | 9.4.3 |
| | | .4.3 | | x-compress | Deprecated (alias for | Section |
| x-compress | Deprecated (alias for compress) | Section 7 | | | compress) | 7.1.2.1 |
| | | .1.2.1 | | x-gzip | Deprecated (alias for gzip) | Section |
| x-gzip | Deprecated (alias for gzip) | Section 7 | | | | 7.1.2.3 |
| | | .1.2.3 | +------------+-------------------------------+-----------+
+------------+------------------------------------------+-----------+
Table 2 Table 4
7.1.2.1. Compress Coding 7.1.2.1. Compress Coding
The "compress" coding is an adaptive Lempel-Ziv-Welch (LZW) coding The "compress" coding is an adaptive Lempel-Ziv-Welch (LZW) coding
[Welch] that is commonly produced by the UNIX file compression [Welch] that is commonly produced by the UNIX file compression
program "compress". A recipient SHOULD consider "x-compress" to be program "compress". A recipient SHOULD consider "x-compress" to be
equivalent to "compress". equivalent to "compress".
7.1.2.2. Deflate Coding 7.1.2.2. Deflate Coding
The "deflate" coding is a "zlib" data format [RFC1950] containing a The "deflate" coding is a "zlib" data format [RFC1950] containing a
"deflate" compressed data stream [RFC1951] that uses a combination of "deflate" compressed data stream [RFC1951] that uses a combination of
the Lempel-Ziv (LZ77) compression algorithm and Huffman coding. the Lempel-Ziv (LZ77) compression algorithm and Huffman coding.
Note: Some non-conformant implementations send the "deflate" | *Note:* Some non-conformant implementations send the "deflate"
compressed data without the zlib wrapper. | compressed data without the zlib wrapper.
7.1.2.3. Gzip Coding 7.1.2.3. Gzip Coding
The "gzip" coding is an LZ77 coding with a 32-bit Cyclic Redundancy The "gzip" coding is an LZ77 coding with a 32-bit Cyclic Redundancy
Check (CRC) that is commonly produced by the gzip file compression Check (CRC) that is commonly produced by the gzip file compression
program [RFC1952]. A recipient SHOULD consider "x-gzip" to be program [RFC1952]. A recipient SHOULD consider "x-gzip" to be
equivalent to "gzip". equivalent to "gzip".
7.1.2.4. Content Coding Registry 7.1.2.4. Content Coding Registry
skipping to change at page 57, line 12 skipping to change at page 58, line 29
Section 4.8 of [RFC8126]) and MUST conform to the purpose of content Section 4.8 of [RFC8126]) and MUST conform to the purpose of content
coding defined in Section 7.1.2. coding defined in Section 7.1.2.
7.1.3. Language Tags 7.1.3. Language Tags
A language tag, as defined in [RFC5646], identifies a natural A language tag, as defined in [RFC5646], identifies a natural
language spoken, written, or otherwise conveyed by human beings for language spoken, written, or otherwise conveyed by human beings for
communication of information to other human beings. Computer communication of information to other human beings. Computer
languages are explicitly excluded. languages are explicitly excluded.
HTTP uses language tags within the Accept-Language and Content- HTTP uses language tags within the Accept-Language and
Language header fields. Accept-Language uses the broader language- Content-Language header fields. Accept-Language uses the broader
range production defined in Section 9.4.4, whereas Content-Language language-range production defined in Section 9.4.4, whereas
uses the language-tag production defined below. Content-Language uses the language-tag production defined below.
language-tag = <Language-Tag, see [RFC5646], Section 2.1> language-tag = <Language-Tag, see [RFC5646], Section 2.1>
A language tag is a sequence of one or more case-insensitive subtags, A language tag is a sequence of one or more case-insensitive subtags,
each separated by a hyphen character ("-", %x2D). In most cases, a each separated by a hyphen character ("-", %x2D). In most cases, a
language tag consists of a primary language subtag that identifies a language tag consists of a primary language subtag that identifies a
broad family of related languages (e.g., "en" = English), which is broad family of related languages (e.g., "en" = English), which is
optionally followed by a series of subtags that refine or narrow that optionally followed by a series of subtags that refine or narrow that
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
skipping to change at page 57, line 44 skipping to change at page 59, line 17
Representation data can be partitioned into subranges when there are Representation data can be partitioned into subranges when there are
addressable structural units inherent to that data's content coding addressable structural units inherent to that data's content coding
or media type. For example, octet (a.k.a., byte) boundaries are a or media type. For example, octet (a.k.a., byte) boundaries are a
structural unit common to all representation data, allowing structural unit common to all representation data, allowing
partitions of the data to be identified as a range of bytes at some partitions of the data to be identified as a range of bytes at some
offset from the start or end of that data. offset from the start or end of that data.
This general notion of a "range unit" is used in the Accept-Ranges This general notion of a "range unit" is used in the Accept-Ranges
(Section 11.4.1) response header field to advertise support for range (Section 11.4.1) response header field to advertise support for range
requests, the Range (Section 9.3) request header field to delineate requests, the Range (Section 9.3) request header field to delineate
the parts of a representation that are requested, and the Content- the parts of a representation that are requested, and the
Range (Section 7.3.4) payload header field to describe which part of Content-Range (Section 7.3.4) payload header field to describe which
a representation is being transferred. part of a representation is being transferred.
range-unit = token range-unit = token
All range unit names are case-insensitive and ought to be registered All range unit names are case-insensitive and ought to be registered
within the "HTTP Range Unit Registry", as defined in Section 7.1.4.4 within the "HTTP Range Unit Registry", as defined in Section 7.1.4.4
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 Name | Description | Reference |
| Name | | | | bytes | a range of octets | Section |
+------------+-----------------------------------------+------------+ | | | 7.1.4.2 |
| bytes | a range of octets | Section 7. | | none | reserved as keyword to indicate | Section |
| | | 1.4.2 | | | range requests are not supported | 11.4.1 |
| none | reserved as keyword to indicate range | Section 11 | +-----------------+----------------------------------+-----------+
| | requests are not supported | .4.1 |
+------------+-----------------------------------------+------------+
Table 3 Table 5
7.1.4.1. Range Specifiers 7.1.4.1. Range Specifiers
Ranges are expressed in terms of a range unit paired with a set of Ranges are expressed in terms of a range unit paired with a set of
range specifiers. The range unit name determines what kinds of range specifiers. The range unit name determines what kinds of
range-spec are applicable to its own specifiers. Hence, the range-spec are applicable to its own specifiers. Hence, the
following gramar is generic: each range unit is expected to specify following gramar is generic: each range unit is expected to specify
requirements on when int-range, suffix-range, and other-range are requirements on when int-range, suffix-range, and other-range are
allowed. allowed.
skipping to change at page 59, line 37 skipping to change at page 61, line 14
If the representation data has a content coding applied, each byte If the representation data has a content coding applied, each byte
range is calculated with respect to the encoded sequence of bytes, range is calculated with respect to the encoded sequence of bytes,
not the sequence of underlying bytes that would be obtained after not the sequence of underlying bytes that would be obtained after
decoding. decoding.
Examples of bytes range specifiers: 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 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-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-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 (N > 0) of the selected A client can request the last N bytes (N > 0) of the selected
representation using a suffix-range. If the selected representation representation using a suffix-range. If the selected representation
is shorter than the specified suffix-length, the entire is shorter than the specified suffix-length, the entire
representation is used. 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: o The first, middle, and last 1000 bytes:
bytes= 0-999, 4500-5499, -1000 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 bytes range-set includes at least one range-spec with a If a valid bytes range-set includes at least one range-spec with a
first-pos that is less than the current length of the representation, first-pos that is less than the current length of the representation,
or at least one suffix-range with a non-zero suffix-length, then the or at least one suffix-range with a non-zero suffix-length, then the
bytes range-set is satisfiable. Otherwise, the bytes range-set is bytes range-set is satisfiable. Otherwise, the bytes range-set is
unsatisfiable. unsatisfiable.
If the selected representation has zero length, the only satisfiable If the selected representation has zero length, the only satisfiable
form of range-spec is a suffix-range with a non-zero suffix-length. form of range-spec is a suffix-range with a non-zero suffix-length.
skipping to change at page 62, line 7 skipping to change at page 63, line 19
representation header fields describe how to interpret the representation header fields describe how to interpret the
representation data enclosed in the payload body. In a response to a representation data enclosed in the payload body. In a response to a
HEAD request, the representation header fields describe the HEAD request, the representation header fields describe the
representation data that would have been enclosed in the payload body representation data that would have been enclosed in the payload body
if the same request had been a GET. if the same request had been a GET.
The following header fields convey representation metadata: The following header fields convey representation metadata:
+------------------+---------------+ +------------------+---------------+
| Field Name | Defined in... | | Field Name | Defined in... |
+------------------+---------------+
| Content-Type | Section 7.2.1 | | Content-Type | Section 7.2.1 |
| Content-Encoding | Section 7.2.2 | | Content-Encoding | Section 7.2.2 |
| Content-Language | Section 7.2.3 | | Content-Language | Section 7.2.3 |
| Content-Length | Section 7.2.4 | | Content-Length | Section 7.2.4 |
| Content-Location | Section 7.2.5 | | Content-Location | Section 7.2.5 |
+------------------+---------------+ +------------------+---------------+
Table 6
7.2.1. Content-Type 7.2.1. Content-Type
The "Content-Type" header field indicates the media type of the The "Content-Type" header field indicates the media type of the
associated representation: either the representation enclosed in the associated representation: either the representation enclosed in the
message payload or the selected representation, as determined by the message payload or the selected representation, as determined by the
message semantics. The indicated media type defines both the data message semantics. The indicated media type defines both the data
format and how that data is intended to be processed by a recipient, format and how that data is intended to be processed by a recipient,
within the scope of the received message semantics, after any content within the scope of the received message semantics, after any content
codings indicated by Content-Encoding are decoded. codings indicated by Content-Encoding are decoded.
skipping to change at page 64, line 45 skipping to change at page 66, line 8
Content-Language: mi, en Content-Language: mi, en
However, just because multiple languages are present within a However, just because multiple languages are present within a
representation does not mean that it is intended for multiple representation does not mean that it is intended for multiple
linguistic audiences. An example would be a beginner's language linguistic audiences. An example would be a beginner's language
primer, such as "A First Lesson in Latin", which is clearly intended primer, such as "A First Lesson in Latin", which is clearly intended
to be used by an English-literate audience. In this case, the to be used by an English-literate audience. In this case, the
Content-Language would properly only include "en". Content-Language would properly only include "en".
Content-Language MAY be applied to any media type -- it is not Content-Language MAY be applied to any media type - it is not limited
limited to textual documents. to textual documents.
7.2.4. Content-Length 7.2.4. Content-Length
[[CREF1: The "Content-Length" header field indicates the number of // The "Content-Length" header field indicates the number of data
data octets (body length) for the representation. In some cases, // octets (body length) for the representation. In some cases,
Content-Length is used to define or estimate message framing. ]] // Content-Length is used to define or estimate message framing.
Content-Length = 1*DIGIT Content-Length = 1*DIGIT
An example is An example is
Content-Length: 3495 Content-Length: 3495
A sender MUST NOT send a Content-Length header field in any message A sender MUST NOT send a Content-Length header field in any message
that contains a Transfer-Encoding header field. that contains a Transfer-Encoding header field.
A user agent SHOULD send a Content-Length in a request message when A user agent SHOULD send a Content-Length in a request message when
skipping to change at page 66, line 7 skipping to change at page 67, line 20
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 12.5).
If a message is received that has a Content-Length header field value If a message is received that has a Content-Length header field value
consisting of the same decimal value as a comma-separated list consisting of the same decimal value as a comma-separated list
(Section 5.5) -- for example, "Content-Length: 42, 42" -- indicating (Section 5.5) - for example, "Content-Length: 42, 42" - indicating
that duplicate Content-Length header fields have been generated or that duplicate Content-Length header fields have been generated or
combined by an upstream message processor, then the recipient MUST combined by an upstream message processor, then the recipient MUST
either reject the message as invalid or replace the duplicated field either reject the message as invalid or replace the duplicated field
values with a single valid Content-Length field containing that values with a single valid Content-Length field containing that
decimal value prior to determining the message body length or decimal value prior to determining the message body length or
forwarding the message. forwarding the message.
7.2.5. Content-Location 7.2.5. Content-Location
The "Content-Location" header field references a URI that can be used The "Content-Location" header field references a URI that can be used
skipping to change at page 68, line 20 skipping to change at page 69, line 32
HEAD) or only some part(s) of the representation data (e.g., the 206 HEAD) or only some part(s) of the representation data (e.g., the 206
(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.
+-------------------+----------------------------+ +-------------------+----------------------------+
| Field Name | Defined in... | | Field Name | Defined in... |
+-------------------+----------------------------+
| Content-Range | Section 7.3.4 | | Content-Range | Section 7.3.4 |
| Trailer | Section 5.6.3 | | Trailer | Section 5.6.3 |
| Transfer-Encoding | Section 6.1 of [Messaging] | | Transfer-Encoding | Section 6.1 of [Messaging] |
+-------------------+----------------------------+ +-------------------+----------------------------+
Table 7
7.3.1. Purpose 7.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 8.3.4) represents the desired state of the target request (Section 8.3.4) represents the desired state of the target
resource if the request is successfully applied, whereas a resource if the request is successfully applied, whereas a
representation in the payload of a POST request (Section 8.3.3) representation in the payload of a POST request (Section 8.3.3)
represents information to be processed by the target resource. represents information to be processed by the target resource.
In a response, the payload's purpose is defined by both the request In a response, the payload's purpose is defined by both the request
skipping to change at page 71, line 44 skipping to change at page 73, line 24
The Content-Range header field has no meaning for status codes that The Content-Range header field has no meaning for status codes that
do not explicitly describe its semantic. For this specification, do not explicitly describe its semantic. For this specification,
only the 206 (Partial Content) and 416 (Range Not Satisfiable) status only the 206 (Partial Content) and 416 (Range Not Satisfiable) status
codes describe a meaning for Content-Range. codes describe a meaning for Content-Range.
The following are examples of Content-Range values in which the The following are examples of Content-Range values in which the
selected representation contains a total of 1234 bytes: selected representation contains a total of 1234 bytes:
o The first 500 bytes: o The first 500 bytes:
Content-Range: bytes 0-499/1234 Content-Range: bytes 0-499/1234
o The second 500 bytes: o The second 500 bytes:
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
7.3.5. Media Type multipart/byteranges 7.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
skipping to change at page 72, line 38 skipping to change at page 74, line 14
1. Additional CRLFs might precede the first boundary string in the 1. Additional CRLFs might precede the first boundary string in the
body. body.
2. Although [RFC2046] permits the boundary string to be quoted, some 2. Although [RFC2046] permits the boundary string to be quoted, some
existing implementations handle a quoted boundary string existing implementations handle a quoted boundary string
incorrectly. incorrectly.
3. A number of clients and servers were coded to an early draft of 3. A number of clients and servers were coded to an early draft of
the byteranges specification that used a media type of multipart/ the byteranges specification that used a media type of multipart/
x-byteranges, which is almost (but not quite) compatible with x-byteranges , which is almost (but not quite) compatible with
this type. this type.
Despite the name, the "multipart/byteranges" media type is not Despite the name, the "multipart/byteranges" media type is not
limited to byte ranges. The following example uses an "exampleunit" limited to byte ranges. The following example uses an "exampleunit"
range unit: range unit:
HTTP/1.1 206 Partial Content HTTP/1.1 206 Partial Content
Date: Tue, 14 Nov 1995 06:25:24 GMT Date: Tue, 14 Nov 1995 06:25:24 GMT
Last-Modified: Tue, 14 July 04:58:08 GMT Last-Modified: Tue, 14 July 04:58:08 GMT
Content-Length: 2331785 Content-Length: 2331785
skipping to change at page 73, line 48 skipping to change at page 75, line 16
Interoperability considerations: N/A Interoperability considerations: N/A
Published specification: This specification (see Section 7.3.5). Published specification: This specification (see Section 7.3.5).
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 Magic number(s): N/A
Magic number(s): N/A File extension(s): N/A
File extension(s): N/A
Macintosh file type code(s): N/A Macintosh file type code(s): N/A
Person and email address to contact for further information: See Aut Person and email address to contact for further information: See Aut
hors' Addresses section. hors' Addresses section.
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: N/A Restrictions on usage: N/A
Author: See Authors' Addresses section. Author: See Authors' Addresses section.
skipping to change at page 77, line 10 skipping to change at page 78, line 32
request to obtain an alternate representation. Furthermore, this request to obtain an alternate representation. Furthermore, this
specification does not define a mechanism for supporting automatic specification does not define a mechanism for supporting automatic
selection, though it does not prevent such a mechanism from being selection, though it does not prevent such a mechanism from being
developed as an extension. developed as an extension.
7.4.3. Request Payload Negotiation 7.4.3. Request Payload Negotiation
When content negotiation preferences are sent in a server's response, When content negotiation preferences are sent in a server's response,
the listed preferences are called request payload negotiation because the listed preferences are called request payload negotiation because
they intend to influence selection of an appropriate payload for they intend to influence selection of an appropriate payload for
subsequent requests to that resource. For example, the Accept- subsequent requests to that resource. For example, the
Encoding field (Section 9.4.3) can be sent in a response to indicate Accept-Encoding field (Section 9.4.3) can be sent in a response to
preferred content codings for subsequent requests to that resource indicate preferred content codings for subsequent requests to that
[RFC7694]. resource [RFC7694].
Similarly, Section 3.1 of [RFC5789] defines the "Accept-Patch" | Similarly, Section 3.1 of [RFC5789] defines the "Accept-Patch"
response header field which allows discovery of which content | response header field which allows discovery of which content
types are accepted in PATCH requests. | types are accepted in PATCH requests.
7.4.4. Quality Values 7.4.4. Quality Values
The content negotiation fields defined by this specification use a The content negotiation fields defined by this specification use a
common parameter, named "q" (case-insensitive), to assign a relative common parameter, named "q" (case-insensitive), to assign a relative
"weight" to the preference for that associated kind of content. This "weight" to the preference for that associated kind of content. This
weight is referred to as a "quality value" (or "qvalue") because the weight is referred to as a "quality value" (or "qvalue") because the
same parameter name is often used within server configurations to same parameter name is often used within server configurations to
assign a weight to the relative quality of the various assign a weight to the relative quality of the various
representations that can be selected for a resource. representations that can be selected for a resource.
skipping to change at page 79, line 5 skipping to change at page 80, line 8
Unlike distributed objects, the standardized request methods in HTTP Unlike distributed objects, the standardized request methods in HTTP
are not resource-specific, since uniform interfaces provide for are not resource-specific, since uniform interfaces provide for
better visibility and reuse in network-based systems [REST]. Once better visibility and reuse in network-based systems [REST]. Once
defined, a standardized method ought to have the same semantics when defined, a standardized method ought to have the same semantics when
applied to any resource, though each resource determines for itself applied to any resource, though each resource determines for itself
whether those semantics are implemented or allowed. whether those semantics are implemented or allowed.
This specification defines a number of standardized methods that are This specification defines a number of standardized methods that are
commonly used in HTTP, as outlined by the following table. commonly used in HTTP, as outlined by the following table.
+---------+-------------------------------------------------+-------+ +---------+--------------------------------------------+-------+
| Method | Description | Sec. | | Method | Description | Sec. |
+---------+-------------------------------------------------+-------+ | GET | Transfer a current representation of the | 8.3.1 |
| GET | Transfer a current representation of the target | 8.3.1 | | | target resource. | |
| | resource. | | | HEAD | Same as GET, but do not transfer the | 8.3.2 |
| HEAD | Same as GET, but do not transfer the response | 8.3.2 | | | response body. | |
| | body. | | | POST | Perform resource-specific processing on | 8.3.3 |
| POST | Perform resource-specific processing on the | 8.3.3 | | | the request payload. | |
| | request payload. | | | PUT | Replace all current representations of the | 8.3.4 |
| PUT | Replace all current representations of the | 8.3.4 | | | target resource with the request payload. | |
| | target resource with the request payload. | | | DELETE | Remove all current representations of the | 8.3.5 |
| DELETE | Remove all current representations of the | 8.3.5 | | | target resource. | |
| | target resource. | | | CONNECT | Establish a tunnel to the server | 8.3.6 |
| CONNECT | Establish a tunnel to the server identified by | 8.3.6 | | | identified by the target resource. | |
| | the target resource. | | | OPTIONS | Describe the communication options for the | 8.3.7 |
| OPTIONS | Describe the communication options for the | 8.3.7 | | | target resource. | |
| | target resource. | | | TRACE | Perform a message loop-back test along the | 8.3.8 |
| TRACE | Perform a message loop-back test along the path | 8.3.8 | | | path to the target resource. | |
| | to the target resource. | | +---------+--------------------------------------------+-------+
+---------+-------------------------------------------------+-------+
Table 4 Table 8
All general-purpose servers MUST support the methods GET and HEAD. All general-purpose servers MUST support the methods GET and HEAD.
All other methods are OPTIONAL. All other methods are OPTIONAL.
The set of methods allowed by a target resource can be listed in an The set of methods allowed by a target resource can be listed in an
Allow header field (Section 11.4.2). However, the set of allowed Allow header field (Section 11.4.2). However, the set of allowed
methods can change dynamically. When a request method is received methods can change dynamically. When a request method is received
that is unrecognized or not implemented by an origin server, the that is unrecognized or not implemented by an origin server, the
origin server SHOULD respond with the 501 (Not Implemented) status origin server SHOULD respond with the 501 (Not Implemented) status
code. When a request method is received that is known by an origin code. When a request method is received that is known by an origin
server but not allowed for the target resource, the origin server server but not allowed for the target resource, the origin server
SHOULD respond with the 405 (Method Not Allowed) status code. SHOULD respond with the 405 (Method Not Allowed) status code.
8.2. Common Method Properties 8.2. Common Method Properties
+---------+------+------------+----------------+
| Method | Safe | Idempotent | Reference |
+---------+------+------------+----------------+
| CONNECT | no | no | Section 8.3.6 |
| DELETE | no | yes | Section 8.3.5 |
| GET | yes | yes | Section 8.3.1 |
| HEAD | yes | yes | Section 8.3.2 |
| OPTIONS | yes | yes | Section 8.3.7 |
| POST | no | no | Section 8.3.3 |
| PUT | no | yes | Section 8.3.4 |
| TRACE | yes | yes | Section 8.3.8 |
+---------+------+------------+----------------+
Table 5 +---------+------+------------+---------------+
| Method | Safe | Idempotent | Reference |
| CONNECT | no | no | Section 8.3.6 |
| DELETE | no | yes | Section 8.3.5 |
| GET | yes | yes | Section 8.3.1 |
| HEAD | yes | yes | Section 8.3.2 |
| OPTIONS | yes | yes | Section 8.3.7 |
| POST | no | no | Section 8.3.3 |
| PUT | no | yes | Section 8.3.4 |
| TRACE | yes | yes | Section 8.3.8 |
+---------+------+------------+---------------+
Table 9
8.2.1. Safe Methods 8.2.1. Safe Methods
Request methods are considered "safe" if their defined semantics are Request methods are considered "safe" if their defined semantics are
essentially read-only; i.e., the client does not request, and does essentially read-only; i.e., the client does not request, and does
not expect, any state change on the origin server as a result of not expect, any state change on the origin server as a result of
applying a safe method to a target resource. Likewise, reasonable applying a safe method to a target resource. Likewise, reasonable
use of a safe method is not expected to cause any harm, loss of use of a safe method is not expected to cause any harm, loss of
property, or unusual burden on the origin server. property, or unusual burden on the origin server.
skipping to change at page 88, line 5 skipping to change at page 88, line 50
might or might not be destroyed by the origin server, and the might or might not be destroyed by the origin server, and the
associated storage might or might not be reclaimed, depending associated storage might or might not be reclaimed, depending
entirely on the nature of the resource and its implementation by the entirely on the nature of the resource and its implementation by the
origin server (which are beyond the scope of this specification). origin server (which are beyond the scope of this specification).
Likewise, other implementation aspects of a resource might need to be Likewise, other implementation aspects of a resource might need to be
deactivated or archived as a result of a DELETE, such as database or deactivated or archived as a result of a DELETE, such as database or
gateway connections. In general, it is assumed that the origin gateway connections. In general, it is assumed that the origin
server will only allow DELETE on resources for which it has a server will only allow DELETE on resources for which it has a
prescribed mechanism for accomplishing the deletion. prescribed mechanism for accomplishing the deletion.
Relatively few resources allow the DELETE method -- its primary use Relatively few resources allow the DELETE method - its primary use is
is for remote authoring environments, where the user has some for remote authoring environments, where the user has some direction
direction regarding its effect. For example, a resource that was regarding its effect. For example, a resource that was previously
previously created using a PUT request, or identified via the created using a PUT request, or identified via the Location header
Location header field after a 201 (Created) response to a POST field after a 201 (Created) response to a POST request, might allow a
request, might allow a corresponding DELETE request to undo those corresponding DELETE request to undo those actions. Similarly,
actions. Similarly, custom user agent implementations that implement custom user agent implementations that implement an authoring
an authoring function, such as revision control clients using HTTP function, such as revision control clients using HTTP for remote
for remote operations, might use DELETE based on an assumption that operations, might use DELETE based on an assumption that the server's
the server's URI space has been crafted to correspond to a version URI space has been crafted to correspond to a version repository.
repository.
If a DELETE method is successfully applied, the origin server SHOULD If a DELETE method is successfully applied, the origin server SHOULD
send send
o a 202 (Accepted) status code if the action will likely succeed but o a 202 (Accepted) status code if the action will likely succeed but
has not yet been enacted, has not yet been enacted,
o a 204 (No Content) status code if the action has been enacted and o a 204 (No Content) status code if the action has been enacted and
no further information is to be supplied, or no further information is to be supplied, or
skipping to change at page 93, line 5 skipping to change at page 93, line 43
body if any is present in the request and what refinements the method body if any is present in the request and what refinements the method
makes to header field or status code semantics. If the new method is makes to header field or status code semantics. If the new method is
cacheable, its definition ought to describe how, and under what cacheable, its definition ought to describe how, and under what
conditions, a cache can store a response and use it to satisfy a conditions, a cache can store a response and use it to satisfy a
subsequent request. The new method ought to describe whether it can subsequent request. The new method ought to describe whether it can
be made conditional (Section 9.2) and, if so, how a server responds be made conditional (Section 9.2) and, if so, how a server responds
when the condition is false. Likewise, if the new method might have when the condition is false. Likewise, if the new method might have
some use for partial response semantics (Section 9.3), it ought to some use for partial response semantics (Section 9.3), it ought to
document this, too. document this, too.
Note: Avoid defining a method name that starts with "M-", since | *Note:* Avoid defining a method name that starts with "M-",
that prefix might be misinterpreted as having the semantics | since that prefix might be misinterpreted as having the
assigned to it by [RFC2774]. | semantics assigned to it by [RFC2774].
9. Request Header Fields 9. Request Header Fields
A client sends request header fields to provide more information A client sends request header fields to provide more information
about the request context, make the request conditional based on the about the request context, make the request conditional based on the
target resource state, suggest preferred formats for the response, target resource state, suggest preferred formats for the response,
supply authentication credentials, or modify the expected request supply authentication credentials, or modify the expected request
processing. These fields act as request modifiers, similar to the processing. These fields act as request modifiers, similar to the
parameters on a programming language method invocation. parameters on a programming language method invocation.
9.1. Controls 9.1. Controls
Controls are request header fields that direct specific handling of Controls are request header fields that direct specific handling of
the request. the request.
+---------------+----------------------------+ +---------------+----------------------------+
| Field Name | Defined in... | | Field Name | Defined in... |
+---------------+----------------------------+
| Cache-Control | Section 5.2 of [Caching] | | Cache-Control | Section 5.2 of [Caching] |
| Expect | Section 9.1.1 | | Expect | Section 9.1.1 |
| Host | Section 6.6 | | Host | Section 6.6 |
| Max-Forwards | Section 9.1.2 | | Max-Forwards | Section 9.1.2 |
| Pragma | Section 5.4 of [Caching] | | Pragma | Section 5.4 of [Caching] |
| TE | Section 7.4 of [Messaging] | | TE | Section 7.4 of [Messaging] |
+---------------+----------------------------+ +---------------+----------------------------+
Table 10
9.1.1. Expect 9.1.1. Expect
The "Expect" header field in a request indicates a certain set of The "Expect" header field in a request indicates a certain set of
behaviors (expectations) that need to be supported by the server in behaviors (expectations) that need to be supported by the server in
order to properly handle this request. The only such expectation order to properly handle this request. The only such expectation
defined by this specification is 100-continue. defined by this specification is 100-continue.
Expect = "100-continue" Expect = "100-continue"
The Expect field value is case-insensitive. The Expect field value is case-insensitive.
skipping to change at page 95, line 41 skipping to change at page 96, line 41
100-continue expectation and indicates a request message body will 100-continue expectation and indicates a request message body will
follow, either send an immediate response with a final status code, follow, either send an immediate response with a final status code,
if that status can be determined by examining just the method, target if that status can be determined by examining just the method, target
URI, and header fields, or begin forwarding the request toward the URI, and header fields, or begin forwarding the request toward the
origin server by sending a corresponding request-line and header origin server by sending a corresponding request-line and header
section to the next inbound server. If the proxy believes (from section to the next inbound server. If the proxy believes (from
configuration or past interaction) that the next inbound server only configuration or past interaction) that the next inbound server only
supports HTTP/1.0, the proxy MAY generate an immediate 100 (Continue) supports HTTP/1.0, the proxy MAY generate an immediate 100 (Continue)
response to encourage the client to begin sending the message body. response to encourage the client to begin sending the message body.
Note: The Expect header field was added after the original | *Note:* The Expect header field was added after the original
publication of HTTP/1.1 [RFC2068] as both the means to request an | publication of HTTP/1.1 [RFC2068] as both the means to request
interim 100 (Continue) response and the general mechanism for | an interim 100 (Continue) response and the general mechanism
indicating must-understand extensions. However, the extension | for indicating must-understand extensions. However, the
mechanism has not been used by clients and the must-understand | extension mechanism has not been used by clients and the must-
requirements have not been implemented by many servers, rendering | understand requirements have not been implemented by many
the extension mechanism useless. This specification has removed | servers, rendering the extension mechanism useless. This
the extension mechanism in order to simplify the definition and | specification has removed the extension mechanism in order to
processing of 100-continue. | simplify the definition and processing of 100-continue.
9.1.2. Max-Forwards 9.1.2. Max-Forwards
The "Max-Forwards" header field provides a mechanism with the TRACE The "Max-Forwards" header field provides a mechanism with the TRACE
(Section 8.3.8) and OPTIONS (Section 8.3.7) request methods to limit (Section 8.3.8) and OPTIONS (Section 8.3.7) request methods to limit
the number of times that the request is forwarded by proxies. This the number of times that the request is forwarded by proxies. This
can be useful when the client is attempting to trace a request that can be useful when the client is attempting to trace a request that
appears to be failing or looping mid-chain. appears to be failing or looping mid-chain.
Max-Forwards = 1*DIGIT Max-Forwards = 1*DIGIT
skipping to change at page 97, line 22 skipping to change at page 98, line 22
specification consists of a comparison between a set of validators specification consists of a comparison between a set of validators
obtained from prior representations of the target resource to the obtained from prior representations of the target resource to the
current state of validators for the selected representation current state of validators for the selected representation
(Section 11.2). Hence, these preconditions evaluate whether the (Section 11.2). Hence, these preconditions evaluate whether the
state of the target resource has changed since a given state known by state of the target resource has changed since a given state known by
the client. The effect of such an evaluation depends on the method the client. The effect of such an evaluation depends on the method
semantics and choice of conditional, as defined in Section 9.2.1. semantics and choice of conditional, as defined in Section 9.2.1.
+---------------------+---------------+ +---------------------+---------------+
| Field Name | Defined in... | | Field Name | Defined in... |
+---------------------+---------------+
| If-Match | Section 9.2.3 | | If-Match | Section 9.2.3 |
| If-None-Match | Section 9.2.4 | | If-None-Match | Section 9.2.4 |
| If-Modified-Since | Section 9.2.5 | | If-Modified-Since | Section 9.2.5 |
| If-Unmodified-Since | Section 9.2.6 | | If-Unmodified-Since | Section 9.2.6 |
| If-Range | Section 9.2.7 | | If-Range | Section 9.2.7 |
+---------------------+---------------+ +---------------------+---------------+
Table 11
9.2.1. Evaluation 9.2.1. Evaluation
Except when excluded below, a recipient cache or origin server MUST Except when excluded below, a recipient cache or origin server MUST
evaluate received request preconditions after it has successfully evaluate received request preconditions after it has successfully
performed its normal request checks and just before it would perform performed its normal request checks and just before it would perform
the action associated with the request method. A server MUST ignore the action associated with the request method. A server MUST ignore
all received preconditions if its response to the same request all received preconditions if its response to the same request
without those conditions would have been a status code other than a without those conditions would have been a status code other than a
2xx (Successful) or 412 (Precondition Failed). In other words, 2xx (Successful) or 412 (Precondition Failed). In other words,
redirects and failures take precedence over the evaluation of redirects and failures take precedence over the evaluation of
skipping to change at page 98, line 42 skipping to change at page 100, line 5
validation, a validated cache is more efficient than a partial validation, a validated cache is more efficient than a partial
response, and entity tags are presumed to be more accurate than date response, and entity tags are presumed to be more accurate than date
validators. validators.
A recipient cache or origin server MUST evaluate the request A recipient cache or origin server MUST evaluate the request
preconditions defined by this specification in the following order: preconditions defined by this specification in the following order:
1. When recipient is the origin server and If-Match is present, 1. When recipient is the origin server and If-Match is present,
evaluate the If-Match precondition: evaluate the If-Match precondition:
* if true, continue to step 3 o if true, continue to step 3
* if false, respond 412 (Precondition Failed) unless it can be o if false, respond 412 (Precondition Failed) unless it can be
determined that the state-changing request has already determined that the state-changing request has already
succeeded (see Section 9.2.3) succeeded (see Section 9.2.3)
2. When recipient is the origin server, If-Match is not present, and 2. When recipient is the origin server, If-Match is not present, and
If-Unmodified-Since is present, evaluate the If-Unmodified-Since If-Unmodified-Since is present, evaluate the If-Unmodified-Since
precondition: precondition:
* if true, continue to step 3 o if true, continue to step 3
* if false, respond 412 (Precondition Failed) unless it can be o if false, respond 412 (Precondition Failed) unless it can be
determined that the state-changing request has already determined that the state-changing request has already
succeeded (see Section 9.2.6) succeeded (see Section 9.2.6)
3. When If-None-Match is present, evaluate the If-None-Match 3. When If-None-Match is present, evaluate the If-None-Match
precondition: precondition:
* if true, continue to step 5 o if true, continue to step 5
* if false for GET/HEAD, respond 304 (Not Modified) o if false for GET/HEAD, respond 304 (Not Modified)
* if false for other methods, respond 412 (Precondition Failed) o if false for other methods, respond 412 (Precondition Failed)
4. When the method is GET or HEAD, If-None-Match is not present, and 4. When the method is GET or HEAD, If-None-Match is not present, and
If-Modified-Since is present, evaluate the If-Modified-Since If-Modified-Since is present, evaluate the If-Modified-Since
precondition: precondition:
* if true, continue to step 5 o if true, continue to step 5
* if false, respond 304 (Not Modified) o if false, respond 304 (Not Modified)
5. When the method is GET and both Range and If-Range are present, 5. When the method is GET and both Range and If-Range are present,
evaluate the If-Range precondition: evaluate the If-Range precondition:
* if the validator matches and the Range specification is o if the validator matches and the Range specification is
applicable to the selected representation, respond 206 applicable to the selected representation, respond 206
(Partial Content) (Partial Content)
6. Otherwise, 6. Otherwise,
* all conditions are met, so perform the requested action and o all conditions are met, so perform the requested action and
respond according to its success or failure. respond according to its success or failure.
Any extension to HTTP that defines additional conditional request Any extension to HTTP that defines additional conditional request
header fields ought to define its own expectations regarding the header fields ought to define its own expectations regarding the
order for evaluating such fields in relation to those defined in this order for evaluating such fields in relation to those defined in this
document and other conditionals that might be found in practice. document and other conditionals that might be found in practice.
9.2.3. If-Match 9.2.3. If-Match
The "If-Match" header field makes the request method conditional on The "If-Match" header field makes the request method conditional on
skipping to change at page 103, line 27 skipping to change at page 104, line 15
If-Modified-Since = HTTP-date If-Modified-Since = HTTP-date
An example of the field is: An example of the field is:
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
A recipient MUST ignore If-Modified-Since if the request contains an A recipient MUST ignore If-Modified-Since if the request contains an
If-None-Match header field; the condition in If-None-Match is If-None-Match header field; the condition in If-None-Match is
considered to be a more accurate replacement for the condition in If- considered to be a more accurate replacement for the condition in If-
Modified-Since, and the two are only combined for the sake of Modified-Since, and the two are only combined for the sake of
interoperating with older intermediaries that might not implement If- interoperating with older intermediaries that might not implement
None-Match. If-None-Match.
A recipient MUST ignore the If-Modified-Since header field if the A recipient MUST ignore the If-Modified-Since header field if the
received field value is not a valid HTTP-date, or if the request received field value is not a valid HTTP-date, or if the request
method is neither GET nor HEAD. method is neither GET nor HEAD.
A recipient MUST interpret an If-Modified-Since field value's A recipient MUST interpret an If-Modified-Since field value's
timestamp in terms of the origin server's clock. timestamp in terms of the origin server's clock.
If-Modified-Since is typically used for two distinct purposes: 1) to If-Modified-Since is typically used for two distinct purposes: 1) to
allow efficient updates of a cached representation that does not have allow efficient updates of a cached representation that does not have
skipping to change at page 104, line 11 skipping to change at page 104, line 47
archived backup). However, caches occasionally generate the field archived backup). However, caches occasionally generate the field
value based on other data, such as the Date header field of the value based on other data, such as the Date header field of the
cached message or the local clock time that the message was received, cached message or the local clock time that the message was received,
particularly when the cached message does not contain a Last-Modified particularly when the cached message does not contain a Last-Modified
field. field.
When used for limiting the scope of retrieval to a recent time When used for limiting the scope of retrieval to a recent time
window, a user agent will generate an If-Modified-Since field value window, a user agent will generate an If-Modified-Since field value
based on either its own local clock or a Date header field received based on either its own local clock or a Date header field received
from the server in a prior response. Origin servers that choose an from the server in a prior response. Origin servers that choose an
exact timestamp match based on the selected representation's Last- exact timestamp match based on the selected representation's
Modified field will not be able to help the user agent limit its data Last-Modified field will not be able to help the user agent limit its
transfers to only those changed during the specified window. data transfers to only those changed during the specified window.
An origin server that receives an If-Modified-Since header field An origin server that receives an If-Modified-Since header field
SHOULD evaluate the condition as per Section 9.2.1 prior to SHOULD evaluate the condition as per Section 9.2.1 prior to
performing the method. The origin server SHOULD NOT perform the performing the method. The origin server SHOULD NOT perform the
requested method if the selected representation's last modification requested method if the selected representation's last modification
date is earlier than or equal to the date provided in the field date is earlier than or equal to the date provided in the field
value; instead, the origin server SHOULD generate a 304 (Not value; instead, the origin server SHOULD generate a 304 (Not
Modified) response, including only those metadata that are useful for Modified) response, including only those metadata that are useful for
identifying or updating a previously cached response. identifying or updating a previously cached response.
skipping to change at page 106, line 38 skipping to change at page 107, line 31
provided that is not a strong validator in the sense defined by provided that is not a strong validator in the sense defined by
Section 11.2.2.2. A valid entity-tag can be distinguished from a Section 11.2.2.2. A valid entity-tag can be distinguished from a
valid HTTP-date by examining the first two characters for a DQUOTE. valid HTTP-date by examining the first two characters for a DQUOTE.
If the validator given in the If-Range header field matches the If the validator given in the If-Range header field matches the
current validator for the selected representation of the target current validator for the selected representation of the target
resource, then the server SHOULD process the Range header field as resource, then the server SHOULD process the Range header field as
requested. If the validator does not match, the server MUST ignore requested. If the validator does not match, the server MUST ignore
the Range header field. Note that this comparison by exact match, the Range header field. Note that this comparison by exact match,
including when the validator is an HTTP-date, differs from the including when the validator is an HTTP-date, differs from the
"earlier than or equal to" comparison used when evaluating an If- "earlier than or equal to" comparison used when evaluating an
Unmodified-Since conditional. If-Unmodified-Since conditional.
9.3. Range 9.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 (Section 7.1), rather than the entire selected representation data (Section 7.1), rather than the entire
selected representation. selected representation.
Range = ranges-specifier Range = ranges-specifier
skipping to change at page 108, line 38 skipping to change at page 109, line 32
The following request header fields can be sent by a user agent to The following request header fields can be sent by a user agent to
engage in proactive negotiation of the response content, as defined engage in proactive negotiation of the response content, as defined
in Section 7.4.1. The preferences sent in these fields apply to any in Section 7.4.1. The preferences sent in these fields apply to any
content in the response, including representations of the target content in the response, including representations of the target
resource, representations of error or processing status, and resource, representations of error or processing status, and
potentially even the miscellaneous text strings that might appear potentially even the miscellaneous text strings that might appear
within the protocol. within the protocol.
+-----------------+---------------+ +-----------------+---------------+
| Field Name | Defined in... | | Field Name | Defined in... |
+-----------------+---------------+
| Accept | Section 9.4.1 | | Accept | Section 9.4.1 |
| Accept-Charset | Section 9.4.2 | | Accept-Charset | Section 9.4.2 |
| Accept-Encoding | Section 9.4.3 | | Accept-Encoding | Section 9.4.3 |
| Accept-Language | Section 9.4.4 | | Accept-Language | Section 9.4.4 |
+-----------------+---------------+ +-----------------+---------------+
Table 12
For each of these header fields, a request that does not contain it For each of these header fields, a request that does not contain it
implies that the user agent has no preference on that axis of implies that the user agent has no preference on that axis of
negotiation. If the header field is present in a request and none of negotiation. If the header field is present in a request and none of
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 12.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
practical value, because it is seldom useful to say, for example, "I limited practical value, because it is seldom useful to say, for
prefer image/* more or less than (some other specific value)". example, "I prefer image/* more or less than (some other specific
Clients can explicitly request a 406 (Not Acceptable) response if a value)". Clients can explicitly request a 406 (Not Acceptable)
more preferred format is not available by sending Accept: */*;q=0, response if a more preferred format is not available by sending
but they still need to be able to handle a different response, since Accept: */*;q=0, but they still need to be able to handle a different
the server is allowed to ignore their preference. response, since the server is allowed to ignore their preference.
9.4.1. Accept 9.4.1. Accept
The "Accept" header field can be used by user agents to specify their The "Accept" header field can be used by user agents to specify their
preferences regarding response media types. For example, Accept preferences regarding response media types. For example, Accept
header fields can be used to indicate that the request is header fields can be used to indicate that the request is
specifically limited to a small set of desired types, as in the case specifically limited to a small set of desired types, as in the case
of a request for an in-line image. of a request for an in-line image.
When sent by a server in a response, Accept provides information When sent by a server in a response, Accept provides information
skipping to change at page 110, line 9 skipping to change at page 111, line 12
subtypes of that type. The media-range can include media type subtypes of that type. The media-range can include media type
parameters that are applicable to that range. parameters that are applicable to that range.
Each media-range might be followed by zero or more applicable media Each media-range might be followed by zero or more applicable media
type parameters (e.g., charset), an optional "q" parameter for type parameters (e.g., charset), an optional "q" parameter for
indicating a relative weight (Section 7.4.4), and then zero or more indicating a relative weight (Section 7.4.4), and then zero or more
extension parameters. The "q" parameter is necessary if any extension parameters. The "q" parameter is necessary if any
extensions (accept-ext) are present, since it acts as a separator extensions (accept-ext) are present, since it acts as a separator
between the two parameter sets. between the two parameter sets.
Note: Use of the "q" parameter name to separate media type | *Note:* Use of the "q" parameter name to separate media type
parameters from Accept extension parameters is due to historical | parameters from Accept extension parameters is due to
practice. Although this prevents any media type parameter named | historical practice. Although this prevents any media type
"q" from being used with a media range, such an event is believed | parameter named "q" from being used with a media range, such an
to be unlikely given the lack of any "q" parameters in the IANA | event is believed to be unlikely given the lack of any "q"
media type registry and the rare usage of any media type | parameters in the IANA media type registry and the rare usage
parameters in Accept. Future media types are discouraged from | of any media type parameters in Accept. Future media types are
registering any parameter named "q". | discouraged from registering any parameter named "q".
The example The example
Accept: audio/*; q=0.2, audio/basic Accept: audio/*; q=0.2, audio/basic
is interpreted as "I prefer audio/basic, but send me any audio type is interpreted as "I prefer audio/basic, but send me any audio type
if it is the best available after an 80% markdown in quality". if it is the best available after an 80% markdown in quality".
A more elaborate example is A more elaborate example is
skipping to change at page 111, line 15 skipping to change at page 112, line 15
determined by finding the media range with the highest precedence determined by finding the media range with the highest precedence
that matches the type. For example, that matches the type. For example,
Accept: text/*;q=0.3, text/plain;q=0.7, text/plain;format=flowed, Accept: text/*;q=0.3, text/plain;q=0.7, text/plain;format=flowed,
text/plain;format=fixed;q=0.4, */*;q=0.5 text/plain;format=fixed;q=0.4, */*;q=0.5
would cause the following values to be associated: would cause the following values to be associated:
+--------------------------+---------------+ +--------------------------+---------------+
| Media Type | Quality Value | | Media Type | Quality Value |
+--------------------------+---------------+
| text/plain;format=flowed | 1 | | text/plain;format=flowed | 1 |
| text/plain | 0.7 | | text/plain | 0.7 |
| text/html | 0.3 | | text/html | 0.3 |
| image/jpeg | 0.5 | | image/jpeg | 0.5 |
| text/plain;format=fixed | 0.4 | | text/plain;format=fixed | 0.4 |
| text/html;level=3 | 0.7 | | text/html;level=3 | 0.7 |
+--------------------------+---------------+ +--------------------------+---------------+
Note: A user agent might be provided with a default set of quality Table 13
*Note:* A user agent might be provided with a default set of quality
values for certain media ranges. However, unless the user agent is a values for certain media ranges. However, unless the user agent is a
closed system that cannot interact with other rendering agents, this closed system that cannot interact with other rendering agents, this
default set ought to be configurable by the user. default set ought to be configurable by the user.
9.4.2. Accept-Charset 9.4.2. Accept-Charset
The "Accept-Charset" header field can be sent by a user agent to The "Accept-Charset" header field can be sent by a user agent to
indicate its preferences for charsets in textual response content. indicate its preferences for charsets in textual response content.
For example, this field allows user agents capable of understanding For example, this field allows user agents capable of understanding
more comprehensive or special-purpose charsets to signal that more comprehensive or special-purpose charsets to signal that
skipping to change at page 112, line 5 skipping to change at page 113, line 5
associate a quality value with each charset to indicate the user's associate a quality value with each charset to indicate the user's
relative preference for that charset, as defined in Section 7.4.4. relative preference for that charset, as defined in Section 7.4.4.
An example is An example is
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 12.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.
9.4.3. Accept-Encoding 9.4.3. Accept-Encoding
The "Accept-Encoding" header field can be used to indicate The "Accept-Encoding" header field can be used to indicate
preferences regarding the use of content codings (Section 7.1.2). preferences regarding the use of content codings (Section 7.1.2).
skipping to change at page 113, line 48 skipping to change at page 114, line 48
The most common use of Accept-Encoding is in responses with a 415 The most common use of Accept-Encoding is in responses with a 415
(Unsupported Media Type) status code, in response to optimistic use (Unsupported Media Type) status code, in response to optimistic use
of a content coding by clients. However, the header field can also of a content coding by clients. However, the header field can also
be used to indicate to clients that content codings are supported, to be used to indicate to clients that content codings are supported, to
optimize future interactions. For example, a resource might include optimize future interactions. For example, a resource might include
it in a 2xx (Successful) response when the request payload was big it in a 2xx (Successful) response when the request payload was big
enough to justify use of a compression coding but the client failed enough to justify use of a compression coding but the client failed
do so. do so.
Note: Most HTTP/1.0 applications do not recognize or obey qvalues | *Note:* Most HTTP/1.0 applications do not recognize or obey
associated with content-codings. This means that qvalues might | qvalues associated with content-codings. This means that
not work and are not permitted with x-gzip or x-compress. | qvalues might not work and are not permitted with x-gzip or
| x-compress.
9.4.4. Accept-Language 9.4.4. Accept-Language
The "Accept-Language" header field can be used by user agents to The "Accept-Language" header field can be used by user agents to
indicate the set of natural languages that are preferred in the indicate the set of natural languages that are preferred in the
response. Language tags are defined in Section 7.1.3. response. Language tags are defined in Section 7.1.3.
Accept-Language = 1#( language-range [ weight ] ) Accept-Language = 1#( language-range [ weight ] )
language-range = language-range =
<language-range, see [RFC4647], Section 2.1> <language-range, see [RFC4647], Section 2.1>
skipping to change at page 114, line 50 skipping to change at page 115, line 50
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 12.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
a preference, since users are rarely familiar with the details of | setting a preference, since users are rarely familiar with the
language matching as described above. For example, users might | details of language matching as described above. For example,
assume that on selecting "en-gb", they will be served any kind of | users might assume that on selecting "en-gb", they will be
English document if British English is not available. A user | served any kind of English document if British English is not
agent might suggest, in such a case, to add "en" to the list for | available. A user agent might suggest, in such a case, to add
better matching behavior. | "en" to the list for better matching behavior.
9.5. Authentication Credentials 9.5. Authentication Credentials
HTTP provides a general framework for access control and HTTP provides a general framework for access control and
authentication, via an extensible set of challenge-response authentication, via an extensible set of challenge-response
authentication schemes, which can be used by a server to challenge a authentication schemes, which can be used by a server to challenge a
client request and by a client to provide authentication information. client request and by a client to provide authentication information.
Two header fields are used for carrying authentication credentials. Two header fields are used for carrying authentication credentials.
Note that various custom mechanisms for user authentication use the Note that various custom mechanisms for user authentication use the
Cookie header field for this purpose, as defined in [RFC6265]. Cookie header field for this purpose, as defined in [RFC6265].
+---------------------+---------------+ +---------------------+---------------+
| Field Name | Defined in... | | Field Name | Defined in... |
+---------------------+---------------+
| Authorization | Section 9.5.3 | | Authorization | Section 9.5.3 |
| Proxy-Authorization | Section 9.5.4 | | Proxy-Authorization | Section 9.5.4 |
+---------------------+---------------+ +---------------------+---------------+
Table 14
9.5.1. Challenge and Response 9.5.1. Challenge and Response
HTTP provides a simple challenge-response authentication framework HTTP provides a simple challenge-response authentication framework
that can be used by a server to challenge a client request and by a that can be used by a server to challenge a client request and by a
client to provide authentication information. It uses a case- client to provide authentication information. It uses a case-
insensitive token as a means to identify the authentication scheme, insensitive token as a means to identify the authentication scheme,
followed by additional information necessary for achieving followed by additional information necessary for achieving
authentication via that scheme. The latter can be either a comma- authentication via that scheme. The latter can be either a comma-
separated list of parameters or a single sequence of characters separated list of parameters or a single sequence of characters
capable of holding base64-encoded information. capable of holding base64-encoded information.
skipping to change at page 116, line 8 skipping to change at page 117, line 12
token68 = 1*( ALPHA / DIGIT / token68 = 1*( ALPHA / DIGIT /
"-" / "." / "_" / "~" / "+" / "/" ) *"=" "-" / "." / "_" / "~" / "+" / "/" ) *"="
The token68 syntax allows the 66 unreserved URI characters The token68 syntax allows the 66 unreserved URI characters
([RFC3986]), plus a few others, so that it can hold a base64, ([RFC3986]), plus a few others, so that it can hold a base64,
base64url (URL and filename safe alphabet), base32, or base16 (hex) base64url (URL and filename safe alphabet), base32, or base16 (hex)
encoding, with or without padding, but excluding whitespace encoding, with or without padding, but excluding whitespace
([RFC4648]). ([RFC4648]).
A 401 (Unauthorized) response message is used by an origin server to A 401 (Unauthorized) response message is used by an origin server to
challenge the authorization of a user agent, including a WWW- challenge the authorization of a user agent, including a
Authenticate header field containing at least one challenge WWW-Authenticate header field containing at least one challenge
applicable to the requested resource. applicable to the requested resource.
A 407 (Proxy Authentication Required) response message is used by a A 407 (Proxy Authentication Required) response message is used by a
proxy to challenge the authorization of a client, including a Proxy- proxy to challenge the authorization of a client, including a
Authenticate header field containing at least one challenge Proxy-Authenticate header field containing at least one challenge
applicable to the proxy for the requested resource. applicable to the proxy for the requested resource.
challenge = auth-scheme [ 1*SP ( token68 / #auth-param ) ] challenge = auth-scheme [ 1*SP ( token68 / #auth-param ) ]
Note: Many clients fail to parse a challenge that contains an | *Note:* Many clients fail to parse a challenge that contains an
unknown scheme. A workaround for this problem is to list well- | unknown scheme. A workaround for this problem is to list well-
supported schemes (such as "basic") first. | supported schemes (such as "basic") first.
A user agent that wishes to authenticate itself with an origin server A user agent that wishes to authenticate itself with an origin server
-- usually, but not necessarily, after receiving a 401 (Unauthorized) - usually, but not necessarily, after receiving a 401 (Unauthorized)
-- can do so by including an Authorization header field with the - can do so by including an Authorization header field with the
request. request.
A client that wishes to authenticate itself with a proxy -- usually, A client that wishes to authenticate itself with a proxy - usually,
but not necessarily, after receiving a 407 (Proxy Authentication but not necessarily, after receiving a 407 (Proxy Authentication
Required) -- can do so by including a Proxy-Authorization header Required) - can do so by including a Proxy-Authorization header field
field with the request. with the request.
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
skipping to change at page 118, line 10 skipping to change at page 119, line 13
outside the scope of its server. outside the scope of its server.
For historical reasons, a sender MUST only generate the quoted-string For historical reasons, a sender MUST only generate the quoted-string
syntax. Recipients might have to support both token and quoted- syntax. Recipients might have to support both token and quoted-
string syntax for maximum interoperability with existing clients that string syntax for maximum interoperability with existing clients that
have been accepting both notations for a long time. have been accepting both notations for a long time.
9.5.3. Authorization 9.5.3. Authorization
The "Authorization" header field allows a user agent to authenticate The "Authorization" header field allows a user agent to authenticate
itself with an origin server -- usually, but not necessarily, after itself with an origin server - usually, but not necessarily, after
receiving a 401 (Unauthorized) response. Its value consists of receiving a 401 (Unauthorized) response. Its value consists of
credentials containing the authentication information of the user credentials containing the authentication information of the user
agent for the realm of the resource being requested. agent for the realm of the resource being requested.
Authorization = credentials Authorization = credentials
If a request is authenticated and a realm specified, the same If a request is authenticated and a realm specified, the same
credentials are presumed to be valid for all other requests within credentials are presumed to be valid for all other requests within
this realm (assuming that the authentication scheme itself does not this realm (assuming that the authentication scheme itself does not
require otherwise, such as credentials that vary according to a require otherwise, such as credentials that vary according to a
skipping to change at page 120, line 16 skipping to change at page 121, line 20
o The parsing of challenges and credentials is defined by this o The parsing of challenges and credentials is defined by this
specification and cannot be modified by new authentication specification and cannot be modified by new authentication
schemes. When the auth-param syntax is used, all parameters ought schemes. When the auth-param syntax is used, all parameters ought
to support both token and quoted-string syntax, and syntactical to support both token and quoted-string syntax, and syntactical
constraints ought to be defined on the field value after parsing constraints ought to be defined on the field value after parsing
(i.e., quoted-string processing). This is necessary so that (i.e., quoted-string processing). This is necessary so that
recipients can use a generic parser that applies to all recipients can use a generic parser that applies to all
authentication schemes. authentication schemes.
Note: The fact that the value syntax for the "realm" parameter is *Note:* The fact that the value syntax for the "realm" parameter
restricted to quoted-string was a bad design choice not to be is restricted to quoted-string was a bad design choice not to be
repeated for new parameters. repeated for new parameters.
o Definitions of new schemes ought to define the treatment of o Definitions of new schemes ought to define the treatment of
unknown extension parameters. In general, a "must-ignore" rule is unknown extension parameters. In general, a "must-ignore" rule is
preferable to a "must-understand" rule, because otherwise it will preferable to a "must-understand" rule, because otherwise it will
be hard to introduce new parameters in the presence of legacy be hard to introduce new parameters in the presence of legacy
recipients. Furthermore, it's good to describe the policy for recipients. Furthermore, it's good to describe the policy for
defining new parameters (such as "update the specification" or defining new parameters (such as "update the specification" or
"use this registry"). "use this registry").
skipping to change at page 121, line 18 skipping to change at page 122, line 13
Section 12.14.4). Section 12.14.4).
9.6. Request Context 9.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.
+------------+---------------+ +------------+---------------+
| Field Name | Defined in... | | Field Name | Defined in... |
+------------+---------------+
| From | Section 9.6.1 | | From | Section 9.6.1 |
| Referer | Section 9.6.2 | | Referer | Section 9.6.2 |
| User-Agent | Section 9.6.3 | | User-Agent | Section 9.6.3 |
+------------+---------------+ +------------+---------------+
Table 15
9.6.1. From 9.6.1. From
The "From" header field contains an Internet email address for a The "From" header field contains an Internet email address for a
human user who controls the requesting user agent. The address ought human user who controls the requesting user agent. The address ought
to be machine-usable, as defined by "mailbox" in Section 3.4 of to be machine-usable, as defined by "mailbox" in Section 3.4 of
[RFC5322]: [RFC5322]:
From = mailbox From = mailbox
mailbox = <mailbox, see [RFC5322], Section 3.4> mailbox = <mailbox, see [RFC5322], Section 3.4>
skipping to change at page 123, line 43 skipping to change at page 124, line 39
identifiers are listed in decreasing order of their significance for identifiers are listed in decreasing order of their significance for
identifying the user agent software. Each product identifier identifying the user agent software. Each product identifier
consists of a name and 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
version that is not a version identifier (i.e., successive versions product-version that is not a version identifier (i.e., successive
of the same product name ought to differ only in the product-version versions of the same product name ought to differ only in the
portion of the product identifier). product-version portion of the product identifier).
Example: Example:
User-Agent: CERN-LineMode/2.15 libwww/2.17b3 User-Agent: CERN-LineMode/2.15 libwww/2.17b3
A user agent SHOULD NOT generate a User-Agent field containing A user agent SHOULD NOT generate a User-Agent 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 User-Agent subproducts by third parties. Overly long and detailed User-Agent
field values increase request latency and the risk of a user being field values increase request latency and the risk of a user being
identified against their wishes ("fingerprinting"). identified against their wishes ("fingerprinting").
skipping to change at page 125, line 16 skipping to change at page 126, line 8
valid request valid request
A single request can have multiple associated responses: zero or more A single request can have multiple associated responses: zero or more
interim (non-final) responses with status codes in the interim (non-final) responses with status codes in the
"informational" (1xx) range, followed by exactly one final response "informational" (1xx) range, followed by exactly one final response
with a status code in one of the other ranges. with a status code in one of the other ranges.
10.1. Overview of Status Codes 10.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 heuristically Responses with status codes that are defined as heuristically
cacheable (e.g., 200, 203, 204, 206, 300, 301, 308, 404, 405, 410, cacheable (e.g., 200, 203, 204, 206, 300, 301, 308, 404, 405, 410,
414, and 501 in this specification) can be reused by a cache with 414, and 501 in this specification) can be reused by a cache with
heuristic expiration unless otherwise indicated by the method heuristic expiration unless otherwise indicated by the method
definition or explicit cache controls [Caching]; all other status definition or explicit cache controls [Caching]; all other status
codes are not heuristically cacheable. codes are not heuristically cacheable.
+-------+-------------------------------+------------------+ +-------+-------------------------------+-----------------+
| Value | Description | Reference | | Value | Description | Reference |
+-------+-------------------------------+------------------+ | 100 | Continue | Section 10.2.1 |
| 100 | Continue | Section 10.2.1 | | 101 | Switching Protocols | Section 10.2.2 |
| 101 | Switching Protocols | Section 10.2.2 | | 200 | OK | Section 10.3.1 |
| 200 | OK | Section 10.3.1 | | 201 | Created | Section 10.3.2 |
| 201 | Created | Section 10.3.2 | | 202 | Accepted | Section 10.3.3 |
| 202 | Accepted | Section 10.3.3 | | 203 | Non-Authoritative Information | Section 10.3.4 |
| 203 | Non-Authoritative Information | Section 10.3.4 | | 204 | No Content | Section 10.3.5 |
| 204 | No Content | Section 10.3.5 | | 205 | Reset Content | Section 10.3.6 |
| 205 | Reset Content | Section 10.3.6 | | 206 | Partial Content | Section 10.3.7 |
| 206 | Partial Content | Section 10.3.7 | | 300 | Multiple Choices | Section 10.4.1 |
| 300 | Multiple Choices | Section 10.4.1 | | 301 | Moved Permanently | Section 10.4.2 |
| 301 | Moved Permanently | Section 10.4.2 | | 302 | Found | Section 10.4.3 |
| 302 | Found | Section 10.4.3 | | 303 | See Other | Section 10.4.4 |
| 303 | See Other | Section 10.4.4 | | 304 | Not Modified | Section 10.4.5 |
| 304 | Not Modified | Section 10.4.5 | | 305 | Use Proxy | Section 10.4.6 |
| 305 | Use Proxy | Section 10.4.6 | | 306 | (Unused) | Section 10.4.7 |
| 306 | (Unused) | Section 10.4.7 | | 307 | Temporary Redirect | Section 10.4.8 |
| 307 | Temporary Redirect | Section 10.4.8 | | 308 | Permanent Redirect | Section 10.4.9 |
| 308 | Permanent Redirect | Section 10.4.9 | | 400 | Bad Request | Section 10.5.1 |
| 400 | Bad Request | Section 10.5.1 | | 401 | Unauthorized | Section 10.5.2 |
| 401 | Unauthorized | Section 10.5.2 | | 402 | Payment Required | Section 10.5.3 |
| 402 | Payment Required | Section 10.5.3 | | 403 | Forbidden | Section 10.5.4 |
| 403 | Forbidden | Section 10.5.4 | | 404 | Not Found | Section 10.5.5 |
| 404 | Not Found | Section 10.5.5 | | 405 | Method Not Allowed | Section 10.5.6 |
| 405 | Method Not Allowed | Section 10.5.6 | | 406 | Not Acceptable | Section 10.5.7 |
| 406 | Not Acceptable | Section 10.5.7 | | 407 | Proxy Authentication Required | Section 10.5.8 |
| 407 | Proxy Authentication Required | Section 10.5.8 | | 408 | Request Timeout | Section 10.5.9 |
| 408 | Request Timeout | Section 10.5.9 | | 409 | Conflict | Section 10.5.10 |
| 409 | Conflict | Section 10.5.10 | | 410 | Gone | Section 10.5.11 |
| 410 | Gone | Section 10.5.11 | | 411 | Length Required | Section 10.5.12 |
| 411 | Length Required | Section 10.5.12 | | 412 | Precondition Failed | Section 10.5.13 |
| 412 | Precondition Failed | Section 10.5.13 | | 413 | Payload Too Large | Section 10.5.14 |
| 413 | Payload Too Large | Section 10.5.14 | | 414 | URI Too Long | Section 10.5.15 |
| 414 | URI Too Long | Section 10.5.15 | | 415 | Unsupported Media Type | Section 10.5.16 |
| 415 | Unsupported Media Type | Section 10.5.16 | | 416 | Range Not Satisfiable | Section 10.5.17 |
| 416 | Range Not Satisfiable | Section 10.5.17 | | 417 | Expectation Failed | Section 10.5.18 |
| 417 | Expectation Failed | Section 10.5.18 | | 418 | (Unused) | Section 10.5.19 |
| 418 | (Unused) | Section 10.5.19 | | 422 | Unprocessable Payload | Section 10.5.20 |
| 422 | Unprocessable Payload | Section 10.5.20 | | 426 | Upgrade Required | Section 10.5.21 |
| 426 | Upgrade Required | Section 10.5.21 | | 500 | Internal Server Error | Section 10.6.1 |
| 500 | Internal Server Error | Section 10.6.1 | | 501 | Not Implemented | Section 10.6.2 |
| 501 | Not Implemented | Section 10.6.2 | | 502 | Bad Gateway | Section 10.6.3 |
| 502 | Bad Gateway | Section 10.6.3 | | 503 | Service Unavailable | Section 10.6.4 |
| 503 | Service Unavailable | Section 10.6.4 | | 504 | Gateway Timeout | Section 10.6.5 |
| 504 | Gateway Timeout | Section 10.6.5 | | 505 | HTTP Version Not Supported | Section 10.6.6 |
| 505 | HTTP Version Not Supported | Section 10.6.6 | +-------+-------------------------------+-----------------+
+-------+-------------------------------+------------------+
Table 6 Table 16
Note that this list is not exhaustive -- it does not include Note that this list is not exhaustive - it does not include extension
extension status codes defined in other specifications status codes defined in other specifications (Section 10.7).
(Section 10.7).
10.2. Informational 1xx 10.2. Informational 1xx
The 1xx (Informational) class of status code indicates an interim The 1xx (Informational) class of status code indicates an interim
response for communicating connection status or request progress response for communicating connection status or request progress
prior to completing the requested action and sending a final prior to completing the requested action and sending a final
response. 1xx responses are terminated by the end of the header response. 1xx responses are terminated by the end of the header
section. Since HTTP/1.0 did not define any 1xx status codes, a section. Since HTTP/1.0 did not define any 1xx status codes, a
server MUST NOT send a 1xx response to an HTTP/1.0 client. server MUST NOT send a 1xx response to an HTTP/1.0 client.
skipping to change at page 134, line 26 skipping to change at page 135, line 34
capable of representing the original target resource, as in the capable of representing the original target resource, as in the
300 (Multiple Choices) status code. 300 (Multiple Choices) status code.
3. Redirection to a different resource, identified by the Location 3. Redirection to a different resource, identified by the Location
field, that can represent an indirect response to the request, as field, that can represent an indirect response to the request, as
in the 303 (See Other) status code. in the 303 (See Other) status code.
4. Redirection to a previously cached result, as in the 304 (Not 4. Redirection to a previously cached result, as in the 304 (Not
Modified) status code. Modified) status code.
Note: In HTTP/1.0, the status codes 301 (Moved Permanently) and | *Note:* In HTTP/1.0, the status codes 301 (Moved Permanently)
302 (Found) were defined for the first type of redirect | and 302 (Found) were defined for the first type of redirect
([RFC1945], Section 9.3). Early user agents split on whether the | ([RFC1945], Section 9.3). Early user agents split on whether
method applied to the redirect target would be the same as the | the method applied to the redirect target would be the same as
original request or would be rewritten as GET. Although HTTP | the original request or would be rewritten as GET. Although
originally defined the former semantics for 301 and 302 (to match | HTTP originally defined the former semantics for 301 and 302
its original implementation at CERN), and defined 303 (See Other) | (to match its original implementation at CERN), and defined 303
to match the latter semantics, prevailing practice gradually | (See Other) to match the latter semantics, prevailing practice
converged on the latter semantics for 301 and 302 as well. The | gradually converged on the latter semantics for 301 and 302 as
first revision of HTTP/1.1 added 307 (Temporary Redirect) to | well. The first revision of HTTP/1.1 added 307 (Temporary
indicate the former semantics of 302 without being impacted by | Redirect) to indicate the former semantics of 302 without being
divergent practice. For the same reason, 308 (Permanent Redirect) | impacted by divergent practice. For the same reason, 308
was later on added in [RFC7538] to match 301. Over 10 years | (Permanent Redirect) was later on added in [RFC7538] to match
later, most user agents still do method rewriting for 301 and 302; | 301. Over 10 years later, most user agents still do method
therefore, [RFC7231] made that behavior conformant when the | rewriting for 301 and 302; therefore, [RFC7231] made that
original request is POST. | behavior conformant when the original request is POST.
A client SHOULD detect and intervene in cyclical redirections (i.e., A client SHOULD detect and intervene in cyclical redirections (i.e.,
"infinite" redirection loops). "infinite" redirection loops).
Note: An earlier version of this specification recommended a | *Note:* An earlier version of this specification recommended a
maximum of five redirections ([RFC2068], Section 10.3). Content | maximum of five redirections ([RFC2068], Section 10.3).
developers need to be aware that some clients might implement such | Content developers need to be aware that some clients might
a fixed limitation. | implement such a fixed limitation.
10.4.1. 300 Multiple Choices 10.4.1. 300 Multiple Choices
The 300 (Multiple Choices) status code indicates that the target The 300 (Multiple Choices) status code indicates that the target
resource has more than one representation, each with its own more resource has more than one representation, each with its own more
specific identifier, and information about the alternatives is being specific identifier, and information about the alternatives is being
provided so that the user (or user agent) can select a preferred provided so that the user (or user agent) can select a preferred
representation by redirecting its request to one or more of those representation by redirecting its request to one or more of those
identifiers. In other words, the server desires that the user agent identifiers. In other words, the server desires that the user agent
engage in reactive negotiation to select the most appropriate engage in reactive negotiation to select the most appropriate
skipping to change at page 135, line 45 skipping to change at page 136, line 42
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 heuristically cacheable; 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
URI header field as providing a list of alternative | the 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
However, lack of deployment and disagreement over syntax led to | method. However, lack of deployment and disagreement over
both URI and Alternates (a subsequent proposal) being dropped from | syntax led to both URI and Alternates (a subsequent proposal)
this specification. It is possible to communicate the list as a | being dropped from this specification. It is possible to
Link header field value [RFC8288] whose members have a | communicate the list as a Link header field value [RFC8288]
relationship of "alternate", though deployment is a chicken-and- | whose members have a relationship of "alternate", though
egg problem. | deployment is a chicken-and-egg problem.
10.4.2. 301 Moved Permanently 10.4.2. 301 Moved Permanently
The 301 (Moved Permanently) status code indicates that the target The 301 (Moved Permanently) status code indicates that the target
resource has been assigned a new permanent URI and any future resource has been assigned a new permanent URI and any future
references to this resource ought to use one of the enclosed URIs. references to this resource ought to use one of the enclosed URIs.
Clients with link-editing capabilities ought to automatically re-link Clients with link-editing capabilities ought to automatically re-link
references to the target URI to one or more of the new references references to the target URI to one or more of the new references
sent by the server, where possible. 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).
Note: For historical reasons, a user agent MAY change the request | *Note:* For historical reasons, a user agent MAY change the
method from POST to GET for the subsequent request. If this | request method from POST to GET for the subsequent request. If
behavior is undesired, the 308 (Permanent Redirect) status code | this behavior is undesired, the 308 (Permanent Redirect) status
can be used instead. | code can be used instead.
A 301 response is heuristically cacheable; 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]).
10.4.3. 302 Found 10.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
target URI for future requests. target URI for future requests.
The server SHOULD generate a Location header field in the response The server SHOULD generate a Location header field in the response
containing a URI reference for the different URI. The user agent MAY containing a URI reference for the different URI. The user agent MAY
use the Location field value for automatic redirection. The server's use the Location field value for automatic redirection. The server's
response payload usually contains a short hypertext note with a response payload usually contains a short hypertext note with a
hyperlink to the different URI(s). hyperlink to the different URI(s).
Note: For historical reasons, a user agent MAY change the request | *Note:* For historical reasons, a user agent MAY change the
method from POST to GET for the subsequent request. If this | request method from POST to GET for the subsequent request. If
behavior is undesired, the 307 (Temporary Redirect) status code | this behavior is undesired, the 307 (Temporary Redirect) status
can be used instead. | code can be used instead.
10.4.4. 303 See Other 10.4.4. 303 See Other
The 303 (See Other) status code indicates that the server is The 303 (See Other) status code indicates that the server is
redirecting the user agent to a different resource, as indicated by a redirecting the user agent to a different resource, as indicated by a
URI in the Location header field, which is intended to provide an URI in the Location header field, which is intended to provide an
indirect response to the original request. A user agent can perform indirect response to the original request. A user agent can perform
a retrieval request targeting that URI (a GET or HEAD request if a retrieval request targeting that URI (a GET or HEAD request if
using HTTP), which might also be redirected, and present the eventual using HTTP), which might also be redirected, and present the eventual
result as an answer to the original request. Note that the new URI result as an answer to the original request. Note that the new URI
skipping to change at page 139, line 24 skipping to change at page 140, line 24
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 heuristically cacheable; 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.
Section 4 of [RFC7538] for deployment considerations. | See Section 4 of [RFC7538] for deployment considerations.
10.5. Client Error 4xx 10.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
seems to have erred. Except when responding to a HEAD request, the seems to have erred. Except when responding to a HEAD request, the
server SHOULD send a representation containing an explanation of the server SHOULD send a representation containing an explanation of the
error situation, and whether it is a temporary or permanent error situation, and whether it is a temporary or permanent
condition. These status codes are applicable to any request method. condition. These status codes are applicable to any request method.
User agents SHOULD display any included representation to the user. User agents SHOULD display any included representation to the user.
skipping to change at page 141, line 40 skipping to change at page 142, line 40
not define any standard for such automatic selection, as described in not define any standard for such automatic selection, as described in
Section 10.4.1. Section 10.4.1.
10.5.8. 407 Proxy Authentication Required 10.5.8. 407 Proxy Authentication Required
The 407 (Proxy Authentication Required) status code is similar to 401 The 407 (Proxy Authentication Required) status code is similar to 401
(Unauthorized), but it indicates that the client needs to (Unauthorized), but it indicates that the client needs to
authenticate itself in order to use a proxy for this request. The authenticate itself in order to use a proxy for this request. The
proxy MUST send a Proxy-Authenticate header field (Section 11.3.2) proxy MUST send a Proxy-Authenticate header field (Section 11.3.2)
containing a challenge applicable to that proxy for the request. The containing a challenge applicable to that proxy for the request. The
client MAY repeat the request with a new or replaced Proxy- client MAY repeat the request with a new or replaced
Authorization header field (Section 9.5.4). Proxy-Authorization header field (Section 9.5.4).
10.5.9. 408 Request Timeout 10.5.9. 408 Request Timeout
The 408 (Request Timeout) status code indicates that the server did The 408 (Request Timeout) status code indicates that the server did
not receive a complete request message within the time that it was not receive a complete request message within the time that it was
prepared to wait. If the client has an outstanding request in prepared to wait. If the client has an outstanding request in
transit, the client MAY repeat that request on a new connection. transit, the client MAY repeat that request on a new connection.
10.5.10. 409 Conflict 10.5.10. 409 Conflict
skipping to change at page 142, line 38 skipping to change at page 143, line 38
is permanent, the status code 404 (Not Found) ought to be used is permanent, the status code 404 (Not Found) ought to be used
instead. instead.
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 heuristically cacheable; 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]).
10.5.12. 411 Length Required 10.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
skipping to change at page 143, line 22 skipping to change at page 144, line 22
from being applied if the target resource is in an unexpected state. from being applied if the target resource is in an unexpected state.
10.5.14. 413 Payload Too Large 10.5.14. 413 Payload Too Large
The 413 (Payload Too Large) status code indicates that the server is The 413 (Payload Too Large) status code indicates that the server is
refusing to process a request because the request payload is larger refusing to process a request because the request payload is larger
than the server is willing or able to process. The server MAY than the server is willing or able to process. The server MAY
terminate the request, if the protocol version in use allows it; terminate the request, if the protocol version in use allows it;
otherwise, the server MAY close the connection. otherwise, the server MAY close the connection.
If the condition is temporary, the server SHOULD generate a Retry- If the condition is temporary, the server SHOULD generate a
After header field to indicate that it is temporary and after what Retry-After header field to indicate that it is temporary and after
time the client MAY try again. what time the client MAY try again.
10.5.15. 414 URI Too Long 10.5.15. 414 URI Too Long
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 target URI is longer than refusing to service the request because the target URI is longer than
the server is willing to interpret. This rare condition is only the server is willing to interpret. This rare condition is only
likely to occur when a client has improperly converted a POST request likely to occur when a client has improperly converted a POST request
to a GET request with long query information, when the client has to a GET request with long query information, when the client has
descended into a "black hole" of redirection (e.g., a redirected URI descended into a "black hole" of redirection (e.g., a redirected URI
prefix that points to a suffix of itself) or when the server is under prefix that points to a suffix of itself) or when the server is under
skipping to change at page 143, line 47 skipping to change at page 144, line 47
A 414 response is heuristically cacheable; 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]).
10.5.16. 415 Unsupported Media Type 10.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
Type or Content-Encoding, or as a result of inspecting the data Content-Type or Content-Encoding, or as a result of inspecting the
directly. data directly.
If the problem was caused by an unsupported content coding, the If the problem was caused by an unsupported content coding, the
Accept-Encoding response header field (Section 9.4.3) ought to be Accept-Encoding response header field (Section 9.4.3) ought to be
used to indicate what (if any) content codings would have been used to indicate what (if any) content codings would have been
accepted in the request. accepted in the request.
On the other hand, if the cause was an unsupported media type, the On the other hand, if the cause was an unsupported media type, the
Accept response header field (Section 9.4.1) can be used to indicate Accept response header field (Section 9.4.1) can be used to indicate
what media types would have been accepted in the request. what media types would have been accepted in the request.
skipping to change at page 144, line 34 skipping to change at page 145, line 37
request, the sender SHOULD generate a Content-Range header field request, the sender SHOULD generate a Content-Range header field
specifying the current length of the selected representation specifying the current length of the selected representation
(Section 7.3.4). (Section 7.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 respond with the entire selected | implementations will 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
most clients are prepared to receive a 200 (OK) to complete the | most clients are prepared to receive a 200 (OK) to complete the
task (albeit less efficiently) and partly because clients might | task (albeit less efficiently) and partly because clients might
not stop making an invalid partial request until they have | not stop making an invalid partial request until they have
received a complete representation. Thus, clients cannot depend | received a complete representation. Thus, clients cannot
on receiving a 416 (Range Not Satisfiable) response even when it | depend on receiving a 416 (Range Not Satisfiable) response even
is most appropriate. | when it is most appropriate.
10.5.18. 417 Expectation Failed 10.5.18. 417 Expectation Failed
The 417 (Expectation Failed) status code indicates that the The 417 (Expectation Failed) status code indicates that the
expectation given in the request's Expect header field expectation given in the request's Expect header field
(Section 9.1.1) could not be met by at least one of the inbound (Section 9.1.1) could not be met by at least one of the inbound
servers. servers.
10.5.19. 418 (Unused) 10.5.19. 418 (Unused)
skipping to change at page 146, line 42 skipping to change at page 147, line 48
10.6.4. 503 Service Unavailable 10.6.4. 503 Service Unavailable
The 503 (Service Unavailable) status code indicates that the server The 503 (Service Unavailable) status code indicates that the server
is currently unable to handle the request due to a temporary overload is currently unable to handle the request due to a temporary overload
or scheduled maintenance, which will likely be alleviated after some or scheduled maintenance, which will likely be alleviated after some
delay. The server MAY send a Retry-After header field delay. The server MAY send a Retry-After header field
(Section 11.1.3) to suggest an appropriate amount of time for the (Section 11.1.3) to suggest an appropriate amount of time for the
client to wait before retrying the request. client to wait before retrying the request.
Note: The existence of the 503 status code does not imply that a | *Note:* The existence of the 503 status code does not imply
server has to use it when becoming overloaded. Some servers might | that a server has to use it when becoming overloaded. Some
simply refuse the connection. | servers might simply refuse the connection.
10.6.5. 504 Gateway Timeout 10.6.5. 504 Gateway Timeout
The 504 (Gateway Timeout) status code indicates that the server, The 504 (Gateway Timeout) status code indicates that the server,
while acting as a gateway or proxy, did not receive a timely response while acting as a gateway or proxy, did not receive a timely response
from an upstream server it needed to access in order to complete the from an upstream server it needed to access in order to complete the
request. request.
10.6.6. 505 HTTP Version Not Supported 10.6.6. 505 HTTP Version Not Supported
skipping to change at page 148, line 23 skipping to change at page 149, line 36
The definition of a new status code ought to explain the request The definition of a new status code ought to explain the request
conditions that would cause a response containing that status code conditions that would cause a response containing that status code
(e.g., combinations of request header fields and/or method(s)) along (e.g., combinations of request header fields and/or method(s)) along
with any dependencies on response header fields (e.g., what fields with any dependencies on response header fields (e.g., what fields
are required, what fields can modify the semantics, and what field are required, what fields can modify the semantics, and what field
semantics are further refined when used with the new status code). semantics are further refined when used with the new status code).
By default, a status code applies only to the request corresponding By default, a status code applies only to the request corresponding
to the response it occurs within. If a status code applies to a to the response it occurs within. If a status code applies to a
larger scope of applicability -- for example, all requests to the larger scope of applicability - for example, all requests to the
resource in question, or all requests to a server -- this must be resource in question, or all requests to a server - this must be
explicitly specified. When doing so, it should be noted that not all explicitly specified. When doing so, it should be noted that not all
clients can be expected to consistently apply a larger scope, because clients can be expected to consistently apply a larger scope, because
they might not understand the new status code. they might not understand the new status code.
The definition of a new status code ought to specify whether or not The definition of a new status code ought to specify whether or not
it is cacheable. Note that all status codes can be cached if the it is cacheable. Note that all status codes can be cached if the
response they occur in has explicit freshness information; however, response they occur in has explicit freshness information; however,
status codes that are defined as being cacheable are allowed to be status codes that are defined as being cacheable are allowed to be
cached without explicit freshness information. Likewise, the cached without explicit freshness information. Likewise, the
definition of a status code can place constraints upon cache definition of a status code can place constraints upon cache
skipping to change at page 149, line 13 skipping to change at page 150, line 24
semantics of the request method and/or response status code. semantics of the request method and/or response status code.
11.1. Control Data 11.1. Control Data
Response header fields can supply control data that supplements the Response header fields can supply control data that supplements the
status code, directs caching, or instructs the client where to go status code, directs caching, or instructs the client where to go
next. next.
+---------------+--------------------------+ +---------------+--------------------------+
| Field Name | Defined in... | | Field Name | Defined in... |
+---------------+--------------------------+
| Age | Section 5.1 of [Caching] | | Age | Section 5.1 of [Caching] |
| Cache-Control | Section 5.2 of [Caching] | | Cache-Control | Section 5.2 of [Caching] |
| Expires | Section 5.3 of [Caching] | | Expires | Section 5.3 of [Caching] |
| Date | Section 11.1.1 | | Date | Section 11.1.1 |
| Location | Section 11.1.2 | | Location | Section 11.1.2 |
| Retry-After | Section 11.1.3 | | Retry-After | Section 11.1.3 |
| Vary | Section 11.1.4 | | Vary | Section 11.1.4 |
| Warning | Section 5.5 of [Caching] | | Warning | Section 5.5 of [Caching] |
+---------------+--------------------------+ +---------------+--------------------------+
Table 17
11.1.1. Date 11.1.1. Date
The "Date" header field represents the date and time at which the The "Date" header field represents the date and time at which the
message was originated, having the same semantics as the Origination message was originated, having the same semantics as the Origination
Date Field (orig-date) defined in Section 3.6.1 of [RFC5322]. The Date Field (orig-date) defined in Section 3.6.1 of [RFC5322]. The
field value is an HTTP-date, as defined in Section 5.4.1.5. field value is an HTTP-date, as defined in Section 5.4.1.5.
Date = HTTP-date Date = HTTP-date
An example is An example is
skipping to change at page 151, line 16 skipping to change at page 152, line 35
which suggests that the user agent redirect to which suggests that the user agent redirect to
"http://www.example.net/index.html#larry", preserving the original "http://www.example.net/index.html#larry", preserving the original
fragment identifier. fragment identifier.
There are circumstances in which a fragment identifier in a Location There are circumstances in which a fragment identifier in a Location
value would not be appropriate. For example, the Location header value would not be appropriate. For example, the Location header
field in a 201 (Created) response is supposed to provide a URI that field in a 201 (Created) response is supposed to provide a URI that
is specific to the created resource. is specific to the created resource.
Note: Some recipients attempt to recover from Location fields that | *Note:* Some recipients attempt to recover from Location fields
are not valid URI references. This specification does not mandate | that are not valid URI references. This specification does not
or define such processing, but does allow it for the sake of | mandate or define such processing, but does allow it for the
robustness. | sake of robustness.
Note: The Content-Location header field (Section 7.2.5) differs | *Note:* The Content-Location header field (Section 7.2.5)
from Location in that the Content-Location refers to the most | differs from Location in that the Content-Location refers to
specific resource corresponding to the enclosed representation. | the most specific resource corresponding to the enclosed
It is therefore possible for a response to contain both the | representation. It is therefore possible for a response to
Location and Content-Location header fields. | contain both the Location and Content-Location header fields.
11.1.3. Retry-After 11.1.3. Retry-After
Servers send the "Retry-After" header field to indicate how long the Servers send the "Retry-After" header field to indicate how long the
user agent ought to wait before making a follow-up request. When user agent ought to wait before making a follow-up request. When
sent with a 503 (Service Unavailable) response, Retry-After indicates sent with a 503 (Service Unavailable) response, Retry-After indicates
how long the service is expected to be unavailable to the client. how long the service is expected to be unavailable to the client.
When sent with any 3xx (Redirection) response, Retry-After indicates When sent with any 3xx (Redirection) response, Retry-After indicates
the minimum time that the user agent is asked to wait before issuing the minimum time that the user agent is asked to wait before issuing
the redirected request. the redirected request.
skipping to change at page 153, line 38 skipping to change at page 155, line 12
fields describe the new representation that has replaced the prior fields describe the new representation that has replaced the prior
selected representation as a result of processing the request. selected representation as a result of processing the request.
For example, an ETag field in a 201 (Created) response communicates For example, an ETag field in a 201 (Created) response communicates
the entity-tag of the newly created resource's representation, so the entity-tag of the newly created resource's representation, so
that it can be used in later conditional requests to prevent the that it can be used in later conditional requests to prevent the
"lost update" problem Section 9.2. "lost update" problem Section 9.2.
+---------------+----------------+ +---------------+----------------+
| Field Name | Defined in... | | Field Name | Defined in... |
+---------------+----------------+
| ETag | Section 11.2.3 | | ETag | Section 11.2.3 |
| Last-Modified | Section 11.2.2 | | Last-Modified | Section 11.2.2 |
+---------------+----------------+ +---------------+----------------+
Table 18
This specification defines two forms of metadata that are commonly This specification defines two forms of metadata that are commonly
used to observe resource state and test for preconditions: used to observe resource state and test for preconditions:
modification dates (Section 11.2.2) and opaque entity tags modification dates (Section 11.2.2) and opaque entity tags
(Section 11.2.3). Additional metadata that reflects resource state (Section 11.2.3). Additional metadata that reflects resource state
has been defined by various extensions of HTTP, such as Web has been defined by various extensions of HTTP, such as Web
Distributed Authoring and Versioning (WebDAV, [RFC4918]), that are Distributed Authoring and Versioning (WebDAV, [RFC4918]), that are
beyond the scope of this specification. A resource metadata value is beyond the scope of this specification. A resource metadata value is
referred to as a "validator" when it is used within a precondition. referred to as a "validator" when it is used within a precondition.
11.2.1. Weak versus Strong 11.2.1. Weak versus Strong
skipping to change at page 157, line 11 skipping to change at page 158, line 32
o The validator is being compared by an origin server to the actual o The validator is being compared by an origin server to the actual
current validator for the representation and, current validator for the representation and,
o That origin server reliably knows that the associated o That origin server reliably knows that the associated
representation did not change twice during the second covered by representation did not change twice during the second covered by
the presented validator. the presented validator.
or or
o The validator is about to be used by a client in an If-Modified- o The validator is about to be used by a client in an
Since, If-Unmodified-Since, or If-Range header field, because the If-Modified-Since, If-Unmodified-Since, or If-Range header field,
client has a cache entry for the associated representation, and because the client has a cache entry for the associated
representation, and
o That cache entry includes a Date value, which gives the time when o That cache entry includes a Date value, which gives the time when
the origin server sent the original response, and the origin server sent the original response, and
o The presented Last-Modified time is at least 60 seconds before the o The presented Last-Modified time is at least 60 seconds before the
Date value. Date value.
or or
o The validator is being compared by an intermediate cache to the o The validator is being compared by an intermediate cache to the
skipping to change at page 158, line 13 skipping to change at page 159, line 35
prefixed by a weakness indicator. prefixed by a weakness indicator.
ETag = entity-tag ETag = entity-tag
entity-tag = [ weak ] opaque-tag entity-tag = [ weak ] opaque-tag
weak = %s"W/" weak = %s"W/"
opaque-tag = DQUOTE *etagc DQUOTE opaque-tag = DQUOTE *etagc DQUOTE
etagc = %x21 / %x23-7E / obs-text etagc = %x21 / %x23-7E / obs-text
; VCHAR except double quotes, plus obs-text ; VCHAR except double quotes, plus obs-text
Note: Previously, opaque-tag was defined to be a quoted-string | *Note:* Previously, opaque-tag was defined to be a quoted-
([RFC2616], Section 3.11); thus, some recipients might perform | string ([RFC2616], Section 3.11); thus, some recipients might
backslash unescaping. Servers therefore ought to avoid backslash | perform backslash unescaping. Servers therefore ought to avoid
characters in entity tags. | backslash characters in entity tags.
An entity-tag can be more reliable for validation than a modification An entity-tag can be more reliable for validation than a modification
date in situations where it is inconvenient to store modification date in situations where it is inconvenient to store modification
dates, where the one-second resolution of HTTP date values is not dates, where the one-second resolution of HTTP date values is not
sufficient, or where modification dates are not consistently sufficient, or where modification dates are not consistently
maintained. maintained.
Examples: Examples:
ETag: "xyzzy" ETag: "xyzzy"
skipping to change at page 159, line 34 skipping to change at page 161, line 10
o Weak comparison: two entity-tags are equivalent if their opaque- o Weak comparison: two entity-tags are equivalent if their opaque-
tags match character-by-character, regardless of either or both tags match character-by-character, regardless of either or both
being tagged as "weak". being tagged as "weak".
The example below shows the results for a set of entity-tag pairs and The example below shows the results for a set of entity-tag pairs and
both the weak and strong comparison function results: both the weak and strong comparison function results:
+--------+--------+-------------------+-----------------+ +--------+--------+-------------------+-----------------+
| ETag 1 | ETag 2 | Strong Comparison | Weak Comparison | | ETag 1 | ETag 2 | Strong Comparison | Weak Comparison |
+--------+--------+-------------------+-----------------+
| W/"1" | W/"1" | no match | match | | W/"1" | W/"1" | no match | match |
| W/"1" | W/"2" | no match | no match | | W/"1" | W/"2" | no match | no match |
| W/"1" | "1" | no match | match | | W/"1" | "1" | no match | match |
| "1" | "1" | match | match | | "1" | "1" | match | match |
+--------+--------+-------------------+-----------------+ +--------+--------+-------------------+-----------------+
Table 19
11.2.3.3. Example: Entity-Tags Varying on Content-Negotiated Resources 11.2.3.3. Example: Entity-Tags Varying on Content-Negotiated Resources
Consider a resource that is subject to content negotiation Consider a resource that is subject to content negotiation
(Section 7.4), and where the representations sent in response to a (Section 7.4), and where the representations sent in response to a
GET request vary based on the Accept-Encoding request header field GET request vary based on the Accept-Encoding request header field
(Section 9.4.3): (Section 9.4.3):
>> Request: >> Request:
GET /index HTTP/1.1 GET /index HTTP/1.1
skipping to change at page 160, line 42 skipping to change at page 162, line 17
HTTP/1.1 200 OK HTTP/1.1 200 OK
Date: Fri, 26 Mar 2010 00:05:00 GMT Date: Fri, 26 Mar 2010 00:05:00 GMT
ETag: "123-b" ETag: "123-b"
Content-Length: 43 Content-Length: 43
Vary: Accept-Encoding Vary: Accept-Encoding
Content-Type: text/plain Content-Type: text/plain
Content-Encoding: gzip Content-Encoding: gzip
...binary data... ...binary data...
Note: Content codings are a property of the representation data, | *Note:* Content codings are a property of the representation
so a strong entity-tag for a content-encoded representation has to | data, so a strong entity-tag for a content-encoded
be distinct from the entity tag of an unencoded representation to | representation has to be distinct from the entity tag of an
prevent potential conflicts during cache updates and range | unencoded representation to prevent potential conflicts during
requests. In contrast, transfer codings (Section 7 of | cache updates and range requests. In contrast, transfer
[Messaging]) apply only during message transfer and do not result | codings (Section 7 of [Messaging]) apply only during message
in distinct entity-tags. | transfer and do not result in distinct entity-tags.
11.2.4. When to Use Entity-Tags and Last-Modified Dates 11.2.4. When to Use Entity-Tags and Last-Modified Dates
In 200 (OK) responses to GET or HEAD, an origin server: In 200 (OK) responses to GET or HEAD, an origin server:
o SHOULD send an entity-tag validator unless it is not feasible to o SHOULD send an entity-tag validator unless it is not feasible to
generate one. generate one.
o MAY send a weak entity-tag instead of a strong entity-tag, if o MAY send a weak entity-tag instead of a strong entity-tag, if
performance considerations support the use of weak entity-tags, or performance considerations support the use of weak entity-tags, or
skipping to change at page 161, line 49 skipping to change at page 163, line 22
origin server. This allows both HTTP/1.0 and HTTP/1.1 caches to origin server. This allows both HTTP/1.0 and HTTP/1.1 caches to
respond appropriately. respond appropriately.
11.3. Authentication Challenges 11.3. Authentication Challenges
Authentication challenges indicate what mechanisms are available for Authentication challenges indicate what mechanisms are available for
the client to provide authentication credentials in future requests. the client to provide authentication credentials in future requests.
+--------------------+----------------+ +--------------------+----------------+
| Field Name | Defined in... | | Field Name | Defined in... |
+--------------------+----------------+
| WWW-Authenticate | Section 11.3.1 | | WWW-Authenticate | Section 11.3.1 |
| Proxy-Authenticate | Section 11.3.2 | | Proxy-Authenticate | Section 11.3.2 |
+--------------------+----------------+ +--------------------+----------------+
Table 20
Furthermore, the "Authentication-Info" and "Proxy-Authentication- Furthermore, the "Authentication-Info" and "Proxy-Authentication-
Info" response header fields are defined for use in authentication Info" response header fields are defined for use in authentication
schemes that need to return information once the client's schemes that need to return information once the client's
authentication credentials have been accepted. authentication credentials have been accepted.
+---------------------------+----------------+ +---------------------------+----------------+
| Field Name | Defined in... | | Field Name | Defined in... |
+---------------------------+----------------+
| Authentication-Info | Section 11.3.3 | | Authentication-Info | Section 11.3.3 |
| Proxy-Authentication-Info | Section 11.3.4 | | Proxy-Authentication-Info | Section 11.3.4 |
+---------------------------+----------------+ +---------------------------+----------------+
Table 21
11.3.1. WWW-Authenticate 11.3.1. WWW-Authenticate
The "WWW-Authenticate" header field indicates the authentication The "WWW-Authenticate" header field indicates the authentication
scheme(s) and parameters applicable to the target resource. scheme(s) and parameters applicable to the target resource.
WWW-Authenticate = 1#challenge WWW-Authenticate = 1#challenge
A server generating a 401 (Unauthorized) response MUST send a WWW- A server generating a 401 (Unauthorized) response MUST send a WWW-
Authenticate header field containing at least one challenge. A Authenticate header field containing at least one challenge. A
server MAY generate a WWW-Authenticate header field in other response server MAY generate a WWW-Authenticate header field in other response
skipping to change at page 162, line 48 skipping to change at page 164, line 24
For instance: For instance:
WWW-Authenticate: Newauth realm="apps", type=1, WWW-Authenticate: Newauth realm="apps", type=1,
title="Login to \"apps\"", Basic realm="simple" title="Login to \"apps\"", Basic realm="simple"
This header field contains two challenges; one for the "Newauth" This header field contains two challenges; one for the "Newauth"
scheme with a realm value of "apps", and two additional parameters scheme with a realm value of "apps", and two additional parameters
"type" and "title", and another one for the "Basic" scheme with a "type" and "title", and another one for the "Basic" scheme with a
realm value of "simple". realm value of "simple".
Note: The challenge grammar production uses the list syntax as | *Note:* The challenge grammar production uses the list syntax
well. Therefore, a sequence of comma, whitespace, and comma can | as well. Therefore, a sequence of comma, whitespace, and comma
be considered either as applying to the preceding challenge, or to | can be considered either as applying to the preceding
be an empty entry in the list of challenges. In practice, this | challenge, or to be an empty entry in the list of challenges.
ambiguity does not affect the semantics of the header field value | In practice, this ambiguity does not affect the semantics of
and thus is harmless. | the header field value and thus is harmless.
11.3.2. Proxy-Authenticate 11.3.2. Proxy-Authenticate
The "Proxy-Authenticate" header field consists of at least one The "Proxy-Authenticate" header field consists of at least one
challenge that indicates the authentication scheme(s) and parameters challenge that indicates the authentication scheme(s) and parameters
applicable to the proxy for this request. A proxy MUST send at least applicable to the proxy for this request. A proxy MUST send at least
one Proxy-Authenticate header field in each 407 (Proxy Authentication one Proxy-Authenticate header field in each 407 (Proxy Authentication
Required) response that it generates. Required) response that it generates.
Proxy-Authenticate = 1#challenge Proxy-Authenticate = 1#challenge
skipping to change at page 165, line 12 skipping to change at page 166, line 34
Proxy-Authentication-Info is being forwarded because each proxy will Proxy-Authentication-Info is being forwarded because each proxy will
send the same field value. send the same field value.
11.4. Response Context 11.4. Response Context
The remaining response header fields provide more information about The remaining response header fields provide more information about
the target resource for potential use in later requests. the target resource for potential use in later requests.
+---------------+----------------+ +---------------+----------------+
| Field Name | Defined in... | | Field Name | Defined in... |
+---------------+----------------+
| Accept-Ranges | Section 11.4.1 | | Accept-Ranges | Section 11.4.1 |
| Allow | Section 11.4.2 | | Allow | Section 11.4.2 |
| Server | Section 11.4.3 | | Server | Section 11.4.3 |
+---------------+----------------+ +---------------+----------------+
Table 22
11.4.1. Accept-Ranges 11.4.1. Accept-Ranges
The "Accept-Ranges" header field allows a server to indicate that it The "Accept-Ranges" header field allows a server to indicate that it
supports range requests for the target resource. supports range requests for the target resource.
Accept-Ranges = acceptable-ranges Accept-Ranges = acceptable-ranges
acceptable-ranges = 1#range-unit / "none" acceptable-ranges = 1#range-unit / "none"
An origin server that supports byte-range requests for a given target An origin server that supports byte-range requests for a given target
resource MAY send resource MAY send
skipping to change at page 166, line 14 skipping to change at page 167, line 36
Allow: GET, HEAD, PUT Allow: GET, HEAD, PUT
The actual set of allowed methods is defined by the origin server at The actual set of allowed methods is defined by the origin server at
the time of each request. An origin server MUST generate an Allow the time of each request. An origin server MUST generate an Allow
field in a 405 (Method Not Allowed) response and MAY do so in any field in a 405 (Method Not Allowed) response and MAY do so in any
other response. An empty Allow field value indicates that the other response. An empty Allow field value indicates that the
resource allows no methods, which might occur in a 405 response if resource allows no methods, which might occur in a 405 response if
the resource has been temporarily disabled by configuration. the resource has been temporarily disabled by configuration.
A proxy MUST NOT modify the Allow header field -- it does not need to A proxy MUST NOT modify the Allow header field - it does not need to
understand all of the indicated methods in order to handle them understand all of the indicated methods in order to handle them
according to the generic message handling rules. according to the generic message handling rules.
11.4.3. Server 11.4.3. Server
The "Server" header field contains information about the software The "Server" header field contains information about the software
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
skipping to change at page 178, line 44 skipping to change at page 180, line 35
1. use this document as "Reference", and 1. use this document as "Reference", and
2. when currently unspecified, set "Assignee" to "IESG" and 2. when currently unspecified, set "Assignee" to "IESG" and
"Contact" to "IETF_Chair". "Contact" to "IETF_Chair".
14. References 14. References
14.1. Normative References 14.1. Normative References
[Caching] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [Caching] Fielding, R., Ed., Nottingham, M., Ed., and J. F. Reschke,
Ed., "HTTP Caching", draft-ietf-httpbis-cache-09 (work in Ed., "HTTP Caching", Work in Progress, Internet-Draft,
progress), July 2020. draft-ietf-httpbis-cache-10, July 12, 2020,
<https://tools.ietf.org/html/draft-ietf-httpbis-cache-10>.
[Messaging] [Messaging]
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Fielding, R., Ed., Nottingham, M., Ed., and J. F. Reschke,
Ed., "HTTP/1.1 Messaging", draft-ietf-httpbis-messaging-09 Ed., "HTTP/1.1 Messaging", Work in Progress, Internet-
(work in progress), July 2020. Draft, draft-ietf-httpbis-messaging-10, July 12, 2020,
<https://tools.ietf.org/html/draft-ietf-httpbis-messaging-
10>.
[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.P. and J-L. Gailly, "ZLIB Compressed Data
Specification version 3.3", RFC 1950, Format 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>.
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification
version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996, version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996,
<https://www.rfc-editor.org/info/rfc1951>. <https://www.rfc-editor.org/info/rfc1951>.
[RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G. [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L.P., and
Randers-Pehrson, "GZIP file format specification version G. Randers-Pehrson, "GZIP file format specification
4.3", RFC 1952, DOI 10.17487/RFC1952, May 1996, version 4.3", RFC 1952, DOI 10.17487/RFC1952, May 1996,
<https://www.rfc-editor.org/info/rfc1952>. <https://www.rfc-editor.org/info/rfc1952>.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2045] Freed, N. and N.S. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
<https://www.rfc-editor.org/info/rfc2045>. <https://www.rfc-editor.org/info/rfc2045>.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, Extensions (MIME) Part Two: Media Types", RFC 2046,
DOI 10.17487/RFC2046, November 1996, DOI 10.17487/RFC2046, November 1996,
<https://www.rfc-editor.org/info/rfc2046>. <https://www.rfc-editor.org/info/rfc2046>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 180, line 37 skipping to change at page 182, line 32
<https://www.rfc-editor.org/info/rfc7405>. <https://www.rfc-editor.org/info/rfc7405>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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., "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 14.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>.
skipping to change at page 181, line 14 skipping to change at page 183, line 9
[BCP35] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines [BCP35] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines
and Registration Procedures for URI Schemes", BCP 35, and Registration Procedures for URI Schemes", BCP 35,
RFC 7595, June 2015, RFC 7595, June 2015,
<https://www.rfc-editor.org/info/bcp35>. <https://www.rfc-editor.org/info/bcp35>.
[Bujlow] Bujlow, T., Carela-Espanol, V., Sole-Pareta, J., and P. [Bujlow] Bujlow, T., Carela-Espanol, V., Sole-Pareta, J., and P.
Barlet-Ros, "A Survey on Web Tracking: Mechanisms, Barlet-Ros, "A Survey on Web Tracking: Mechanisms,
Implications, and Defenses", Implications, and Defenses",
DOI 10.1109/JPROC.2016.2637878, Proceedings of the DOI 10.1109/JPROC.2016.2637878, Proceedings of the
IEEE 105(8), August 2017. IEEE 105(8), August 2017,
<https://doi.org/10.1109/JPROC.2016.2637878>.
[Err1912] RFC Errata, Erratum ID 1912, RFC 2978, [Err1912] RFC Errata, Erratum ID 1912, RFC 2978,
<https://www.rfc-editor.org/errata/eid1912>. <https://www.rfc-editor.org/errata/eid1912>.
[Err5433] RFC Errata, Erratum ID 5433, RFC 2978, [Err5433] RFC Errata, Erratum ID 5433, RFC 2978,
<https://www.rfc-editor.org/errata/eid5433>. <https://www.rfc-editor.org/errata/eid5433>.
[Georgiev] [Georgiev] Georgiev, M., Iyengar, S., Jana, S., Anubhai, R., Boneh,
Georgiev, M., Iyengar, S., Jana, S., Anubhai, R., Boneh,
D., and V. Shmatikov, "The Most Dangerous Code in the D., and V. Shmatikov, "The Most Dangerous Code in the
World: Validating SSL Certificates in Non-browser World: Validating SSL Certificates in Non-browser
Software", DOI 10.1145/2382196.2382204, In Proceedings of Software", DOI 10.1145/2382196.2382204, In Proceedings of
the 2012 ACM Conference on Computer and Communications the 2012 ACM Conference on Computer and Communications
Security (CCS '12), pp. 38-49, October 2012. Security (CCS '12), pp. 38-49, October 2012,
<https://doi.org/10.1145/2382196.2382204>.
[ISO-8859-1] [ISO-8859-1]
International Organization for Standardization, International Organization for Standardization,
"Information technology -- 8-bit single-byte coded graphic "Information technology -- 8-bit single-byte coded graphic
character sets -- Part 1: Latin alphabet No. 1", ISO/ character sets -- Part 1: Latin alphabet No. 1", ISO/
IEC 8859-1:1998, 1998. IEC 8859-1:1998, 1998.
[Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and [Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and
Politics", ACM Transactions on Internet Technology 1(2), Politics", ACM Transactions on Internet Technology 1(2),
November 2001, <http://arxiv.org/abs/cs.SE/0105018>. November 2001, <http://arxiv.org/abs/cs.SE/0105018>.
[OWASP] van der Stock, A., Ed., "A Guide to Building Secure Web [OWASP] van der Stock, A., Ed., "A Guide to Building Secure Web
Applications and Web Services", The Open Web Application Applications and Web Services", The Open Web Application
Security Project (OWASP) 2.0.1, July 2005, Security Project (OWASP) 2.0.1, July 27, 2005,
<https://www.owasp.org/>. <https://www.owasp.org/>.
[REST] Fielding, R., "Architectural Styles and the Design of [REST] Fielding, R.T., "Architectural Styles and the Design of
Network-based Software Architectures", Network-based Software Architectures",
Doctoral Dissertation, University of California, Irvine, Doctoral Dissertation, University of California, Irvine,
September 2000, September 2000,
<https://roy.gbiv.com/pubs/dissertation/top.htm>. <https://roy.gbiv.com/pubs/dissertation/top.htm>.
[RFC1919] Chatel, M., "Classical versus Transparent IP Proxies", [RFC1919] Chatel, M., "Classical versus Transparent IP Proxies",
RFC 1919, DOI 10.17487/RFC1919, March 1996, RFC 1919, DOI 10.17487/RFC1919, March 1996,
<https://www.rfc-editor.org/info/rfc1919>. <https://www.rfc-editor.org/info/rfc1919>.
[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext [RFC1945] Berners-Lee, T., Fielding, R.T., and H.F. Nielsen,
Transfer Protocol -- HTTP/1.0", RFC 1945, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945,
DOI 10.17487/RFC1945, May 1996, DOI 10.17487/RFC1945, May 1996,
<https://www.rfc-editor.org/info/rfc1945>. <https://www.rfc-editor.org/info/rfc1945>.
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII Text", Part Three: Message Header Extensions for Non-ASCII Text",
RFC 2047, DOI 10.17487/RFC2047, November 1996, RFC 2047, DOI 10.17487/RFC2047, November 1996,
<https://www.rfc-editor.org/info/rfc2047>. <https://www.rfc-editor.org/info/rfc2047>.
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
RFC 2068, DOI 10.17487/RFC2068, January 1997, RFC 2068, DOI 10.17487/RFC2068, January 1997,
<https://www.rfc-editor.org/info/rfc2068>. <https://www.rfc-editor.org/info/rfc2068>.
[RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use [RFC2145] Mogul, J.C., Fielding, R.T., Gettys, J., and H.F. Nielsen,
and Interpretation of HTTP Version Numbers", RFC 2145, "Use and Interpretation of HTTP Version Numbers",
DOI 10.17487/RFC2145, May 1997, RFC 2145, DOI 10.17487/RFC2145, May 1997,
<https://www.rfc-editor.org/info/rfc2145>. <https://www.rfc-editor.org/info/rfc2145>.
[RFC2295] Holtman, K. and A. Mutz, "Transparent Content Negotiation [RFC2295] Holtman, K. and A.H. Mutz, "Transparent Content
in HTTP", RFC 2295, DOI 10.17487/RFC2295, March 1998, Negotiation in HTTP", RFC 2295, DOI 10.17487/RFC2295,
<https://www.rfc-editor.org/info/rfc2295>. March 1998, <https://www.rfc-editor.org/info/rfc2295>.
[RFC2324] Masinter, L., "Hyper Text Coffee Pot Control Protocol [RFC2324] Masinter, L., "Hyper Text Coffee Pot Control Protocol
(HTCPCP/1.0)", RFC 2324, DOI 10.17487/RFC2324, April 1998, (HTCPCP/1.0)", RFC 2324, DOI 10.17487/RFC2324, April 1,
<https://www.rfc-editor.org/info/rfc2324>. 1998, <https://www.rfc-editor.org/info/rfc2324>.
[RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud, [RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud,
"MIME Encapsulation of Aggregate Documents, such as HTML "MIME Encapsulation of Aggregate Documents, such as HTML
(MHTML)", RFC 2557, DOI 10.17487/RFC2557, March 1999, (MHTML)", RFC 2557, DOI 10.17487/RFC2557, March 1999,
<https://www.rfc-editor.org/info/rfc2557>. <https://www.rfc-editor.org/info/rfc2557>.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, Transfer Protocol -- HTTP/1.1", RFC 2616,
DOI 10.17487/RFC2616, June 1999, DOI 10.17487/RFC2616, June 1999,
<https://www.rfc-editor.org/info/rfc2616>. <https://www.rfc-editor.org/info/rfc2616>.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., [RFC2617] Franks, J., Hallam-Baker, P.M., Hostetler, J.L., Lawrence,
Leach, P., Luotonen, A., and L. Stewart, "HTTP S.D., Leach, P.J., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication", Authentication: Basic and Digest Access Authentication",
RFC 2617, DOI 10.17487/RFC2617, June 1999, RFC 2617, DOI 10.17487/RFC2617, June 1999,
<https://www.rfc-editor.org/info/rfc2617>. <https://www.rfc-editor.org/info/rfc2617>.
[RFC2774] Frystyk, H., Leach, P., and S. Lawrence, "An HTTP [RFC2774] Frystyk, H., Leach, P., and S. Lawrence, "An HTTP
Extension Framework", RFC 2774, DOI 10.17487/RFC2774, Extension Framework", RFC 2774, DOI 10.17487/RFC2774,
February 2000, <https://www.rfc-editor.org/info/rfc2774>. February 2000, <https://www.rfc-editor.org/info/rfc2774>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000, DOI 10.17487/RFC2818, May 2000,
skipping to change at page 183, line 32 skipping to change at page 185, line 28
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005, RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/info/rfc4033>. <https://www.rfc-editor.org/info/rfc4033>.
[RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based
Kerberos and NTLM HTTP Authentication in Microsoft Kerberos and NTLM HTTP Authentication in Microsoft
Windows", RFC 4559, DOI 10.17487/RFC4559, June 2006, Windows", RFC 4559, DOI 10.17487/RFC4559, June 2006,
<https://www.rfc-editor.org/info/rfc4559>. <https://www.rfc-editor.org/info/rfc4559>.
[RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed [RFC4918] Dusseault, L.M., Ed., "HTTP Extensions for Web Distributed
Authoring and Versioning (WebDAV)", RFC 4918, Authoring and Versioning (WebDAV)", RFC 4918,
DOI 10.17487/RFC4918, June 2007, DOI 10.17487/RFC4918, June 2007,
<https://www.rfc-editor.org/info/rfc4918>. <https://www.rfc-editor.org/info/rfc4918>.
[RFC5322] Resnick, P., "Internet Message Format", RFC 5322, [RFC5322] Resnick, P., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008, DOI 10.17487/RFC5322, October 2008,
<https://www.rfc-editor.org/info/rfc5322>. <https://www.rfc-editor.org/info/rfc5322>.
[RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP", [RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP",
RFC 5789, DOI 10.17487/RFC5789, March 2010, RFC 5789, DOI 10.17487/RFC5789, March 2010,
skipping to change at page 184, line 24 skipping to change at page 186, line 17
<https://www.rfc-editor.org/info/rfc6265>. <https://www.rfc-editor.org/info/rfc6265>.
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
DOI 10.17487/RFC6454, December 2011, DOI 10.17487/RFC6454, December 2011,
<https://www.rfc-editor.org/info/rfc6454>. <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. F. Reschke, Ed., "Hypertext
Protocol (HTTP/1.1): Message Syntax and Routing", Transfer 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. F. Reschke, Ed., "Hypertext
Protocol (HTTP/1.1): Semantics and Content", RFC 7231, Transfer Protocol (HTTP/1.1): Semantics and Content",
DOI 10.17487/RFC7231, June 2014, RFC 7231, DOI 10.17487/RFC7231, June 2014,
<https://www.rfc-editor.org/info/rfc7231>. <https://www.rfc-editor.org/info/rfc7231>.
[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7232] Fielding, R., Ed. and J. F. Reschke, Ed., "Hypertext
Protocol (HTTP/1.1): Conditional Requests", RFC 7232, Transfer Protocol (HTTP/1.1): Conditional Requests",
DOI 10.17487/RFC7232, June 2014, RFC 7232, DOI 10.17487/RFC7232, June 2014,
<https://www.rfc-editor.org/info/rfc7232>. <https://www.rfc-editor.org/info/rfc7232>.
[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. F. Reschke, Ed.,
"Hypertext Transfer Protocol (HTTP): Range Requests", "Hypertext Transfer Protocol (HTTP): Range Requests",
RFC 7233, DOI 10.17487/RFC7233, June 2014, RFC 7233, DOI 10.17487/RFC7233, June 2014,
<https://www.rfc-editor.org/info/rfc7233>. <https://www.rfc-editor.org/info/rfc7233>.
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7235] Fielding, R., Ed. and J. F. Reschke, Ed., "Hypertext
Protocol (HTTP/1.1): Authentication", RFC 7235, Transfer Protocol (HTTP/1.1): Authentication", RFC 7235,
DOI 10.17487/RFC7235, June 2014, DOI 10.17487/RFC7235, June 2014,
<https://www.rfc-editor.org/info/rfc7235>. <https://www.rfc-editor.org/info/rfc7235>.
[RFC7538] Reschke, J., "The Hypertext Transfer Protocol Status Code [RFC7538] Reschke, J. F., "The Hypertext Transfer Protocol Status
308 (Permanent Redirect)", RFC 7538, DOI 10.17487/RFC7538, Code 308 (Permanent Redirect)", RFC 7538,
April 2015, <https://www.rfc-editor.org/info/rfc7538>. DOI 10.17487/RFC7538, April 2015,
<https://www.rfc-editor.org/info/rfc7538>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540, Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015, DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/info/rfc7540>. <https://www.rfc-editor.org/info/rfc7540>.
[RFC7578] Masinter, L., "Returning Values from Forms: multipart/ [RFC7578] Masinter, L., "Returning Values from Forms: multipart/
form-data", RFC 7578, DOI 10.17487/RFC7578, July 2015, form-data", RFC 7578, DOI 10.17487/RFC7578, July 2015,
<https://www.rfc-editor.org/info/rfc7578>. <https://www.rfc-editor.org/info/rfc7578>.
[RFC7615] Reschke, J., "HTTP Authentication-Info and Proxy- [RFC7615] Reschke, J. F., "HTTP Authentication-Info and Proxy-
Authentication-Info Response Header Fields", RFC 7615, Authentication-Info Response Header Fields", RFC 7615,
DOI 10.17487/RFC7615, September 2015, DOI 10.17487/RFC7615, September 2015,
<https://www.rfc-editor.org/info/rfc7615>. <https://www.rfc-editor.org/info/rfc7615>.
[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. F., "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>.
[RFC7694] Reschke, J., "Hypertext Transfer Protocol (HTTP) Client- [RFC7694] Reschke, J. F., "Hypertext Transfer Protocol (HTTP)
Initiated Content-Encoding", RFC 7694, Client-Initiated Content-Encoding", RFC 7694,
DOI 10.17487/RFC7694, November 2015, DOI 10.17487/RFC7694, November 2015,
<https://www.rfc-editor.org/info/rfc7694>. <https://www.rfc-editor.org/info/rfc7694>.
[RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP
Alternative Services", RFC 7838, DOI 10.17487/RFC7838, Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
April 2016, <https://www.rfc-editor.org/info/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. F., "Indicating Character Encoding and
for HTTP Header Field Parameters", RFC 8187, Language 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", [RFC8336] Nottingham, M. and E. Nygren, "The ORIGIN HTTP/2 Frame",
RFC 8336, DOI 10.17487/RFC8336, March 2018, RFC 8336, DOI 10.17487/RFC8336, March 2018,
<https://www.rfc-editor.org/info/rfc8336>. <https://www.rfc-editor.org/info/rfc8336>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[Sniffing] [Sniffing] WHATWG, "MIME Sniffing",
WHATWG, "MIME Sniffing",
<https://mimesniff.spec.whatwg.org>. <https://mimesniff.spec.whatwg.org>.
Appendix A. Collected ABNF Appendix A. Collected ABNF
In the collected ABNF below, list rules are expanded as per In the collected ABNF below, list rules are expanded as per
Section 5.5.1. Section 5.5.1.
Accept = [ ( media-range [ accept-params ] ) *( OWS "," OWS ( Accept = [ ( media-range [ accept-params ] ) *( OWS "," OWS (
media-range [ accept-params ] ) ) ] media-range [ accept-params ] ) ) ]
Accept-Charset = ( ( charset / "*" ) [ weight ] ) *( OWS "," OWS ( ( Accept-Charset = ( ( charset / "*" ) [ weight ] ) *( OWS "," OWS ( (
skipping to change at page 191, line 45 skipping to change at page 193, line 6
None yet. None yet.
B.2. Changes from RFC 7230 B.2. Changes from RFC 7230
The sections introducing HTTP's design goals, history, architecture, The sections introducing HTTP's design goals, history, architecture,
conformance criteria, protocol versioning, URIs, message routing, and conformance criteria, protocol versioning, URIs, message routing, and
header fields have been moved here (without substantive change). header fields have been moved here (without substantive change).
"Field value" now refers to the value after multiple instances are "Field value" now refers to the value after multiple instances are
combined with commas -- by far the most common use. To refer to a combined with commas - by far the most common use. To refer to a
single header line's value, use "field line value". (Section 5) single header line's value, use "field line value". (Section 5)
Trailer field semantics now transcend the specifics of chunked Trailer field semantics now transcend the specifics of chunked
encoding. Use of trailer fields has been further limited to only encoding. Use of trailer fields has been further limited to only
allow generation as a trailer field when the sender knows the field allow generation as a trailer field when the sender knows the field
defines that usage and to only allow merging into the header section defines that usage and to only allow merging into the header section
if the recipient knows the corresponding field definition permits and if the recipient knows the corresponding field definition permits and
defines how to merge. In all other cases, implementations are defines how to merge. In all other cases, implementations are
encouraged to either store the trailer fields separately or discard encouraged to either store the trailer fields separately or discard
them instead of merging. (Section 5.6.2) them instead of merging. (Section 5.6.2)
skipping to change at page 203, line 39 skipping to change at page 204, line 51
o Add Section 4 about Extending and Versioning HTTP o Add Section 4 about Extending and Versioning HTTP
(<https://github.com/httpwg/http-core/issues/384>) (<https://github.com/httpwg/http-core/issues/384>)
o In Section 10.1, include status 308 in list of heuristically o In Section 10.1, include status 308 in list of heuristically
cacheable status codes (<https://github.com/httpwg/http-core/ cacheable status codes (<https://github.com/httpwg/http-core/
issues/385>) issues/385>)
o In Section 7.2.2, make it clearer that "identity" is not to be o In Section 7.2.2, make it clearer that "identity" is not to be
included (<https://github.com/httpwg/http-core/issues/388>) included (<https://github.com/httpwg/http-core/issues/388>)
Index D.11. Since draft-ietf-httpbis-semantics-09
o Switch to xml2rfc v3 mode for draft generation
1 (<https://github.com/httpwg/http-core/issues/394>)
100 Continue (status code) 127
100-continue (expect value) 93
101 Switching Protocols (status code) 127
1xx Informational (status code class) 126
2
200 OK (status code) 127
201 Created (status code) 128
202 Accepted (status code) 128
203 Non-Authoritative Information (status code) 129
204 No Content (status code) 129
205 Reset Content (status code) 130
206 Partial Content (status code) 130
2xx Successful (status code class) 127
3
300 Multiple Choices (status code) 135
301 Moved Permanently (status code) 136
302 Found (status code) 136
303 See Other (status code) 137
304 Not Modified (status code) 137
305 Use Proxy (status code) 138
306 (Unused) (status code) 138
307 Temporary Redirect (status code) 138
308 Permanent Redirect (status code) 139
3xx Redirection (status code class) 133
4
400 Bad Request (status code) 139
401 Unauthorized (status code) 139
402 Payment Required (status code) 140
403 Forbidden (status code) 140
404 Not Found (status code) 140
405 Method Not Allowed (status code) 141
406 Not Acceptable (status code) 141
407 Proxy Authentication Required (status code) 141
408 Request Timeout (status code) 141
409 Conflict (status code) 142
410 Gone (status code) 142
411 Length Required (status code) 142
412 Precondition Failed (status code) 143
413 Payload Too Large (status code) 143
414 URI Too Long (status code) 143
415 Unsupported Media Type (status code) 143
416 Range Not Satisfiable (status code) 144
417 Expectation Failed (status code) 144
418 (Unused) (status code) 145
422 Unprocessable Payload (status code) 145
426 Upgrade Required (status code) 145
4xx Client Error (status code class) 139
5
500 Internal Server Error (status code) 146
501 Not Implemented (status code) 146
502 Bad Gateway (status code) 146
503 Service Unavailable (status code) 146
504 Gateway Timeout (status code) 146
505 HTTP Version Not Supported (status code) 147
5xx Server Error (status code class) 145
A
Accept header field 109
Accept-Charset header field 111
Accept-Encoding header field 112
Accept-Language header field 114
Accept-Ranges header field 165
Allow header field 165
Authentication-Info header field 163
Authorization header field 118
accelerator 14
authoritative response 167
B
browser 11
C
CONNECT method 88
Canonical Root URI 117
Content-Encoding header field 63
Content-Language header field 64
Content-Length header field 64
Content-Location header field 66
Content-MD5 header field 177
Content-Range header field 70
Content-Type header field 62
cache 15
cacheable 16
captive portal 15
client 11
complete 12
compress (Coding Format) 56
compress (content coding) 55
conditional request 96
connection 11
content coding 55
content negotiation 9
D
DELETE method 87
Date header field 149
Delimiters 31
deflate (Coding Format) 56
deflate (content coding) 55
downstream 14
E
ETag field 157
Expect header field 93
effective request URI 47
F
Fields
Accept 109
Accept-Charset 111
Accept-Encoding 112
Accept-Language 114
Accept-Ranges 165
Allow 165
Authentication-Info 163
Authorization 118
Content-Encoding 63
Content-Language 64
Content-Length 64
Content-Location 66
Content-MD5 177
Content-Range 70
Content-Type 62
Date 149
ETag 157
Expect 93
From 121
Host 48
If-Match 100
If-Modified-Since 103
If-None-Match 101
If-Range 105
If-Unmodified-Since 104
Last-Modified 155
Location 150
Max-Forwards 96
Proxy-Authenticate 163
Proxy-Authentication-Info 164
Proxy-Authorization 118
Range 106
Referer 122
Retry-After 151
Server 166
Trailer 37
User-Agent 123
Vary 152
Via 49
WWW-Authenticate 162
Fragment Identifiers 20
From header field 121
field 25
field line 26
field line value 26
field name 26
field value 26
G
GET method 82
Grammar
absolute-path 17
absolute-URI 17
Accept 109
Accept-Charset 111
Accept-Encoding 112
accept-ext 109
Accept-Language 114
accept-params 109
Accept-Ranges 165
acceptable-ranges 165
Allow 165
ALPHA 10
asctime-date 34
auth-param 115
auth-scheme 115
Authentication-Info 163
authority 17
Authorization 118
BWS 11
challenge 116
charset 53
codings 112
comment 32
complete-length 70
content-coding 55
Content-Encoding 63
Content-Language 64
Content-Length 65
Content-Location 66
Content-Range 70
Content-Type 62
CR 10
credentials 116
CRLF 10
ctext 32
CTL 10
Date 149
date1 34
day 34
day-name 34
day-name-l 34
delay-seconds 151
DIGIT 10
DQUOTE 10
entity-tag 158
ETag 158
etagc 158
Expect 93
field-content 30
field-name 28, 38
field-value 30
field-vchar 30
first-pos 58, 70
From 121
GMT 34
HEXDIG 10
Host 48
hour 34
HTAB 10
HTTP-date 33
http-URI 18
https-URI 19
If-Match 100
If-Modified-Since 103
If-None-Match 101
If-Range 106
If-Unmodified-Since 104
IMF-fixdate 34
incl-range 70
int-range 58
language-range 114
language-tag 57
Last-Modified 155
last-pos 58, 70
LF 10
Location 150
Max-Forwards 96
media-range 109
media-type 53
method 78
minute 34
month 34
obs-date 34
obs-text 32
OCTET 10
opaque-tag 158
other-range 59
OWS 11
parameter 33
parameter-name 33
parameter-value 33
partial-URI 17
port 17
product 123
product-version 123
protocol-name 49
protocol-version 49
Proxy-Authenticate 163
Proxy-Authentication-Info 164
Proxy-Authorization 118
pseudonym 49
qdtext 32
query 17
quoted-pair 32
quoted-string 32
qvalue 77
Range 106
range-resp 70
range-set 58
range-spec 58
range-unit 57
ranges-specifier 58
received-by 49
received-protocol 49
Referer 122
Retry-After 151
rfc850-date 34
RWS 11
second 34
segment 17
Server 166
SP 10
subtype 53
suffix-length 59
suffix-range 59
tchar 32
time-of-day 34
token 32
token68 115
Trailer 38
type 53
unsatisfied-range 70
uri-host 17
URI-reference 17
User-Agent 123
Vary 152
VCHAR 10
Via 49
weak 158
weight 77
WWW-Authenticate 162
year 34
gateway 14
gzip (Coding Format) 56
gzip (content coding) 55
H
HEAD method 83
Header Fields
Accept 109
Accept-Charset 111
Accept-Encoding 112
Accept-Language 114
Accept-Ranges 165
Allow 165
Authentication-Info 163
Authorization 118
Content-Encoding 63
Content-Language 64
Content-Length 64
Content-Location 66
Content-MD5 177
Content-Range 70
Content-Type 62
Date 149
ETag 157
Expect 93
From 121
Host 48
If-Match 100
If-Modified-Since 103
If-None-Match 101
If-Range 105
If-Unmodified-Since 104
Last-Modified 155
Location 150
Max-Forwards 96
Proxy-Authenticate 163
Proxy-Authentication-Info 164
Proxy-Authorization 118
Range 106
Referer 122
Retry-After 151
Server 166
Trailer 37
User-Agent 123
Vary 152
Via 49
WWW-Authenticate 162
Host header field 48
header section 25
http URI scheme 18
https URI scheme 18
I
If-Match header field 100
If-Modified-Since header field 103
If-None-Match header field 101
If-Range header field 105
If-Unmodified-Since header field 104
idempotent 81
inbound 14
incomplete 12
interception proxy 15
intermediary 13
L
Last-Modified header field 155
Location header field 150
M
Max-Forwards header field 96
Media Type
multipart/byteranges 72
multipart/x-byteranges 72
message 12
metadata 153
multipart/byteranges Media Type 72
multipart/x-byteranges Media Type 72
N
non-transforming proxy 51
O
OPTIONS method 90
origin 42
origin server 11
outbound 14
P
POST method 84
PUT method 85
Protection Space 117
Proxy-Authenticate header field 163
Proxy-Authentication-Info header field 164
Proxy-Authorization header field 118
payload 68
phishing 167
proxy 14
R
Range header field 106
Realm 117
Referer header field 122
Retry-After header field 151
recipient 11
representation 52
request 12
resource 16
response 12
reverse proxy 14
S
Server header field 166
Status Code 124
Status Codes
Final 125
Informational 125
Interim 125
Status Codes Classes
1xx Informational 126
2xx Successful 127
3xx Redirection 133
4xx Client Error 139
5xx Server Error 145
safe 80
secured 18
selected representation 52, 96, 153
sender 11
server 11
spider 11
T
TRACE method 91
Trailer Fields
ETag 157
Trailer header field 37
target URI 41
target resource 41
trailer fields 36
trailer section 25
trailers 36
transforming proxy 51
transparent proxy 15
tunnel 15
U
URI
origin 42
URI scheme
http 18
https 18
User-Agent header field 123
upstream 14
user agent 11
V
Vary header field 152
Via header field 49
validator 153
strong 154
weak 154
W
WWW-Authenticate header field 162
X
x-compress (content coding) 55
x-gzip (content coding) 55
Acknowledgments Acknowledgments
This edition of the HTTP specification builds on the many This edition of the HTTP specification builds on the many
contributions that went into RFC 1945, RFC 2068, RFC 2145, RFC 2616, contributions that went into RFC 1945, RFC 2068, RFC 2145, RFC 2616,
and RFC 2818, including substantial contributions made by the and RFC 2818, including substantial contributions made by the
previous authors, editors, and Working Group Chairs: Tim Berners-Lee, previous authors, editors, and Working Group Chairs: Tim Berners-Lee,
Ari Luotonen, Roy T. Fielding, Henrik Frystyk Nielsen, Jim Gettys, Ari Luotonen, Roy T. Fielding, Henrik Frystyk Nielsen, Jim Gettys,
Jeffrey C. Mogul, Larry Masinter, Paul J. Leach, Eric Rescorla, and Jeffrey C. Mogul, Larry Masinter, Paul J. Leach, Eric Rescorla, and
Yves Lafon. Yves Lafon.
skipping to change at page 214, line 5 skipping to change at page 205, line 27
See Section 10 of [RFC7230] for further acknowledgements from prior See Section 10 of [RFC7230] for further acknowledgements from prior
revisions. revisions.
In addition, this document has reincorporated the HTTP Authentication In addition, this document has reincorporated the HTTP Authentication
Framework, previously defined in RFC 7235 and RFC 2617. We thank Framework, previously defined in RFC 7235 and RFC 2617. We thank
John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott
D. Lawrence, Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart D. Lawrence, Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart
for their work on that specification. See Section 6 of [RFC2617] for for their work on that specification. See Section 6 of [RFC2617] for
further acknowledgements. further acknowledgements.
[[newacks: New acks to be added here.]] // 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
United States of America 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 48155 48155 Münster
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. 187 change blocks. 
1231 lines changed or deleted 782 lines changed or added

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