draft-ietf-httpbis-semantics-07.txt   draft-ietf-httpbis-semantics-08.txt 
HTTP Working Group R. Fielding, Ed. HTTP Working Group R. Fielding, Ed.
Internet-Draft Adobe Internet-Draft Adobe
Obsoletes: M. Nottingham, Ed. Obsoletes: 2818,7230,7231,7232,7233,7235 M. Nottingham, Ed.
2818,7230,7231,7232,7233,7235 Fastly ,7538,7615,7694 (if approved) Fastly
,7538,7615 (if approved) J. Reschke, Ed. Intended status: Standards Track J. Reschke, Ed.
Intended status: Standards Track greenbytes Expires: November 27, 2020 greenbytes
Expires: September 8, 2020 March 7, 2020 May 26, 2020
HTTP Semantics HTTP Semantics
draft-ietf-httpbis-semantics-07 draft-ietf-httpbis-semantics-08
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is a stateless application- The Hypertext Transfer Protocol (HTTP) is a stateless application-
level protocol for distributed, collaborative, hypertext information level protocol for distributed, collaborative, hypertext information
systems. This document defines the semantics of HTTP: its systems. This document defines the semantics of HTTP: its
architecture, terminology, the "http" and "https" Uniform Resource architecture, terminology, the "http" and "https" Uniform Resource
Identifier (URI) schemes, core request methods, request header Identifier (URI) schemes, core request methods, request header
fields, response status codes, response header fields, and content fields, response status codes, response header fields, and content
negotiation. negotiation.
This document obsoletes RFC 2818, RFC 7231, RFC 7232, RFC 7233, RFC This document obsoletes RFC 2818, RFC 7231, RFC 7232, RFC 7233, RFC
7235, RFC 7538, RFC 7615, and portions of RFC 7230. 7235, RFC 7538, RFC 7615, RFC 7694, and portions of RFC 7230.
Editorial Note Editorial Note
This note is to be removed before publishing as an RFC. This note is to be removed before publishing as an RFC.
Discussion of this draft takes place on the HTTP working group Discussion of this draft takes place on the HTTP working group
mailing list (ietf-http-wg@w3.org), which is archived at mailing list (ietf-http-wg@w3.org), which is archived at
<https://lists.w3.org/Archives/Public/ietf-http-wg/>. <https://lists.w3.org/Archives/Public/ietf-http-wg/>.
Working Group information can be found at <https://httpwg.org/>; Working Group information can be found at <https://httpwg.org/>;
source code and issues list for this draft can be found at source code and issues list for this draft can be found at
<https://github.com/httpwg/http-core>. <https://github.com/httpwg/http-core>.
The changes in this draft are summarized in Appendix C.8. The changes in this draft are summarized in Appendix D.9.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 8, 2020. This Internet-Draft will expire on November 27, 2020.
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/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 51 skipping to change at page 2, line 51
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 . . . . . . . . . . . . . . . . . . . . . 13
2.3. Caches . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.3. Caches . . . . . . . . . . . . . . . . . . . . . . . . . 15
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 . . . . . . . . . . . . . . . . . . . 17 2.5.1. http URI Scheme . . . . . . . . . . . . . . . . . . . 18
2.5.2. https URI Scheme . . . . . . . . . . . . . . . . . . 18 2.5.2. https URI Scheme . . . . . . . . . . . . . . . . . . 18
2.5.3. http and https URI Normalization and Comparison . . . 19 2.5.3. http and https URI Normalization and Comparison . . . 19
2.5.4. Deprecated userinfo . . . . . . . . . . . . . . . . . 19 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 . . . 20
3. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 20 3. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1. Implementation Diversity . . . . . . . . . . . . . . . . 20 3.1. Implementation Diversity . . . . . . . . . . . . . . . . 21
3.2. Role-based Requirements . . . . . . . . . . . . . . . . . 21 3.2. Role-based Requirements . . . . . . . . . . . . . . . . . 21
3.3. Parsing Elements . . . . . . . . . . . . . . . . . . . . 21 3.3. Parsing Elements . . . . . . . . . . . . . . . . . . . . 22
3.4. Error Handling . . . . . . . . . . . . . . . . . . . . . 22 3.4. Error Handling . . . . . . . . . . . . . . . . . . . . . 23
3.5. Protocol Versioning . . . . . . . . . . . . . . . . . . . 22 3.5. Protocol Versioning . . . . . . . . . . . . . . . . . . . 23
4. Header and Trailer Fields . . . . . . . . . . . . . . . . . . 24 4. Header and Trailer Fields . . . . . . . . . . . . . . . . . . 24
4.1. Field Ordering and Combination . . . . . . . . . . . . . 25 4.1. Field Ordering and Combination . . . . . . . . . . . . . 25
4.2. Field Limits . . . . . . . . . . . . . . . . . . . . . . 26 4.2. Field Limits . . . . . . . . . . . . . . . . . . . . . . 26
4.3. Field Names . . . . . . . . . . . . . . . . . . . . . . . 26 4.3. Field Names . . . . . . . . . . . . . . . . . . . . . . . 27
4.3.1. Field Extensibility . . . . . . . . . . . . . . . . . 27 4.3.1. Field Extensibility . . . . . . . . . . . . . . . . . 27
4.3.2. Field Name Registry . . . . . . . . . . . . . . . . . 27 4.3.2. Field Name Registry . . . . . . . . . . . . . . . . . 28
4.4. Field Values . . . . . . . . . . . . . . . . . . . . . . 28 4.4. Field Values . . . . . . . . . . . . . . . . . . . . . . 29
4.4.1. Common Field Value Components . . . . . . . . . . . . 30 4.4.1. Common Field Value Components . . . . . . . . . . . . 30
4.5. ABNF List Extension: #rule . . . . . . . . . . . . . . . 31 4.5. ABNF List Extension: #rule . . . . . . . . . . . . . . . 32
4.5.1. Sender Requirements . . . . . . . . . . . . . . . . . 31 4.5.1. Sender Requirements . . . . . . . . . . . . . . . . . 32
4.5.2. Recipient Requirements . . . . . . . . . . . . . . . 32 4.5.2. Recipient Requirements . . . . . . . . . . . . . . . 32
4.6. Trailer Fields . . . . . . . . . . . . . . . . . . . . . 32 4.6. Trailer Fields . . . . . . . . . . . . . . . . . . . . . 33
4.6.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 33 4.6.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 33
4.6.2. Limitations . . . . . . . . . . . . . . . . . . . . . 33 4.6.2. Limitations . . . . . . . . . . . . . . . . . . . . . 34
4.6.3. Trailer . . . . . . . . . . . . . . . . . . . . . . . 34 4.6.3. Trailer . . . . . . . . . . . . . . . . . . . . . . . 34
4.7. Considerations for New HTTP Fields . . . . . . . . . . . 34 4.7. Considerations for New HTTP Fields . . . . . . . . . . . 35
4.8. Fields Defined In This Document . . . . . . . . . . . . . 35 4.8. Fields Defined In This Document . . . . . . . . . . . . . 36
5. Message Routing . . . . . . . . . . . . . . . . . . . . . . . 37 5. Message Routing . . . . . . . . . . . . . . . . . . . . . . . 38
5.1. Identifying a Target Resource . . . . . . . . . . . . . . 37 5.1. Identifying a Target Resource . . . . . . . . . . . . . . 38
5.2. Determining Origin . . . . . . . . . . . . . . . . . . . 37 5.2. Determining Origin . . . . . . . . . . . . . . . . . . . 38
5.3. Routing Inbound . . . . . . . . . . . . . . . . . . . . . 38 5.3. Routing Inbound . . . . . . . . . . . . . . . . . . . . . 39
5.4. Direct Authoritative Access . . . . . . . . . . . . . . . 38 5.4. Direct Authoritative Access . . . . . . . . . . . . . . . 40
5.4.1. http origins . . . . . . . . . . . . . . . . . . . . 38 5.4.1. http origins . . . . . . . . . . . . . . . . . . . . 40
5.4.2. https origins . . . . . . . . . . . . . . . . . . . . 39 5.4.2. https origins . . . . . . . . . . . . . . . . . . . . 41
5.4.3. Initiating HTTP Over TLS . . . . . . . . . . . . . . 41 5.4.3. Initiating HTTP Over TLS . . . . . . . . . . . . . . 42
5.5. Effective Request URI . . . . . . . . . . . . . . . . . . 43 5.5. Reconstructing the Target URI . . . . . . . . . . . . . . 44
5.6. Host . . . . . . . . . . . . . . . . . . . . . . . . . . 43 5.6. Host . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.7. Message Forwarding . . . . . . . . . . . . . . . . . . . 44 5.7. Message Forwarding . . . . . . . . . . . . . . . . . . . 45
5.7.1. Via . . . . . . . . . . . . . . . . . . . . . . . . . 45 5.7.1. Via . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.7.2. Transformations . . . . . . . . . . . . . . . . . . . 47 5.7.2. Transformations . . . . . . . . . . . . . . . . . . . 47
6. Representations . . . . . . . . . . . . . . . . . . . . . . . 48 6. Representations . . . . . . . . . . . . . . . . . . . . . . . 49
6.1. Representation Data . . . . . . . . . . . . . . . . . . . 48 6.1. Representation Data . . . . . . . . . . . . . . . . . . . 49
6.1.1. Media Type . . . . . . . . . . . . . . . . . . . . . 49 6.1.1. Media Type . . . . . . . . . . . . . . . . . . . . . 49
6.1.2. Content Codings . . . . . . . . . . . . . . . . . . . 51 6.1.2. Content Codings . . . . . . . . . . . . . . . . . . . 52
6.1.3. Language Tags . . . . . . . . . . . . . . . . . . . . 53 6.1.3. Language Tags . . . . . . . . . . . . . . . . . . . . 53
6.1.4. Range Units . . . . . . . . . . . . . . . . . . . . . 54 6.1.4. Range Units . . . . . . . . . . . . . . . . . . . . . 54
6.2. Representation Metadata . . . . . . . . . . . . . . . . . 58 6.2. Representation Metadata . . . . . . . . . . . . . . . . . 58
6.2.1. Content-Type . . . . . . . . . . . . . . . . . . . . 58 6.2.1. Content-Type . . . . . . . . . . . . . . . . . . . . 59
6.2.2. Content-Encoding . . . . . . . . . . . . . . . . . . 59 6.2.2. Content-Encoding . . . . . . . . . . . . . . . . . . 60
6.2.3. Content-Language . . . . . . . . . . . . . . . . . . 60 6.2.3. Content-Language . . . . . . . . . . . . . . . . . . 61
6.2.4. Content-Length . . . . . . . . . . . . . . . . . . . 61 6.2.4. Content-Length . . . . . . . . . . . . . . . . . . . 61
6.2.5. Content-Location . . . . . . . . . . . . . . . . . . 62 6.2.5. Content-Location . . . . . . . . . . . . . . . . . . 63
6.3. Payload . . . . . . . . . . . . . . . . . . . . . . . . . 64 6.3. Payload . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.3.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 64 6.3.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 65
6.3.2. Identification . . . . . . . . . . . . . . . . . . . 65 6.3.2. Identification . . . . . . . . . . . . . . . . . . . 65
6.3.3. Payload Body . . . . . . . . . . . . . . . . . . . . 66 6.3.3. Payload Body . . . . . . . . . . . . . . . . . . . . 66
6.3.4. Content-Range . . . . . . . . . . . . . . . . . . . . 66 6.3.4. Content-Range . . . . . . . . . . . . . . . . . . . . 67
6.3.5. Media Type multipart/byteranges . . . . . . . . . . . 68 6.3.5. Media Type multipart/byteranges . . . . . . . . . . . 69
6.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 70 6.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 71
6.4.1. Proactive Negotiation . . . . . . . . . . . . . . . . 71 6.4.1. Proactive Negotiation . . . . . . . . . . . . . . . . 72
6.4.2. Reactive Negotiation . . . . . . . . . . . . . . . . 72 6.4.2. Reactive Negotiation . . . . . . . . . . . . . . . . 73
7. Request Methods . . . . . . . . . . . . . . . . . . . . . . . 73 6.4.3. Request Payload Negotiation . . . . . . . . . . . . . 74
7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 73 6.4.4. Quality Values . . . . . . . . . . . . . . . . . . . 74
7.2. Common Method Properties . . . . . . . . . . . . . . . . 74 7. Request Methods . . . . . . . . . . . . . . . . . . . . . . . 74
7.2.1. Safe Methods . . . . . . . . . . . . . . . . . . . . 75 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 74
7.2.2. Idempotent Methods . . . . . . . . . . . . . . . . . 76 7.2. Common Method Properties . . . . . . . . . . . . . . . . 76
7.2.3. Methods and Caching . . . . . . . . . . . . . . . . . 77 7.2.1. Safe Methods . . . . . . . . . . . . . . . . . . . . 77
7.3. Method Definitions . . . . . . . . . . . . . . . . . . . 77 7.2.2. Idempotent Methods . . . . . . . . . . . . . . . . . 78
7.3.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 77 7.2.3. Methods and Caching . . . . . . . . . . . . . . . . . 79
7.3.2. HEAD . . . . . . . . . . . . . . . . . . . . . . . . 78 7.3. Method Definitions . . . . . . . . . . . . . . . . . . . 79
7.3.3. POST . . . . . . . . . . . . . . . . . . . . . . . . 79 7.3.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 79
7.3.4. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 80 7.3.2. HEAD . . . . . . . . . . . . . . . . . . . . . . . . 80
7.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . 82 7.3.3. POST . . . . . . . . . . . . . . . . . . . . . . . . 81
7.3.6. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 83 7.3.4. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 82
7.3.7. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 85 7.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . 84
7.3.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . 86 7.3.6. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 85
7.4. Method Extensibility . . . . . . . . . . . . . . . . . . 86 7.3.7. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 87
7.4.1. Method Registry . . . . . . . . . . . . . . . . . . . 86 7.3.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . 88
7.4.2. Considerations for New Methods . . . . . . . . . . . 87 7.4. Method Extensibility . . . . . . . . . . . . . . . . . . 88
8. Request Header Fields . . . . . . . . . . . . . . . . . . . . 87 7.4.1. Method Registry . . . . . . . . . . . . . . . . . . . 88
8.1. Controls . . . . . . . . . . . . . . . . . . . . . . . . 88 7.4.2. Considerations for New Methods . . . . . . . . . . . 89
8.1.1. Expect . . . . . . . . . . . . . . . . . . . . . . . 88 8. Request Header Fields . . . . . . . . . . . . . . . . . . . . 89
8.1.2. Max-Forwards . . . . . . . . . . . . . . . . . . . . 90 8.1. Controls . . . . . . . . . . . . . . . . . . . . . . . . 90
8.2. Preconditions . . . . . . . . . . . . . . . . . . . . . . 91 8.1.1. Expect . . . . . . . . . . . . . . . . . . . . . . . 90
8.2.1. Evaluation . . . . . . . . . . . . . . . . . . . . . 92 8.1.2. Max-Forwards . . . . . . . . . . . . . . . . . . . . 92
8.2.2. Precedence . . . . . . . . . . . . . . . . . . . . . 93 8.2. Preconditions . . . . . . . . . . . . . . . . . . . . . . 93
8.2.3. If-Match . . . . . . . . . . . . . . . . . . . . . . 95 8.2.1. Evaluation . . . . . . . . . . . . . . . . . . . . . 94
8.2.4. If-None-Match . . . . . . . . . . . . . . . . . . . . 96 8.2.2. Precedence . . . . . . . . . . . . . . . . . . . . . 95
8.2.5. If-Modified-Since . . . . . . . . . . . . . . . . . . 97 8.2.3. If-Match . . . . . . . . . . . . . . . . . . . . . . 97
8.2.6. If-Unmodified-Since . . . . . . . . . . . . . . . . . 98 8.2.4. If-None-Match . . . . . . . . . . . . . . . . . . . . 98
8.2.7. If-Range . . . . . . . . . . . . . . . . . . . . . . 100 8.2.5. If-Modified-Since . . . . . . . . . . . . . . . . . . 99
8.3. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 101 8.2.6. If-Unmodified-Since . . . . . . . . . . . . . . . . . 101
8.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 102 8.2.7. If-Range . . . . . . . . . . . . . . . . . . . . . . 102
8.4.1. Quality Values . . . . . . . . . . . . . . . . . . . 103 8.3. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 103
8.4.2. Accept . . . . . . . . . . . . . . . . . . . . . . . 104 8.4. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 105
8.4.3. Accept-Charset . . . . . . . . . . . . . . . . . . . 106 8.4.1. Accept . . . . . . . . . . . . . . . . . . . . . . . 106
8.4.4. Accept-Encoding . . . . . . . . . . . . . . . . . . . 107 8.4.2. Accept-Charset . . . . . . . . . . . . . . . . . . . 108
8.4.5. Accept-Language . . . . . . . . . . . . . . . . . . . 108 8.4.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . 108
8.5. Authentication Credentials . . . . . . . . . . . . . . . 109 8.4.4. Accept-Language . . . . . . . . . . . . . . . . . . . 110
8.5.1. Challenge and Response . . . . . . . . . . . . . . . 109 8.5. Authentication Credentials . . . . . . . . . . . . . . . 111
8.5.2. Protection Space (Realm) . . . . . . . . . . . . . . 111 8.5.1. Challenge and Response . . . . . . . . . . . . . . . 112
8.5.3. Authorization . . . . . . . . . . . . . . . . . . . . 112 8.5.2. Protection Space (Realm) . . . . . . . . . . . . . . 113
8.5.4. Proxy-Authorization . . . . . . . . . . . . . . . . . 112 8.5.3. Authorization . . . . . . . . . . . . . . . . . . . . 114
8.5.5. Authentication Scheme Extensibility . . . . . . . . . 113 8.5.4. Proxy-Authorization . . . . . . . . . . . . . . . . . 115
8.6. Request Context . . . . . . . . . . . . . . . . . . . . . 115 8.5.5. Authentication Scheme Extensibility . . . . . . . . . 115
8.6.1. From . . . . . . . . . . . . . . . . . . . . . . . . 115 8.6. Request Context . . . . . . . . . . . . . . . . . . . . . 117
8.6.2. Referer . . . . . . . . . . . . . . . . . . . . . . . 116 8.6.1. From . . . . . . . . . . . . . . . . . . . . . . . . 118
8.6.3. User-Agent . . . . . . . . . . . . . . . . . . . . . 117 8.6.2. Referer . . . . . . . . . . . . . . . . . . . . . . . 118
9. Response Status Codes . . . . . . . . . . . . . . . . . . . . 118 8.6.3. User-Agent . . . . . . . . . . . . . . . . . . . . . 119
9.1. Overview of Status Codes . . . . . . . . . . . . . . . . 119 9. Response Status Codes . . . . . . . . . . . . . . . . . . . . 120
9.2. Informational 1xx . . . . . . . . . . . . . . . . . . . . 120 9.1. Overview of Status Codes . . . . . . . . . . . . . . . . 121
9.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 121 9.2. Informational 1xx . . . . . . . . . . . . . . . . . . . . 123
9.2.2. 101 Switching Protocols . . . . . . . . . . . . . . . 121 9.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 123
9.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . 121 9.2.2. 101 Switching Protocols . . . . . . . . . . . . . . . 123
9.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 121 9.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . 124
9.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 122 9.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 124
9.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . 122 9.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 124
9.3.4. 203 Non-Authoritative Information . . . . . . . . . . 123 9.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . 125
9.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . 123 9.3.4. 203 Non-Authoritative Information . . . . . . . . . . 125
9.3.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 124 9.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . 125
9.3.7. 206 Partial Content . . . . . . . . . . . . . . . . . 124 9.3.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 126
9.4. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 127 9.3.7. 206 Partial Content . . . . . . . . . . . . . . . . . 127
9.4.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 129 9.4. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 130
9.4.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 130 9.4.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 131
9.4.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 130 9.4.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 132
9.4.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 131 9.4.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 132
9.4.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 131 9.4.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 133
9.4.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 132 9.4.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 133
9.4.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . 132 9.4.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 134
9.4.8. 307 Temporary Redirect . . . . . . . . . . . . . . . 132 9.4.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . 134
9.4.9. 308 Permanent Redirect . . . . . . . . . . . . . . . 133 9.4.8. 307 Temporary Redirect . . . . . . . . . . . . . . . 134
9.5. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 133 9.4.9. 308 Permanent Redirect . . . . . . . . . . . . . . . 135
9.5.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 133 9.5. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 135
9.5.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 133 9.5.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 135
9.5.3. 402 Payment Required . . . . . . . . . . . . . . . . 134 9.5.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 135
9.5.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 134 9.5.3. 402 Payment Required . . . . . . . . . . . . . . . . 136
9.5.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 134 9.5.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 136
9.5.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 135 9.5.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 136
9.5.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 135 9.5.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 137
9.5.8. 407 Proxy Authentication Required . . . . . . . . . . 135 9.5.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 137
9.5.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 135 9.5.8. 407 Proxy Authentication Required . . . . . . . . . . 137
9.5.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . 136 9.5.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 137
9.5.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 136 9.5.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . 138
9.5.12. 411 Length Required . . . . . . . . . . . . . . . . . 136 9.5.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 138
9.5.13. 412 Precondition Failed . . . . . . . . . . . . . . . 137 9.5.12. 411 Length Required . . . . . . . . . . . . . . . . . 138
9.5.14. 413 Payload Too Large . . . . . . . . . . . . . . . . 137 9.5.13. 412 Precondition Failed . . . . . . . . . . . . . . . 139
9.5.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . 137 9.5.14. 413 Payload Too Large . . . . . . . . . . . . . . . . 139
9.5.16. 415 Unsupported Media Type . . . . . . . . . . . . . 137 9.5.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . 139
9.5.17. 416 Range Not Satisfiable . . . . . . . . . . . . . . 138 9.5.16. 415 Unsupported Media Type . . . . . . . . . . . . . 139
9.5.18. 417 Expectation Failed . . . . . . . . . . . . . . . 138 9.5.17. 416 Range Not Satisfiable . . . . . . . . . . . . . . 140
9.5.19. 418 (Unused) . . . . . . . . . . . . . . . . . . . . 138 9.5.18. 417 Expectation Failed . . . . . . . . . . . . . . . 140
9.5.20. 422 Unprocessable Payload . . . . . . . . . . . . . . 139 9.5.19. 418 (Unused) . . . . . . . . . . . . . . . . . . . . 140
9.5.21. 426 Upgrade Required . . . . . . . . . . . . . . . . 139 9.5.20. 422 Unprocessable Payload . . . . . . . . . . . . . . 141
9.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 139 9.5.21. 426 Upgrade Required . . . . . . . . . . . . . . . . 141
9.6.1. 500 Internal Server Error . . . . . . . . . . . . . . 140 9.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 141
9.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 140 9.6.1. 500 Internal Server Error . . . . . . . . . . . . . . 142
9.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 140 9.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 142
9.6.4. 503 Service Unavailable . . . . . . . . . . . . . . . 140 9.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 142
9.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 140 9.6.4. 503 Service Unavailable . . . . . . . . . . . . . . . 142
9.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . 140 9.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 142
9.7. Status Code Extensibility . . . . . . . . . . . . . . . . 141 9.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . 142
9.7.1. Status Code Registry . . . . . . . . . . . . . . . . 141 9.7. Status Code Extensibility . . . . . . . . . . . . . . . . 143
9.7.2. Considerations for New Status Codes . . . . . . . . . 141 9.7.1. Status Code Registry . . . . . . . . . . . . . . . . 143
10. Response Header Fields . . . . . . . . . . . . . . . . . . . 142 9.7.2. Considerations for New Status Codes . . . . . . . . . 143
10.1. Control Data . . . . . . . . . . . . . . . . . . . . . . 142 10. Response Header Fields . . . . . . . . . . . . . . . . . . . 144
10.1.1. Origination Date . . . . . . . . . . . . . . . . . . 143 10.1. Control Data . . . . . . . . . . . . . . . . . . . . . . 144
10.1.2. Location . . . . . . . . . . . . . . . . . . . . . . 146 10.1.1. Origination Date . . . . . . . . . . . . . . . . . . 145
10.1.3. Retry-After . . . . . . . . . . . . . . . . . . . . 147 10.1.2. Location . . . . . . . . . . . . . . . . . . . . . . 148
10.1.4. Vary . . . . . . . . . . . . . . . . . . . . . . . . 147 10.1.3. Retry-After . . . . . . . . . . . . . . . . . . . . 149
10.2. Validators . . . . . . . . . . . . . . . . . . . . . . . 149 10.1.4. Vary . . . . . . . . . . . . . . . . . . . . . . . . 149
10.2.1. Weak versus Strong . . . . . . . . . . . . . . . . . 150 10.2. Validators . . . . . . . . . . . . . . . . . . . . . . . 151
10.2.2. Last-Modified . . . . . . . . . . . . . . . . . . . 151 10.2.1. Weak versus Strong . . . . . . . . . . . . . . . . . 152
10.2.3. ETag . . . . . . . . . . . . . . . . . . . . . . . . 153 10.2.2. Last-Modified . . . . . . . . . . . . . . . . . . . 153
10.2.4. When to Use Entity-Tags and Last-Modified Dates . . 157 10.2.3. ETag . . . . . . . . . . . . . . . . . . . . . . . . 155
10.3. Authentication Challenges . . . . . . . . . . . . . . . 157 10.2.4. When to Use Entity-Tags and Last-Modified Dates . . 159
10.3.1. WWW-Authenticate . . . . . . . . . . . . . . . . . . 158 10.3. Authentication Challenges . . . . . . . . . . . . . . . 159
10.3.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . 159 10.3.1. WWW-Authenticate . . . . . . . . . . . . . . . . . . 160
10.3.3. Authentication-Info . . . . . . . . . . . . . . . . 159 10.3.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . 161
10.3.4. Proxy-Authentication-Info . . . . . . . . . . . . . 160 10.3.3. Authentication-Info . . . . . . . . . . . . . . . . 161
10.4. Response Context . . . . . . . . . . . . . . . . . . . . 161 10.3.4. Proxy-Authentication-Info . . . . . . . . . . . . . 162
10.4.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . 161 10.4. Response Context . . . . . . . . . . . . . . . . . . . . 163
10.4.2. Allow . . . . . . . . . . . . . . . . . . . . . . . 161 10.4.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . 163
10.4.3. Server . . . . . . . . . . . . . . . . . . . . . . . 162 10.4.2. Allow . . . . . . . . . . . . . . . . . . . . . . . 163
11. Security Considerations . . . . . . . . . . . . . . . . . . . 163 10.4.3. Server . . . . . . . . . . . . . . . . . . . . . . . 164
11.1. Establishing Authority . . . . . . . . . . . . . . . . . 163 11. Security Considerations . . . . . . . . . . . . . . . . . . . 165
11.2. Risks of Intermediaries . . . . . . . . . . . . . . . . 164 11.1. Establishing Authority . . . . . . . . . . . . . . . . . 165
11.3. Attacks Based on File and Path Names . . . . . . . . . . 165 11.2. Risks of Intermediaries . . . . . . . . . . . . . . . . 166
11.4. Attacks Based on Command, Code, or Query Injection . . . 165 11.3. Attacks Based on File and Path Names . . . . . . . . . . 167
11.5. Attacks via Protocol Element Length . . . . . . . . . . 166 11.4. Attacks Based on Command, Code, or Query Injection . . . 167
11.6. Disclosure of Personal Information . . . . . . . . . . . 166 11.5. Attacks via Protocol Element Length . . . . . . . . . . 168
11.7. Privacy of Server Log Information . . . . . . . . . . . 166 11.6. Disclosure of Personal Information . . . . . . . . . . . 168
11.8. Disclosure of Sensitive Information in URIs . . . . . . 167 11.7. Privacy of Server Log Information . . . . . . . . . . . 168
11.9. Disclosure of Fragment after Redirects . . . . . . . . . 167 11.8. Disclosure of Sensitive Information in URIs . . . . . . 169
11.10. Disclosure of Product Information . . . . . . . . . . . 168 11.9. Disclosure of Fragment after Redirects . . . . . . . . . 169
11.11. Browser Fingerprinting . . . . . . . . . . . . . . . . . 168 11.10. Disclosure of Product Information . . . . . . . . . . . 170
11.12. Validator Retention . . . . . . . . . . . . . . . . . . 169 11.11. Browser Fingerprinting . . . . . . . . . . . . . . . . . 170
11.13. Denial-of-Service Attacks Using Range . . . . . . . . . 170 11.12. Validator Retention . . . . . . . . . . . . . . . . . . 171
11.14. Authentication Considerations . . . . . . . . . . . . . 170 11.13. Denial-of-Service Attacks Using Range . . . . . . . . . 172
11.14.1. Confidentiality of Credentials . . . . . . . . . . 170 11.14. Authentication Considerations . . . . . . . . . . . . . 172
11.14.2. Credentials and Idle Clients . . . . . . . . . . . 171 11.14.1. Confidentiality of Credentials . . . . . . . . . . 172
11.14.3. Protection Spaces . . . . . . . . . . . . . . . . . 171 11.14.2. Credentials and Idle Clients . . . . . . . . . . . 173
11.14.4. Additional Response Fields . . . . . . . . . . . . 172 11.14.3. Protection Spaces . . . . . . . . . . . . . . . . . 173
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 172 11.14.4. Additional Response Fields . . . . . . . . . . . . 174
12.1. URI Scheme Registration . . . . . . . . . . . . . . . . 172 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 174
12.2. Method Registration . . . . . . . . . . . . . . . . . . 172 12.1. URI Scheme Registration . . . . . . . . . . . . . . . . 174
12.3. Status Code Registration . . . . . . . . . . . . . . . . 172 12.2. Method Registration . . . . . . . . . . . . . . . . . . 174
12.4. HTTP Field Name Registration . . . . . . . . . . . . . . 173 12.3. Status Code Registration . . . . . . . . . . . . . . . . 174
12.5. Authentication Scheme Registration . . . . . . . . . . . 173 12.4. HTTP Field Name Registration . . . . . . . . . . . . . . 175
12.6. Content Coding Registration . . . . . . . . . . . . . . 173 12.5. Authentication Scheme Registration . . . . . . . . . . . 175
12.7. Range Unit Registration . . . . . . . . . . . . . . . . 174 12.6. Content Coding Registration . . . . . . . . . . . . . . 175
12.8. Media Type Registration . . . . . . . . . . . . . . . . 174 12.7. Range Unit Registration . . . . . . . . . . . . . . . . 176
12.9. Port Registration . . . . . . . . . . . . . . . . . . . 174 12.8. Media Type Registration . . . . . . . . . . . . . . . . 176
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 174 12.9. Port Registration . . . . . . . . . . . . . . . . . . . 176
13.1. Normative References . . . . . . . . . . . . . . . . . . 174 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 176
13.2. Informative References . . . . . . . . . . . . . . . . . 176 13.1. Normative References . . . . . . . . . . . . . . . . . . 176
Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 182 13.2. Informative References . . . . . . . . . . . . . . . . . 178
Appendix B. Changes from previous RFCs . . . . . . . . . . . . . 186 Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 184
B.1. Changes from RFC 2818 . . . . . . . . . . . . . . . . . . 186 Appendix B. Changes from previous RFCs . . . . . . . . . . . . . 188
B.2. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 186 B.1. Changes from RFC 2818 . . . . . . . . . . . . . . . . . . 188
B.3. Changes from RFC 7231 . . . . . . . . . . . . . . . . . . 187 B.2. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 188
B.4. Changes from RFC 7232 . . . . . . . . . . . . . . . . . . 188 B.3. Changes from RFC 7231 . . . . . . . . . . . . . . . . . . 189
B.5. Changes from RFC 7233 . . . . . . . . . . . . . . . . . . 188 B.4. Changes from RFC 7232 . . . . . . . . . . . . . . . . . . 190
B.6. Changes from RFC 7235 . . . . . . . . . . . . . . . . . . 188 B.5. Changes from RFC 7233 . . . . . . . . . . . . . . . . . . 190
B.7. Changes from RFC 7538 . . . . . . . . . . . . . . . . . . 188 B.6. Changes from RFC 7235 . . . . . . . . . . . . . . . . . . 190
B.8. Changes from RFC 7615 . . . . . . . . . . . . . . . . . . 188 B.7. Changes from RFC 7538 . . . . . . . . . . . . . . . . . . 190
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 188 B.8. Changes from RFC 7615 . . . . . . . . . . . . . . . . . . 190
C.1. Between RFC723x and draft 00 . . . . . . . . . . . . . . 188 Appendix C. Changes from RFC 7694 . . . . . . . . . . . . . . . 190
C.2. Since draft-ietf-httpbis-semantics-00 . . . . . . . . . . 189 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 191
C.3. Since draft-ietf-httpbis-semantics-01 . . . . . . . . . . 189 D.1. Between RFC723x and draft 00 . . . . . . . . . . . . . . 191
C.4. Since draft-ietf-httpbis-semantics-02 . . . . . . . . . . 191 D.2. Since draft-ietf-httpbis-semantics-00 . . . . . . . . . . 191
C.5. Since draft-ietf-httpbis-semantics-03 . . . . . . . . . . 192 D.3. Since draft-ietf-httpbis-semantics-01 . . . . . . . . . . 192
C.6. Since draft-ietf-httpbis-semantics-04 . . . . . . . . . . 192 D.4. Since draft-ietf-httpbis-semantics-02 . . . . . . . . . . 193
C.7. Since draft-ietf-httpbis-semantics-05 . . . . . . . . . . 193 D.5. Since draft-ietf-httpbis-semantics-03 . . . . . . . . . . 194
C.8. Since draft-ietf-httpbis-semantics-06 . . . . . . . . . . 194 D.6. Since draft-ietf-httpbis-semantics-04 . . . . . . . . . . 195
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 D.7. Since draft-ietf-httpbis-semantics-05 . . . . . . . . . . 195
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 205 D.8. Since draft-ietf-httpbis-semantics-06 . . . . . . . . . . 196
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 206 D.9. Since draft-ietf-httpbis-semantics-07 . . . . . . . . . . 198
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 209
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 210
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 8, line 48 skipping to change at page 8, line 48
are limited to defining the syntax of communication, the intent of are limited to defining the syntax of communication, the intent of
received communication, and the expected behavior of recipients. If received communication, and the expected behavior of recipients. If
the communication is considered in isolation, then successful actions the communication is considered in isolation, then successful actions
ought to be reflected in corresponding changes to the observable ought to be reflected in corresponding changes to the observable
interface provided by servers. However, since multiple clients might interface provided by servers. However, since multiple clients might
act in parallel and perhaps at cross-purposes, we cannot require that act in parallel and perhaps at cross-purposes, we cannot require that
such changes be observable beyond the scope of a single response. such changes be observable beyond the scope of a single response.
Each HTTP message is either a request or a response. A server Each HTTP message is either a request or a response. A server
listens on a connection for a request, parses each message received, listens on a connection for a request, parses each message received,
interprets the message semantics in relation to the identified interprets the message semantics in relation to the identified target
request target, and responds to that request with one or more resource, and responds to that request with one or more response
response messages. A client constructs request messages to messages. A client constructs request messages to communicate
communicate specific intentions, examines received responses to see specific intentions, examines received responses to see if the
if the intentions were carried out, and determines how to interpret intentions were carried out, and determines how to interpret the
the results. results.
HTTP provides a uniform interface for interacting with a resource HTTP provides a uniform interface for interacting with a resource
(Section 2.5), regardless of its type, nature, or implementation, via (Section 2.5), regardless of its type, nature, or implementation, via
the manipulation and transfer of representations (Section 6). the manipulation and transfer of representations (Section 6).
This document defines semantics that are common to all versions of This document defines semantics that are common to all versions of
HTTP. HTTP semantics include the intentions defined by each request HTTP. HTTP semantics include the intentions defined by each request
method (Section 7), extensions to those semantics that might be method (Section 7), extensions to those semantics that might be
described in request header fields (Section 8), the meaning of status described in request header fields (Section 8), the meaning of status
codes to indicate a machine-readable response (Section 9), and the codes to indicate a machine-readable response (Section 9), and the
skipping to change at page 9, line 35 skipping to change at page 9, line 35
This document defines HTTP range requests, partial responses, and the This document defines HTTP range requests, partial responses, and the
multipart/byteranges media type. multipart/byteranges media type.
This document obsoletes the portions of RFC 7230 that are independent This document obsoletes the portions of RFC 7230 that are independent
of the HTTP/1.1 messaging syntax and connection management, with the of the HTTP/1.1 messaging syntax and connection management, with the
changes being summarized in Appendix B.2. The other parts of RFC changes being summarized in Appendix B.2. The other parts of RFC
7230 are obsoleted by "HTTP/1.1 Messaging" [Messaging]. This 7230 are obsoleted by "HTTP/1.1 Messaging" [Messaging]. This
document also obsoletes RFC 2818 (see Appendix B.1), RFC 7231 (see document also obsoletes RFC 2818 (see Appendix B.1), RFC 7231 (see
Appendix B.3), RFC 7232 (see Appendix B.4), RFC 7233 (see Appendix B.3), RFC 7232 (see Appendix B.4), RFC 7233 (see
Appendix B.5), RFC 7235 (see Appendix B.6), RFC 7538 (see Appendix B.5), RFC 7235 (see Appendix B.6), RFC 7538 (see
Appendix B.7), and RFC 7615 (see Appendix B.8). Appendix B.7), RFC 7615 (see Appendix B.8), and RFC 7694 (see
Appendix C).
1.1. Requirements Notation 1.1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Conformance criteria and considerations regarding error handling are Conformance criteria and considerations regarding error handling are
skipping to change at page 10, line 32 skipping to change at page 10, line 32
CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double
quote), HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF quote), HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF
(line feed), OCTET (any 8-bit sequence of data), SP (space), and (line feed), OCTET (any 8-bit sequence of data), SP (space), and
VCHAR (any visible US-ASCII character). VCHAR (any visible US-ASCII character).
Section 4.4.1 defines some generic syntactic components for field Section 4.4.1 defines some generic syntactic components for field
values. values.
The rules below are defined in [Messaging]: The rules below are defined in [Messaging]:
obs-fold = <obs-fold, see [Messaging], Section 5.2>
protocol-name = <protocol-name, see [Messaging], Section 9.9> protocol-name = <protocol-name, see [Messaging], Section 9.9>
protocol-version = <protocol-version, see [Messaging], Section 9.9> protocol-version = <protocol-version, see [Messaging], Section 9.9>
request-target = <request-target, see [Messaging], Section 3.2>
This specification uses the terms "character", "character encoding This specification uses the terms "character", "character encoding
scheme", "charset", and "protocol element" as they are defined in scheme", "charset", and "protocol element" as they are defined in
[RFC6365]. [RFC6365].
1.2.1. Whitespace 1.2.1. Whitespace
This specification uses three rules to denote the use of linear This specification uses three rules to denote the use of linear
whitespace: OWS (optional whitespace), RWS (required whitespace), and whitespace: OWS (optional whitespace), RWS (required whitespace), and
BWS ("bad" whitespace). BWS ("bad" whitespace).
skipping to change at page 11, line 38 skipping to change at page 11, line 38
2. Architecture 2. Architecture
HTTP was created for the World Wide Web (WWW) architecture and has HTTP was created for the World Wide Web (WWW) architecture and has
evolved over time to support the scalability needs of a worldwide evolved over time to support the scalability needs of a worldwide
hypertext system. Much of that architecture is reflected in the hypertext system. Much of that architecture is reflected in the
terminology and syntax productions used to define HTTP. terminology and syntax productions used to define HTTP.
2.1. Client/Server Messaging 2.1. Client/Server Messaging
HTTP is a stateless request/response protocol that operates by HTTP is a stateless request/response protocol that operates by
exchanging messages (Section 2 of [Messaging]) across a reliable exchanging messages across a reliable transport- or session-layer
transport- or session-layer "connection" (Section 9 of [Messaging]). "connection". An HTTP "client" is a program that establishes a
An HTTP "client" is a program that establishes a connection to a connection to a server for the purpose of sending one or more HTTP
server for the purpose of sending one or more HTTP requests. An HTTP requests. An HTTP "server" is a program that accepts connections in
"server" is a program that accepts connections in order to service order to service HTTP requests by sending HTTP responses.
HTTP requests by sending HTTP responses.
The terms "client" and "server" refer only to the roles that these The terms "client" and "server" refer only to the roles that these
programs perform for a particular connection. The same program might programs perform for a particular connection. The same program might
act as a client on some connections and a server on others. The term act as a client on some connections and a server on others. The term
"user agent" refers to any of the various client programs that "user agent" refers to any of the various client programs that
initiate a request, including (but not limited to) browsers, spiders initiate a request, including (but not limited to) browsers, spiders
(web-based robots), command-line tools, custom applications, and (web-based robots), command-line tools, custom applications, and
mobile apps. The term "origin server" refers to the program that can mobile apps. The term "origin server" refers to the program that can
originate authoritative responses for a given target resource. The originate authoritative responses for a given target resource. The
terms "sender" and "recipient" refer to any implementation that sends terms "sender" and "recipient" refer to any implementation that sends
skipping to change at page 12, line 28 skipping to change at page 12, line 28
UA ======================================= O UA ======================================= O
< response < response
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, beginning with a method (Section 7) and URI, followed by message, beginning with a method (Section 7) and request target,
header fields containing request modifiers, client information, and followed by header fields containing request modifiers, client
representation metadata (Section 4), and finally a payload body (if information, and representation metadata (Section 4), and finally a
any, Section 6.3.3). payload body (if any, Section 6.3.3).
A server responds to a client's request by sending one or more HTTP A server responds to a client's request by sending one or more HTTP
response messages, each beginning with a success or error code response messages, each beginning with a success or error code
(Section 9), possibly followed by header fields containing server (Section 9), possibly followed by header fields containing server
information, resource metadata, and representation metadata information, resource metadata, and representation metadata
(Section 4), and finally a payload body (if any, Section 6.3.3). (Section 4), and finally a payload body (if any, Section 6.3.3).
One of the functions of the message framing mechanism is to assure
that messages are complete. A message is considered complete when
all of the octets indicated by its framing are available. Note that,
when no explicit framing is used, a response message that is ended by
the transport connection's close is considered complete even though
it might be indistinguishable from an incomplete response, unless a
transport-level error indicates that it is not complete.
A connection might be used for multiple request/response exchanges. A connection might be used for multiple request/response exchanges.
The mechanism used to correlate between request and response messages The mechanism used to correlate between request and response messages
is version dependent; some versions of HTTP use implicit ordering of is version dependent; some versions of HTTP use implicit ordering of
messages, while others use an explicit identifier. messages, while others use an explicit identifier.
Responses (both final and interim) can be sent at any time after a Responses (both final and interim) can be sent at any time after a
request is received, even if it is not yet complete. However, request is received, even if it is not yet complete. However,
clients (including intermediaries) might abandon a request if the clients (including intermediaries) might abandon a request if the
response is not forthcoming within a reasonable period of time. response is not forthcoming within a reasonable period of time.
skipping to change at page 16, line 51 skipping to change at page 17, line 23
query = <query, see [RFC3986], Section 3.4> query = <query, see [RFC3986], Section 3.4>
absolute-path = 1*( "/" segment ) absolute-path = 1*( "/" segment )
partial-URI = relative-part [ "?" query ] partial-URI = relative-part [ "?" query ]
Each protocol element in HTTP that allows a URI reference will Each protocol element in HTTP that allows a URI reference will
indicate in its ABNF production whether the element allows any form indicate in its ABNF production whether the element allows any form
of reference (URI-reference), only a URI in absolute form (absolute- of reference (URI-reference), only a URI in absolute form (absolute-
URI), only the path and optional query components, or some URI), only the path and optional query components, or some
combination of the above. Unless otherwise indicated, URI references combination of the above. Unless otherwise indicated, URI references
are parsed relative to the effective request URI (Section 5.5). are parsed relative to the target URI (Section 5.1).
It is RECOMMENDED that all senders and recipients support, at a It is RECOMMENDED that all senders and recipients support, at a
minimum, URIs with lengths of 8000 octets in protocol elements. Note minimum, URIs with lengths of 8000 octets in protocol elements. Note
that this implies some structures and on-wire representations (for that this implies some structures and on-wire representations (for
example, the request line in HTTP/1.1) will necessarily be larger in example, the request line in HTTP/1.1) will necessarily be larger in
some cases. some cases.
2.5. Resources 2.5. Resources
The target of an HTTP request is called a "resource". HTTP does not The target of an HTTP request is called a "resource". HTTP does not
limit the nature of a resource; it merely defines an interface that limit the nature of a resource; it merely defines an interface that
might be used to interact with resources. Each resource is might be used to interact with resources. Most resources are
identified by a Uniform Resource Identifier (URI), as described in identified by a Uniform Resource Identifier (URI), as described in
Section 2.4. Section 2.4.
One design goal of HTTP is to separate resource identification from One design goal of HTTP is to separate resource identification from
request semantics, which is made possible by vesting the request request semantics, which is made possible by vesting the request
semantics in the request method (Section 7) and a few request- semantics in the request method (Section 7) and a few request-
modifying header fields (Section 8). If there is a conflict between modifying header fields (Section 8). If there is a conflict between
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 7.2.1, the method semantics take precedence. described in Section 7.2.1, the method semantics take precedence.
skipping to change at page 19, line 21 skipping to change at page 19, line 44
host domains. host domains.
2.5.3. http and https URI Normalization and Comparison 2.5.3. http and https URI Normalization and Comparison
Since the "http" and "https" schemes conform to the URI generic Since the "http" and "https" schemes conform to the URI generic
syntax, such URIs are normalized and compared according to the syntax, such URIs are normalized and compared according to the
algorithm defined in Section 6 of [RFC3986], using the defaults algorithm defined in Section 6 of [RFC3986], using the defaults
described above for each scheme. described above for each scheme.
If the port is equal to the default port for a scheme, the normal If the port is equal to the default port for a scheme, the normal
form is to omit the port subcomponent. When not being used in form is to omit the port subcomponent. When not being used as the
absolute form as the request target of an OPTIONS request, an empty target of an OPTIONS request, an empty path component is equivalent
path component is equivalent to an absolute path of "/", so the to an absolute path of "/", so the normal form is to provide a path
normal form is to provide a path of "/" instead. The scheme and host of "/" instead. The scheme and host are case-insensitive and
are case-insensitive and normally provided in lowercase; all other normally provided in lowercase; all other components are compared in
components are compared in a case-sensitive manner. Characters other a case-sensitive manner. Characters other than those in the
than those in the "reserved" set are equivalent to their percent- "reserved" set are equivalent to their percent-encoded octets: the
encoded octets: the normal form is to not encode them (see Sections normal form is to not encode them (see Sections 2.1 and 2.2 of
2.1 and 2.2 of [RFC3986]). [RFC3986]).
For example, the following three URIs are equivalent: For example, the following three URIs are equivalent:
http://example.com:80/~smith/home.html http://example.com:80/~smith/home.html
http://EXAMPLE.com/%7Esmith/home.html http://EXAMPLE.com/%7Esmith/home.html
http://EXAMPLE.com:/%7esmith/home.html http://EXAMPLE.com:/%7esmith/home.html
2.5.4. Deprecated userinfo 2.5.4. Deprecated userinfo
The URI generic syntax for authority also includes a userinfo The URI generic syntax for authority also includes a userinfo
skipping to change at page 19, line 51 skipping to change at page 20, line 27
authentication information in the URI. In that subcomponent, the use authentication information in the URI. In that subcomponent, the use
of the format "user:password" is deprecated. of the format "user:password" is deprecated.
Some implementations make use of the userinfo component for internal Some implementations make use of the userinfo component for internal
configuration of authentication information, such as within command configuration of authentication information, such as within command
invocation options, configuration files, or bookmark lists, even invocation options, configuration files, or bookmark lists, even
though such usage might expose a user identifier or password. though such usage might expose a user identifier or password.
A sender MUST NOT generate the userinfo subcomponent (and its "@" A sender MUST NOT generate the userinfo subcomponent (and its "@"
delimiter) when an "http" or "https" URI reference is generated delimiter) when an "http" or "https" URI reference is generated
within a message as a request target or field value. within a message as a target URI or field value.
Before making use of an "http" or "https" URI reference received from Before making use of an "http" or "https" URI reference received from
an untrusted source, a recipient SHOULD parse for userinfo and treat an untrusted source, a recipient SHOULD parse for userinfo and treat
its presence as an error; it is likely being used to obscure the its presence as an error; it is likely being used to obscure the
authority for the sake of phishing attacks. authority for the sake of phishing attacks.
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
skipping to change at page 22, line 17 skipping to change at page 22, line 47
reasonable length for each protocol element. Furthermore, what is reasonable length for each protocol element. Furthermore, what is
commonly understood to be a reasonable length for some protocol commonly understood to be a reasonable length for some protocol
elements has changed over the course of the past two decades of HTTP elements has changed over the course of the past two decades of HTTP
use and is expected to continue changing in the future. use and is expected to continue changing in the future.
At a minimum, a recipient MUST be able to parse and process protocol At a minimum, a recipient MUST be able to parse and process protocol
element lengths that are at least as long as the values that it element lengths that are at least as long as the values that it
generates for those same protocol elements in other messages. For generates for those same protocol elements in other messages. For
example, an origin server that publishes very long URI references to example, an origin server that publishes very long URI references to
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 request target. 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 Accept-
Encoding header field if inspection of the User-Agent header field Encoding header field if inspection of the User-Agent header field
skipping to change at page 25, line 25 skipping to change at page 26, line 10
when not to handle a message as early as possible. A server MUST NOT when not to handle a message as early as possible. A server MUST NOT
apply a request to the target resource until the entire request apply a request to the target resource until the entire request
header section is received, since later header field lines might header section is received, since later header field lines might
include conditionals, authentication credentials, or deliberately include conditionals, authentication credentials, or deliberately
misleading duplicate header fields that would impact request misleading duplicate header fields that would impact request
processing. processing.
A recipient MAY combine multiple field lines with the same field name A recipient MAY combine multiple field lines with the same field name
into one field line, without changing the semantics of the message, into one field line, without changing the semantics of the message,
by appending each subsequent field line value to the initial field by appending each subsequent field line value to the initial field
line value in order, separated by a comma and optional whitespace. line value in order, separated by a comma and OWS (optional
For consistency, use comma SP. whitespace). For consistency, use comma SP.
The order in which field lines with the same name are received is The order in which field lines with the same name are received is
therefore significant to the interpretation of the field value; a therefore significant to the interpretation of the field value; a
proxy MUST NOT change the order of these field line values when proxy MUST NOT change the order of these field line values when
forwarding a message. forwarding a message.
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 4.5]. such as an ABNF rule of #(values) defined in Section 4.5].
Note: In practice, the "Set-Cookie" header field ([RFC6265]) often Note: In practice, the "Set-Cookie" header field ([RFC6265]) often
appears in a response message across multiple field and does not appears in a response message across multiple field lines and does
use the list syntax, violating the above requirements on multiple not use the list syntax, violating the above requirements on
field lines with the same field name. Since it cannot be combined multiple field lines with the same field name. Since it cannot be
into a single field value, recipients ought to handle "Set-Cookie" combined into a single field value, recipients ought to handle
as a special case while processing fields. (See Appendix A.2.3 of "Set-Cookie" as a special case while processing fields. (See
[Kri2001] for details.) Appendix A.2.3 of [Kri2001] for details.)
4.2. Field Limits 4.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 28, line 45 skipping to change at page 29, line 31
otherwise. otherwise.
4.4. Field Values 4.4. Field Values
HTTP field values typically have their syntax defined using ABNF HTTP field values typically have their syntax defined using ABNF
([RFC5234]), using the extension defined in Section 4.5 as necessary, ([RFC5234]), using the extension defined in Section 4.5 as necessary,
and are usually constrained to the range of US-ASCII characters. and are usually constrained to the range of US-ASCII characters.
Fields needing a greater range of characters can use an encoding such Fields needing a greater range of characters can use an encoding such
as the one defined in [RFC8187]. as the one defined in [RFC8187].
field-value = *( field-content / obs-fold ) field-value = *field-content
field-content = field-vchar field-content = field-vchar
[ 1*( SP / HTAB / field-vchar ) field-vchar ] [ 1*( SP / HTAB / field-vchar ) field-vchar ]
field-vchar = VCHAR / obs-text field-vchar = VCHAR / obs-text
Historically, HTTP allowed field content with text in the ISO-8859-1 Historically, HTTP allowed field content with text in the ISO-8859-1
charset [ISO-8859-1], supporting other charsets only through use of charset [ISO-8859-1], supporting other charsets only through use of
[RFC2047] encoding. In practice, most HTTP field values use only a [RFC2047] encoding. In practice, most HTTP field values use only a
subset of the US-ASCII charset [USASCII]. Newly defined fields subset of the US-ASCII charset [USASCII]. Newly defined fields
SHOULD limit their values to US-ASCII octets. A recipient SHOULD SHOULD limit their values to US-ASCII octets. A recipient SHOULD
treat other octets in field content (obs-text) as opaque data. treat other octets in field content (obs-text) as opaque data.
skipping to change at page 29, line 40 skipping to change at page 30, line 27
Many fields (such as Content-Type, defined in Section 6.2.1) use a Many fields (such as Content-Type, defined in Section 6.2.1) use a
common syntax for parameters that allows both unquoted (token) and common syntax for parameters that allows both unquoted (token) and
quoted (quoted-string) syntax for a parameter value quoted (quoted-string) syntax for a parameter value
(Section 4.4.1.4). Use of common syntax allows recipients to reuse (Section 4.4.1.4). Use of common syntax allows recipients to reuse
existing parser components. When allowing both forms, the meaning of existing parser components. When allowing both forms, the meaning of
a parameter value ought to be the same whether it was received as a a parameter value ought to be the same whether it was received as a
token or a quoted string. token or a quoted string.
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). [[CREF1: This document assumes that any such obs- tab (obs-fold). This document assumes that any such obsolete line
fold 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].
This specification does not use ABNF rules to define each "Field This specification does not use ABNF rules to define each "Field
Name: Field Value" pair, as was done in earlier editions. Name: Field Value" pair, as was done in earlier editions.
Instead, this specification uses ABNF rules that are named Instead, this specification uses ABNF rules that are named
according to each registered field name, wherein the rule defines according to each registered field name, wherein the rule defines
the valid grammar for that field's corresponding field values the valid grammar for that field's corresponding field values
(i.e., after the field value has been extracted by a generic field (i.e., after the field value has been extracted by a generic field
parser). parser).
4.4.1. Common Field Value Components 4.4.1. Common Field Value Components
skipping to change at page 31, line 23 skipping to change at page 32, line 9
preceding semicolon. preceding semicolon.
parameter = parameter-name "=" parameter-value parameter = parameter-name "=" parameter-value
parameter-name = token parameter-name = token
parameter-value = ( token / quoted-string ) parameter-value = ( token / quoted-string )
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 6.1.1) and the Accept header field be seen in media types (Section 6.1.1) and the Accept header field
(Section 8.4.2). (Section 8.4.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.
4.5. ABNF List Extension: #rule 4.5. ABNF List Extension: #rule
skipping to change at page 33, line 43 skipping to change at page 34, line 27
Trailer fields can be difficult to process by intermediaries that Trailer fields can be difficult to process by intermediaries that
forward messages from one protocol version to another. If the entire forward messages from one protocol version to another. If the entire
message can be buffered in transit, some intermediaries could merge message can be buffered in transit, some intermediaries could merge
trailer fields into the header section (as appropriate) before it is trailer fields into the header section (as appropriate) before it is
forwarded. However, in most cases, the trailers are simply forwarded. However, in most cases, the trailers are simply
discarded. A recipient MUST NOT merge a trailer field into a header discarded. A recipient MUST NOT merge a trailer field into a header
section unless the recipient understands the corresponding header section unless the recipient understands the corresponding header
field definition and that definition explicitly permits and defines field definition and that definition explicitly permits and defines
how trailer field values can be safely merged. how trailer field values can be safely merged.
A client can send a TE header field indicating "trailers" is The presence of the keyword "trailers" in the TE header field
acceptable, as described in Section 7.4 of [Messaging], to inform the (Section 7.4 of [Messaging]) indicates that the client is willing to
server that it will not discard trailer fields. accept trailer fields, on behalf of itself and any downstream
clients. For requests from an intermediary, this implies that all
downstream clients are willing to accept trailer fields in the
forwarded response. Note that the presence of "trailers" does not
mean that the client(s) will process any particular trailer field in
the response; only that the trailer section as a whole will not be
dropped by any of the clients.
Because of the potential for trailer fields to be discarded in Because of the potential for trailer fields to be discarded in
transit, a server SHOULD NOT generate trailer fields that it believes transit, a server SHOULD NOT generate trailer fields that it believes
are necessary for the user agent to receive. are necessary for the user agent to receive.
4.6.3. Trailer 4.6.3. Trailer
The "Trailer" header field provides a list of field names that the The "Trailer" header field provides a list of field names that the
sender anticipates sending as trailer fields within that message. sender anticipates sending as trailer fields within that message.
This allows a recipient to prepare for receipt of the indicated This allows a recipient to prepare for receipt of the indicated
skipping to change at page 35, line 5 skipping to change at page 35, line 38
multiple field instances into a single one, despite the field's multiple field instances into a single one, despite the field's
definition not allowing the list syntax. A robust format enables definition not allowing the list syntax. A robust format enables
recipients to discover these situations (good example: "Content- recipients to discover these situations (good example: "Content-
Type", as the comma can only appear inside quoted strings; bad Type", as the comma can only appear inside quoted strings; bad
example: "Location", as a comma can occur inside a URI). example: "Location", as a comma can occur inside a URI).
o Under what conditions the field can be used; e.g., only in o Under what conditions the field can be used; e.g., only in
responses or requests, in all messages, only on responses to a responses or requests, in all messages, only on responses to a
particular request method, etc. particular request method, etc.
o What the scope of applicability for the information conveyed in
the field is. By default, fields apply only to the message they
are associated with, but some response fields are designed to
apply to all representations of a resource, the resource itself,
or an even broader scope. Specifications that expand the scope of
a response field will need to carefully consider issues such as
content negotiation, the time period of applicability, and (in
some cases) multi-tenant server deployments.
o Whether the field should be stored by origin servers that o Whether the field should be stored by origin servers that
understand it upon a PUT request. understand it upon a PUT request.
o Whether the field semantics are further refined by the context, o Whether the field semantics are further refined by the context,
such as by existing request methods or status codes. such as by existing request methods or status codes.
o Whether it is appropriate to list the field name in the Connection o Whether it is appropriate to list the field name in the Connection
header field (i.e., if the field is to be hop-by-hop; see header field (i.e., if the field is to be hop-by-hop; see
Section 9.1 of [Messaging]). Section 9.1 of [Messaging]).
skipping to change at page 36, line 8 skipping to change at page 37, line 8
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.
4.8. Fields Defined In This Document 4.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 8.4.2 | | Accept | standard | Section 8.4.1 |
| Accept-Charset | deprecated | Section 8.4.3 | | Accept-Charset | deprecated | Section 8.4.2 |
| Accept-Encoding | standard | Section 8.4.4 | | Accept-Encoding | standard | Section 8.4.3 |
| Accept-Language | standard | Section 8.4.5 | | Accept-Language | standard | Section 8.4.4 |
| Accept-Ranges | standard | Section 10.4.1 | | Accept-Ranges | standard | Section 10.4.1 |
| Allow | standard | Section 10.4.2 | | Allow | standard | Section 10.4.2 |
| Authentication-Info | standard | Section 10.3.3 | | Authentication-Info | standard | Section 10.3.3 |
| Authorization | standard | Section 8.5.3 | | Authorization | standard | Section 8.5.3 |
| Content-Encoding | standard | Section 6.2.2 | | Content-Encoding | standard | Section 6.2.2 |
| Content-Language | standard | Section 6.2.3 | | Content-Language | standard | Section 6.2.3 |
| Content-Length | standard | Section 6.2.4 | | Content-Length | standard | Section 6.2.4 |
| Content-Location | standard | Section 6.2.5 | | Content-Location | standard | Section 6.2.5 |
| Content-Range | standard | Section 6.3.4 | | Content-Range | standard | Section 6.3.4 |
| Content-Type | standard | Section 6.2.1 | | Content-Type | standard | Section 6.2.1 |
skipping to change at page 37, line 23 skipping to change at page 38, line 23
5.1. Identifying a Target Resource 5.1. Identifying a Target Resource
HTTP is used in a wide variety of applications, ranging from general- HTTP is used in a wide variety of applications, ranging from general-
purpose computers to home appliances. In some cases, communication purpose computers to home appliances. In some cases, communication
options are hard-coded in a client's configuration. However, most options are hard-coded in a client's configuration. However, most
HTTP clients rely on the same resource identification mechanism and HTTP clients rely on the same resource identification mechanism and
configuration techniques as general-purpose Web browsers. configuration techniques as general-purpose Web browsers.
HTTP communication is initiated by a user agent for some purpose. HTTP communication is initiated by a user agent for some purpose.
The purpose is a combination of request semantics and a target The purpose is a combination of request semantics and a target
resource upon which to apply those semantics. A URI reference resource upon which to apply those semantics. The "request target"
(Section 2.4) is typically used as an identifier for the "target is the protocol element that identifies the "target resource".
resource", which a user agent would resolve to its absolute form in
order to obtain the "target URI". The target URI excludes the Typically, the request target is a URI reference (Section 2.4) which
reference's fragment component, if any, since fragment identifiers a user agent would resolve to its absolute form in order to obtain
are reserved for client-side processing ([RFC3986], Section 3.5). the "target URI". The target URI excludes the reference's fragment
component, if any, since fragment identifiers are reserved for
client-side processing ([RFC3986], Section 3.5).
However, there are two special, method-specific forms allowed for the
request target in specific circumstances:
o For CONNECT (Section 7.3.6), the request target is the host name
and port number of the tunnel destination, separated by a colon.
o For OPTIONS (Section 7.3.7), the request target can be a single
asterisk ("*").
See the respective method definitions for details. These forms MUST
NOT be used with other methods.
5.2. Determining Origin 5.2. Determining Origin
The "origin" for a given URI is the triple of scheme, host, and port The "origin" for a given URI is the triple of scheme, host, and port
after normalizing the scheme and host to lowercase and normalizing after normalizing the scheme and host to lowercase and normalizing
the port to remove any leading zeros. If port is elided from the the port to remove any leading zeros. If port is elided from the
URI, the default port for that scheme is used. For example, the URI URI, the default port for that scheme is used. For example, the URI
https://Example.Com/happy.js https://Example.Com/happy.js
skipping to change at page 38, line 41 skipping to change at page 40, line 7
to that proxy. to that proxy.
If no proxy is applicable, a typical client will invoke a handler If no proxy is applicable, a typical client will invoke a handler
routine, usually specific to the target URI's scheme, to connect routine, usually specific to the target URI's scheme, to connect
directly to an origin for the target resource. How that is directly to an origin for the target resource. How that is
accomplished is dependent on the target URI scheme and defined by its accomplished is dependent on the target URI scheme and defined by its
associated specification, similar to how this specification defines associated specification, similar to how this specification defines
origin server access for resolution of the "http" (Section 2.5.1) and origin server access for resolution of the "http" (Section 2.5.1) and
"https" (Section 2.5.2) schemes. "https" (Section 2.5.2) schemes.
HTTP requirements regarding connection management are defined in
Section 9 of [Messaging].
5.4. Direct Authoritative Access 5.4. Direct Authoritative Access
5.4.1. http origins 5.4.1. http origins
Although HTTP is independent of the transport protocol, the "http" Although HTTP is independent of the transport protocol, the "http"
scheme is specific to associating authority with whomever controls scheme is specific to associating authority with whomever controls
the origin server listening for TCP connections on the indicated port the origin server listening for TCP connections on the indicated port
of whatever host is identified within the authority component. This of whatever host is identified within the authority component. This
is a very weak sense of authority because it depends on both client- is a very weak sense of authority because it depends on both client-
specific name resolution mechanisms and communication that might not specific name resolution mechanisms and communication that might not
skipping to change at page 40, line 46 skipping to change at page 42, line 11
present in the certificate. However, a client will only do that if present in the certificate. However, a client will only do that if
it concludes that it could open a connection to the origin for that it concludes that it could open a connection to the origin for that
URI. In practice, a client will make a DNS query and see that it URI. In practice, a client will make a DNS query and see that it
contains the same server IP address. A server sending the ORIGIN contains the same server IP address. A server sending the ORIGIN
frame removes this restriction [RFC8336]. frame removes this restriction [RFC8336].
In addition to the client's verification, an origin server is In addition to the client's verification, an origin server is
responsible for verifying that requests it receives over a connection responsible for verifying that requests it receives over a connection
correspond to resources for which it actually wants to be the origin. correspond to resources for which it actually wants to be the origin.
If a network attacker causes connections for port N to be received at If a network attacker causes connections for port N to be received at
port Q, checking the effective request URI is necessary to ensure port Q, checking the target URI is necessary to ensure that the
that the attacker can't cause "https://example.com:N/foo" to be attacker can't cause "https://example.com:N/foo" to be replaced by
replaced by "https://example.com:Q/foo" without consent. Likewise, a "https://example.com:Q/foo" without consent. Likewise, a server
server might be unwilling to serve as the origin for some hosts even might be unwilling to serve as the origin for some hosts even when
when they have the authority to do so. they have the authority to do so.
When an "https" URI is used within a context that calls for access to When an "https" URI is used within a context that calls for access to
the indicated resource, a client MAY attempt access by resolving the the indicated resource, a client MAY attempt access by resolving the
host identifier to an IP address, establishing a TCP connection to host identifier to an IP address, establishing a TCP connection to
that address on the indicated port, securing the connection end-to- that address on the indicated port, securing the connection end-to-
end by successfully initiating TLS over TCP with confidentiality and end by successfully initiating TLS over TCP with confidentiality and
integrity protection, and sending an HTTP request message to the integrity protection, and sending an HTTP request message to the
server over that secured connection containing the URI's identifying server over that secured connection containing the URI's identifying
data (Section 2 of [Messaging]). data (Section 2 of [Messaging]).
skipping to change at page 43, line 5 skipping to change at page 44, line 13
meets their expectations. meets their expectations.
5.4.3.2. Identifying HTTPS Clients 5.4.3.2. Identifying HTTPS Clients
Typically, the server has no external knowledge of what the client's Typically, the server has no external knowledge of what the client's
identity ought to be and so checks (other than that the client has a identity ought to be and so checks (other than that the client has a
certificate chain rooted in an appropriate CA) are not possible. If certificate chain rooted in an appropriate CA) are not possible. If
a server has such knowledge (typically from some source external to a server has such knowledge (typically from some source external to
HTTP or TLS) it SHOULD check the identity as described above. HTTP or TLS) it SHOULD check the identity as described above.
5.5. Effective Request URI 5.5. Reconstructing the Target URI
Once an inbound connection is obtained, the client sends an HTTP Once an inbound connection is obtained, the client sends an HTTP
request message (Section 2 of [Messaging]). request message (Section 2 of [Messaging]).
Depending on the nature of the request, the client's target URI might Depending on the nature of the request, the client's target URI might
be split into components and transmitted (or implied) within various be split into components and transmitted (or implied) within various
parts of a request message. These parts are recombined by each parts of a request message. These parts are recombined by each
recipient, in accordance with their local configuration and incoming recipient, in accordance with their local configuration and incoming
connection context, to form an "effective request URI" for connection context, to determine the target URI. Appendix of
identifying the intended target resource with respect to that server. [Messaging] defines how a server determines the target URI for an
Section 3.3 of [Messaging] defines how a server determines the HTTP/1.1 request.
effective request URI for an HTTP/1.1 request.
For a user agent, the effective request URI is the target URI.
Once the effective request URI has been constructed, an origin server Once the target URI has been reconstructed, an origin server needs to
needs to decide whether or not to provide service for that URI via decide whether or not to provide service for that URI via the
the 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 request-target or Host such that the information within a received Host header field differs
header field differs from the host or port upon which the connection from the host or port upon which the connection has been made. If
has been made. If the connection is from a trusted gateway, that the connection is from a trusted gateway, that inconsistency might be
inconsistency might be expected; otherwise, it might indicate an expected; otherwise, it might indicate an attempt to bypass security
attempt to bypass security filters, trick the server into delivering filters, trick the server into delivering non-public content, or
non-public content, or poison a cache. See Section 11 for security poison a cache. See Section 11 for security considerations regarding
considerations regarding message routing. message routing.
Note: previous specifications defined the recomposed target URI as
a distinct concept, the effective request URI.
5.6. Host 5.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 44, line 11 skipping to change at page 45, line 19
Since the Host field value is critical information for handling a Since the Host field value is critical information for handling a
request, a user agent SHOULD generate Host as the first header field request, a user agent SHOULD generate Host as the first header field
following the request-line. following the request-line.
For example, a GET request to the origin server for For example, a GET request to the origin server for
<http://www.example.org/pub/WWW/> would begin with: <http://www.example.org/pub/WWW/> would begin with:
GET /pub/WWW/ HTTP/1.1 GET /pub/WWW/ HTTP/1.1
Host: www.example.org Host: www.example.org
A client MUST send a Host header field in an HTTP/1.1 request even if
the request-target is in the absolute-form, since this allows the
Host information to be forwarded through ancient HTTP/1.0 proxies
that might not have implemented Host.
When a proxy receives a request with an absolute-form of request-
target, the proxy MUST ignore the received Host header field (if any)
and instead replace it with the host information of the request-
target. A proxy that forwards such a request MUST generate a new
Host field value based on the received request-target rather than
forward the received Host field value.
When an origin server receives a request with an absolute-form of
request-target, the origin server MUST ignore the received Host
header field (if any) and instead use the host information of the
request-target. Note that if the request-target does not have an
authority component, an empty Host header field will be sent in this
case.
Since the Host header field acts as an application-level routing Since the Host header field acts as an application-level routing
mechanism, it is a frequent target for malware seeking to poison a mechanism, it is a frequent target for malware seeking to poison a
shared cache or redirect a request to an unintended server. An shared cache or redirect a request to an unintended server. An
interception proxy is particularly vulnerable if it relies on the interception proxy is particularly vulnerable if it relies on the
Host field value for redirecting requests to internal servers, or for Host field value for redirecting requests to internal servers, or for
use as a cache key in a shared cache, without first verifying that use as a cache key in a shared cache, without first verifying that
the intercepted connection is targeting a valid IP address for that the intercepted connection is targeting a valid IP address for that
host. host.
A server MUST respond with a 400 (Bad Request) status code to any A server MUST respond with a 400 (Bad Request) status code to any
skipping to change at page 47, line 34 skipping to change at page 48, line 22
meaningful way (i.e., modifications, beyond those required by normal meaningful way (i.e., modifications, beyond those required by normal
HTTP processing, that change the message in a way that would be HTTP processing, that change the message in a way that would be
significant to the original sender or potentially significant to significant to the original sender or potentially significant to
downstream recipients). For example, a transforming proxy might be downstream recipients). For example, a transforming proxy might be
acting as a shared annotation server (modifying responses to include acting as a shared annotation server (modifying responses to include
references to a local annotation database), a malware filter, a references to a local annotation database), a malware filter, a
format transcoder, or a privacy filter. Such transformations are format transcoder, or a privacy filter. Such transformations are
presumed to be desired by whichever client (or client organization) presumed to be desired by whichever client (or client organization)
selected the proxy. selected the proxy.
If a proxy receives a request-target with a host name that is not a If a proxy receives a target URI with a host name that is not a fully
fully qualified domain name, it MAY add its own domain to the host qualified domain name, it MAY add its own domain to the host name it
name it received when forwarding the request. A proxy MUST NOT received when forwarding the request. A proxy MUST NOT change the
change the host name if the request-target contains a fully qualified host name if the target URI contains a fully qualified domain name.
domain name.
A proxy MUST NOT modify the "absolute-path" and "query" parts of the A proxy MUST NOT modify the "absolute-path" and "query" parts of the
received request-target when forwarding it to the next inbound received target URI when forwarding it to the next inbound server,
server, except as noted above to replace an empty path with "/" or except as noted above to replace an empty path with "/" or "*".
"*".
A proxy MAY modify the message body through application or removal of A proxy MAY modify the message body through application or removal of
a transfer coding (Section 7 of [Messaging]). a transfer coding (Section 7 of [Messaging]).
A proxy MUST NOT transform the payload (Section 6.3) of a message A proxy MUST NOT transform the payload (Section 6.3) of a message
that contains a no-transform cache-control response directive that contains a no-transform cache-control response directive
(Section 5.2 of [Caching]). (Section 5.2 of [Caching]).
A proxy MAY transform the payload of a message that does not contain A proxy MAY transform the payload of a message that does not contain
a no-transform cache-control directive. A proxy that transforms the a no-transform cache-control directive. A proxy that transforms the
skipping to change at page 48, line 40 skipping to change at page 49, line 28
protocol, and that consists of a set of representation metadata and a protocol, and that consists of a set of representation metadata and a
potentially unbounded stream of representation data. potentially unbounded stream of representation data.
An origin server might be provided with, or be capable of generating, An origin server might be provided with, or be capable of generating,
multiple representations that are each intended to reflect the multiple representations that are each intended to reflect the
current state of a target resource. In such cases, some algorithm is current state of a target resource. In such cases, some algorithm is
used by the origin server to select one of those representations as used by the origin server to select one of those representations as
most applicable to a given request, usually based on content most applicable to a given request, usually based on content
negotiation. This "selected representation" is used to provide the negotiation. This "selected representation" is used to provide the
data and metadata for evaluating conditional requests (Section 8.2) data and metadata for evaluating conditional requests (Section 8.2)
and constructing the payload for 200 (OK) and 304 (Not Modified) and constructing the payload for 200 (OK), 206 (Partial Content), and
responses to GET (Section 7.3.1). 304 (Not Modified) responses to GET (Section 7.3.1).
6.1. Representation Data 6.1. Representation Data
The representation data associated with an HTTP message is either The representation data associated with an HTTP message is either
provided as the payload body of the message or referred to by the provided as the payload body of the message or referred to by the
message semantics and the effective request URI. The representation message semantics and the target URI. The representation data is in
data is in a format and encoding defined by the representation a format and encoding defined by the representation metadata header
metadata header fields. fields.
The data type of the representation data is determined via the header The data type of the representation data is determined via the header
fields Content-Type and Content-Encoding. These define a two-layer, fields Content-Type and Content-Encoding. These define a two-layer,
ordered encoding model: ordered encoding model:
representation-data := Content-Encoding( Content-Type( bits ) ) representation-data := Content-Encoding( Content-Type( bits ) )
6.1.1. Media Type 6.1.1. Media Type
HTTP uses media types [RFC2046] in the Content-Type (Section 6.2.1) HTTP uses media types [RFC2046] in the Content-Type (Section 6.2.1)
and Accept (Section 8.4.2) header fields in order to provide open and and Accept (Section 8.4.1) header fields in order to provide open and
extensible data typing and type negotiation. Media types define both extensible data typing and type negotiation. Media types define both
a data format and various processing models: how to process that data a data format and various processing models: how to process that data
in accordance with each context in which it is received. in accordance with each context in which it is received.
media-type = type "/" subtype *( OWS ";" OWS parameter ) media-type = type "/" subtype *( OWS ";" OWS parameter )
type = token type = token
subtype = token subtype = token
The type and subtype tokens are case-insensitive. The type and subtype tokens are case-insensitive.
skipping to change at page 51, line 29 skipping to change at page 52, line 21
underlying media type and without loss of information. Frequently, underlying media type and without loss of information. Frequently,
the representation is stored in coded form, transmitted directly, and the representation is stored in coded form, transmitted directly, and
only decoded by the final recipient. only decoded by the final recipient.
content-coding = token content-coding = token
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 6.1.2.4 Section 6.1.2.4
Content-coding values are used in the Accept-Encoding (Section 8.4.4) Content-coding values are used in the Accept-Encoding (Section 8.4.3)
and Content-Encoding (Section 6.2.2) header fields. and Content-Encoding (Section 6.2.2) header fields.
The following content-coding values are defined by this The following content-coding values are defined by this
specification: specification:
+------------+------------------------------------------+-----------+ +------------+------------------------------------------+-----------+
| Name | Description | Reference | | Name | Description | Reference |
+------------+------------------------------------------+-----------+ +------------+------------------------------------------+-----------+
| compress | UNIX "compress" data format [Welch] | Section 6 | | compress | UNIX "compress" data format [Welch] | Section 6 |
| | | .1.2.1 | | | | .1.2.1 |
| deflate | "deflate" compressed data ([RFC1951]) | Section 6 | | deflate | "deflate" compressed data ([RFC1951]) | Section 6 |
| | inside the "zlib" data format | .1.2.2 | | | inside the "zlib" data format | .1.2.2 |
| | ([RFC1950]) | | | | ([RFC1950]) | |
| gzip | GZIP file format [RFC1952] | Section 6 | | gzip | GZIP file format [RFC1952] | Section 6 |
| | | .1.2.3 | | | | .1.2.3 |
| identity | Reserved (synonym for "no encoding" in | Section 8 | | identity | Reserved (synonym for "no encoding" in | Section 8 |
| | Accept-Encoding) | .4.4 | | | Accept-Encoding) | .4.3 |
| x-compress | Deprecated (alias for compress) | Section 6 | | x-compress | Deprecated (alias for compress) | Section 6 |
| | | .1.2.1 | | | | .1.2.1 |
| x-gzip | Deprecated (alias for gzip) | Section 6 | | x-gzip | Deprecated (alias for gzip) | Section 6 |
| | | .1.2.3 | | | | .1.2.3 |
+------------+------------------------------------------+-----------+ +------------+------------------------------------------+-----------+
Table 2 Table 2
6.1.2.1. Compress Coding 6.1.2.1. Compress Coding
skipping to change at page 53, line 31 skipping to change at page 54, line 4
6.1.3. Language Tags 6.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 Content-
Language header fields. Accept-Language uses the broader language- Language header fields. Accept-Language uses the broader language-
range production defined in Section 8.4.5, whereas Content-Language range production defined in Section 8.4.4, whereas Content-Language
uses the language-tag production defined below. 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
skipping to change at page 61, line 12 skipping to change at page 61, line 46
linguistic audiences. An example would be a beginner's language linguistic audiences. An example would be a beginner's language
primer, such as "A First Lesson in Latin", which is clearly intended primer, such as "A First Lesson in Latin", which is clearly intended
to be used by an English-literate audience. In this case, the to be used by an English-literate audience. In this case, the
Content-Language would properly only include "en". Content-Language would properly only include "en".
Content-Language MAY be applied to any media type -- it is not Content-Language MAY be applied to any media type -- it is not
limited to textual documents. limited to textual documents.
6.2.4. Content-Length 6.2.4. Content-Length
[[CREF2: The "Content-Length" header field indicates the number of [[CREF1: The "Content-Length" header field indicates the number of
data octets (body length) for the representation. In some cases, data octets (body length) for the representation. In some cases,
Content-Length is used to define or estimate message framing. ]] Content-Length is used to define or estimate message framing. ]]
Content-Length = 1*DIGIT Content-Length = 1*DIGIT
An example is An example is
Content-Length: 3495 Content-Length: 3495
A sender MUST NOT send a Content-Length header field in any message A sender MUST NOT send a Content-Length header field in any message
that contains a Transfer-Encoding header field. that contains a Transfer-Encoding header field.
A user agent SHOULD send a Content-Length in a request message when A user agent SHOULD send a Content-Length in a request message when
no Transfer-Encoding is sent and the request method defines a meaning no Transfer-Encoding is sent and the request method defines a meaning
for an enclosed payload body. For example, a Content-Length header for an enclosed payload body. For example, a Content-Length header
field is normally sent in a POST request even when the value is 0 field is normally sent in a POST request even when the value is 0
(indicating an empty payload body). A user agent SHOULD NOT send a (indicating an empty payload body). A user agent SHOULD NOT send a
skipping to change at page 62, line 18 skipping to change at page 62, line 48
header section. This will allow downstream recipients to measure header section. This will allow downstream recipients to measure
transfer progress, know when a received message is complete, and transfer progress, know when a received message is complete, and
potentially reuse the connection for additional requests. potentially reuse the connection for additional requests.
Any Content-Length field value greater than or equal to zero is Any Content-Length field value greater than or equal to zero is
valid. Since there is no predefined limit to the length of a valid. Since there is no predefined limit to the length of a
payload, a recipient MUST anticipate potentially large decimal payload, a recipient MUST anticipate potentially large decimal
numerals and prevent parsing errors due to integer conversion numerals and prevent parsing errors due to integer conversion
overflows (Section 11.5). overflows (Section 11.5).
If a message is received that has multiple Content-Length header If a message is received that has a Content-Length header field value
fields with field values consisting of the same decimal value, or a consisting of the same decimal value as a comma-separated list
single Content-Length header field with a field value containing a (Section 4.5) -- for example, "Content-Length: 42, 42" -- indicating
list of identical decimal values (e.g., "Content-Length: 42, 42"), that duplicate Content-Length header fields have been generated or
indicating that duplicate Content-Length header fields have been combined by an upstream message processor, then the recipient MUST
generated or combined by an upstream message processor, then the either reject the message as invalid or replace the duplicated field
recipient MUST either reject the message as invalid or replace the values with a single valid Content-Length field containing that
duplicated field values with a single valid Content-Length field decimal value prior to determining the message body length or
containing that decimal value prior to determining the message body forwarding the message.
length or forwarding the message.
6.2.5. Content-Location 6.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
as an identifier for a specific resource corresponding to the as an identifier for a specific resource corresponding to the
representation in this message's payload. In other words, if one representation in this message's payload. In other words, if one
were to perform a GET request on this URI at the time of this were to perform a GET request on this URI at the time of this
message's generation, then a 200 (OK) response would contain the same message's generation, then a 200 (OK) response would contain the same
representation that is enclosed as payload in this message. representation that is enclosed as payload in this message.
Content-Location = absolute-URI / partial-URI Content-Location = absolute-URI / partial-URI
The Content-Location value is not a replacement for the effective The field value is either an absolute-URI or a partial-URI. In the
Request URI (Section 5.5). It is representation metadata. It has latter case (Section 2.4), the referenced URI is relative to the
the same syntax and semantics as the header field of the same name target URI ([RFC3986], Section 5).
defined for MIME body parts in Section 4 of [RFC2557]. However, its
appearance in an HTTP message has some special implications for HTTP The Content-Location value is not a replacement for the target URI
recipients. (Section 5.1). It is representation metadata. It has the same
syntax and semantics as the header field of the same name defined for
MIME body parts in Section 4 of [RFC2557]. However, its appearance
in an HTTP message has some special implications for HTTP recipients.
If Content-Location is included in a 2xx (Successful) response If Content-Location is included in a 2xx (Successful) response
message and its value refers (after conversion to absolute form) to a message and its value refers (after conversion to absolute form) to a
URI that is the same as the effective request URI, then the recipient URI that is the same as the target URI, then the recipient MAY
MAY consider the payload to be a current representation of that consider the payload to be a current representation of that resource
resource at the time indicated by the message origination date. For at the time indicated by the message origination date. For a GET
a GET (Section 7.3.1) or HEAD (Section 7.3.2) request, this is the (Section 7.3.1) or HEAD (Section 7.3.2) request, this is the same as
same as the default semantics when no Content-Location is provided by the default semantics when no Content-Location is provided by the
the server. For a state-changing request like PUT (Section 7.3.4) or server. For a state-changing request like PUT (Section 7.3.4) or
POST (Section 7.3.3), it implies that the server's response contains POST (Section 7.3.3), it implies that the server's response contains
the new representation of that resource, thereby distinguishing it the new representation of that resource, thereby distinguishing it
from representations that might only report about the action (e.g., from representations that might only report about the action (e.g.,
"It worked!"). This allows authoring applications to update their "It worked!"). This allows authoring applications to update their
local copies without the need for a subsequent GET request. local copies without the need for a subsequent GET request.
If Content-Location is included in a 2xx (Successful) response If Content-Location is included in a 2xx (Successful) response
message and its field value refers to a URI that differs from the message and its field value refers to a URI that differs from the
effective request URI, then the origin server claims that the URI is target URI, then the origin server claims that the URI is an
an identifier for a different resource corresponding to the enclosed identifier for a different resource corresponding to the enclosed
representation. Such a claim can only be trusted if both identifiers representation. Such a claim can only be trusted if both identifiers
share the same resource owner, which cannot be programmatically share the same resource owner, which cannot be programmatically
determined via HTTP. determined via HTTP.
o For a response to a GET or HEAD request, this is an indication o For a response to a GET or HEAD request, this is an indication
that the effective request URI refers to a resource that is that the target URI refers to a resource that is subject to
subject to content negotiation and the Content-Location field content negotiation and the Content-Location field value is a more
value is a more specific identifier for the selected specific identifier for the selected representation.
representation.
o For a 201 (Created) response to a state-changing method, a o For a 201 (Created) response to a state-changing method, a
Content-Location field value that is identical to the Location Content-Location field value that is identical to the Location
field value indicates that this payload is a current field value indicates that this payload is a current
representation of the newly created resource. representation of the newly created resource.
o Otherwise, such a Content-Location indicates that this payload is o Otherwise, such a Content-Location indicates that this payload is
a representation reporting on the requested action's status and a representation reporting on the requested action's status and
that the same report is available (for future access with GET) at that the same report is available (for future access with GET) at
the given URI. For example, a purchase transaction made via a the given URI. For example, a purchase transaction made via a
skipping to change at page 65, line 34 skipping to change at page 66, line 17
might still be useful for revision history links. might still be useful for revision history links.
o Otherwise, the payload is unidentified. o Otherwise, the payload is unidentified.
For a response message, the following rules are applied in order For a response message, the following rules are applied in order
until a match is found: until a match is found:
1. If the request method is GET or HEAD and the response status code 1. If the request method is GET or HEAD and the response status code
is 200 (OK), 204 (No Content), 206 (Partial Content), or 304 (Not is 200 (OK), 204 (No Content), 206 (Partial Content), or 304 (Not
Modified), the payload is a representation of the resource Modified), the payload is a representation of the resource
identified by the effective request URI (Section 5.5). identified by the target URI (Section 5.1).
2. If the request method is GET or HEAD and the response status code 2. If the request method is GET or HEAD and the response status code
is 203 (Non-Authoritative Information), the payload is a is 203 (Non-Authoritative Information), the payload is a
potentially modified or enhanced representation of the target potentially modified or enhanced representation of the target
resource as provided by an intermediary. resource as provided by an intermediary.
3. If the response has a Content-Location header field and its field 3. If the response has a Content-Location header field and its field
value is a reference to the same URI as the effective request value is a reference to the same URI as the target URI, the
URI, the payload is a representation of the resource identified payload is a representation of the target resource.
by the effective request URI.
4. If the response has a Content-Location header field and its field 4. If the response has a Content-Location header field and its field
value is a reference to a URI different from the effective value is a reference to a URI different from the target URI, then
request URI, then the sender asserts that the payload is a the sender asserts that the payload is a representation of the
representation of the resource identified by the Content-Location resource identified by the Content-Location field value.
field value. However, such an assertion cannot be trusted unless However, such an assertion cannot be trusted unless it can be
it can be verified by other means (not defined by this verified by other means (not defined by this specification).
specification).
5. Otherwise, the payload is unidentified. 5. Otherwise, the payload is unidentified.
6.3.3. Payload Body 6.3.3. Payload Body
The payload body contains the data of a request or response. This is The payload body contains the data of a request or response. This is
distinct from the message body (e.g., Section 6 of [Messaging]), distinct from the message body (e.g., Section 6 of [Messaging]),
which is how the payload body is transferred "on the wire", and might which is how the payload body is transferred "on the wire", and might
be encoded, depending on the HTTP version in use. be encoded, depending on the HTTP version in use.
skipping to change at page 70, line 43 skipping to change at page 71, line 30
When responses convey payload information, whether indicating a When responses convey payload information, whether indicating a
success or an error, the origin server often has different ways of success or an error, the origin server often has different ways of
representing that information; for example, in different formats, representing that information; for example, in different formats,
languages, or encodings. Likewise, different users or user agents languages, or encodings. Likewise, different users or user agents
might have differing capabilities, characteristics, or preferences might have differing capabilities, characteristics, or preferences
that could influence which representation, among those available, that could influence which representation, among those available,
would be best to deliver. For this reason, HTTP provides mechanisms would be best to deliver. For this reason, HTTP provides mechanisms
for content negotiation. for content negotiation.
This specification defines two patterns of content negotiation that This specification defines three patterns of content negotiation that
can be made visible within the protocol: "proactive", where the can be made visible within the protocol: "proactive" negotiation,
server selects the representation based upon the user agent's stated where the server selects the representation based upon the user
preferences, and "reactive" negotiation, where the server provides a agent's stated preferences, "reactive" negotiation, where the server
list of representations for the user agent to choose from. Other provides a list of representations for the user agent to choose from,
patterns of content negotiation include "conditional content", where and "request payload" negotiation, where the user agent selects the
the representation consists of multiple parts that are selectively representation for a future request based upon the server's stated
rendered based on user agent parameters, "active content", where the preferences in past responses. Other patterns of content negotiation
representation contains a script that makes additional (more include "conditional content", where the representation consists of
specific) requests based on the user agent characteristics, and multiple parts that are selectively rendered based on user agent
"Transparent Content Negotiation" ([RFC2295]), where content parameters, "active content", where the representation contains a
selection is performed by an intermediary. These patterns are not script that makes additional (more specific) requests based on the
mutually exclusive, and each has trade-offs in applicability and user agent characteristics, and "Transparent Content Negotiation"
practicality. ([RFC2295]), where content selection is performed by an intermediary.
These patterns are not mutually exclusive, and each has trade-offs in
applicability and practicality.
Note that, in all cases, HTTP is not aware of the resource semantics. Note that, in all cases, HTTP is not aware of the resource semantics.
The consistency with which an origin server responds to requests, The consistency with which an origin server responds to requests,
over time and over the varying dimensions of content negotiation, and over time and over the varying dimensions of content negotiation, and
thus the "sameness" of a resource's observed representations over thus the "sameness" of a resource's observed representations over
time, is determined entirely by whatever entity or algorithm selects time, is determined entirely by whatever entity or algorithm selects
or generates those responses. HTTP pays no attention to the man or generates those responses.
behind the curtain.
6.4.1. Proactive Negotiation 6.4.1. Proactive Negotiation
When content negotiation preferences are sent by the user agent in a When content negotiation preferences are sent by the user agent in a
request to encourage an algorithm located at the server to select the request to encourage an algorithm located at the server to select the
preferred representation, it is called proactive negotiation (a.k.a., preferred representation, it is called proactive negotiation (a.k.a.,
server-driven negotiation). Selection is based on the available server-driven negotiation). Selection is based on the available
representations for a response (the dimensions over which it might representations for a response (the dimensions over which it might
vary, such as language, content-coding, etc.) compared to various vary, such as language, content-coding, etc.) compared to various
information supplied in the request, including both the explicit information supplied in the request, including both the explicit
skipping to change at page 73, line 16 skipping to change at page 74, line 5
caches are used to distribute server load and reduce network usage. caches are used to distribute server load and reduce network usage.
Reactive negotiation suffers from the disadvantages of transmitting a Reactive negotiation suffers from the disadvantages of transmitting a
list of alternatives to the user agent, which degrades user-perceived list of alternatives to the user agent, which degrades user-perceived
latency if transmitted in the header section, and needing a second latency if transmitted in the header section, and needing a second
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.
6.4.3. Request Payload Negotiation
When content negotiation preferences are sent in a server's response,
the listed preferences are called request payload negotiation because
they intend to influence selection of an appropriate payload for
subsequent requests to that resource. For example, the Accept-
Encoding field (Section 8.4.3) can be sent in a response to indicate
preferred content codings for subsequent requests to that resource
[RFC7694].
Similarly, Section 3.1 of [RFC5789] defines the "Accept-Patch"
response header field which allows discovery of which content
types are accepted in PATCH requests.
6.4.4. Quality Values
The content negotiation fields defined by this specification use a
common parameter, named "q" (case-insensitive), to assign a relative
"weight" to the preference for that associated kind of content. This
weight is referred to as a "quality value" (or "qvalue") because the
same parameter name is often used within server configurations to
assign a weight to the relative quality of the various
representations that can be selected for a resource.
The weight is normalized to a real number in the range 0 through 1,
where 0.001 is the least preferred and 1 is the most preferred; a
value of 0 means "not acceptable". If no "q" parameter is present,
the default weight is 1.
weight = OWS ";" OWS "q=" qvalue
qvalue = ( "0" [ "." 0*3DIGIT ] )
/ ( "1" [ "." 0*3("0") ] )
A sender of qvalue MUST NOT generate more than three digits after the
decimal point. User configuration of these values ought to be
limited in the same fashion.
7. Request Methods 7. Request Methods
7.1. Overview 7.1. Overview
The request method token is the primary source of request semantics; The request method token is the primary source of request semantics;
it indicates the purpose for which the client has made this request it indicates the purpose for which the client has made this request
and what is expected by the client as a successful result. and what is expected by the client as a successful result.
The request method's semantics might be further specialized by the The request method's semantics might be further specialized by the
semantics of some header fields when present in a request (Section 8) semantics of some header fields when present in a request (Section 8)
skipping to change at page 74, line 13 skipping to change at page 76, line 10
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 target | 7.3.1 | | GET | Transfer a current representation of the target | 7.3.1 |
| | resource. | | | | resource. | |
| HEAD | Same as GET, but only transfer the status line | 7.3.2 | | HEAD | Same as GET, but do not transfer the response | 7.3.2 |
| | and header section. | | | | body. | |
| POST | Perform resource-specific processing on the | 7.3.3 | | POST | Perform resource-specific processing on the | 7.3.3 |
| | request payload. | | | | request payload. | |
| PUT | Replace all current representations of the | 7.3.4 | | PUT | Replace all current representations of the | 7.3.4 |
| | target resource with the request payload. | | | | target resource with the request payload. | |
| DELETE | Remove all current representations of the | 7.3.5 | | DELETE | Remove all current representations of the | 7.3.5 |
| | target resource. | | | | target resource. | |
| CONNECT | Establish a tunnel to the server identified by | 7.3.6 | | CONNECT | Establish a tunnel to the server identified by | 7.3.6 |
| | the target resource. | | | | the target resource. | |
| OPTIONS | Describe the communication options for the | 7.3.7 | | OPTIONS | Describe the communication options for the | 7.3.7 |
| | target resource. | | | | target resource. | |
skipping to change at page 76, line 9 skipping to change at page 78, line 9
allow automated retrieval processes (spiders) and cache performance allow automated retrieval processes (spiders) and cache performance
optimization (pre-fetching) to work without fear of causing harm. In optimization (pre-fetching) to work without fear of causing harm. In
addition, it allows a user agent to apply appropriate constraints on addition, it allows a user agent to apply appropriate constraints on
the automated use of unsafe methods when processing potentially the automated use of unsafe methods when processing potentially
untrusted content. untrusted content.
A user agent SHOULD distinguish between safe and unsafe methods when A user agent SHOULD distinguish between safe and unsafe methods when
presenting potential actions to a user, such that the user can be presenting potential actions to a user, such that the user can be
made aware of an unsafe action before it is requested. made aware of an unsafe action before it is requested.
When a resource is constructed such that parameters within the When a resource is constructed such that parameters within the target
effective request URI have the effect of selecting an action, it is URI have the effect of selecting an action, it is the resource
the resource owner's responsibility to ensure that the action is owner's responsibility to ensure that the action is consistent with
consistent with the request method semantics. For example, it is the request method semantics. For example, it is common for Web-
common for Web-based content editing software to use actions within based content editing software to use actions within query
query parameters, such as "page?do=delete". If the purpose of such a parameters, such as "page?do=delete". If the purpose of such a
resource is to perform an unsafe action, then the resource owner MUST resource is to perform an unsafe action, then the resource owner MUST
disable or disallow that action when it is accessed using a safe disable or disallow that action when it is accessed using a safe
request method. Failure to do so will result in unfortunate side request method. Failure to do so will result in unfortunate side
effects when automated processes perform a GET on every URI reference effects when automated processes perform a GET on every URI reference
for the sake of link maintenance, pre-fetching, building a search for the sake of link maintenance, pre-fetching, building a search
index, etc. index, etc.
7.2.2. Idempotent Methods 7.2.2. Idempotent Methods
A request method is considered "idempotent" if the intended effect on A request method is considered "idempotent" if the intended effect on
skipping to change at page 79, line 40 skipping to change at page 81, line 40
If one or more resources has been created on the origin server as a If one or more resources has been created on the origin server as a
result of successfully processing a POST request, the origin server result of successfully processing a POST request, the origin server
SHOULD send a 201 (Created) response containing a Location header SHOULD send a 201 (Created) response containing a Location header
field that provides an identifier for the primary resource created field that provides an identifier for the primary resource created
(Section 10.1.2) and a representation that describes the status of (Section 10.1.2) and a representation that describes the status of
the request while referring to the new resource(s). the request while referring to the new resource(s).
Responses to POST requests are only cacheable when they include Responses to POST requests are only cacheable when they include
explicit freshness information (see Section 4.2.1 of [Caching]) and a explicit freshness information (see Section 4.2.1 of [Caching]) and a
Content-Location header field that has the same value as the POST's Content-Location header field that has the same value as the POST's
effective request URI (Section 6.2.5). A cached POST response can be target URI (Section 6.2.5). A cached POST response can be reused to
reused to satisfy a later GET or HEAD request, but not a POST satisfy a later GET or HEAD request, but not a POST request, since
request, since POST is required to be written through to the origin POST is required to be written through to the origin server, because
server, because it is unsafe; see Section 4 of [Caching]. it is unsafe; see Section 4 of [Caching].
If the result of processing a POST would be equivalent to a If the result of processing a POST would be equivalent to a
representation of an existing resource, an origin server MAY redirect representation of an existing resource, an origin server MAY redirect
the user agent to that resource by sending a 303 (See Other) response the user agent to that resource by sending a 303 (See Other) response
with the existing resource's identifier in the Location field. This with the existing resource's identifier in the Location field. This
has the benefits of providing the user agent a resource identifier has the benefits of providing the user agent a resource identifier
and transferring the representation via a method more amenable to and transferring the representation via a method more amenable to
shared caching, though at the cost of an extra request if the user shared caching, though at the cost of an extra request if the user
agent does not already have the representation cached. agent does not already have the representation cached.
skipping to change at page 82, line 30 skipping to change at page 84, line 30
Content-Range header field (Section 6.3.4), since the payload is Content-Range header field (Section 6.3.4), since the payload is
likely to be partial content that has been mistakenly PUT as a full likely to be partial content that has been mistakenly PUT as a full
representation. Partial content updates are possible by targeting a representation. Partial content updates are possible by targeting a
separately identified resource with state that overlaps a portion of separately identified resource with state that overlaps a portion of
the larger resource, or by using a different method that has been the larger resource, or by using a different method that has been
specifically defined for partial updates (for example, the PATCH specifically defined for partial updates (for example, the PATCH
method defined in [RFC5789]). method defined in [RFC5789]).
Responses to the PUT method are not cacheable. If a successful PUT Responses to the PUT method are not cacheable. If a successful PUT
request passes through a cache that has one or more stored responses request passes through a cache that has one or more stored responses
for the effective request URI, those stored responses will be for the target URI, those stored responses will be invalidated (see
invalidated (see Section 4.4 of [Caching]). Section 4.4 of [Caching]).
7.3.5. DELETE 7.3.5. DELETE
The DELETE method requests that the origin server remove the The DELETE method requests that the origin server remove the
association between the target resource and its current association between the target resource and its current
functionality. In effect, this method is similar to the rm command functionality. In effect, this method is similar to the rm command
in UNIX: it expresses a deletion operation on the URI mapping of the in UNIX: it expresses a deletion operation on the URI mapping of the
origin server rather than an expectation that the previously origin server rather than an expectation that the previously
associated information be deleted. associated information be deleted.
skipping to change at page 83, line 36 skipping to change at page 85, line 36
o a 200 (OK) status code if the action has been enacted and the o a 200 (OK) status code if the action has been enacted and the
response message includes a representation describing the status. response message includes a representation describing the status.
A client SHOULD NOT generate a body in a DELETE request. A payload A client SHOULD NOT generate a body in a DELETE request. A payload
received in a DELETE request has no defined semantics, cannot alter received in a DELETE request has no defined semantics, cannot alter
the meaning or target of the request, and might lead some the meaning or target of the request, and might lead some
implementations to reject the request. implementations to reject the request.
Responses to the DELETE method are not cacheable. If a successful Responses to the DELETE method are not cacheable. If a successful
DELETE request passes through a cache that has one or more stored DELETE request passes through a cache that has one or more stored
responses for the effective request URI, those stored responses will responses for the target URI, those stored responses will be
be invalidated (see Section 4.4 of [Caching]). invalidated (see Section 4.4 of [Caching]).
7.3.6. CONNECT 7.3.6. CONNECT
The CONNECT method requests that the recipient establish a tunnel to The CONNECT method requests that the recipient establish a tunnel to
the destination origin server identified by the request-target and, the destination origin server identified by the request target and,
if successful, thereafter restrict its behavior to blind forwarding if successful, thereafter restrict its behavior to blind forwarding
of packets, in both directions, until the tunnel is closed. Tunnels of data, in both directions, until the tunnel is closed. Tunnels are
are commonly used to create an end-to-end virtual connection, through commonly used to create an end-to-end virtual connection, through one
one or more proxies, which can then be secured using TLS (Transport or more proxies, which can then be secured using TLS (Transport Layer
Layer Security, [RFC8446]). Security, [RFC8446]).
CONNECT is intended only for use in requests to a proxy. An origin CONNECT is intended only for use in requests to a proxy. An origin
server that receives a CONNECT request for itself MAY respond with a server that receives a CONNECT request for itself MAY respond with a
2xx (Successful) status code to indicate that a connection is 2xx (Successful) status code to indicate that a connection is
established. However, most origin servers do not implement CONNECT. established. However, most origin servers do not implement CONNECT.
A client sending a CONNECT request MUST send the authority form of A client sending a CONNECT request MUST send the authority component
request-target (Section 3.2 of [Messaging]); i.e., the request-target (described in Section 3.2 of [RFC3986]) as the request target; i.e.,
consists of only the host name and port number of the tunnel the request target consists of only the host name and port number of
destination, separated by a colon. For example, the tunnel destination, separated by a colon. For example,
CONNECT server.example.com:80 HTTP/1.1 CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com:80 Host: server.example.com:80
The recipient proxy can establish a tunnel either by directly The recipient proxy can establish a tunnel either by directly
connecting to the request-target or, if configured to use another connecting to the request target or, if configured to use another
proxy, by forwarding the CONNECT request to the next inbound proxy. proxy, by forwarding the CONNECT request to the next inbound proxy.
Any 2xx (Successful) response indicates that the sender (and all Any 2xx (Successful) response indicates that the sender (and all
inbound proxies) will switch to tunnel mode immediately after the inbound proxies) will switch to tunnel mode immediately after the
blank line that concludes the successful response's header section; blank line that concludes the successful response's header section;
data received after that blank line is from the server identified by data received after that blank line is from the server identified by
the request-target. Any response other than a successful response the request target. Any response other than a successful response
indicates that the tunnel has not yet been formed and that the indicates that the tunnel has not yet been formed and that the
connection remains governed by HTTP. connection remains governed by HTTP.
A tunnel is closed when a tunnel intermediary detects that either A tunnel is closed when a tunnel intermediary detects that either
side has closed its connection: the intermediary MUST attempt to send side has closed its connection: the intermediary MUST attempt to send
any outstanding data that came from the closed side to the other any outstanding data that came from the closed side to the other
side, close both connections, and then discard any remaining data side, close both connections, and then discard any remaining data
left undelivered. left undelivered.
Proxy authentication might be used to establish the authority to Proxy authentication might be used to establish the authority to
create a tunnel. For example, create a tunnel. For example,
CONNECT server.example.com:80 HTTP/1.1 CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com:80 Host: server.example.com:80
Proxy-Authorization: basic aGVsbG86d29ybGQ= Proxy-Authorization: basic aGVsbG86d29ybGQ=
There are significant risks in establishing a tunnel to arbitrary There are significant risks in establishing a tunnel to arbitrary
servers, particularly when the destination is a well-known or servers, particularly when the destination is a well-known or
reserved TCP port that is not intended for Web traffic. For example, reserved TCP port that is not intended for Web traffic. For example,
a CONNECT to a request-target of "example.com:25" would suggest that a CONNECT to "example.com:25" would suggest that the proxy connect to
the proxy connect to the reserved port for SMTP traffic; if allowed, the reserved port for SMTP traffic; if allowed, that could trick the
that could trick the proxy into relaying spam email. Proxies that proxy into relaying spam email. Proxies that support CONNECT SHOULD
support CONNECT SHOULD restrict its use to a limited set of known restrict its use to a limited set of known ports or a configurable
ports or a configurable whitelist of safe request targets. whitelist of safe request targets.
A server MUST NOT send any Transfer-Encoding or Content-Length header A server MUST NOT send any Transfer-Encoding or Content-Length header
fields in a 2xx (Successful) response to CONNECT. A client MUST fields in a 2xx (Successful) response to CONNECT. A client MUST
ignore any Content-Length or Transfer-Encoding header fields received ignore any Content-Length or Transfer-Encoding header fields received
in a successful response to CONNECT. in a successful response to CONNECT.
A payload within a CONNECT request message has no defined semantics; A payload within a CONNECT request message has no defined semantics;
sending a payload body on a CONNECT request might cause some existing sending a payload body on a CONNECT request might cause some existing
implementations to reject the request. implementations to reject the request.
skipping to change at page 85, line 20 skipping to change at page 87, line 20
7.3.7. OPTIONS 7.3.7. OPTIONS
The OPTIONS method requests information about the communication The OPTIONS method requests information about the communication
options available for the target resource, at either the origin options available for the target resource, at either the origin
server or an intervening intermediary. This method allows a client server or an intervening intermediary. This method allows a client
to determine the options and/or requirements associated with a to determine the options and/or requirements associated with a
resource, or the capabilities of a server, without implying a resource, or the capabilities of a server, without implying a
resource action. resource action.
An OPTIONS request with an asterisk ("*") as the request-target An OPTIONS request with an asterisk ("*") as the request target
(Section 3.2 of [Messaging]) applies to the server in general rather (Section 5.1) applies to the server in general rather than to a
than to a specific resource. Since a server's communication options specific resource. Since a server's communication options typically
typically depend on the resource, the "*" request is only useful as a depend on the resource, the "*" request is only useful as a "ping" or
"ping" or "no-op" type of method; it does nothing beyond allowing the "no-op" type of method; it does nothing beyond allowing the client to
client to test the capabilities of the server. For example, this can test the capabilities of the server. For example, this can be used
be used to test a proxy for HTTP/1.1 conformance (or lack thereof). to test a proxy for HTTP/1.1 conformance (or lack thereof).
If the request-target is not an asterisk, the OPTIONS request applies If the request target is not an asterisk, the OPTIONS request applies
to the options that are available when communicating with the target to the options that are available when communicating with the target
resource. resource.
A server generating a successful response to OPTIONS SHOULD send any A server generating a successful response to OPTIONS SHOULD send any
header that might indicate optional features implemented by the header that might indicate optional features implemented by the
server and applicable to the target resource (e.g., Allow), including server and applicable to the target resource (e.g., Allow), including
potential extensions not defined by this specification. The response potential extensions not defined by this specification. The response
payload, if any, might also describe the communication options in a payload, if any, might also describe the communication options in a
machine or human-readable representation. A standard format for such machine or human-readable representation. A standard format for such
a representation is not defined by this specification, but might be a representation is not defined by this specification, but might be
skipping to change at page 88, line 41 skipping to change at page 90, line 41
Expect = "100-continue" Expect = "100-continue"
The Expect field value is case-insensitive. The Expect field value is case-insensitive.
A server that receives an Expect field value other than 100-continue A server that receives an Expect field value other than 100-continue
MAY respond with a 417 (Expectation Failed) status code to indicate MAY respond with a 417 (Expectation Failed) status code to indicate
that the unexpected expectation cannot be met. that the unexpected expectation cannot be met.
A 100-continue expectation informs recipients that the client is A 100-continue expectation informs recipients that the client is
about to send a (presumably large) message body in this request and about to send a (presumably large) message body in this request and
wishes to receive a 100 (Continue) interim response if the request- wishes to receive a 100 (Continue) interim response if the method,
line and header fields are not sufficient to cause an immediate target URI, and header fields are not sufficient to cause an
success, redirect, or error response. This allows the client to wait immediate success, redirect, or error response. This allows the
for an indication that it is worthwhile to send the message body client to wait for an indication that it is worthwhile to send the
before actually doing so, which can improve efficiency when the message body before actually doing so, which can improve efficiency
message body is huge or when the client anticipates that an error is when the message body is huge or when the client anticipates that an
likely (e.g., when sending a state-changing method, for the first error is likely (e.g., when sending a state-changing method, for the
time, without previously verified authentication credentials). first time, without previously verified authentication credentials).
For example, a request that begins with For example, a request that begins with
PUT /somewhere/fun HTTP/1.1 PUT /somewhere/fun HTTP/1.1
Host: origin.example.com Host: origin.example.com
Content-Type: video/h264 Content-Type: video/h264
Content-Length: 1234567890987 Content-Length: 1234567890987
Expect: 100-continue Expect: 100-continue
allows the origin server to immediately respond with an error allows the origin server to immediately respond with an error
message, such as 401 (Unauthorized) or 405 (Method Not Allowed), message, such as 401 (Unauthorized) or 405 (Method Not Allowed),
skipping to change at page 90, line 10 skipping to change at page 92, line 10
o A server that sends a 100 (Continue) response MUST ultimately send o A server that sends a 100 (Continue) response MUST ultimately send
a final status code, once the message body is received and a final status code, once the message body is received and
processed, unless the connection is closed prematurely. processed, unless the connection is closed prematurely.
o A server that responds with a final status code before reading the o A server that responds with a final status code before reading the
entire request payload body SHOULD indicate whether it intends to entire request payload body SHOULD indicate whether it intends to
close the connection (see Section 9.7 of [Messaging]) or continue close the connection (see Section 9.7 of [Messaging]) or continue
reading the payload body. reading the payload body.
An origin server MUST, upon receiving an HTTP/1.1 (or later) request- An origin server MUST, upon receiving an HTTP/1.1 (or later) request
line and a complete header section that contains a 100-continue that has a method, target URI, and complete header section that
expectation and indicates a request message body will follow, either contains a 100-continue expectation and indicates a request message
send an immediate response with a final status code, if that status body will follow, either send an immediate response with a final
can be determined by examining just the request-line and header status code, if that status can be determined by examining just the
fields, or send an immediate 100 (Continue) response to encourage the method, target URI, and header fields, or send an immediate 100
client to send the request's message body. The origin server MUST (Continue) response to encourage the client to send the request's
NOT wait for the message body before sending the 100 (Continue) message body. The origin server MUST NOT wait for the message body
response. before sending the 100 (Continue) response.
A proxy MUST, upon receiving an HTTP/1.1 (or later) request-line and A proxy MUST, upon receiving an HTTP/1.1 (or later) request that has
a complete header section that contains a 100-continue expectation a method, target URI, and complete header section that contains a
and indicates a request message body will follow, either send an 100-continue expectation and indicates a request message body will
immediate response with a final status code, if that status can be follow, either send an immediate response with a final status code,
determined by examining just the request-line and header fields, or if that status can be determined by examining just the method, target
begin forwarding the request toward the origin server by sending a URI, and header fields, or begin forwarding the request toward the
corresponding request-line and header section to the next inbound origin server by sending a corresponding request-line and header
server. If the proxy believes (from configuration or past section to the next inbound server. If the proxy believes (from
interaction) that the next inbound server only supports HTTP/1.0, the configuration or past interaction) that the next inbound server only
proxy MAY generate an immediate 100 (Continue) response to encourage supports HTTP/1.0, the proxy MAY generate an immediate 100 (Continue)
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 an
interim 100 (Continue) response and the general mechanism for interim 100 (Continue) response and the general mechanism for
indicating must-understand extensions. However, the extension indicating must-understand extensions. However, the extension
mechanism has not been used by clients and the must-understand mechanism has not been used by clients and the must-understand
requirements have not been implemented by many servers, rendering requirements have not been implemented by many servers, rendering
the extension mechanism useless. This specification has removed the extension mechanism useless. This specification has removed
the extension mechanism in order to simplify the definition and the extension mechanism in order to simplify the definition and
processing of 100-continue. processing of 100-continue.
skipping to change at page 91, line 40 skipping to change at page 93, line 40
cache updates [Caching]. Conditionals can also be applied to state- cache updates [Caching]. Conditionals can also be applied to state-
changing methods, such as PUT and DELETE, to prevent the "lost changing methods, such as PUT and DELETE, to prevent the "lost
update" problem: one client accidentally overwriting the work of update" problem: one client accidentally overwriting the work of
another client that has been acting in parallel. another client that has been acting in parallel.
Conditional request preconditions are based on the state of the Conditional request preconditions are based on the state of the
target resource as a whole (its current value set) or the state as target resource as a whole (its current value set) or the state as
observed in a previously obtained representation (one value in that observed in a previously obtained representation (one value in that
set). A resource might have multiple current representations, each set). A resource might have multiple current representations, each
with its own observable state. The conditional request mechanisms with its own observable state. The conditional request mechanisms
assume that the mapping of requests to a "selected representation" assume that the mapping of requests to a selected representation
(Section 6) will be consistent over time if the server intends to (Section 6) will be consistent over time if the server intends to
take advantage of conditionals. Regardless, if the mapping is take advantage of conditionals. Regardless, if the mapping is
inconsistent and the server is unable to select the appropriate inconsistent and the server is unable to select the appropriate
representation, then no harm will result when the precondition representation, then no harm will result when the precondition
evaluates to false. evaluates to false.
The following request header fields allow a client to place a The following request header fields allow a client to place a
precondition on the state of the target resource, so that the action precondition on the state of the target resource, so that the action
corresponding to the method semantics will not be applied if the corresponding to the method semantics will not be applied if the
precondition evaluates to false. Each precondition defined by this precondition evaluates to false. Each precondition defined by this
skipping to change at page 95, line 5 skipping to change at page 97, line 5
* if the validator matches and the Range specification is * 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 * 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/1.1 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.
8.2.3. If-Match 8.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
the recipient origin server either having at least one current the recipient origin server either having at least one current
representation of the target resource, when the field value is "*", representation of the target resource, when the field value is "*",
or having a current representation of the target resource that has an or having a current representation of the target resource that has an
skipping to change at page 95, line 40 skipping to change at page 97, line 40
If-Match: * If-Match: *
If-Match is most often used with state-changing methods (e.g., POST, If-Match is most often used with state-changing methods (e.g., POST,
PUT, DELETE) to prevent accidental overwrites when multiple user PUT, DELETE) to prevent accidental overwrites when multiple user
agents might be acting in parallel on the same resource (i.e., to agents might be acting in parallel on the same resource (i.e., to
prevent the "lost update" problem). It can also be used with safe prevent the "lost update" problem). It can also be used with safe
methods to abort a request if the selected representation does not methods to abort a request if the selected representation does not
match one already stored (or partially stored) from a prior request. match one already stored (or partially stored) from a prior request.
An origin server that receives an If-Match header field MUST evaluate An origin server that receives an If-Match header field MUST evaluate
the condition prior to performing the method (Section 8.2.1). If the the condition prior to performing the method (Section 8.2.1).
field value is "*", the condition is false if the origin server does
not have a current representation for the target resource. If the To evaluate a received If-Match header field:
field value is a list of entity-tags, the condition is false if none
of the listed tags match the entity-tag of the selected 1. If the field value is "*", the condition is true if the origin
representation. server has a current representation for the target resource.
2. If the field value is a list of entity-tags, the condition is
true if any of the listed tags match the entity-tag of the
selected representation.
3. Otherwise, the condition is false.
An origin server MUST NOT perform the requested method if a received An origin server MUST NOT perform the requested method if a received
If-Match condition evaluates to false; instead, the origin server If-Match condition evaluates to false; instead, the origin server
MUST respond with either a) the 412 (Precondition Failed) status code MUST respond with either a) the 412 (Precondition Failed) status code
or b) one of the 2xx (Successful) status codes if the origin server or b) one of the 2xx (Successful) status codes if the origin server
has verified that a state change is being requested and the final has verified that a state change is being requested and the final
state is already reflected in the current state of the target state is already reflected in the current state of the target
resource (i.e., the change requested by the user agent has already resource (i.e., the change requested by the user agent has already
succeeded, but the user agent might not be aware of it, perhaps succeeded, but the user agent might not be aware of it, perhaps
because the prior response was lost or a compatible change was made because the prior response was lost or a compatible change was made
skipping to change at page 97, line 9 skipping to change at page 99, line 15
If-None-Match can also be used with a value of "*" to prevent an If-None-Match can also be used with a value of "*" to prevent an
unsafe request method (e.g., PUT) from inadvertently modifying an unsafe request method (e.g., PUT) from inadvertently modifying an
existing representation of the target resource when the client existing representation of the target resource when the client
believes that the resource does not have a current representation believes that the resource does not have a current representation
(Section 7.2.1). This is a variation on the "lost update" problem (Section 7.2.1). This is a variation on the "lost update" problem
that might arise if more than one client attempts to create an that might arise if more than one client attempts to create an
initial representation for the target resource. initial representation for the target resource.
An origin server that receives an If-None-Match header field MUST An origin server that receives an If-None-Match header field MUST
evaluate the condition prior to performing the method evaluate the condition prior to performing the method
(Section 8.2.1). If the field value is "*", the condition is false (Section 8.2.1).
if the origin server has a current representation for the target
resource. If the field value is a list of entity-tags, the condition To evaluate a received If-None-Match header field:
is false if one of the listed tags match the entity-tag of the
selected representation. 1. If the field value is "*", the condition is false if the origin
server has a current representation for the target resource.
2. If the field value is a list of entity-tags, the condition is
false if one of the listed tags matches the entity-tag of the
selected representation.
3. Otherwise, the condition is true.
An origin server MUST NOT perform the requested method if the An origin server MUST NOT perform the requested method if the
condition evaluates to false; instead, the origin server MUST respond condition evaluates to false; instead, the origin server MUST respond
with either a) the 304 (Not Modified) status code if the request with either a) the 304 (Not Modified) status code if the request
method is GET or HEAD or b) the 412 (Precondition Failed) status code method is GET or HEAD or b) the 412 (Precondition Failed) status code
for all other request methods. for all other request methods.
Requirements on cache handling of a received If-None-Match header Requirements on cache handling of a received If-None-Match header
field are defined in Section 4.3.2 of [Caching]. field are defined in Section 4.3.2 of [Caching].
skipping to change at page 99, line 30 skipping to change at page 101, line 43
If-Unmodified-Since is most often used with state-changing methods If-Unmodified-Since is most often used with state-changing methods
(e.g., POST, PUT, DELETE) to prevent accidental overwrites when (e.g., POST, PUT, DELETE) to prevent accidental overwrites when
multiple user agents might be acting in parallel on a resource that multiple user agents might be acting in parallel on a resource that
does not supply entity-tags with its representations (i.e., to does not supply entity-tags with its representations (i.e., to
prevent the "lost update" problem). It can also be used with safe prevent the "lost update" problem). It can also be used with safe
methods to abort a request if the selected representation does not methods to abort a request if the selected representation does not
match one already stored (or partially stored) from a prior request. match one already stored (or partially stored) from a prior request.
An origin server that receives an If-Unmodified-Since header field An origin server that receives an If-Unmodified-Since header field
MUST evaluate the condition prior to performing the method MUST evaluate the condition (Section 8.2.1) prior to performing the
(Section 8.2.1). The origin server MUST NOT perform the requested method.
method if the selected representation's last modification date is
more recent than the date provided in the field value; instead the If the selected representation has a last modification date, the
origin server MUST NOT perform the requested method if that date is
more recent than the date provided in the field value. Instead, the
origin server MUST respond with either a) the 412 (Precondition origin server MUST respond with either a) the 412 (Precondition
Failed) status code or b) one of the 2xx (Successful) status codes if Failed) status code or b) one of the 2xx (Successful) status codes if
the origin server has verified that a state change is being requested the origin server has verified that a state change is being requested
and the final state is already reflected in the current state of the and the final state is already reflected in the current state of the
target resource (i.e., the change requested by the user agent has target resource (i.e., the change requested by the user agent has
already succeeded, but the user agent might not be aware of that already succeeded, but the user agent might not be aware of that
because the prior response message was lost or a compatible change because the prior response message was lost or a compatible change
was made by some other user agent). In the latter case, the origin was made by some other user agent). In the latter case, the origin
server MUST NOT send a validator header field in the response unless server MUST NOT send a validator header field in the response unless
it can verify that the request is a duplicate of an immediately prior it can verify that the request is a duplicate of an immediately prior
skipping to change at page 101, line 13 skipping to change at page 103, line 25
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 If-
Unmodified-Since conditional. Unmodified-Since conditional.
8.3. Range 8.3. Range
The "Range" header field on a GET request modifies the method The "Range" header field on a GET request modifies the method
semantics to request transfer of only one or more subranges of the semantics to request transfer of only one or more subranges of the
selected representation data, rather than the entire selected selected representation data (Section 6.1), rather than the entire
representation data. selected representation.
Range = ranges-specifier Range = ranges-specifier
Clients often encounter interrupted data transfers as a result of Clients often encounter interrupted data transfers as a result of
canceled requests or dropped connections. When a client has stored a canceled requests or dropped connections. When a client has stored a
partial representation, it is desirable to request the remainder of partial representation, it is desirable to request the remainder of
that representation in a subsequent request rather than transfer the that representation in a subsequent request rather than transfer the
entire representation. Likewise, devices with limited local storage entire representation. Likewise, devices with limited local storage
might benefit from being able to request only a subset of a larger might benefit from being able to request only a subset of a larger
representation, such as a single page of a very large document, or representation, such as a single page of a very large document, or
skipping to change at page 102, line 38 skipping to change at page 105, line 5
valid and satisfiable (as defined in Section 6.1.4.2), the server valid and satisfiable (as defined in Section 6.1.4.2), the server
SHOULD send a 206 (Partial Content) response with a payload SHOULD send a 206 (Partial Content) response with a payload
containing one or more partial representations that correspond to the containing one or more partial representations that correspond to the
satisfiable ranges requested. satisfiable ranges requested.
If all of the preconditions are true, the server supports the Range If all of the preconditions are true, the server supports the Range
header field for the target resource, and the specified range(s) are header field for the target resource, and the specified range(s) are
invalid or unsatisfiable, the server SHOULD send a 416 (Range Not invalid or unsatisfiable, the server SHOULD send a 416 (Range Not
Satisfiable) response. Satisfiable) response.
8.4. Content Negotiation 8.4. Negotiation
The following request header fields are 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 6.4.1. The preferences sent in these fields apply to any in Section 6.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 8.4.2 | | Accept | Section 8.4.1 |
| Accept-Charset | Section 8.4.3 | | Accept-Charset | Section 8.4.2 |
| Accept-Encoding | Section 8.4.4 | | Accept-Encoding | Section 8.4.3 |
| Accept-Language | Section 8.4.5 | | Accept-Language | Section 8.4.4 |
+-----------------+---------------+ +-----------------+---------------+
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
skipping to change at page 103, line 42 skipping to change at page 106, line 5
the client. the client.
Note: In practice, using wildcards in content negotiation has limited Note: In practice, using wildcards in content negotiation has limited
practical value, because it is seldom useful to say, for example, "I practical value, because it is seldom useful to say, for example, "I
prefer image/* more or less than (some other specific value)". prefer image/* more or less than (some other specific value)".
Clients can explicitly request a 406 (Not Acceptable) response if a Clients can explicitly request a 406 (Not Acceptable) response if a
more preferred format is not available by sending Accept: */*;q=0, more preferred format is not available by sending Accept: */*;q=0,
but they still need to be able to handle a different response, since but they still need to be able to handle a different response, since
the server is allowed to ignore their preference. the server is allowed to ignore their preference.
8.4.1. Quality Values 8.4.1. Accept
Many of the request header fields for proactive negotiation use a
common parameter, named "q" (case-insensitive), to assign a relative
"weight" to the preference for that associated kind of content. This
weight is referred to as a "quality value" (or "qvalue") because the
same parameter name is often used within server configurations to
assign a weight to the relative quality of the various
representations that can be selected for a resource.
The weight is normalized to a real number in the range 0 through 1,
where 0.001 is the least preferred and 1 is the most preferred; a
value of 0 means "not acceptable". If no "q" parameter is present,
the default weight is 1.
weight = OWS ";" OWS "q=" qvalue
qvalue = ( "0" [ "." 0*3DIGIT ] )
/ ( "1" [ "." 0*3("0") ] )
A sender of qvalue MUST NOT generate more than three digits after the
decimal point. User configuration of these values ought to be
limited in the same fashion.
8.4.2. 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.
Accept = #( media-range [ accept-params ] ) Accept = #( media-range [ accept-params ] )
media-range = ( "*/*" media-range = ( "*/*"
skipping to change at page 104, line 42 skipping to change at page 106, line 29
accept-params = weight *( accept-ext ) accept-params = weight *( accept-ext )
accept-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ] accept-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ]
The asterisk "*" character is used to group media types into ranges, The asterisk "*" character is used to group media types into ranges,
with "*/*" indicating all media types and "type/*" indicating all with "*/*" indicating all media types and "type/*" indicating all
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 8.4.1), and then zero or more indicating a relative weight (Section 6.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 historical
practice. Although this prevents any media type parameter named practice. Although this prevents any media type parameter named
"q" from being used with a media range, such an event is believed "q" from being used with a media range, such an event is believed
to be unlikely given the lack of any "q" parameters in the IANA to be unlikely given the lack of any "q" parameters in the IANA
media type registry and the rare usage of any media type media type registry and the rare usage of any media type
skipping to change at page 106, line 21 skipping to change at page 108, line 5
| image/jpeg | 0.5 | | image/jpeg | 0.5 |
| text/html;level=2 | 0.4 | | text/html;level=2 | 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 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.
8.4.3. Accept-Charset 8.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
capability to an origin server that is capable of representing capability to an origin server that is capable of representing
information in those charsets. information in those charsets.
Accept-Charset = 1#( ( charset / "*" ) [ weight ] ) Accept-Charset = 1#( ( charset / "*" ) [ weight ] )
Charset names are defined in Section 6.1.1.1. A user agent MAY Charset names are defined in Section 6.1.1.1. A user agent MAY
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 8.4.1. relative preference for that charset, as defined in Section 6.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 11.11). Most general-purpose user agents do far too easy (Section 11.11). Most general-purpose user agents do
not send Accept-Charset, unless specifically configured to do so. not send Accept-Charset, unless specifically configured to do so.
8.4.4. Accept-Encoding 8.4.3. Accept-Encoding
The "Accept-Encoding" header field can be used by user agents to The "Accept-Encoding" header field can be used to indicate
indicate their preferences regarding response content-codings preferences regarding the use of content codings (Section 6.1.2).
(Section 6.1.2). An "identity" token is used as a synonym for "no
encoding" in order to communicate when no encoding is preferred. When sent by a user agent in a request, Accept-Encoding indicates the
content codings acceptable in a response.
When sent by a server in a response, Accept-Encoding provides
information about what content codings are preferred in the payload
of a subsequent request to the same resource.
An "identity" token is used as a synonym for "no encoding" in order
to communicate when no encoding is preferred.
Accept-Encoding = #( codings [ weight ] ) Accept-Encoding = #( codings [ weight ] )
codings = content-coding / "identity" / "*" codings = content-coding / "identity" / "*"
Each codings value MAY be given an associated quality value Each codings value MAY be given an associated quality value
representing the preference for that encoding, as defined in representing the preference for that encoding, as defined in
Section 8.4.1. The asterisk "*" symbol in an Accept-Encoding field Section 6.4.4. The asterisk "*" symbol in an Accept-Encoding field
matches any available content-coding not explicitly listed in the matches any available content-coding not explicitly listed in the
header field. header field.
For example, For example,
Accept-Encoding: compress, gzip Accept-Encoding: compress, gzip
Accept-Encoding: Accept-Encoding:
Accept-Encoding: * Accept-Encoding: *
Accept-Encoding: compress;q=0.5, gzip;q=1.0 Accept-Encoding: compress;q=0.5, gzip;q=1.0
Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0 Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0
skipping to change at page 107, line 43 skipping to change at page 109, line 30
is considered acceptable by the user agent. is considered acceptable by the user agent.
2. If the representation has no content-coding, then it is 2. If the representation has no content-coding, then it is
acceptable by default unless specifically excluded by the Accept- acceptable by default unless specifically excluded by the Accept-
Encoding field stating either "identity;q=0" or "*;q=0" without a Encoding field stating either "identity;q=0" or "*;q=0" without a
more specific entry for "identity". more specific entry for "identity".
3. If the representation's content-coding is one of the content- 3. If the representation's content-coding is one of the content-
codings listed in the Accept-Encoding field value, then it is codings listed in the Accept-Encoding field value, then it is
acceptable unless it is accompanied by a qvalue of 0. (As acceptable unless it is accompanied by a qvalue of 0. (As
defined in Section 8.4.1, a qvalue of 0 means "not acceptable".) defined in Section 6.4.4, a qvalue of 0 means "not acceptable".)
4. If multiple content-codings are acceptable, then the acceptable 4. If multiple content-codings are acceptable, then the acceptable
content-coding with the highest non-zero qvalue is preferred. content-coding with the highest non-zero qvalue is preferred.
An Accept-Encoding header field with a field value that is empty An Accept-Encoding header field with a field value that is empty
implies that the user agent does not want any content-coding in implies that the user agent does not want any content-coding in
response. If an Accept-Encoding header field is present in a request response. If an Accept-Encoding header field is present in a request
and none of the available representations for the response have a and none of the available representations for the response have a
content-coding that is listed as acceptable, the origin server SHOULD content-coding that is listed as acceptable, the origin server SHOULD
send a response without any content-coding. send a response without any content-coding.
When the Accept-Encoding header field is present in a response, it
indicates what content codings the resource was willing to accept in
the associated request. The field value is evaluated the same way as
in a request.
Note that this information is specific to the associated request; the
set of supported encodings might be different for other resources on
the same server and could change over time or depend on other aspects
of the request (such as the request method).
Servers that fail a request due to an unsupported content coding
ought to respond with a 415 (Unsupported Media Type) status and
include an Accept-Encoding header field in that response, allowing
clients to distinguish between issues related to content codings and
media types. In order to avoid confusion with issues related to
media types, servers that fail a request with a 415 status for
reasons unrelated to content codings MUST NOT include the Accept-
Encoding header field.
The most common use of Accept-Encoding is in responses with a 415
(Unsupported Media Type) status code, in response to optimistic use
of a content coding by clients. However, the header field can also
be used to indicate to clients that content codings are supported, to
optimize future interactions. For example, a resource might include
it in a 2xx (Successful) response when the request payload was big
enough to justify use of a compression coding but the client failed
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 qvalues
associated with content-codings. This means that qvalues might associated with content-codings. This means that qvalues might
not work and are not permitted with x-gzip or x-compress. not work and are not permitted with x-gzip or x-compress.
8.4.5. Accept-Language 8.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 6.1.3. response. Language tags are defined in Section 6.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>
Each language-range can be given an associated quality value Each language-range can be given an associated quality value
representing an estimate of the user's preference for the languages representing an estimate of the user's preference for the languages
specified by that range, as defined in Section 8.4.1. For example, specified by that range, as defined in Section 6.4.4. For example,
Accept-Language: da, en-gb;q=0.8, en;q=0.7 Accept-Language: da, en-gb;q=0.8, en;q=0.7
would mean: "I prefer Danish, but will accept British English and would mean: "I prefer Danish, but will accept British English and
other types of English". other types of English".
Note that some recipients treat the order in which language tags are Note that some recipients treat the order in which language tags are
listed as an indication of descending priority, particularly for tags listed as an indication of descending priority, particularly for tags
that are assigned equal quality values (no value is the same as q=1). that are assigned equal quality values (no value is the same as q=1).
However, this behavior cannot be relied upon. For consistency and to However, this behavior cannot be relied upon. For consistency and to
skipping to change at page 111, line 40 skipping to change at page 114, line 6
encapsulation, and with additional header fields specifying encapsulation, and with additional header fields specifying
authentication information. However, such additional mechanisms are authentication information. However, such additional mechanisms are
not defined by this specification. not defined by this specification.
8.5.2. Protection Space (Realm) 8.5.2. Protection Space (Realm)
The "realm" authentication parameter is reserved for use by The "realm" authentication parameter is reserved for use by
authentication schemes that wish to indicate a scope of protection. authentication schemes that wish to indicate a scope of protection.
A protection space is defined by the canonical root URI (the scheme A protection space is defined by the canonical root URI (the scheme
and authority components of the effective request URI; see and authority components of the target URI; see Section 5.1) of the
Section 5.5) of the server being accessed, in combination with the server being accessed, in combination with the realm value if
realm value if present. These realms allow the protected resources present. These realms allow the protected resources on a server to
on a server to be partitioned into a set of protection spaces, each be partitioned into a set of protection spaces, each with its own
with its own authentication scheme and/or authorization database. authentication scheme and/or authorization database. The realm value
The realm value is a string, generally assigned by the origin server, is a string, generally assigned by the origin server, that can have
that can have additional semantics specific to the authentication additional semantics specific to the authentication scheme. Note
scheme. Note that a response can have multiple challenges with the that a response can have multiple challenges with the same auth-
same auth-scheme but with different realms. scheme but with different realms.
The protection space determines the domain over which credentials can The protection space determines the domain over which credentials can
be automatically applied. If a prior request has been authorized, be automatically applied. If a prior request has been authorized,
the user agent MAY reuse the same credentials for all other requests the user agent MAY reuse the same credentials for all other requests
within that protection space for a period of time determined by the within that protection space for a period of time determined by the
authentication scheme, parameters, and/or user preferences (such as a authentication scheme, parameters, and/or user preferences (such as a
configurable inactivity timeout). Unless specifically allowed by the configurable inactivity timeout). Unless specifically allowed by the
authentication scheme, a single protection space cannot extend authentication scheme, a single protection space cannot extend
outside the scope of its server. outside the scope of its server.
skipping to change at page 112, line 33 skipping to change at page 114, line 47
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
challenge value or using synchronized clocks). challenge value or using synchronized clocks).
A proxy forwarding a request MUST NOT modify any Authorization fields A proxy forwarding a request MUST NOT modify any Authorization fields
in that request. See Section 3.2 of [Caching] for details of and in that request. See Section 3.3 of [Caching] for details of and
requirements pertaining to handling of the Authorization field by requirements pertaining to handling of the Authorization field by
HTTP caches. HTTP caches.
8.5.4. Proxy-Authorization 8.5.4. Proxy-Authorization
The "Proxy-Authorization" header field allows the client to identify The "Proxy-Authorization" header field allows the client to identify
itself (or its user) to a proxy that requires authentication. Its itself (or its user) to a proxy that requires authentication. Its
value consists of credentials containing the authentication value consists of credentials containing the authentication
information of the client for the proxy and/or realm of the resource information of the client for the proxy and/or realm of the resource
being requested. being requested.
skipping to change at page 116, line 30 skipping to change at page 118, line 45
The "Referer" [sic] header field allows the user agent to specify a The "Referer" [sic] header field allows the user agent to specify a
URI reference for the resource from which the target URI was obtained URI reference for the resource from which the target URI was obtained
(i.e., the "referrer", though the field name is misspelled). A user (i.e., the "referrer", though the field name is misspelled). A user
agent MUST NOT include the fragment and userinfo components of the agent MUST NOT include the fragment and userinfo components of the
URI reference [RFC3986], if any, when generating the Referer field URI reference [RFC3986], if any, when generating the Referer field
value. value.
Referer = absolute-URI / partial-URI Referer = absolute-URI / partial-URI
The field value is either an absolute-URI or a partial-URI. In the
latter case (Section 2.4), the referenced URI is relative to the
target URI ([RFC3986], Section 5).
The Referer header field allows servers to generate back-links to The Referer header field allows servers to generate back-links to
other resources for simple analytics, logging, optimized caching, other resources for simple analytics, logging, optimized caching,
etc. It also allows obsolete or mistyped links to be found for etc. It also allows obsolete or mistyped links to be found for
maintenance. Some servers use the Referer header field as a means of maintenance. Some servers use the Referer header field as a means of
denying links from other sites (so-called "deep linking") or denying links from other sites (so-called "deep linking") or
restricting cross-site request forgery (CSRF), but not all requests restricting cross-site request forgery (CSRF), but not all requests
contain it. contain it.
Example: Example:
skipping to change at page 117, line 19 skipping to change at page 119, line 38
Some intermediaries have been known to indiscriminately remove Some intermediaries have been known to indiscriminately remove
Referer header fields from outgoing requests. This has the Referer header fields from outgoing requests. This has the
unfortunate side effect of interfering with protection against CSRF unfortunate side effect of interfering with protection against CSRF
attacks, which can be far more harmful to their users. attacks, which can be far more harmful to their users.
Intermediaries and user agent extensions that wish to limit Intermediaries and user agent extensions that wish to limit
information disclosure in Referer ought to restrict their changes to information disclosure in Referer ought to restrict their changes to
specific edits, such as replacing internal domain names with specific edits, such as replacing internal domain names with
pseudonyms or truncating the query and/or path components. An pseudonyms or truncating the query and/or path components. An
intermediary SHOULD NOT modify or delete the Referer header field intermediary SHOULD NOT modify or delete the Referer header field
when the field value shares the same scheme and host as the request when the field value shares the same scheme and host as the target
target. URI.
8.6.3. User-Agent 8.6.3. User-Agent
The "User-Agent" header field contains information about the user The "User-Agent" header field contains information about the user
agent originating the request, which is often used by servers to help agent originating the request, which is often used by servers to help
identify the scope of reported interoperability problems, to work identify the scope of reported interoperability problems, to work
around or tailor responses to avoid particular user agent around or tailor responses to avoid particular user agent
limitations, and for analytics regarding browser or operating system limitations, and for analytics regarding browser or operating system
use. A user agent SHOULD send a User-Agent field in each request use. A user agent SHOULD send a User-Agent field in each request
unless specifically configured not to do so. unless specifically configured not to do so.
skipping to change at page 120, line 40 skipping to change at page 123, line 10
Table 6 Table 6
Note that this list is not exhaustive -- it does not include Note that this list is not exhaustive -- it does not include
extension status codes defined in other specifications (Section 9.7). extension status codes defined in other specifications (Section 9.7).
9.2. Informational 1xx 9.2. Informational 1xx
The 1xx (Informational) class of status code indicates an interim The 1xx (Informational) class of status code indicates an interim
response for communicating connection status or request progress response for communicating connection status or request progress
prior to completing the requested action and sending a final prior to completing the requested action and sending a final
response. 1xx responses are terminated by the first empty line after response. 1xx responses are terminated by the end of the header
the status-line (the empty line signaling 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.
A client MUST be able to parse one or more 1xx responses received A client MUST be able to parse one or more 1xx responses received
prior to a final response, even if the client does not expect one. A prior to a final response, even if the client does not expect one. A
user agent MAY ignore unexpected 1xx responses. user agent MAY ignore unexpected 1xx responses.
A proxy MUST forward 1xx responses unless the proxy itself requested A proxy MUST forward 1xx responses unless the proxy itself requested
the generation of the 1xx response. For example, if a proxy adds an the generation of the 1xx response. For example, if a proxy adds an
"Expect: 100-continue" field when it forwards a request, then it need "Expect: 100-continue" field when it forwards a request, then it need
not forward the corresponding 100 (Continue) response(s). not forward the corresponding 100 (Continue) response(s).
skipping to change at page 122, line 37 skipping to change at page 124, line 51
A 200 response is heuristically cacheable; i.e., unless otherwise A 200 response is heuristically cacheable; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [Caching]). Section 4.2.2 of [Caching]).
9.3.2. 201 Created 9.3.2. 201 Created
The 201 (Created) status code indicates that the request has been The 201 (Created) status code indicates that the request has been
fulfilled and has resulted in one or more new resources being fulfilled and has resulted in one or more new resources being
created. The primary resource created by the request is identified created. The primary resource created by the request is identified
by either a Location header field in the response or, if no Location by either a Location header field in the response or, if no Location
field is received, by the effective request URI. field is received, by the target URI.
The 201 response payload typically describes and links to the The 201 response payload typically describes and links to the
resource(s) created. See Section 10.2 for a discussion of the resource(s) created. See Section 10.2 for a discussion of the
meaning and purpose of validator header fields, such as ETag and meaning and purpose of validator header fields, such as ETag and
Last-Modified, in a 201 response. Last-Modified, in a 201 response.
9.3.3. 202 Accepted 9.3.3. 202 Accepted
The 202 (Accepted) status code indicates that the request has been The 202 (Accepted) status code indicates that the request has been
accepted for processing, but the processing has not been completed. accepted for processing, but the processing has not been completed.
skipping to change at page 124, line 33 skipping to change at page 126, line 48
state as received from the origin server. state as received from the origin server.
This response is intended to support a common data entry use case This response is intended to support a common data entry use case
where the user receives content that supports data entry (a form, where the user receives content that supports data entry (a form,
notepad, canvas, etc.), enters or manipulates data in that space, notepad, canvas, etc.), enters or manipulates data in that space,
causes the entered data to be submitted in a request, and then the causes the entered data to be submitted in a request, and then the
data entry mechanism is reset for the next entry so that the user can data entry mechanism is reset for the next entry so that the user can
easily initiate another input action. easily initiate another input action.
Since the 205 status code implies that no additional content will be Since the 205 status code implies that no additional content will be
provided, a server MUST NOT generate a payload in a 205 response. In provided, a server MUST NOT generate a payload in a 205 response.
other words, a server MUST do one of the following for a 205
response: a) indicate a zero-length body for the response by
including a Content-Length header field with a value of 0; b)
indicate a zero-length payload for the response by including a
Transfer-Encoding header field with a value of chunked and a message
body consisting of a single chunk of zero-length; or, c) close the
connection immediately after sending the blank line terminating the
header section.
9.3.7. 206 Partial Content 9.3.7. 206 Partial Content
The 206 (Partial Content) status code indicates that the server is The 206 (Partial Content) status code indicates that the server is
successfully fulfilling a range request for the target resource by successfully fulfilling a range request for the target resource by
transferring one or more parts of the selected representation. transferring one or more parts of the selected representation.
When a 206 response is generated, the server MUST generate the When a 206 response is generated, the server MUST generate the
following header fields, in addition to those required in the following header fields, in addition to those required in the
subsections below, if the field would have been sent in a 200 (OK) subsections below, if the field would have been sent in a 200 (OK)
skipping to change at page 128, line 16 skipping to change at page 130, line 26
since the user might not wish to redirect an unsafe request. since the user might not wish to redirect an unsafe request.
There are several types of redirects: There are several types of redirects:
1. Redirects that indicate the resource might be available at a 1. Redirects that indicate the resource might be available at a
different URI, as provided by the Location field, as in the different URI, as provided by the Location field, as in the
status codes 301 (Moved Permanently), 302 (Found), 307 (Temporary status codes 301 (Moved Permanently), 302 (Found), 307 (Temporary
Redirect), and 308 (Permanent Redirect). Redirect), and 308 (Permanent Redirect).
2. Redirection that offers a choice of matching resources, each 2. Redirection that offers a choice of matching resources, each
capable of representing the original request target, 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) and
skipping to change at page 130, line 13 skipping to change at page 132, line 22
Link header field value [RFC8288] whose members have a Link header field value [RFC8288] whose members have a
relationship of "alternate", though deployment is a chicken-and- relationship of "alternate", though deployment is a chicken-and-
egg problem. egg problem.
9.4.2. 301 Moved Permanently 9.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 effective request URI to one or more of the new references to the target URI to one or more of the new references
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 request
method from POST to GET for the subsequent request. If this method from POST to GET for the subsequent request. If this
behavior is undesired, the 308 (Permanent Redirect) status code behavior is undesired, the 308 (Permanent Redirect) status code
skipping to change at page 130, line 36 skipping to change at page 132, line 45
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]).
9.4.3. 302 Found 9.4.3. 302 Found
The 302 (Found) status code indicates that the target resource The 302 (Found) status code indicates that the target resource
resides temporarily under a different URI. Since the redirection resides temporarily under a different URI. Since the redirection
might be altered on occasion, the client ought to continue to use the might be altered on occasion, the client ought to continue to use the
effective request URI for future requests. 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 request
method from POST to GET for the subsequent request. If this method from POST to GET for the subsequent request. If this
behavior is undesired, the 307 (Temporary Redirect) status code behavior is undesired, the 307 (Temporary Redirect) status code
skipping to change at page 131, line 15 skipping to change at page 133, line 20
9.4.4. 303 See Other 9.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
in the Location header field is not considered equivalent to the in the Location header field is not considered equivalent to the
effective request URI. target URI.
This status code is applicable to any HTTP method. It is primarily This status code is applicable to any HTTP method. It is primarily
used to allow the output of a POST action to redirect the user agent used to allow the output of a POST action to redirect the user agent
to a selected resource, since doing so provides the information to a selected resource, since doing so provides the information
corresponding to the POST response in a form that can be separately corresponding to the POST response in a form that can be separately
identified, bookmarked, and cached, independent of the original identified, bookmarked, and cached, independent of the original
request. request.
A 303 response to a GET request indicates that the origin server does A 303 response to a GET request indicates that the origin server does
not have a representation of the target resource that can be not have a representation of the target resource that can be
skipping to change at page 132, line 39 skipping to change at page 134, line 44
The 306 status code was defined in a previous version of this The 306 status code was defined in a previous version of this
specification, is no longer used, and the code is reserved. specification, is no longer used, and the code is reserved.
9.4.8. 307 Temporary Redirect 9.4.8. 307 Temporary Redirect
The 307 (Temporary Redirect) status code indicates that the target The 307 (Temporary Redirect) status code indicates that the target
resource resides temporarily under a different URI and the user agent resource resides temporarily under a different URI and the user agent
MUST NOT change the request method if it performs an automatic MUST NOT change the request method if it performs an automatic
redirection to that URI. Since the redirection can change over time, redirection to that URI. Since the redirection can change over time,
the client ought to continue using the original effective request URI the client ought to continue using the original target URI for future
for future requests. 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).
9.4.9. 308 Permanent Redirect 9.4.9. 308 Permanent Redirect
The 308 (Permanent Redirect) status code indicates that the target The 308 (Permanent Redirect) 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 effective request URI to one or more of the new references to the target URI to one or more of the new references
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).
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]).
skipping to change at page 135, line 37 skipping to change at page 137, line 37
from which the user or user agent can choose the one most from which the user or user agent can choose the one most
appropriate. A user agent MAY automatically select the most appropriate. A user agent MAY automatically select the most
appropriate choice from that list. However, this specification does appropriate choice from that list. However, this specification does
not define any standard for such automatic selection, as described in not define any standard for such automatic selection, as described in
Section 9.4.1. Section 9.4.1.
9.5.8. 407 Proxy Authentication Required 9.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. The proxy MUST send a authenticate itself in order to use a proxy for this request. The
Proxy-Authenticate header field (Section 10.3.2) containing a proxy MUST send a Proxy-Authenticate header field (Section 10.3.2)
challenge applicable to that proxy for the target resource. 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 Proxy-
Authorization header field (Section 8.5.4). Authorization header field (Section 8.5.4).
9.5.9. 408 Request Timeout 9.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. A server SHOULD send the "close" connection option prepared to wait. If the client has an outstanding request in
(Section 9.1 of [Messaging]) in the response, since 408 implies that transit, the client MAY repeat that request on a new connection.
the server has decided to close the connection rather than continue
waiting. If the client has an outstanding request in transit, the
client MAY repeat that request on a new connection.
9.5.10. 409 Conflict 9.5.10. 409 Conflict
The 409 (Conflict) status code indicates that the request could not The 409 (Conflict) status code indicates that the request could not
be completed due to a conflict with the current state of the target be completed due to a conflict with the current state of the target
resource. This code is used in situations where the user might be resource. This code is used in situations where the user might be
able to resolve the conflict and resubmit the request. The server able to resolve the conflict and resubmit the request. The server
SHOULD generate a payload that includes enough information for a user SHOULD generate a payload that includes enough information for a user
to recognize the source of the conflict. to recognize the source of the conflict.
skipping to change at page 137, line 18 skipping to change at page 139, line 18
conditions given in the request header fields evaluated to false when conditions given in the request header fields evaluated to false when
tested on the server. This response status code allows the client to tested on the server. This response status code allows the client to
place preconditions on the current resource state (its current place preconditions on the current resource state (its current
representations and metadata) and, thus, prevent the request method representations and metadata) and, thus, prevent the request method
from being applied if the target resource is in an unexpected state. from being applied if the target resource is in an unexpected state.
9.5.14. 413 Payload Too Large 9.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 close than the server is willing or able to process. The server MAY
the connection to prevent the client from continuing the request. terminate the request, if the protocol version in use allows it;
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 Retry-
After header field to indicate that it is temporary and after what After header field to indicate that it is temporary and after what
time the client MAY try again. time the client MAY try again.
9.5.15. 414 URI Too Long 9.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 request-target refusing to service the request because the target URI is longer than
(Section 3.2 of [Messaging]) is longer than the server is willing to the server is willing to interpret. This rare condition is only
interpret. This rare condition is only likely to occur when a client likely to occur when a client has improperly converted a POST request
has improperly converted a POST request to a GET request with long to a GET request with long query information, when the client has
query information, when the client has descended into a "black hole" descended into a "black hole" of redirection (e.g., a redirected URI
of redirection (e.g., a redirected URI prefix that points to a suffix prefix that points to a suffix of itself) or when the server is under
of itself) or when the server is under attack by a client attempting attack by a client attempting to exploit potential security holes.
to exploit potential security holes.
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]).
9.5.16. 415 Unsupported Media Type 9.5.16. 415 Unsupported Media Type
The 415 (Unsupported Media Type) status code indicates that the The 415 (Unsupported Media Type) status code indicates that the
origin server is refusing to service the request because the payload origin server is refusing to service the request because the payload
is in a format not supported by this method on the target resource. is in a format not supported by this method on the target resource.
skipping to change at page 137, line 46 skipping to change at page 139, line 46
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]).
9.5.16. 415 Unsupported Media Type 9.5.16. 415 Unsupported Media Type
The 415 (Unsupported Media Type) status code indicates that the The 415 (Unsupported Media Type) status code indicates that the
origin server is refusing to service the request because the payload origin server is refusing to service the request because the payload
is in a format not supported by this method on the target resource. is in a format not supported by this method on the target resource.
The format problem might be due to the request's indicated Content- The format problem might be due to the request's indicated Content-
Type or Content-Encoding, or as a result of inspecting the data Type or Content-Encoding, or as a result of inspecting the data
directly. directly. If the problem was caused by an unsupported content
coding, the Accept-Encoding response header field (Section 8.4.3)
ought to be used to indicate what (if any) content codings would have
been accepted in the request.
9.5.17. 416 Range Not Satisfiable 9.5.17. 416 Range Not Satisfiable
The 416 (Range Not Satisfiable) status code indicates that none of The 416 (Range Not Satisfiable) status code indicates that none of
the ranges in the request's Range header field (Section 8.3) overlap the ranges in the request's Range header field (Section 8.3) overlap
the current extent of the selected representation or that the set of the current extent of the selected representation or that the set of
ranges requested has been rejected due to invalid ranges or an ranges requested has been rejected due to invalid ranges or an
excessive request of small or overlapping ranges. excessive request of small or overlapping ranges.
For byte ranges, failing to overlap the current extent means that the For byte ranges, failing to overlap the current extent means that the
skipping to change at page 142, line 15 skipping to change at page 144, line 15
class of the proposed status code(s) without consuming a number class of the proposed status code(s) without consuming a number
prematurely. prematurely.
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
to the response it occurs within. If a status code applies to a
larger scope of applicability -- for example, all requests to the
resource in question, or all requests to a server -- this must be
explicitly specified. When doing so, it should be noted that not all
clients can be expected to consistently apply a larger scope, because
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
behavior. See [Caching] for more information. behavior. See [Caching] for more information.
Finally, the definition of a new status code ought to indicate Finally, the definition of a new status code ought to indicate
whether the payload has any implied association with an identified whether the payload has any implied association with an identified
resource (Section 6.3.2). resource (Section 6.3.2).
10. Response Header Fields 10. Response Header Fields
The response header fields allow the server to pass additional The response header fields allow the server to pass additional
information about the response beyond what is placed in the status- information about the response beyond the status code. These header
line. These header fields give information about the server, about fields give information about the server, about further access to the
further access to the target resource, or about related resources. target resource, or about related resources.
Although each response header field has a defined meaning, in Although each response header field has a defined meaning, in
general, the precise semantics might be further refined by the general, the precise semantics might be further refined by the
semantics of the request method and/or response status code. semantics of the request method and/or response status code.
10.1. Control Data 10.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.
skipping to change at page 146, line 19 skipping to change at page 148, line 19
The "Location" header field is used in some responses to refer to a The "Location" header field is used in some responses to refer to a
specific resource in relation to the response. The type of specific resource in relation to the response. The type of
relationship is defined by the combination of request method and relationship is defined by the combination of request method and
status code semantics. status code semantics.
Location = URI-reference Location = URI-reference
The field value consists of a single URI-reference. When it has the The field value consists of a single URI-reference. When it has the
form of a relative reference ([RFC3986], Section 4.2), the final form of a relative reference ([RFC3986], Section 4.2), the final
value is computed by resolving it against the effective request URI value is computed by resolving it against the target URI ([RFC3986],
([RFC3986], Section 5). Section 5).
For 201 (Created) responses, the Location value refers to the primary For 201 (Created) responses, the Location value refers to the primary
resource created by the request. For 3xx (Redirection) responses, resource created by the request. For 3xx (Redirection) responses,
the Location value refers to the preferred target resource for the Location value refers to the preferred target resource for
automatically redirecting the request. automatically redirecting the request.
If the Location value provided in a 3xx (Redirection) response does If the Location value provided in a 3xx (Redirection) response does
not have a fragment component, a user agent MUST process the not have a fragment component, a user agent MUST process the
redirection as if the value inherits the fragment component of the redirection as if the value inherits the fragment component of the
URI reference used to generate the request target (i.e., the URI reference used to generate the target URI (i.e., the redirection
redirection inherits the original reference's fragment, if any). inherits the original reference's fragment, if any).
For example, a GET request generated for the URI reference For example, a GET request generated for the URI reference
"http://www.example.org/~tim" might result in a 303 (See Other) "http://www.example.org/~tim" might result in a 303 (See Other)
response containing the header field: response containing the header field:
Location: /People.html#tim Location: /People.html#tim
which suggests that the user agent redirect to which suggests that the user agent redirect to
"http://www.example.org/People.html#tim" "http://www.example.org/People.html#tim"
skipping to change at page 147, line 51 skipping to change at page 149, line 51
Two examples of its use are Two examples of its use are
Retry-After: Fri, 31 Dec 1999 23:59:59 GMT Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120 Retry-After: 120
In the latter example, the delay is 2 minutes. In the latter example, the delay is 2 minutes.
10.1.4. Vary 10.1.4. Vary
The "Vary" header field in a response describes what parts of a The "Vary" header field in a response describes what parts of a
request message, aside from the method, Host header field, and request message, aside from the method, Host header field, and target
request target, might influence the origin server's process for URI, might influence the origin server's process for selecting and
selecting and representing this response. The value consists of representing this response. The value consists of either a single
either a single asterisk ("*") or a list of header field names (case- asterisk ("*") or a list of header field names (case-insensitive).
insensitive).
Vary = "*" / 1#field-name Vary = "*" / 1#field-name
A Vary field value of "*" signals that anything about the request A Vary field value of "*" signals that anything about the request
might play a role in selecting the response representation, possibly might play a role in selecting the response representation, possibly
including elements outside the message syntax (e.g., the client's including elements outside the message syntax (e.g., the client's
network address). A recipient will not be able to determine whether network address). A recipient will not be able to determine whether
this response is appropriate for a later request without forwarding this response is appropriate for a later request without forwarding
the request to the origin server. A proxy MUST NOT generate a Vary the request to the origin server. A proxy MUST NOT generate a Vary
field with a "*" value. field with a "*" value.
skipping to change at page 149, line 7 skipping to change at page 151, line 4
required to match a new request to the stored cache entry. required to match a new request to the stored cache entry.
2. To inform user agent recipients that this response is subject to 2. To inform user agent recipients that this response is subject to
content negotiation (Section 8.4) and that a different content negotiation (Section 8.4) and that a different
representation might be sent in a subsequent request if representation might be sent in a subsequent request if
additional parameters are provided in the listed header fields additional parameters are provided in the listed header fields
(proactive negotiation). (proactive negotiation).
An origin server SHOULD send a Vary header field when its algorithm An origin server SHOULD send a Vary header field when its algorithm
for selecting a representation varies based on aspects of the request for selecting a representation varies based on aspects of the request
message other than the method and request target, unless the variance message other than the method and target URI, unless the variance
cannot be crossed or the origin server has been deliberately cannot be crossed or the origin server has been deliberately
configured to prevent cache transparency. For example, there is no configured to prevent cache transparency. For example, there is no
need to send the Authorization field name in Vary because reuse need to send the Authorization field name in Vary because reuse
across users is constrained by the field definition (Section 8.5.3). across users is constrained by the field definition (Section 8.5.3).
Likewise, an origin server might use Cache-Control response Likewise, an origin server might use Cache-Control response
directives (Section 5.2 of [Caching]) to supplant Vary if it directives (Section 5.2 of [Caching]) to supplant Vary if it
considers the variance less significant than the performance cost of considers the variance less significant than the performance cost of
Vary's impact on caching. Vary's impact on caching.
10.2. Validators 10.2. Validators
skipping to change at page 155, line 46 skipping to change at page 157, line 46
| 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 |
+--------+--------+-------------------+-----------------+ +--------+--------+-------------------+-----------------+
10.2.3.3. Example: Entity-Tags Varying on Content-Negotiated Resources 10.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 6.4), and where the representations sent in response to a (Section 6.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 8.4.4): (Section 8.4.3):
>> Request: >> Request:
GET /index HTTP/1.1 GET /index HTTP/1.1
Host: www.example.com Host: www.example.com
Accept-Encoding: gzip Accept-Encoding: gzip
In this case, the response might or might not use the gzip content In this case, the response might or might not use the gzip content
coding. If it does not, the response might look like: coding. If it does not, the response might look like:
skipping to change at page 159, line 11 skipping to change at page 161, line 11
well. Therefore, a sequence of comma, whitespace, and comma can well. Therefore, a sequence of comma, whitespace, and comma can
be considered either as applying to the preceding challenge, or to be considered either as applying to the preceding challenge, or to
be an empty entry in the list of challenges. In practice, this be an empty entry in the list of challenges. In practice, this
ambiguity does not affect the semantics of the header field value ambiguity does not affect the semantics of the header field value
and thus is harmless. and thus is harmless.
10.3.2. Proxy-Authenticate 10.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 effective request URI (Section 5.5). applicable to the proxy for this request. A proxy MUST send at least
A proxy MUST send at least one Proxy-Authenticate header field in one Proxy-Authenticate header field in each 407 (Proxy Authentication
each 407 (Proxy Authentication Required) response that it generates. Required) response that it generates.
Proxy-Authenticate = 1#challenge Proxy-Authenticate = 1#challenge
Unlike WWW-Authenticate, the Proxy-Authenticate header field applies Unlike WWW-Authenticate, the Proxy-Authenticate header field applies
only to the next outbound client on the response chain. This is only to the next outbound client on the response chain. This is
because only the client that chose a given proxy is likely to have because only the client that chose a given proxy is likely to have
the credentials necessary for authentication. However, when multiple the credentials necessary for authentication. However, when multiple
proxies are used within the same administrative domain, such as proxies are used within the same administrative domain, such as
office and regional caching proxies within a large corporate network, office and regional caching proxies within a large corporate network,
it is common for credentials to be generated by the user agent and it is common for credentials to be generated by the user agent and
skipping to change at page 160, line 10 skipping to change at page 162, line 10
The Authentication-Info header field can be used in any HTTP The Authentication-Info header field can be used in any HTTP
response, independently of request method and status code. Its response, independently of request method and status code. Its
semantics are defined by the authentication scheme indicated by the semantics are defined by the authentication scheme indicated by the
Authorization header field (Section 8.5.3) of the corresponding Authorization header field (Section 8.5.3) of the corresponding
request. request.
A proxy forwarding a response is not allowed to modify the field A proxy forwarding a response is not allowed to modify the field
value in any way. value in any way.
Authentication-Info can be used inside trailers (Section 7.1.2 of Authentication-Info can be used inside trailers (Section 4.6) when
[Messaging]) when the authentication scheme explicitly allows this. the authentication scheme explicitly allows this.
10.3.3.1. Parameter Value Format 10.3.3.1. Parameter Value Format
Parameter values can be expressed either as "token" or as "quoted- Parameter values can be expressed either as "token" or as "quoted-
string" (Section 4.4.1). string" (Section 4.4.1).
Authentication scheme definitions need to allow both notations, both Authentication scheme definitions need to allow both notations, both
for senders and recipients. This allows recipients to use generic for senders and recipients. This allows recipients to use generic
parsing components, independent of the authentication scheme in use. parsing components, independent of the authentication scheme in use.
skipping to change at page 165, line 8 skipping to change at page 167, line 8
of their design and coding decisions, and of the configuration of their design and coding decisions, and of the configuration
options they provide to operators (especially the default options they provide to operators (especially the default
configuration). configuration).
Users need to be aware that intermediaries are no more trustworthy Users need to be aware that intermediaries are no more trustworthy
than the people who run them; HTTP itself cannot solve this problem. than the people who run them; HTTP itself cannot solve this problem.
11.3. Attacks Based on File and Path Names 11.3. Attacks Based on File and Path Names
Origin servers frequently make use of their local file system to Origin servers frequently make use of their local file system to
manage the mapping from effective request URI to resource manage the mapping from target URI to resource representations. Most
representations. Most file systems are not designed to protect file systems are not designed to protect against malicious file or
against malicious file or path names. Therefore, an origin server path names. Therefore, an origin server needs to avoid accessing
needs to avoid accessing names that have a special significance to names that have a special significance to the system when mapping the
the system when mapping the request target to files, folders, or target resource to files, folders, or directories.
directories.
For example, UNIX, Microsoft Windows, and other operating systems use For example, UNIX, Microsoft Windows, and other operating systems use
".." as a path component to indicate a directory level above the ".." as a path component to indicate a directory level above the
current one, and they use specially named paths or file names to send current one, and they use specially named paths or file names to send
data to system devices. Similar naming conventions might exist data to system devices. Similar naming conventions might exist
within other types of storage systems. Likewise, local storage within other types of storage systems. Likewise, local storage
systems have an annoying tendency to prefer user-friendliness over systems have an annoying tendency to prefer user-friendliness over
security when handling invalid or unexpected characters, security when handling invalid or unexpected characters,
recomposition of decomposed characters, and case-normalization of recomposition of decomposed characters, and case-normalization of
case-insensitive names. case-insensitive names.
skipping to change at page 165, line 36 skipping to change at page 167, line 35
of-service (e.g., telling the server to read from a COM port) or of-service (e.g., telling the server to read from a COM port) or
disclosure of configuration and source files that are not meant to be disclosure of configuration and source files that are not meant to be
served. served.
11.4. Attacks Based on Command, Code, or Query Injection 11.4. Attacks Based on Command, Code, or Query Injection
Origin servers often use parameters within the URI as a means of Origin servers often use parameters within the URI as a means of
identifying system services, selecting database entries, or choosing identifying system services, selecting database entries, or choosing
a data source. However, data received in a request cannot be a data source. However, data received in a request cannot be
trusted. An attacker could construct any of the request data trusted. An attacker could construct any of the request data
elements (method, request-target, header fields, or body) to contain elements (method, target URI, header fields, or body) to contain data
data that might be misinterpreted as a command, code, or query when that might be misinterpreted as a command, code, or query when passed
passed through a command invocation, language interpreter, or through a command invocation, language interpreter, or database
database interface. interface.
For example, SQL injection is a common attack wherein additional For example, SQL injection is a common attack wherein additional
query language is inserted within some part of the request-target or query language is inserted within some part of the target URI or
header fields (e.g., Host, Referer, etc.). If the received data is header fields (e.g., Host, Referer, etc.). If the received data is
used directly within a SELECT statement, the query language might be used directly within a SELECT statement, the query language might be
interpreted as a database command instead of a simple string value. interpreted as a database command instead of a simple string value.
This type of implementation vulnerability is extremely common, in This type of implementation vulnerability is extremely common, in
spite of being easy to prevent. spite of being easy to prevent.
In general, resource implementations ought to avoid use of request In general, resource implementations ought to avoid use of request
data in contexts that are processed or interpreted as instructions. data in contexts that are processed or interpreted as instructions.
Parameters ought to be compared to fixed strings and acted upon as a Parameters ought to be compared to fixed strings and acted upon as a
result of that comparison, rather than passed through an interface result of that comparison, rather than passed through an interface
skipping to change at page 166, line 26 skipping to change at page 168, line 25
slow) streams of data, particularly where an implementation is slow) streams of data, particularly where an implementation is
expecting a protocol element with no predefined length (Section 3.3). expecting a protocol element with no predefined length (Section 3.3).
To promote interoperability, specific recommendations are made for To promote interoperability, specific recommendations are made for
minimum size limits on request-line (Section 3 of [Messaging]) and minimum size limits on request-line (Section 3 of [Messaging]) and
fields (Section 4). These are minimum recommendations, chosen to be fields (Section 4). These are minimum recommendations, chosen to be
supportable even by implementations with limited resources; it is supportable even by implementations with limited resources; it is
expected that most implementations will choose substantially higher expected that most implementations will choose substantially higher
limits. limits.
A server can reject a message that has a request-target that is too A server can reject a message that has a target URI that is too long
long (Section 9.5.15) or a request payload that is too large (Section 9.5.15) or a request payload that is too large
(Section 9.5.14). Additional status codes related to capacity limits (Section 9.5.14). Additional status codes related to capacity limits
have been defined by extensions to HTTP [RFC6585]. have been defined by extensions to HTTP [RFC6585].
Recipients ought to carefully limit the extent to which they process Recipients ought to carefully limit the extent to which they process
other protocol elements, including (but not limited to) request other protocol elements, including (but not limited to) request
methods, response status phrases, field names, numeric values, and methods, response status phrases, field names, numeric values, and
body chunks. Failure to limit such processing can result in buffer body chunks. Failure to limit such processing can result in buffer
overflows, arithmetic overflows, or increased vulnerability to overflows, arithmetic overflows, or increased vulnerability to
denial-of-service attacks. denial-of-service attacks.
skipping to change at page 167, line 33 skipping to change at page 169, line 33
11.8. Disclosure of Sensitive Information in URIs 11.8. Disclosure of Sensitive Information in URIs
URIs are intended to be shared, not secured, even when they identify URIs are intended to be shared, not secured, even when they identify
secure resources. URIs are often shown on displays, added to secure resources. URIs are often shown on displays, added to
templates when a page is printed, and stored in a variety of templates when a page is printed, and stored in a variety of
unprotected bookmark lists. It is therefore unwise to include unprotected bookmark lists. It is therefore unwise to include
information within a URI that is sensitive, personally identifiable, information within a URI that is sensitive, personally identifiable,
or a risk to disclose. or a risk to disclose.
Authors of services ought to avoid GET-based forms for the submission Authors of services ought to avoid GET-based forms for the submission
of sensitive data because that data will be placed in the request- of sensitive data because that data will be placed in the target URI.
target. Many existing servers, proxies, and user agents log or Many existing servers, proxies, and user agents log or display the
display the request-target in places where it might be visible to target URI in places where it might be visible to third parties.
third parties. Such services ought to use POST-based form submission Such services ought to use POST-based form submission instead.
instead.
Since the Referer header field tells a target site about the context Since the Referer header field tells a target site about the context
that resulted in a request, it has the potential to reveal that resulted in a request, it has the potential to reveal
information about the user's immediate browsing history and any information about the user's immediate browsing history and any
personal information that might be found in the referring resource's personal information that might be found in the referring resource's
URI. Limitations on the Referer header field are described in URI. Limitations on the Referer header field are described in
Section 8.6.2 to address some of its security considerations. Section 8.6.2 to address some of its security considerations.
11.9. Disclosure of Fragment after Redirects 11.9. Disclosure of Fragment after Redirects
skipping to change at page 173, line 31 skipping to change at page 175, line 31
4. Permanent entries without a status (after confirmation that the 4. Permanent entries without a status (after confirmation that the
registration document did not define one) will have a status of registration document did not define one) will have a status of
'provisional'. The Expert(s) can choose to update their status 'provisional'. The Expert(s) can choose to update their status
if there is evidence that another is more appropriate. if there is evidence that another is more appropriate.
Please annotate the Permanent and Provisional Message Header Please annotate the Permanent and Provisional Message Header
registries to indicate that HTTP field name registrations have moved, registries to indicate that HTTP field name registrations have moved,
with an appropriate link. with an appropriate link.
After that is complete, please update the new registry with the field After that is complete, please update the new registry with the field
names listed in the table of Section 4.3. names listed in the table of Section 4.8.
Finally, please update the "Content-MD5" entry in the new registry to Finally, please update the "Content-MD5" entry in the new registry to
have a status of 'obsoleted' with references to Section 14.15 of have a status of 'obsoleted' with references to Section 14.15 of
[RFC2616] (for the definition of the header field) and Appendix B of [RFC2616] (for the definition of the header field) and Appendix B of
[RFC7231] (which removed the field definition from the updated [RFC7231] (which removed the field definition from the updated
specification). specification).
12.5. Authentication Scheme Registration 12.5. Authentication Scheme Registration
Please update the "Hypertext Transfer Protocol (HTTP) Authentication Please update the "Hypertext Transfer Protocol (HTTP) Authentication
skipping to change at page 174, line 36 skipping to change at page 176, line 36
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".
13. References 13. References
13.1. Normative References 13.1. Normative References
[Caching] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [Caching] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Caching", draft-ietf-httpbis-cache-07 (work in Ed., "HTTP Caching", draft-ietf-httpbis-cache-08 (work in
progress), March 2020. progress), May 2020.
[Messaging] [Messaging]
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP/1.1 Messaging", draft-ietf-httpbis-messaging-07 Ed., "HTTP/1.1 Messaging", draft-ietf-httpbis-messaging-08
(work in progress), March 2020. (work in progress), May 2020.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>. <https://www.rfc-editor.org/info/rfc793>.
[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format
Specification version 3.3", RFC 1950, Specification version 3.3", RFC 1950,
DOI 10.17487/RFC1950, May 1996, DOI 10.17487/RFC1950, May 1996,
<https://www.rfc-editor.org/info/rfc1950>. <https://www.rfc-editor.org/info/rfc1950>.
skipping to change at page 181, line 9 skipping to change at page 183, line 9
[RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP [RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP
Digest Access Authentication", RFC 7616, Digest Access Authentication", RFC 7616,
DOI 10.17487/RFC7616, September 2015, DOI 10.17487/RFC7616, September 2015,
<https://www.rfc-editor.org/info/rfc7616>. <https://www.rfc-editor.org/info/rfc7616>.
[RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", [RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme",
RFC 7617, DOI 10.17487/RFC7617, September 2015, RFC 7617, DOI 10.17487/RFC7617, September 2015,
<https://www.rfc-editor.org/info/rfc7617>. <https://www.rfc-editor.org/info/rfc7617>.
[RFC7694] Reschke, J., "Hypertext Transfer Protocol (HTTP) Client-
Initiated Content-Encoding", RFC 7694,
DOI 10.17487/RFC7694, November 2015,
<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., "Indicating Character Encoding and Language
skipping to change at page 184, line 39 skipping to change at page 186, line 39
/ %x53.75.6E.64.61.79 ; Sunday / %x53.75.6E.64.61.79 ; Sunday
delay-seconds = 1*DIGIT delay-seconds = 1*DIGIT
entity-tag = [ weak ] opaque-tag entity-tag = [ weak ] opaque-tag
etagc = "!" / %x23-7E ; '#'-'~' etagc = "!" / %x23-7E ; '#'-'~'
/ obs-text / obs-text
field-content = field-vchar [ 1*( SP / HTAB / field-vchar ) field-content = field-vchar [ 1*( SP / HTAB / field-vchar )
field-vchar ] field-vchar ]
field-name = token field-name = token
field-value = *( field-content / obs-fold ) field-value = *field-content
field-vchar = VCHAR / obs-text field-vchar = VCHAR / obs-text
first-pos = 1*DIGIT first-pos = 1*DIGIT
hour = 2DIGIT hour = 2DIGIT
http-URI = "http://" authority path-abempty [ "?" query ] http-URI = "http://" authority path-abempty [ "?" query ]
https-URI = "https://" authority path-abempty [ "?" query ] https-URI = "https://" authority path-abempty [ "?" query ]
incl-range = first-pos "-" last-pos incl-range = first-pos "-" last-pos
int-range = first-pos "-" [ last-pos ] int-range = first-pos "-" [ last-pos ]
skipping to change at page 185, line 26 skipping to change at page 187, line 26
/ %x4D.61.79 ; May / %x4D.61.79 ; May
/ %x4A.75.6E ; Jun / %x4A.75.6E ; Jun
/ %x4A.75.6C ; Jul / %x4A.75.6C ; Jul
/ %x41.75.67 ; Aug / %x41.75.67 ; Aug
/ %x53.65.70 ; Sep / %x53.65.70 ; Sep
/ %x4F.63.74 ; Oct / %x4F.63.74 ; Oct
/ %x4E.6F.76 ; Nov / %x4E.6F.76 ; Nov
/ %x44.65.63 ; Dec / %x44.65.63 ; Dec
obs-date = rfc850-date / asctime-date obs-date = rfc850-date / asctime-date
obs-fold = <obs-fold, see [Messaging], Section 5.2>
obs-text = %x80-FF obs-text = %x80-FF
opaque-tag = DQUOTE *etagc DQUOTE opaque-tag = DQUOTE *etagc DQUOTE
other-range = 1*( %x21-2B ; '!'-'+' other-range = 1*( %x21-2B ; '!'-'+'
/ %x2D-7E ; '-'-'~' / %x2D-7E ; '-'-'~'
) )
parameter = parameter-name "=" parameter-value parameter = parameter-name "=" parameter-value
parameter-name = token parameter-name = token
parameter-value = ( token / quoted-string ) parameter-value = ( token / quoted-string )
partial-URI = relative-part [ "?" query ] partial-URI = relative-part [ "?" query ]
skipping to change at page 186, line 12 skipping to change at page 188, line 12
quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] ) qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
range-resp = incl-range "/" ( complete-length / "*" ) range-resp = incl-range "/" ( complete-length / "*" )
range-set = [ range-spec ] *( OWS "," OWS [ range-spec ] ) range-set = [ range-spec ] *( OWS "," OWS [ range-spec ] )
range-spec = int-range / suffix-range / other-range range-spec = int-range / suffix-range / other-range
range-unit = token range-unit = token
ranges-specifier = range-unit "=" range-set ranges-specifier = range-unit "=" range-set
received-by = pseudonym [ ":" port ] received-by = pseudonym [ ":" port ]
received-protocol = [ protocol-name "/" ] protocol-version received-protocol = [ protocol-name "/" ] protocol-version
relative-part = <relative-part, see [RFC3986], Section 4.2> relative-part = <relative-part, see [RFC3986], Section 4.2>
request-target = <request-target, see [Messaging], Section 3.2>
rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT
second = 2DIGIT second = 2DIGIT
segment = <segment, see [RFC3986], Section 3.3> segment = <segment, see [RFC3986], Section 3.3>
subtype = token subtype = token
suffix-length = 1*DIGIT suffix-length = 1*DIGIT
suffix-range = "-" suffix-length suffix-range = "-" suffix-length
tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." / tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." /
"^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA
skipping to change at page 187, line 42 skipping to change at page 189, line 42
servers has been extended for both "http" and "https" URIs to account servers has been extended for both "http" and "https" URIs to account
for alternative services and secured connections that are not for alternative services and secured connections that are not
necessarily based on TCP. (Section 2.5.1, Section 2.5.2, necessarily based on TCP. (Section 2.5.1, Section 2.5.2,
Section 5.2, Section 5.4) Section 5.2, Section 5.4)
B.3. Changes from RFC 7231 B.3. Changes from RFC 7231
Minimum URI lengths to be supported by implementations are now Minimum URI lengths to be supported by implementations are now
recommended. (Section 2.5) recommended. (Section 2.5)
The term "effective request URI" has been replaced with "target URI".
(Section 5.1)
Range units are compared in a case insensitive fashion. Range units are compared in a case insensitive fashion.
(Section 6.1.4) (Section 6.1.4)
Restrictions on client retries have been loosened, to reflect Restrictions on client retries have been loosened, to reflect
implementation behavior. (Section 7.2.2) implementation behavior. (Section 7.2.2)
Clarified that request bodies on GET and DELETE are not Clarified that request bodies on GET and DELETE are not
interoperable. (Section 7.3.1, Section 7.3.5) interoperable. (Section 7.3.1, Section 7.3.5)
Removed a superfluous requirement about setting Content-Length from Removed a superfluous requirement about setting Content-Length from
the description of the OPTIONS method. (Section 7.3.7) the description of the OPTIONS method. (Section 7.3.7)
Allow Accept-Encoding in response messages, as introduced by
[RFC7694]. (Section 8.4)
B.4. Changes from RFC 7232 B.4. Changes from RFC 7232
None yet. Clarify that If-Unmodified-Since doesn't apply to a resource without
a concept of modification time. (Section 8.2.6)
B.5. Changes from RFC 7233 B.5. Changes from RFC 7233
Refactored the range-unit and ranges-specifier grammars to simplify Refactored the range-unit and ranges-specifier grammars to simplify
and reduce artificial distinctions between bytes and other and reduce artificial distinctions between bytes and other
(extension) range units, removing the overlapping grammar of other- (extension) range units, removing the overlapping grammar of other-
range-unit by defining range units generically as a token and placing range-unit by defining range units generically as a token and placing
extensions within the scope of a range-spec (other-range). This extensions within the scope of a range-spec (other-range). This
disambiguates the role of list syntax (commas) in all range sets, disambiguates the role of list syntax (commas) in all range sets,
including extension range units, for indicating a range-set of more including extension range units, for indicating a range-set of more
skipping to change at page 188, line 36 skipping to change at page 190, line 43
None yet. None yet.
B.7. Changes from RFC 7538 B.7. Changes from RFC 7538
None yet. None yet.
B.8. Changes from RFC 7615 B.8. Changes from RFC 7615
None yet. None yet.
Appendix C. Change Log Appendix C. Changes from RFC 7694
This specification includes the extension defined in [RFC7694], but
leaves out examples and deployment considerations.
Appendix D. Change Log
This section is to be removed before publishing as an RFC. This section is to be removed before publishing as an RFC.
C.1. Between RFC723x and draft 00 D.1. Between RFC723x and draft 00
The changes were purely editorial: The changes were purely editorial:
o Change boilerplate and abstract to indicate the "draft" status, o Change boilerplate and abstract to indicate the "draft" status,
and update references to ancestor specifications. and update references to ancestor specifications.
o Remove version "1.1" from document title, indicating that this o Remove version "1.1" from document title, indicating that this
specification applies to all HTTP versions. specification applies to all HTTP versions.
o Adjust historical notes. o Adjust historical notes.
o Update links to sibling specifications. o Update links to sibling specifications.
o Replace sections listing changes from RFC 2616 by new empty o Replace sections listing changes from RFC 2616 by new empty
sections referring to RFC 723x. sections referring to RFC 723x.
o Remove acknowledgements specific to RFC 723x. o Remove acknowledgements specific to RFC 723x.
o Move "Acknowledgements" to the very end and make them unnumbered. o Move "Acknowledgements" to the very end and make them unnumbered.
C.2. Since draft-ietf-httpbis-semantics-00 D.2. Since draft-ietf-httpbis-semantics-00
The changes in this draft are editorial, with respect to HTTP as a The changes in this draft are editorial, with respect to HTTP as a
whole, to merge core HTTP semantics into this document: whole, to merge core HTTP semantics into this document:
o Merged introduction, architecture, conformance, and ABNF o Merged introduction, architecture, conformance, and ABNF
extensions from RFC 7230 (Messaging). extensions from RFC 7230 (Messaging).
o Rearranged architecture to extract conformance, http(s) schemes, o Rearranged architecture to extract conformance, http(s) schemes,
and protocol versioning into a separate major section. and protocol versioning into a separate major section.
skipping to change at page 189, line 39 skipping to change at page 192, line 7
o Merged entire content of RFC 7233 (Range Requests). o Merged entire content of RFC 7233 (Range Requests).
o Merged entire content of RFC 7235 (Auth Framework). o Merged entire content of RFC 7235 (Auth Framework).
o Moved all extensibility tips, registration procedures, and o Moved all extensibility tips, registration procedures, and
registry tables from the IANA considerations to normative registry tables from the IANA considerations to normative
sections, reducing the IANA considerations to just instructions sections, reducing the IANA considerations to just instructions
that will be removed prior to publication as an RFC. that will be removed prior to publication as an RFC.
C.3. Since draft-ietf-httpbis-semantics-01 D.3. Since draft-ietf-httpbis-semantics-01
o Improve [Welch] citation (<https://github.com/httpwg/http-core/ o Improve [Welch] citation (<https://github.com/httpwg/http-core/
issues/63>) issues/63>)
o Remove HTTP/1.1-ism about Range Requests o Remove HTTP/1.1-ism about Range Requests
(<https://github.com/httpwg/http-core/issues/71>) (<https://github.com/httpwg/http-core/issues/71>)
o Cite RFC 8126 instead of RFC 5226 (<https://github.com/httpwg/ o Cite RFC 8126 instead of RFC 5226 (<https://github.com/httpwg/
http-core/issues/75>) http-core/issues/75>)
skipping to change at page 191, line 10 skipping to change at page 193, line 26
o In Section 4.5, fixed an example that had trailing whitespace o In Section 4.5, fixed an example that had trailing whitespace
where it shouldn't (<https://github.com/httpwg/http-core/ where it shouldn't (<https://github.com/httpwg/http-core/
issues/104>, <https://www.rfc-editor.org/errata/eid4169>) issues/104>, <https://www.rfc-editor.org/errata/eid4169>)
o In Section 9.3.7, remove words that were potentially misleading o In Section 9.3.7, remove words that were potentially misleading
with respect to the relation to the requested ranges with respect to the relation to the requested ranges
(<https://github.com/httpwg/http-core/issues/102>, (<https://github.com/httpwg/http-core/issues/102>,
<https://www.rfc-editor.org/errata/eid4358>) <https://www.rfc-editor.org/errata/eid4358>)
C.4. Since draft-ietf-httpbis-semantics-02 D.4. Since draft-ietf-httpbis-semantics-02
o Included (Proxy-)Auth-Info header field definition from RFC 7615 o Included (Proxy-)Auth-Info header field definition from RFC 7615
(<https://github.com/httpwg/http-core/issues/9>) (<https://github.com/httpwg/http-core/issues/9>)
o In Section 7.3.3, clarify POST caching o In Section 7.3.3, clarify POST caching
(<https://github.com/httpwg/http-core/issues/17>) (<https://github.com/httpwg/http-core/issues/17>)
o Add Section 9.5.19 to reserve the 418 status code o Add Section 9.5.19 to reserve the 418 status code
(<https://github.com/httpwg/http-core/issues/43>) (<https://github.com/httpwg/http-core/issues/43>)
skipping to change at page 192, line 5 skipping to change at page 194, line 20
issues/123>) issues/123>)
o In Section 9.5.17, fixed prose about byte range comparison o In Section 9.5.17, fixed prose about byte range comparison
(<https://github.com/httpwg/http-core/issues/135>, (<https://github.com/httpwg/http-core/issues/135>,
<https://www.rfc-editor.org/errata/eid5474>) <https://www.rfc-editor.org/errata/eid5474>)
o In Section 2.1, explain that request/response correlation is o In Section 2.1, explain that request/response correlation is
version specific (<https://github.com/httpwg/http-core/ version specific (<https://github.com/httpwg/http-core/
issues/145>) issues/145>)
C.5. Since draft-ietf-httpbis-semantics-03 D.5. Since draft-ietf-httpbis-semantics-03
o In Section 9.4.9, include status code 308 from RFC 7538 o In Section 9.4.9, include status code 308 from RFC 7538
(<https://github.com/httpwg/http-core/issues/3>) (<https://github.com/httpwg/http-core/issues/3>)
o In Section 6.1.1, clarify that the charset parameter value is o In Section 6.1.1, clarify that the charset parameter value is
case-insensitive due to the definition in RFC 2046 case-insensitive due to the definition in RFC 2046
(<https://github.com/httpwg/http-core/issues/13>) (<https://github.com/httpwg/http-core/issues/13>)
o Define a separate registry for HTTP header field names o Define a separate registry for HTTP header field names
(<https://github.com/httpwg/http-core/issues/42>) (<https://github.com/httpwg/http-core/issues/42>)
skipping to change at page 192, line 42 skipping to change at page 195, line 9
o Use RFC 7405 ABNF notation for case-sensitive string constants o Use RFC 7405 ABNF notation for case-sensitive string constants
(<https://github.com/httpwg/http-core/issues/133>) (<https://github.com/httpwg/http-core/issues/133>)
o Rework Section 2.1 to be more version-independent o Rework Section 2.1 to be more version-independent
(<https://github.com/httpwg/http-core/issues/142>) (<https://github.com/httpwg/http-core/issues/142>)
o In Section 7.3.5, clarify that DELETE needs to be successful to o In Section 7.3.5, clarify that DELETE needs to be successful to
invalidate cache (<https://github.com/httpwg/http-core/ invalidate cache (<https://github.com/httpwg/http-core/
issues/167>, <https://www.rfc-editor.org/errata/eid5541>) issues/167>, <https://www.rfc-editor.org/errata/eid5541>)
C.6. Since draft-ietf-httpbis-semantics-04 D.6. Since draft-ietf-httpbis-semantics-04
o In Section 4.4, fix field-content ABNF o In Section 4.4, fix field-content ABNF
(<https://github.com/httpwg/http-core/issues/19>, (<https://github.com/httpwg/http-core/issues/19>,
<https://www.rfc-editor.org/errata/eid4189>) <https://www.rfc-editor.org/errata/eid4189>)
o Move Section 4.4.1.4 into its own section o Move Section 4.4.1.4 into its own section
(<https://github.com/httpwg/http-core/issues/45>) (<https://github.com/httpwg/http-core/issues/45>)
o In Section 6.2.1, reference MIME Sniffing o In Section 6.2.1, reference MIME Sniffing
(<https://github.com/httpwg/http-core/issues/51>) (<https://github.com/httpwg/http-core/issues/51>)
skipping to change at page 193, line 23 skipping to change at page 195, line 39
o Fix editorial issue in Section 6 (<https://github.com/httpwg/http- o Fix editorial issue in Section 6 (<https://github.com/httpwg/http-
core/issues/223>) core/issues/223>)
o In Section 9.5.20, rephrase language not to use "entity" anymore, o In Section 9.5.20, rephrase language not to use "entity" anymore,
and also avoid lowercase "may" (<https://github.com/httpwg/http- and also avoid lowercase "may" (<https://github.com/httpwg/http-
core/issues/224>) core/issues/224>)
o Move discussion of retries from [Messaging] into Section 7.2.2 o Move discussion of retries from [Messaging] into Section 7.2.2
(<https://github.com/httpwg/http-core/issues/230>) (<https://github.com/httpwg/http-core/issues/230>)
C.7. Since draft-ietf-httpbis-semantics-05 D.7. Since draft-ietf-httpbis-semantics-05
o Moved transport-independent part of the description of trailers o Moved transport-independent part of the description of trailers
into Section 4.6 (<https://github.com/httpwg/http-core/issues/16>) into Section 4.6 (<https://github.com/httpwg/http-core/issues/16>)
o Loosen requirements on retries based upon implementation behavior o Loosen requirements on retries based upon implementation behavior
(<https://github.com/httpwg/http-core/issues/27>) (<https://github.com/httpwg/http-core/issues/27>)
o In Section 12.9, update IANA port registry for TCP/UDP on ports 80 o In Section 12.9, update IANA port registry for TCP/UDP on ports 80
and 443 (<https://github.com/httpwg/http-core/issues/36>) and 443 (<https://github.com/httpwg/http-core/issues/36>)
skipping to change at page 194, line 31 skipping to change at page 196, line 46
o In Section 7.3.7, removed a misleading statement about Content- o In Section 7.3.7, removed a misleading statement about Content-
Length (<https://github.com/httpwg/http-core/issues/235>, Length (<https://github.com/httpwg/http-core/issues/235>,
<https://www.rfc-editor.org/errata/eid5806>) <https://www.rfc-editor.org/errata/eid5806>)
o In Section 11.1, add text from RFC 2818 o In Section 11.1, add text from RFC 2818
(<https://github.com/httpwg/http-core/issues/236>) (<https://github.com/httpwg/http-core/issues/236>)
o Changed "cacheable by default" to "heuristically cacheable" o Changed "cacheable by default" to "heuristically cacheable"
throughout (<https://github.com/httpwg/http-core/issues/242>) throughout (<https://github.com/httpwg/http-core/issues/242>)
C.8. Since draft-ietf-httpbis-semantics-06 D.8. Since draft-ietf-httpbis-semantics-06
o In Section 5.7.1, simplify received-by grammar (and disallow comma o In Section 5.7.1, simplify received-by grammar (and disallow comma
character) (<https://github.com/httpwg/http-core/issues/24>) character) (<https://github.com/httpwg/http-core/issues/24>)
o In Section 4.3, give guidance on interoperable field names o In Section 4.3, give guidance on interoperable field names
(<https://github.com/httpwg/http-core/issues/30>) (<https://github.com/httpwg/http-core/issues/30>)
o In Section 1.2.1, define the semantics and possible replacement of o In Section 1.2.1, define the semantics and possible replacement of
whitespace when it is known to occur (<https://github.com/httpwg/ whitespace when it is known to occur (<https://github.com/httpwg/
http-core/issues/53>) http-core/issues/53>)
skipping to change at page 196, line 5 skipping to change at page 198, line 15
o In Section 2.5.1, Section 2.5.2, Section 5.2, and Section 5.4, o In Section 2.5.1, Section 2.5.2, Section 5.2, and Section 5.4,
refactored schemes to define origin and authoritative access to an refactored schemes to define origin and authoritative access to an
origin server for both "http" and "https" URIs to account for origin server for both "http" and "https" URIs to account for
alternative services and secured connections that are not alternative services and secured connections that are not
necessarily based on TCP (<https://github.com/httpwg/http-core/ necessarily based on TCP (<https://github.com/httpwg/http-core/
issues/237>) issues/237>)
o In Section 1.1, reference RFC 8174 as well o In Section 1.1, reference RFC 8174 as well
(<https://github.com/httpwg/http-core/issues/303>) (<https://github.com/httpwg/http-core/issues/303>)
D.9. Since draft-ietf-httpbis-semantics-07
o In Section 8.3, explicitly reference the definition of
representation data as including any content codings
(<https://github.com/httpwg/http-core/issues/11>)
o Move TE: trailers from [Messaging] into Section 4.6.2
(<https://github.com/httpwg/http-core/issues/18>)
o In Section 6.2.4, adjust requirements for handling multiple
content-length values (<https://github.com/httpwg/http-core/
issues/59>)
o In Section 8.2.3 and Section 8.2.4, clarified condition evaluation
(<https://github.com/httpwg/http-core/issues/72>)
o In Section 4.4, remove concept of obs-fold, as that is
HTTP/1-specific (<https://github.com/httpwg/http-core/issues/116>)
o In Section 6.4, introduce the concept of request payload
negotiation (Section 6.4.3) and define for Accept-Encoding
(<https://github.com/httpwg/http-core/issues/119>)
o In Section 9.3.6, Section 9.5.9, and Section 9.5.14, remove
HTTP/1-specific, connection-related requirements
(<https://github.com/httpwg/http-core/issues/144>)
o In Section 7.3.6, correct language about what is forwarded
(<https://github.com/httpwg/http-core/issues/170>)
o Throughout, replace "effective request URI", "request-target" and
similar with "target URI" (<https://github.com/httpwg/http-core/
issues/259>)
o In Section 4.7 and Section 9.7.2, describe how extensions should
consider scope of applicability (<https://github.com/httpwg/http-
core/issues/265>)
o In Section 2.1, don't rely on the HTTP/1.1 Messaging specification
to define "message" (<https://github.com/httpwg/http-core/
issues/311>)
o In Section 6.2.5 and Section 8.6.2, note that URL resolution is
necessary (<https://github.com/httpwg/http-core/issues/321>)
o In Section 6, explicitly reference 206 as one of the status codes
that provide representation data (<https://github.com/httpwg/http-
core/issues/325>)
o In Section 8.2.6, refine requirements so that they don't apply to
resources without a concept of modification time
(<https://github.com/httpwg/http-core/issues/326>)
o In Section 10.3.2, specify the scope as a request, not a target
resource (<https://github.com/httpwg/http-core/issues/331>)
o In Section 2.1, introduce concept of "complete" messages
(<https://github.com/httpwg/http-core/issues/334>)
o In Section 5.1, Section 7.3.6, and Section 7.3.7, refine use of
"request target" (<https://github.com/httpwg/http-core/
issues/340>)
o Throughout, remove "status-line" and "request-line", as these are
HTTP/1.1-specific (<https://github.com/httpwg/http-core/
issues/361>)
Index Index
1 1
100 Continue (status code) 121 100 Continue (status code) 123
100-continue (expect value) 88 100-continue (expect value) 90
101 Switching Protocols (status code) 121 101 Switching Protocols (status code) 123
1xx Informational (status code class) 120 1xx Informational (status code class) 123
2 2
200 OK (status code) 121 200 OK (status code) 124
201 Created (status code) 122 201 Created (status code) 124
202 Accepted (status code) 122 202 Accepted (status code) 125
203 Non-Authoritative Information (status code) 123 203 Non-Authoritative Information (status code) 125
204 No Content (status code) 123 204 No Content (status code) 125
205 Reset Content (status code) 124 205 Reset Content (status code) 126
206 Partial Content (status code) 124 206 Partial Content (status code) 127
2xx Successful (status code class) 121 2xx Successful (status code class) 124
3 3
300 Multiple Choices (status code) 129 300 Multiple Choices (status code) 131
301 Moved Permanently (status code) 130 301 Moved Permanently (status code) 132
302 Found (status code) 130 302 Found (status code) 132
303 See Other (status code) 131 303 See Other (status code) 133
304 Not Modified (status code) 131 304 Not Modified (status code) 133
305 Use Proxy (status code) 132 305 Use Proxy (status code) 134
306 (Unused) (status code) 132 306 (Unused) (status code) 134
307 Temporary Redirect (status code) 132 307 Temporary Redirect (status code) 134
308 Permanent Redirect (status code) 133 308 Permanent Redirect (status code) 135
3xx Redirection (status code class) 127 3xx Redirection (status code class) 130
4 4
400 Bad Request (status code) 133 400 Bad Request (status code) 135
401 Unauthorized (status code) 133 401 Unauthorized (status code) 135
402 Payment Required (status code) 134 402 Payment Required (status code) 136
403 Forbidden (status code) 134 403 Forbidden (status code) 136
404 Not Found (status code) 134 404 Not Found (status code) 136
405 Method Not Allowed (status code) 135 405 Method Not Allowed (status code) 137
406 Not Acceptable (status code) 135 406 Not Acceptable (status code) 137
407 Proxy Authentication Required (status code) 135 407 Proxy Authentication Required (status code) 137
408 Request Timeout (status code) 135 408 Request Timeout (status code) 137
409 Conflict (status code) 136 409 Conflict (status code) 138
410 Gone (status code) 136 410 Gone (status code) 138
411 Length Required (status code) 136 411 Length Required (status code) 138
412 Precondition Failed (status code) 137 412 Precondition Failed (status code) 139
413 Payload Too Large (status code) 137 413 Payload Too Large (status code) 139
414 URI Too Long (status code) 137 414 URI Too Long (status code) 139
415 Unsupported Media Type (status code) 137 415 Unsupported Media Type (status code) 139
416 Range Not Satisfiable (status code) 138 416 Range Not Satisfiable (status code) 140
417 Expectation Failed (status code) 138 417 Expectation Failed (status code) 140
418 (Unused) (status code) 138 418 (Unused) (status code) 140
422 Unprocessable Payload (status code) 139 422 Unprocessable Payload (status code) 141
426 Upgrade Required (status code) 139 426 Upgrade Required (status code) 141
4xx Client Error (status code class) 133 4xx Client Error (status code class) 135
5 5
500 Internal Server Error (status code) 140 500 Internal Server Error (status code) 142
501 Not Implemented (status code) 140 501 Not Implemented (status code) 142
502 Bad Gateway (status code) 140 502 Bad Gateway (status code) 142
503 Service Unavailable (status code) 140 503 Service Unavailable (status code) 142
504 Gateway Timeout (status code) 140 504 Gateway Timeout (status code) 142
505 HTTP Version Not Supported (status code) 140 505 HTTP Version Not Supported (status code) 142
5xx Server Error (status code class) 139 5xx Server Error (status code class) 141
A A
Accept header field 104 Accept header field 106
Accept-Charset header field 106 Accept-Charset header field 108
Accept-Encoding header field 107 Accept-Encoding header field 108
Accept-Language header field 108 Accept-Language header field 110
Accept-Ranges header field 161 Accept-Ranges header field 163
Allow header field 161 Allow header field 163
Authentication-Info header field 159 Authentication-Info header field 161
Authorization header field 112 Authorization header field 114
accelerator 14 accelerator 14
authoritative response 163 authoritative response 165
B B
browser 11 browser 11
C C
CONNECT method 83 CONNECT method 85
Canonical Root URI 111 Canonical Root URI 113
Content-Encoding header field 59 Content-Encoding header field 60
Content-Language header field 60 Content-Language header field 61
Content-Length header field 61 Content-Length header field 61
Content-Location header field 62 Content-Location header field 63
Content-MD5 header field 173 Content-MD5 header field 175
Content-Range header field 66 Content-Range header field 67
Content-Type header field 58 Content-Type header field 59
cache 15 cache 15
cacheable 15 cacheable 16
captive portal 15 captive portal 15
client 11 client 11
complete 12
compress (Coding Format) 52 compress (Coding Format) 52
compress (content coding) 51 compress (content coding) 52
conditional request 91 conditional request 93
connection 11 connection 11
content coding 51 content coding 52
content negotiation 9 content negotiation 9
D D
DELETE method 82 DELETE method 84
Date header field 145 Date header field 147
Delimiters 30 Delimiters 30
deflate (Coding Format) 52 deflate (Coding Format) 53
deflate (content coding) 51 deflate (content coding) 52
downstream 14 downstream 14
E E
ETag field 153 ETag field 155
Expect header field 88 Expect header field 90
effective request URI 43 effective request URI 44
F F
Fields Fields
Accept 104 Accept 106
Accept-Charset 106 Accept-Charset 108
Accept-Encoding 107 Accept-Encoding 108
Accept-Language 108 Accept-Language 110
Accept-Ranges 161 Accept-Ranges 163
Allow 161 Allow 163
Authentication-Info 159 Authentication-Info 161
Authorization 112 Authorization 114
Content-Encoding 59 Content-Encoding 60
Content-Language 60 Content-Language 61
Content-Length 61 Content-Length 61
Content-Location 62 Content-Location 63
Content-MD5 173 Content-MD5 175
Content-Range 66 Content-Range 67
Content-Type 58 Content-Type 59
Date 145 Date 147
ETag 153 ETag 155
Expect 88 Expect 90
From 115 From 118
Host 43 Host 44
If-Match 95 If-Match 97
If-Modified-Since 97 If-Modified-Since 99
If-None-Match 96 If-None-Match 98
If-Range 100 If-Range 102
If-Unmodified-Since 98 If-Unmodified-Since 101
Last-Modified 151 Last-Modified 153
Location 146 Location 148
Max-Forwards 90 Max-Forwards 92
Proxy-Authenticate 159 Proxy-Authenticate 161
Proxy-Authentication-Info 160 Proxy-Authentication-Info 162
Proxy-Authorization 112 Proxy-Authorization 115
Range 101 Range 103
Referer 116 Referer 118
Retry-After 147 Retry-After 149
Server 162 Server 164
Trailer 34 Trailer 34
User-Agent 117 User-Agent 119
Vary 147 Vary 149
Via 45 Via 46
WWW-Authenticate 158 WWW-Authenticate 160
Fragment Identifiers 20 Fragment Identifiers 20
From header field 115 From header field 118
field 24 field 24
field line 24 field line 25
field line value 24 field line value 25
field name 24 field name 25
field value 24 field value 25
G G
GET method 77 GET method 79
Grammar Grammar
absolute-path 16 absolute-path 17
absolute-URI 16 absolute-URI 17
Accept 104 Accept 106
Accept-Charset 106 Accept-Charset 108
Accept-Encoding 107 Accept-Encoding 108
accept-ext 104 accept-ext 106
Accept-Language 108 Accept-Language 110
accept-params 104 accept-params 106
Accept-Ranges 161 Accept-Ranges 163
acceptable-ranges 161 acceptable-ranges 163
Allow 161 Allow 163
ALPHA 10 ALPHA 10
asctime-date 144 asctime-date 146
auth-param 110 auth-param 112
auth-scheme 110 auth-scheme 112
Authentication-Info 159 Authentication-Info 161
authority 16 authority 17
Authorization 112 Authorization 114
BWS 11 BWS 11
challenge 110 challenge 112
charset 49 charset 50
codings 107 codings 108
comment 31 comment 31
complete-length 67 complete-length 67
content-coding 51 content-coding 52
Content-Encoding 59 Content-Encoding 60
Content-Language 60 Content-Language 61
Content-Length 61 Content-Length 61
Content-Location 62 Content-Location 63
Content-Range 67 Content-Range 67
Content-Type 58 Content-Type 59
CR 10 CR 10
credentials 111 credentials 113
CRLF 10 CRLF 10
ctext 31 ctext 31
CTL 10 CTL 10
Date 145 Date 147
date1 144 date1 146
day 144 day 146
day-name 144 day-name 146
day-name-l 144 day-name-l 146
delay-seconds 147 delay-seconds 149
DIGIT 10 DIGIT 10
DQUOTE 10 DQUOTE 10
entity-tag 154 entity-tag 156
ETag 154 ETag 156
etagc 154 etagc 156
Expect 88 Expect 90
field-content 28 field-content 29
field-name 26, 34 field-name 27, 34
field-value 28 field-value 29
field-vchar 28 field-vchar 29
first-pos 55, 67 first-pos 55, 67
From 115 From 118
GMT 144 GMT 146
HEXDIG 10 HEXDIG 10
Host 43 Host 44
hour 144 hour 146
HTAB 10 HTAB 10
HTTP-date 143 HTTP-date 145
http-URI 17 http-URI 18
https-URI 18 https-URI 19
If-Match 95 If-Match 97
If-Modified-Since 97 If-Modified-Since 99
If-None-Match 96 If-None-Match 98
If-Range 100 If-Range 102
If-Unmodified-Since 98 If-Unmodified-Since 101
IMF-fixdate 144 IMF-fixdate 146
incl-range 67 incl-range 67
int-range 55 int-range 55
language-range 108 language-range 110
language-tag 53 language-tag 54
Last-Modified 151 Last-Modified 153
last-pos 55, 67 last-pos 55, 67
LF 10 LF 10
Location 146 Location 148
Max-Forwards 90 Max-Forwards 92
media-range 104 media-range 106
media-type 49 media-type 50
method 73 method 75
minute 144 minute 146
month 144 month 146
obs-date 144 obs-date 146
obs-text 30 obs-text 31
OCTET 10 OCTET 10
opaque-tag 154 opaque-tag 156
other-range 55 other-range 56
OWS 11 OWS 11
parameter 31 parameter 31
parameter-name 31 parameter-name 31
parameter-value 31 parameter-value 31
partial-URI 16 partial-URI 17
port 16 port 17
product 117 product 120
product-version 117 product-version 120
protocol-name 45 protocol-name 46
protocol-version 45 protocol-version 46
Proxy-Authenticate 159 Proxy-Authenticate 161
Proxy-Authentication-Info 160 Proxy-Authentication-Info 162
Proxy-Authorization 112 Proxy-Authorization 115
pseudonym 45 pseudonym 46
qdtext 30 qdtext 31
query 16 query 17
quoted-pair 30 quoted-pair 31
quoted-string 30 quoted-string 31
qvalue 104 qvalue 74
Range 101 Range 103
range-resp 67 range-resp 67
range-set 55 range-set 55
range-spec 55 range-spec 55
range-unit 54 range-unit 54
ranges-specifier 55 ranges-specifier 55
received-by 45 received-by 46
received-protocol 45 received-protocol 46
Referer 116 Referer 118
Retry-After 147 Retry-After 149
rfc850-date 144 rfc850-date 146
RWS 11 RWS 11
second 144 second 146
segment 16 segment 17
Server 162 Server 164
SP 10 SP 10
subtype 49 subtype 50
suffix-length 55 suffix-length 56
suffix-range 55 suffix-range 56
tchar 30 tchar 31
time-of-day 144 time-of-day 146
token 30 token 31
token68 110 token68 112
Trailer 34 Trailer 34
type 49 type 50
unsatisfied-range 67 unsatisfied-range 67
uri-host 16 uri-host 17
URI-reference 16 URI-reference 17
User-Agent 117 User-Agent 119
Vary 148 Vary 150
VCHAR 10 VCHAR 10
Via 45 Via 46
weak 154 weak 156
weight 104 weight 74
WWW-Authenticate 158 WWW-Authenticate 160
year 144 year 146
gateway 14 gateway 14
gzip (Coding Format) 52 gzip (Coding Format) 53
gzip (content coding) 51 gzip (content coding) 52
H H
HEAD method 78 HEAD method 80
Header Fields Header Fields
Accept 104 Accept 106
Accept-Charset 106 Accept-Charset 108
Accept-Encoding 107 Accept-Encoding 108
Accept-Language 108 Accept-Language 110
Accept-Ranges 161 Accept-Ranges 163
Allow 161 Allow 163
Authentication-Info 159 Authentication-Info 161
Authorization 112 Authorization 114
Content-Encoding 59 Content-Encoding 60
Content-Language 60 Content-Language 61
Content-Length 61 Content-Length 61
Content-Location 62 Content-Location 63
Content-MD5 173 Content-MD5 175
Content-Range 66 Content-Range 67
Content-Type 58 Content-Type 59
Date 145 Date 147
ETag 153 ETag 155
Expect 88 Expect 90
From 115 From 118
Host 43 Host 44
If-Match 95 If-Match 97
If-Modified-Since 97 If-Modified-Since 99
If-None-Match 96 If-None-Match 98
If-Range 100 If-Range 102
If-Unmodified-Since 98 If-Unmodified-Since 101
Last-Modified 151 Last-Modified 153
Location 146 Location 148
Max-Forwards 90 Max-Forwards 92
Proxy-Authenticate 159 Proxy-Authenticate 161
Proxy-Authentication-Info 160 Proxy-Authentication-Info 162
Proxy-Authorization 112 Proxy-Authorization 115
Range 101 Range 103
Referer 116 Referer 118
Retry-After 147 Retry-After 149
Server 162 Server 164
Trailer 34 Trailer 34
User-Agent 117 User-Agent 119
Vary 147 Vary 149
Via 45 Via 46
WWW-Authenticate 158 WWW-Authenticate 160
Host header field 43
Host header field 44
header section 24 header section 24
http URI scheme 17 http URI scheme 18
https URI scheme 18 https URI scheme 18
I I
If-Match header field 95 If-Match header field 97
If-Modified-Since header field 97 If-Modified-Since header field 99
If-None-Match header field 96 If-None-Match header field 98
If-Range header field 100 If-Range header field 102
If-Unmodified-Since header field 98 If-Unmodified-Since header field 101
idempotent 76 idempotent 78
inbound 14 inbound 14
incomplete 12
interception proxy 15 interception proxy 15
intermediary 13 intermediary 13
L L
Last-Modified header field 151 Last-Modified header field 153
Location header field 146 Location header field 148
M M
Max-Forwards header field 90 Max-Forwards header field 92
Media Type Media Type
multipart/byteranges 68 multipart/byteranges 69
multipart/x-byteranges 69 multipart/x-byteranges 69
message 12 message 12
metadata 149 metadata 151
multipart/byteranges Media Type 68 multipart/byteranges Media Type 69
multipart/x-byteranges Media Type 69 multipart/x-byteranges Media Type 69
N N
non-transforming proxy 47 non-transforming proxy 47
O O
OPTIONS method 85 OPTIONS method 87
origin 37 origin 38
origin server 11 origin server 11
outbound 14 outbound 14
P P
POST method 79 POST method 81
PUT method 80 PUT method 82
Protection Space 111 Protection Space 113
Proxy-Authenticate header field 159 Proxy-Authenticate header field 161
Proxy-Authentication-Info header field 160 Proxy-Authentication-Info header field 162
Proxy-Authorization header field 112 Proxy-Authorization header field 115
payload 64 payload 64
phishing 163 phishing 165
proxy 14 proxy 14
R R
Range header field 101 Range header field 103
Realm 111 Realm 113
Referer header field 116 Referer header field 118
Retry-After header field 147 Retry-After header field 149
recipient 11 recipient 11
representation 48 representation 49
request 12 request 12
resource 16 resource 16
response 12 response 12
reverse proxy 14 reverse proxy 14
S S
Server header field 162 Server header field 164
Status Code 118 Status Code 120
Status Codes Status Codes
Final 119 Final 121
Informational 119 Informational 121
Interim 119 Interim 121
Status Codes Classes Status Codes Classes
1xx Informational 120 1xx Informational 123
2xx Successful 121 2xx Successful 124
3xx Redirection 127 3xx Redirection 130
4xx Client Error 133 4xx Client Error 135
5xx Server Error 139 5xx Server Error 141
safe 75 safe 77
secured 18 secured 18
selected representation 48, 91, 149 selected representation 49, 93, 151
sender 11 sender 11
server 11 server 11
spider 11 spider 11
T T
TRACE method 86 TRACE method 88
Trailer Fields Trailer Fields
ETag 153 ETag 155
Trailer header field 34 Trailer header field 34
target URI 37 target URI 38
target resource 37 target resource 38
trailer fields 33 trailer fields 33
trailer section 24 trailer section 24
trailers 33 trailers 33
transforming proxy 47 transforming proxy 47
transparent proxy 15 transparent proxy 15
tunnel 14 tunnel 14
U U
URI URI
origin 37 origin 38
URI scheme URI scheme
http 17 http 18
https 18 https 18
User-Agent header field 117 User-Agent header field 119
upstream 14 upstream 14
user agent 11 user agent 11
V V
Vary header field 147 Vary header field 149
Via header field 45 Via header field 46
validator 149 validator 151
strong 150 strong 152
weak 150 weak 152
W W
WWW-Authenticate header field 158 WWW-Authenticate header field 160
X X
x-compress (content coding) 51 x-compress (content coding) 52
x-gzip (content coding) 51 x-gzip (content coding) 52
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.
 End of changes. 236 change blocks. 
966 lines changed or deleted 1130 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/