draft-ietf-httpbis-semantics-03.txt   draft-ietf-httpbis-semantics-04.txt 
HTTP Working Group R. Fielding, Ed. HTTP Working Group R. Fielding, Ed.
Internet-Draft Adobe Internet-Draft Adobe
Obsoletes: 7230,7231,7232,7233,7235,7615 M. Nottingham, Ed. Obsoletes: M. Nottingham, Ed.
(if approved) Fastly 7230,7231,7232,7233,7235,7538 Fastly
Intended status: Standards Track J. Reschke, Ed. ,7615 (if approved) J. Reschke, Ed.
Expires: April 21, 2019 greenbytes Intended status: Standards Track greenbytes
October 18, 2018 Expires: September 10, 2019 March 9, 2019
HTTP Semantics HTTP Semantics
draft-ietf-httpbis-semantics-03 draft-ietf-httpbis-semantics-04
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 7231, RFC 7232, RFC 7233, RFC 7235, RFC This document obsoletes RFC 7231, RFC 7232, RFC 7233, RFC 7235, RFC
7615, and portions of RFC 7230. 7538, RFC 7615, 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 H.4. The changes in this draft are summarized in Appendix I.5.
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 April 21, 2019. This Internet-Draft will expire on September 10, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 48 skipping to change at page 2, line 48
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 9 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 9
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 9 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 9
2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 10 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 10 2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 10
2.2. Intermediaries . . . . . . . . . . . . . . . . . . . . . 12 2.2. Intermediaries . . . . . . . . . . . . . . . . . . . . . 12
2.3. Caches . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3. Caches . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4. Uniform Resource Identifiers . . . . . . . . . . . . . . 15 2.4. Uniform Resource Identifiers . . . . . . . . . . . . . . 14
2.5. Resources . . . . . . . . . . . . . . . . . . . . . . . . 16 2.5. Resources . . . . . . . . . . . . . . . . . . . . . . . . 15
2.5.1. http URI Scheme . . . . . . . . . . . . . . . . . . . 16 2.5.1. http URI Scheme . . . . . . . . . . . . . . . . . . . 16
2.5.2. https URI Scheme . . . . . . . . . . . . . . . . . . 18 2.5.2. https URI Scheme . . . . . . . . . . . . . . . . . . 17
2.5.3. Fragment Identifiers on http(s) URI References . . . 18 2.5.3. Fragment Identifiers on http(s) URI References . . . 18
2.5.4. http and https URI Normalization and Comparison . . . 19 2.5.4. http and https URI Normalization and Comparison . . . 18
3. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 19 3. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1. Implementation Diversity . . . . . . . . . . . . . . . . 19 3.1. Implementation Diversity . . . . . . . . . . . . . . . . 19
3.2. Role-based Requirements . . . . . . . . . . . . . . . . . 20 3.2. Role-based Requirements . . . . . . . . . . . . . . . . . 19
3.3. Parsing Elements . . . . . . . . . . . . . . . . . . . . 20 3.3. Parsing Elements . . . . . . . . . . . . . . . . . . . . 20
3.4. Error Handling . . . . . . . . . . . . . . . . . . . . . 21 3.4. Error Handling . . . . . . . . . . . . . . . . . . . . . 21
3.5. Protocol Versioning . . . . . . . . . . . . . . . . . . . 21 3.5. Protocol Versioning . . . . . . . . . . . . . . . . . . . 21
4. Message Abstraction . . . . . . . . . . . . . . . . . . . . . 23 4. Message Abstraction . . . . . . . . . . . . . . . . . . . . . 22
4.1. Header Field Names . . . . . . . . . . . . . . . . . . . 23 4.1. Header Field Names . . . . . . . . . . . . . . . . . . . 22
4.1.1. Header Field Name Registry . . . . . . . . . . . . . 25 4.1.1. Header Field Name Registry . . . . . . . . . . . . . 25
4.1.2. Header Field Extensibility . . . . . . . . . . . . . 25 4.1.2. Header Field Extensibility . . . . . . . . . . . . . 26
4.1.3. Considerations for New Header Fields . . . . . . . . 25 4.1.3. Considerations for New Header Fields . . . . . . . . 26
4.2. Header Field Values . . . . . . . . . . . . . . . . . . . 27 4.2. Header Field Values . . . . . . . . . . . . . . . . . . . 27
4.2.1. Header Field Order . . . . . . . . . . . . . . . . . 27 4.2.1. Header Field Order . . . . . . . . . . . . . . . . . 28
4.2.2. Header Field Limits . . . . . . . . . . . . . . . . . 28 4.2.2. Header Field Limits . . . . . . . . . . . . . . . . . 29
4.2.3. Header Field Value Components . . . . . . . . . . . . 28 4.2.3. Header Field Value Components . . . . . . . . . . . . 29
4.2.4. Designing New Header Field Values . . . . . . . . . . 29 4.2.4. Designing New Header Field Values . . . . . . . . . . 30
4.3. Whitespace . . . . . . . . . . . . . . . . . . . . . . . 30 4.3. Whitespace . . . . . . . . . . . . . . . . . . . . . . . 31
4.4. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.4. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 31
5. Message Routing . . . . . . . . . . . . . . . . . . . . . . . 31 5. Message Routing . . . . . . . . . . . . . . . . . . . . . . . 32
5.1. Identifying a Target Resource . . . . . . . . . . . . . . 31 5.1. Identifying a Target Resource . . . . . . . . . . . . . . 32
5.2. Routing Inbound . . . . . . . . . . . . . . . . . . . . . 31 5.2. Routing Inbound . . . . . . . . . . . . . . . . . . . . . 32
5.3. Effective Request URI . . . . . . . . . . . . . . . . . . 32 5.3. Effective Request URI . . . . . . . . . . . . . . . . . . 33
5.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . 33 5.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.5. Message Forwarding . . . . . . . . . . . . . . . . . . . 34 5.5. Message Forwarding . . . . . . . . . . . . . . . . . . . 35
5.5.1. Via . . . . . . . . . . . . . . . . . . . . . . . . . 34 5.5.1. Via . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.5.2. Transformations . . . . . . . . . . . . . . . . . . . 36 5.5.2. Transformations . . . . . . . . . . . . . . . . . . . 37
6. Representations . . . . . . . . . . . . . . . . . . . . . . . 37 6. Representations . . . . . . . . . . . . . . . . . . . . . . . 38
6.1. Representation Data . . . . . . . . . . . . . . . . . . . 38 6.1. Representation Data . . . . . . . . . . . . . . . . . . . 39
6.1.1. Media Type . . . . . . . . . . . . . . . . . . . . . 38 6.1.1. Media Type . . . . . . . . . . . . . . . . . . . . . 39
6.1.2. Content Codings . . . . . . . . . . . . . . . . . . . 40 6.1.2. Content Codings . . . . . . . . . . . . . . . . . . . 41
6.1.3. Language Tags . . . . . . . . . . . . . . . . . . . . 42 6.1.3. Language Tags . . . . . . . . . . . . . . . . . . . . 43
6.1.4. Range Units . . . . . . . . . . . . . . . . . . . . . 43 6.1.4. Range Units . . . . . . . . . . . . . . . . . . . . . 44
6.2. Representation Metadata . . . . . . . . . . . . . . . . . 46 6.2. Representation Metadata . . . . . . . . . . . . . . . . . 47
6.2.1. Content-Type . . . . . . . . . . . . . . . . . . . . 46 6.2.1. Content-Type . . . . . . . . . . . . . . . . . . . . 47
6.2.2. Content-Encoding . . . . . . . . . . . . . . . . . . 47 6.2.2. Content-Encoding . . . . . . . . . . . . . . . . . . 48
6.2.3. Content-Language . . . . . . . . . . . . . . . . . . 48 6.2.3. Content-Language . . . . . . . . . . . . . . . . . . 49
6.2.4. Content-Length . . . . . . . . . . . . . . . . . . . 49 6.2.4. Content-Length . . . . . . . . . . . . . . . . . . . 50
6.2.5. Content-Location . . . . . . . . . . . . . . . . . . 50 6.2.5. Content-Location . . . . . . . . . . . . . . . . . . 51
6.3. Payload . . . . . . . . . . . . . . . . . . . . . . . . . 52 6.3. Payload . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.3.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 52 6.3.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 53
6.3.2. Identification . . . . . . . . . . . . . . . . . . . 53 6.3.2. Identification . . . . . . . . . . . . . . . . . . . 54
6.3.3. Content-Range . . . . . . . . . . . . . . . . . . . . 54 6.3.3. Content-Range . . . . . . . . . . . . . . . . . . . . 55
6.3.4. Media Type multipart/byteranges . . . . . . . . . . . 55 6.3.4. Media Type multipart/byteranges . . . . . . . . . . . 57
6.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 57 6.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 59
6.4.1. Proactive Negotiation . . . . . . . . . . . . . . . . 58 6.4.1. Proactive Negotiation . . . . . . . . . . . . . . . . 59
6.4.2. Reactive Negotiation . . . . . . . . . . . . . . . . 59 6.4.2. Reactive Negotiation . . . . . . . . . . . . . . . . 60
7. Request Methods . . . . . . . . . . . . . . . . . . . . . . . 60 7. Request Methods . . . . . . . . . . . . . . . . . . . . . . . 61
7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 60 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 61
7.2. Common Method Properties . . . . . . . . . . . . . . . . 62 7.2. Common Method Properties . . . . . . . . . . . . . . . . 63
7.2.1. Safe Methods . . . . . . . . . . . . . . . . . . . . 62 7.2.1. Safe Methods . . . . . . . . . . . . . . . . . . . . 63
7.2.2. Idempotent Methods . . . . . . . . . . . . . . . . . 63 7.2.2. Idempotent Methods . . . . . . . . . . . . . . . . . 64
7.2.3. Cacheable Methods . . . . . . . . . . . . . . . . . . 63 7.2.3. Cacheable Methods . . . . . . . . . . . . . . . . . . 64
7.3. Method Definitions . . . . . . . . . . . . . . . . . . . 64 7.3. Method Definitions . . . . . . . . . . . . . . . . . . . 65
7.3.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 64 7.3.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 65
7.3.2. HEAD . . . . . . . . . . . . . . . . . . . . . . . . 64 7.3.2. HEAD . . . . . . . . . . . . . . . . . . . . . . . . 66
7.3.3. POST . . . . . . . . . . . . . . . . . . . . . . . . 65 7.3.3. POST . . . . . . . . . . . . . . . . . . . . . . . . 66
7.3.4. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 66 7.3.4. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 67
7.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . 68 7.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . 70
7.3.6. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 70 7.3.6. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 71
7.3.7. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 71 7.3.7. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 72
7.3.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . 72 7.3.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . 73
7.4. Method Extensibility . . . . . . . . . . . . . . . . . . 73 7.4. Method Extensibility . . . . . . . . . . . . . . . . . . 74
7.4.1. Method Registry . . . . . . . . . . . . . . . . . . . 73 7.4.1. Method Registry . . . . . . . . . . . . . . . . . . . 74
7.4.2. Considerations for New Methods . . . . . . . . . . . 73 7.4.2. Considerations for New Methods . . . . . . . . . . . 74
8. Request Header Fields . . . . . . . . . . . . . . . . . . . . 74 8. Request Header Fields . . . . . . . . . . . . . . . . . . . . 75
8.1. Controls . . . . . . . . . . . . . . . . . . . . . . . . 74 8.1. Controls . . . . . . . . . . . . . . . . . . . . . . . . 75
8.1.1. Expect . . . . . . . . . . . . . . . . . . . . . . . 74 8.1.1. Expect . . . . . . . . . . . . . . . . . . . . . . . 76
8.1.2. Max-Forwards . . . . . . . . . . . . . . . . . . . . 77 8.1.2. Max-Forwards . . . . . . . . . . . . . . . . . . . . 78
8.2. Preconditions . . . . . . . . . . . . . . . . . . . . . . 77 8.2. Preconditions . . . . . . . . . . . . . . . . . . . . . . 79
8.2.1. Evaluation . . . . . . . . . . . . . . . . . . . . . 78 8.2.1. Evaluation . . . . . . . . . . . . . . . . . . . . . 80
8.2.2. Precedence . . . . . . . . . . . . . . . . . . . . . 79 8.2.2. Precedence . . . . . . . . . . . . . . . . . . . . . 81
8.2.3. If-Match . . . . . . . . . . . . . . . . . . . . . . 81 8.2.3. If-Match . . . . . . . . . . . . . . . . . . . . . . 83
8.2.4. If-None-Match . . . . . . . . . . . . . . . . . . . . 82 8.2.4. If-None-Match . . . . . . . . . . . . . . . . . . . . 84
8.2.5. If-Modified-Since . . . . . . . . . . . . . . . . . . 83 8.2.5. If-Modified-Since . . . . . . . . . . . . . . . . . . 85
8.2.6. If-Unmodified-Since . . . . . . . . . . . . . . . . . 84 8.2.6. If-Unmodified-Since . . . . . . . . . . . . . . . . . 86
8.2.7. If-Range . . . . . . . . . . . . . . . . . . . . . . 85 8.2.7. If-Range . . . . . . . . . . . . . . . . . . . . . . 87
8.3. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 87 8.3. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 89
8.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 88 8.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 90
8.4.1. Quality Values . . . . . . . . . . . . . . . . . . . 89 8.4.1. Quality Values . . . . . . . . . . . . . . . . . . . 91
8.4.2. Accept . . . . . . . . . . . . . . . . . . . . . . . 89 8.4.2. Accept . . . . . . . . . . . . . . . . . . . . . . . 92
8.4.3. Accept-Charset . . . . . . . . . . . . . . . . . . . 91 8.4.3. Accept-Charset . . . . . . . . . . . . . . . . . . . 94
8.4.4. Accept-Encoding . . . . . . . . . . . . . . . . . . . 92 8.4.4. Accept-Encoding . . . . . . . . . . . . . . . . . . . 95
8.4.5. Accept-Language . . . . . . . . . . . . . . . . . . . 94 8.4.5. Accept-Language . . . . . . . . . . . . . . . . . . . 96
8.5. Authentication Credentials . . . . . . . . . . . . . . . 95 8.5. Authentication Credentials . . . . . . . . . . . . . . . 97
8.5.1. Challenge and Response . . . . . . . . . . . . . . . 95 8.5.1. Challenge and Response . . . . . . . . . . . . . . . 97
8.5.2. Protection Space (Realm) . . . . . . . . . . . . . . 97 8.5.2. Protection Space (Realm) . . . . . . . . . . . . . . 99
8.5.3. Authorization . . . . . . . . . . . . . . . . . . . . 98 8.5.3. Authorization . . . . . . . . . . . . . . . . . . . . 100
8.5.4. Proxy-Authorization . . . . . . . . . . . . . . . . . 98 8.5.4. Proxy-Authorization . . . . . . . . . . . . . . . . . 100
8.5.5. Authentication Scheme Extensibility . . . . . . . . . 99 8.5.5. Authentication Scheme Extensibility . . . . . . . . . 101
8.6. Request Context . . . . . . . . . . . . . . . . . . . . . 101 8.6. Request Context . . . . . . . . . . . . . . . . . . . . . 103
8.6.1. From . . . . . . . . . . . . . . . . . . . . . . . . 101 8.6.1. From . . . . . . . . . . . . . . . . . . . . . . . . 103
8.6.2. Referer . . . . . . . . . . . . . . . . . . . . . . . 102 8.6.2. Referer . . . . . . . . . . . . . . . . . . . . . . . 104
8.6.3. User-Agent . . . . . . . . . . . . . . . . . . . . . 103 8.6.3. User-Agent . . . . . . . . . . . . . . . . . . . . . 105
9. Response Status Codes . . . . . . . . . . . . . . . . . . . . 104 9. Response Status Codes . . . . . . . . . . . . . . . . . . . . 106
9.1. Overview of Status Codes . . . . . . . . . . . . . . . . 105 9.1. Overview of Status Codes . . . . . . . . . . . . . . . . 107
9.2. Informational 1xx . . . . . . . . . . . . . . . . . . . . 107 9.2. Informational 1xx . . . . . . . . . . . . . . . . . . . . 108
9.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 107 9.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 108
9.2.2. 101 Switching Protocols . . . . . . . . . . . . . . . 107 9.2.2. 101 Switching Protocols . . . . . . . . . . . . . . . 109
9.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . 108 9.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . 109
9.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 108 9.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 109
9.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 109 9.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 110
9.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . 109 9.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . 110
9.3.4. 203 Non-Authoritative Information . . . . . . . . . . 109 9.3.4. 203 Non-Authoritative Information . . . . . . . . . . 111
9.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . 110 9.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . 111
9.3.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 110 9.3.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 112
9.3.7. 206 Partial Content . . . . . . . . . . . . . . . . . 111 9.3.7. 206 Partial Content . . . . . . . . . . . . . . . . . 112
9.4. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 114 9.4. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 115
9.4.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 115 9.4.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 117
9.4.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 116 9.4.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 118
9.4.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 117 9.4.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 118
9.4.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 117 9.4.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 119
9.4.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 118 9.4.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 119
9.4.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 118 9.4.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 120
9.4.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . 119 9.4.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . 120
9.4.8. 307 Temporary Redirect . . . . . . . . . . . . . . . 119 9.4.8. 307 Temporary Redirect . . . . . . . . . . . . . . . 120
9.5. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 119 9.4.9. 308 Permanent Redirect . . . . . . . . . . . . . . . 121
9.5.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 119 9.5. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 121
9.5.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 119 9.5.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 121
9.5.3. 402 Payment Required . . . . . . . . . . . . . . . . 120 9.5.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 121
9.5.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 120 9.5.3. 402 Payment Required . . . . . . . . . . . . . . . . 122
9.5.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 120 9.5.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 122
9.5.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 121 9.5.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 122
9.5.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 121 9.5.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 123
9.5.8. 407 Proxy Authentication Required . . . . . . . . . . 121 9.5.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 123
9.5.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 121 9.5.8. 407 Proxy Authentication Required . . . . . . . . . . 123
9.5.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . 122 9.5.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 123
9.5.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 122 9.5.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . 124
9.5.12. 411 Length Required . . . . . . . . . . . . . . . . . 122 9.5.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 124
9.5.13. 412 Precondition Failed . . . . . . . . . . . . . . . 123 9.5.12. 411 Length Required . . . . . . . . . . . . . . . . . 124
9.5.14. 413 Payload Too Large . . . . . . . . . . . . . . . . 123 9.5.13. 412 Precondition Failed . . . . . . . . . . . . . . . 125
9.5.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . 123 9.5.14. 413 Payload Too Large . . . . . . . . . . . . . . . . 125
9.5.16. 415 Unsupported Media Type . . . . . . . . . . . . . 123 9.5.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . 125
9.5.17. 416 Range Not Satisfiable . . . . . . . . . . . . . . 124 9.5.16. 415 Unsupported Media Type . . . . . . . . . . . . . 125
9.5.18. 417 Expectation Failed . . . . . . . . . . . . . . . 124 9.5.17. 416 Range Not Satisfiable . . . . . . . . . . . . . . 126
9.5.19. 418 (Unused) . . . . . . . . . . . . . . . . . . . . 124 9.5.18. 417 Expectation Failed . . . . . . . . . . . . . . . 126
9.5.20. 422 Unprocessable Entity . . . . . . . . . . . . . . 125 9.5.19. 418 (Unused) . . . . . . . . . . . . . . . . . . . . 126
9.5.21. 426 Upgrade Required . . . . . . . . . . . . . . . . 125 9.5.20. 422 Unprocessable Entity . . . . . . . . . . . . . . 127
9.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 125 9.5.21. 426 Upgrade Required . . . . . . . . . . . . . . . . 127
9.6.1. 500 Internal Server Error . . . . . . . . . . . . . . 126 9.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 127
9.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 126 9.6.1. 500 Internal Server Error . . . . . . . . . . . . . . 128
9.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 126 9.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 128
9.6.4. 503 Service Unavailable . . . . . . . . . . . . . . . 126 9.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 128
9.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 126 9.6.4. 503 Service Unavailable . . . . . . . . . . . . . . . 128
9.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . 126 9.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 128
9.7. Status Code Extensibility . . . . . . . . . . . . . . . . 127 9.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . 128
9.7.1. Status Code Registry . . . . . . . . . . . . . . . . 127 9.7. Status Code Extensibility . . . . . . . . . . . . . . . . 129
9.7.2. Considerations for New Status Codes . . . . . . . . . 127 9.7.1. Status Code Registry . . . . . . . . . . . . . . . . 129
10. Response Header Fields . . . . . . . . . . . . . . . . . . . 128 9.7.2. Considerations for New Status Codes . . . . . . . . . 129
10.1. Control Data . . . . . . . . . . . . . . . . . . . . . . 128 10. Response Header Fields . . . . . . . . . . . . . . . . . . . 130
10.1.1. Origination Date . . . . . . . . . . . . . . . . . . 129 10.1. Control Data . . . . . . . . . . . . . . . . . . . . . . 130
10.1.2. Location . . . . . . . . . . . . . . . . . . . . . . 132 10.1.1. Origination Date . . . . . . . . . . . . . . . . . . 131
10.1.3. Retry-After . . . . . . . . . . . . . . . . . . . . 133 10.1.2. Location . . . . . . . . . . . . . . . . . . . . . . 134
10.1.4. Vary . . . . . . . . . . . . . . . . . . . . . . . . 134 10.1.3. Retry-After . . . . . . . . . . . . . . . . . . . . 135
10.2. Validators . . . . . . . . . . . . . . . . . . . . . . . 135 10.1.4. Vary . . . . . . . . . . . . . . . . . . . . . . . . 136
10.2.1. Weak versus Strong . . . . . . . . . . . . . . . . . 136 10.2. Validators . . . . . . . . . . . . . . . . . . . . . . . 137
10.2.2. Last-Modified . . . . . . . . . . . . . . . . . . . 138 10.2.1. Weak versus Strong . . . . . . . . . . . . . . . . . 138
10.2.3. ETag . . . . . . . . . . . . . . . . . . . . . . . . 140 10.2.2. Last-Modified . . . . . . . . . . . . . . . . . . . 139
10.2.4. When to Use Entity-Tags and Last-Modified Dates . . 143 10.2.3. ETag . . . . . . . . . . . . . . . . . . . . . . . . 141
10.3. Authentication Challenges . . . . . . . . . . . . . . . 144 10.2.4. When to Use Entity-Tags and Last-Modified Dates . . 145
10.3.1. WWW-Authenticate . . . . . . . . . . . . . . . . . . 144 10.3. Authentication Challenges . . . . . . . . . . . . . . . 145
10.3.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . 145 10.3.1. WWW-Authenticate . . . . . . . . . . . . . . . . . . 146
10.3.3. Authentication-Info . . . . . . . . . . . . . . . . 146 10.3.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . 147
10.3.4. Proxy-Authentication-Info . . . . . . . . . . . . . 147 10.3.3. Authentication-Info . . . . . . . . . . . . . . . . 147
10.4. Response Context . . . . . . . . . . . . . . . . . . . . 147 10.3.4. Proxy-Authentication-Info . . . . . . . . . . . . . 148
10.4.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . 147 10.4. Response Context . . . . . . . . . . . . . . . . . . . . 149
10.4.2. Allow . . . . . . . . . . . . . . . . . . . . . . . 148 10.4.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . 149
10.4.3. Server . . . . . . . . . . . . . . . . . . . . . . . 148 10.4.2. Allow . . . . . . . . . . . . . . . . . . . . . . . 149
11. ABNF List Extension: #rule . . . . . . . . . . . . . . . . . 149 10.4.3. Server . . . . . . . . . . . . . . . . . . . . . . . 150
12. Security Considerations . . . . . . . . . . . . . . . . . . . 150 11. ABNF List Extension: #rule . . . . . . . . . . . . . . . . . 151
12.1. Establishing Authority . . . . . . . . . . . . . . . . . 150 12. Security Considerations . . . . . . . . . . . . . . . . . . . 152
12.2. Risks of Intermediaries . . . . . . . . . . . . . . . . 151 12.1. Establishing Authority . . . . . . . . . . . . . . . . . 152
12.3. Attacks Based on File and Path Names . . . . . . . . . . 152 12.2. Risks of Intermediaries . . . . . . . . . . . . . . . . 153
12.4. Attacks Based on Command, Code, or Query Injection . . . 152 12.3. Attacks Based on File and Path Names . . . . . . . . . . 154
12.5. Attacks via Protocol Element Length . . . . . . . . . . 153 12.4. Attacks Based on Command, Code, or Query Injection . . . 154
12.6. Disclosure of Personal Information . . . . . . . . . . . 154 12.5. Attacks via Protocol Element Length . . . . . . . . . . 155
12.7. Privacy of Server Log Information . . . . . . . . . . . 154 12.6. Disclosure of Personal Information . . . . . . . . . . . 155
12.8. Disclosure of Sensitive Information in URIs . . . . . . 154 12.7. Privacy of Server Log Information . . . . . . . . . . . 155
12.9. Disclosure of Fragment after Redirects . . . . . . . . . 155 12.8. Disclosure of Sensitive Information in URIs . . . . . . 156
12.10. Disclosure of Product Information . . . . . . . . . . . 155 12.9. Disclosure of Fragment after Redirects . . . . . . . . . 156
12.11. Browser Fingerprinting . . . . . . . . . . . . . . . . . 155 12.10. Disclosure of Product Information . . . . . . . . . . . 157
12.12. Validator Retention . . . . . . . . . . . . . . . . . . 156 12.11. Browser Fingerprinting . . . . . . . . . . . . . . . . . 157
12.13. Denial-of-Service Attacks Using Range . . . . . . . . . 157 12.12. Validator Retention . . . . . . . . . . . . . . . . . . 158
12.14. Authentication Considerations . . . . . . . . . . . . . 157 12.13. Denial-of-Service Attacks Using Range . . . . . . . . . 159
12.14.1. Confidentiality of Credentials . . . . . . . . . . 157 12.14. Authentication Considerations . . . . . . . . . . . . . 159
12.14.2. Credentials and Idle Clients . . . . . . . . . . . 158 12.14.1. Confidentiality of Credentials . . . . . . . . . . 159
12.14.3. Protection Spaces . . . . . . . . . . . . . . . . . 158 12.14.2. Credentials and Idle Clients . . . . . . . . . . . 160
12.14.4. Additional Response Header Fields . . . . . . . . . 159 12.14.3. Protection Spaces . . . . . . . . . . . . . . . . . 160
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 159 12.14.4. Additional Response Header Fields . . . . . . . . . 161
13.1. URI Scheme Registration . . . . . . . . . . . . . . . . 159 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 161
13.2. Method Registration . . . . . . . . . . . . . . . . . . 159 13.1. URI Scheme Registration . . . . . . . . . . . . . . . . 161
13.3. Status Code Registration . . . . . . . . . . . . . . . . 159 13.2. Method Registration . . . . . . . . . . . . . . . . . . 161
13.4. Header Field Registration . . . . . . . . . . . . . . . 160 13.3. Status Code Registration . . . . . . . . . . . . . . . . 161
13.5. Authentication Scheme Registration . . . . . . . . . . . 160 13.4. Header Field Registration . . . . . . . . . . . . . . . 162
13.6. Content Coding Registration . . . . . . . . . . . . . . 160 13.5. Authentication Scheme Registration . . . . . . . . . . . 162
13.7. Range Unit Registration . . . . . . . . . . . . . . . . 160 13.6. Content Coding Registration . . . . . . . . . . . . . . 163
13.8. Media Type Registration . . . . . . . . . . . . . . . . 160 13.7. Range Unit Registration . . . . . . . . . . . . . . . . 163
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 161 13.8. Media Type Registration . . . . . . . . . . . . . . . . 163
14.1. Normative References . . . . . . . . . . . . . . . . . . 161 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 163
14.2. Informative References . . . . . . . . . . . . . . . . . 162 14.1. Normative References . . . . . . . . . . . . . . . . . . 163
Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 168 14.2. Informative References . . . . . . . . . . . . . . . . . 165
Appendix B. Changes from RFC 7230 . . . . . . . . . . . . . . . 172 Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 171
Appendix C. Changes from RFC 7231 . . . . . . . . . . . . . . . 173 Appendix B. Changes from RFC 7230 . . . . . . . . . . . . . . . 175
Appendix D. Changes from RFC 7232 . . . . . . . . . . . . . . . 173 Appendix C. Changes from RFC 7231 . . . . . . . . . . . . . . . 176
Appendix E. Changes from RFC 7233 . . . . . . . . . . . . . . . 173 Appendix D. Changes from RFC 7232 . . . . . . . . . . . . . . . 176
Appendix F. Changes from RFC 7235 . . . . . . . . . . . . . . . 173 Appendix E. Changes from RFC 7233 . . . . . . . . . . . . . . . 176
Appendix G. Changes from RFC 7615 . . . . . . . . . . . . . . . 173 Appendix F. Changes from RFC 7235 . . . . . . . . . . . . . . . 176
Appendix H. Change Log . . . . . . . . . . . . . . . . . . . . . 173 Appendix G. Changes from RFC 7538 . . . . . . . . . . . . . . . 176
H.1. Between RFC723x and draft 00 . . . . . . . . . . . . . . 173 Appendix H. Changes from RFC 7615 . . . . . . . . . . . . . . . 176
H.2. Since draft-ietf-httpbis-semantics-00 . . . . . . . . . . 174 Appendix I. Change Log . . . . . . . . . . . . . . . . . . . . . 176
H.3. Since draft-ietf-httpbis-semantics-01 . . . . . . . . . . 174 I.1. Between RFC723x and draft 00 . . . . . . . . . . . . . . 176
H.4. Since draft-ietf-httpbis-semantics-02 . . . . . . . . . . 176 I.2. Since draft-ietf-httpbis-semantics-00 . . . . . . . . . . 177
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 I.3. Since draft-ietf-httpbis-semantics-01 . . . . . . . . . . 177
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 184 I.4. Since draft-ietf-httpbis-semantics-02 . . . . . . . . . . 179
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 185 I.5. Since draft-ietf-httpbis-semantics-03 . . . . . . . . . . 180
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 188
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 189
1. Introduction 1. Introduction
The Hypertext Transfer Protocol (HTTP) is a stateless application- The Hypertext Transfer Protocol (HTTP) is a stateless application-
level request/response protocol that uses extensible semantics and level request/response protocol that uses extensible semantics and
self-descriptive messages for flexible interaction with network-based self-descriptive messages for flexible interaction with network-based
hypertext information systems. HTTP is defined by a series of hypertext information systems. HTTP is defined by a series of
documents that collectively form the HTTP/1.1 specification: documents that collectively form the HTTP/1.1 specification:
o "HTTP Semantics" (this document) o "HTTP Semantics" (this document)
skipping to change at page 9, line 10 skipping to change at page 9, line 13
negotiation" (Section 6.4). negotiation" (Section 6.4).
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. The other parts of RFC 7230 changes being summarized in Appendix B. The other parts of RFC 7230
are obsoleted by "HTTP/1.1 Messaging" [Messaging]. This document are obsoleted by "HTTP/1.1 Messaging" [Messaging]. This document
also obsoletes RFC 7231 (see Appendix C), RFC 7232 (see Appendix D), also obsoletes RFC 7231 (see Appendix C), RFC 7232 (see Appendix D),
RFC 7233 (see Appendix E), and RFC 7235 (see Appendix F), and RFC RFC 7233 (see Appendix E), RFC 7235 (see Appendix F), RFC 7538 (see
7615 (see Appendix G). Appendix G), and RFC 7615 (see Appendix H).
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", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Conformance criteria and considerations regarding error handling are Conformance criteria and considerations regarding error handling are
defined in Section 3. defined in Section 3.
1.2. Syntax Notation 1.2. Syntax Notation
This specification uses the Augmented Backus-Naur Form (ABNF) This specification uses the Augmented Backus-Naur Form (ABNF)
notation of [RFC5234] with a list extension, defined in Section 11, notation of [RFC5234], extended with the notation for case-
that allows for compact definition of comma-separated lists using a sensitivity in strings defined in [RFC7405].
'#' operator (similar to how the '*' operator indicates repetition).
Appendix A shows the collected grammar with all list operators It also uses a list extension, defined in Section 11, that allows for
expanded to standard ABNF notation. compact definition of comma-separated lists using a '#' operator
(similar to how the '*' operator indicates repetition). Appendix A
shows the collected grammar with all list operators expanded to
standard ABNF notation.
As a convention, ABNF rule names prefixed with "obs-" denote As a convention, ABNF rule names prefixed with "obs-" denote
"obsolete" grammar rules that appear for historical reasons. "obsolete" grammar rules that appear for historical reasons.
The following core rules are included by reference, as defined in The following core rules are included by reference, as defined in
Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return),
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).
skipping to change at page 10, line 48 skipping to change at page 10, line 52
representation of some resource identified by a URI. In the simplest representation of some resource identified by a URI. In the simplest
case, this might be accomplished via a single bidirectional case, this might be accomplished via a single bidirectional
connection (===) between the user agent (UA) and the origin server connection (===) between the user agent (UA) and the origin server
(O). (O).
request > request >
UA ======================================= O UA ======================================= O
< response < response
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 request-line that includes a method, URI, message, beginning with a method (Section 7) and URI, followed by
and protocol version (Section 3 of [Messaging]), followed by header header fields containing request modifiers, client information, and
fields containing request modifiers, client information, and representation metadata (Section 5 of [Messaging]), and finally a
representation metadata (Section 5 of [Messaging]), an empty line to message body containing the payload body (if any, Section 6 of
indicate the end of the header section, and finally a message body [Messaging]).
containing the payload body (if any, Section 6 of [Messaging]).
A server responds to a client's request by sending one or more HTTP A server responds to a client's request by sending one or more HTTP
response messages, each beginning with a status line that includes response messages, each beginning with a success or error code
the protocol version, a success or error code, and textual reason (Section 9), possibly followed by header fields containing server
phrase (Section 4 of [Messaging]), possibly followed by header fields information, resource metadata, and representation metadata
containing server information, resource metadata, and representation (Section 5 of [Messaging]), and finally a message body containing the
metadata (Section 5 of [Messaging]), an empty line to indicate the
end of the header section, and finally a message body containing the
payload body (if any, Section 6 of [Messaging]). payload body (if any, Section 6 of [Messaging]).
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.
A connection might be used for multiple request/response exchanges,
as defined in Section 9.4 of [Messaging].
Responses (both final and non-final) can be sent at any time after a Responses (both final and non-final) can be sent at any time after a
request is received, even if it is not yet complete. However, request is received, even if it is not yet complete. However,
clients (including intermediaries) might abandon a request if the clients (including intermediaries) might abandon a request if the
response is not forthcoming within a reasonable period of time. response is not forthcoming within a reasonable period of time.
The following example illustrates a typical message exchange for a The following example illustrates a typical message exchange for a
GET request (Section 7.3.1) on the URI "http://www.example.com/ GET request (Section 7.3.1) on the URI "http://www.example.com/
hello.txt": hello.txt":
Client request: Client request:
skipping to change at page 24, line 5 skipping to change at page 24, line 5
be implemented by all HTTP/1.x implementations whether or not they be implemented by all HTTP/1.x implementations whether or not they
advertise conformance with HTTP/1.1. advertise conformance with HTTP/1.1.
New header fields can be introduced without changing the protocol New header fields can be introduced without changing the protocol
version if their defined semantics allow them to be safely ignored by version if their defined semantics allow them to be safely ignored by
recipients that do not recognize them. Header field extensibility is recipients that do not recognize them. Header field extensibility is
discussed in Section 4.1.2. discussed in Section 4.1.2.
The following field names are defined by this document: The following field names are defined by this document:
+---------------------------+----------+----------+-----------------+ +---------------------------+------------+-------------------+
| Header Field Name | Protocol | Status | Reference | | Header Field Name | Status | Reference |
+---------------------------+----------+----------+-----------------+ +---------------------------+------------+-------------------+
| Accept | http | standard | Section 8.4.2 | | Accept | standard | Section 8.4.2 |
| Accept-Charset | http | standard | Section 8.4.3 | | Accept-Charset | deprecated | Section 8.4.3 |
| Accept-Encoding | http | standard | Section 8.4.4 | | Accept-Encoding | standard | Section 8.4.4 |
| Accept-Language | http | standard | Section 8.4.5 | | Accept-Language | standard | Section 8.4.5 |
| Accept-Ranges | http | standard | Section 10.4.1 | | Accept-Ranges | standard | Section 10.4.1 |
| Allow | http | standard | Section 10.4.2 | | Allow | standard | Section 10.4.2 |
| Authentication-Info | http | standard | Section 10.3.3 | | Authentication-Info | standard | Section 10.3.3 |
| Authorization | http | standard | Section 8.5.3 | | Authorization | standard | Section 8.5.3 |
| Content-Encoding | http | standard | Section 6.2.2 | | Content-Encoding | standard | Section 6.2.2 |
| Content-Language | http | standard | Section 6.2.3 | | Content-Language | standard | Section 6.2.3 |
| Content-Length | http | standard | Section 6.2.4 | | Content-Length | standard | Section 6.2.4 |
| Content-Location | http | standard | Section 6.2.5 | | Content-Location | standard | Section 6.2.5 |
| Content-Range | http | standard | Section 6.3.3 | | Content-Range | standard | Section 6.3.3 |
| Content-Type | http | standard | Section 6.2.1 | | Content-Type | standard | Section 6.2.1 |
| Date | http | standard | Section 10.1.1. | | Date | standard | Section 10.1.1.2 |
| | | | 2 | | ETag | standard | Section 10.2.3 |
| ETag | http | standard | Section 10.2.3 | | Expect | standard | Section 8.1.1 |
| Expect | http | standard | Section 8.1.1 | | From | standard | Section 8.6.1 |
| From | http | standard | Section 8.6.1 | | Host | standard | Section 5.4 |
| Host | http | standard | Section 5.4 | | If-Match | standard | Section 8.2.3 |
| If-Match | http | standard | Section 8.2.3 | | If-Modified-Since | standard | Section 8.2.5 |
| If-Modified-Since | http | standard | Section 8.2.5 | | If-None-Match | standard | Section 8.2.4 |
| If-None-Match | http | standard | Section 8.2.4 | | If-Range | standard | Section 8.2.7 |
| If-Range | http | standard | Section 8.2.7 | | If-Unmodified-Since | standard | Section 8.2.6 |
| If-Unmodified-Since | http | standard | Section 8.2.6 | | Last-Modified | standard | Section 10.2.2 |
| Last-Modified | http | standard | Section 10.2.2 | | Location | standard | Section 10.1.2 |
| Location | http | standard | Section 10.1.2 | | Max-Forwards | standard | Section 8.1.2 |
| Max-Forwards | http | standard | Section 8.1.2 | | Proxy-Authenticate | standard | Section 10.3.2 |
| Proxy-Authenticate | http | standard | Section 10.3.2 | | Proxy-Authentication-Info | standard | Section 10.3.4 |
| Proxy-Authentication-Info | http | standard | Section 10.3.4 | | Proxy-Authorization | standard | Section 8.5.4 |
| Proxy-Authorization | http | standard | Section 8.5.4 | | Range | standard | Section 8.3 |
| Range | http | standard | Section 8.3 | | Referer | standard | Section 8.6.2 |
| Referer | http | standard | Section 8.6.2 | | Retry-After | standard | Section 10.1.3 |
| Retry-After | http | standard | Section 10.1.3 | | Server | standard | Section 10.4.3 |
| Server | http | standard | Section 10.4.3 | | Trailer | standard | Section 4.4 |
| Trailer | http | standard | Section 4.4 | | User-Agent | standard | Section 8.6.3 |
| User-Agent | http | standard | Section 8.6.3 | | Vary | standard | Section 10.1.4 |
| Vary | http | standard | Section 10.1.4 | | Via | standard | Section 5.5.1 |
| Via | http | standard | Section 5.5.1 | | WWW-Authenticate | standard | Section 10.3.1 |
| WWW-Authenticate | http | standard | Section 10.3.1 | +---------------------------+------------+-------------------+
+---------------------------+----------+----------+-----------------+
4.1.1. Header Field Name Registry 4.1.1. Header Field Name Registry
HTTP header fields are registered within the "Message Headers" The "Hypertext Transfer Protocol (HTTP) Header Field Registry"
registry located at <https://www.iana.org/assignments/message- defines the namespace for HTTP header field names.
headers>, as defined by [BCP90], with the protocol "http".
Any party can request registration of a HTTP header field. See
Section 4.1.3 for considerations to take into account when creating a
new HTTP header field.
The "HTTP Header Field Name" registry is located at
"https://www.iana.org/assignments/http-headers/". Registration
requests can be made by following the instructions located there or
by sending an email to the "ietf-http-wg@ietf.org" mailing list.
Header field names are registered on the advice of a Designated
Expert (appointed by the IESG or their delegate). Header fields with
the status 'permanent' are Specification Required (using terminology
from [RFC8126]).
Registration requests consist of at least the following information:
o Header field name: The requested field name. It MUST conform to
the field-name syntax defined in Section 4.1, and SHOULD be
restricted to just letters, digits, hyphen ('-') and underscore
('_') characters, with the first character being a letter.
o Status: "permanent" or "provisional"
o Specification document(s): Reference to the document that
specifies the header field, preferably including a URI that can be
used to retrieve a copy of the document. An indication of the
relevant section(s) can also be included, but is not required.
The Expert(s) can define additional fields to be collected in the
registry, in consultation with the community.
Standards-defined names have a status of "permanent". Other names
can also be registered as permanent, if the Expert(s) find that they
are in use, in consultation with the community. Other names should
be registered as "provisional".
Provisional entries can be removed by the Expert(s) if -- in
consultation with the community -- the Expert(s) find that they are
not in use. The Experts can change a provisional entry's status to
permanent at any time.
Note that names can be registered by third parties (including the
Expert(s)), if the Expert(s) determines that an unregistered name is
widely deployed and not likely to be registered in a timely manner
otherwise.
4.1.2. Header Field Extensibility 4.1.2. Header Field Extensibility
Header fields are fully extensible: there is no limit on the Header fields are fully extensible: there is no limit on the
introduction of new field names, each presumably defining new introduction of new field names, each presumably defining new
semantics, nor on the number of header fields used in a given semantics, nor on the number of header fields used in a given
message. Existing fields are defined in each part of this message. Existing fields are defined in each part of this
specification and in many other specifications outside this document specification and in many other specifications outside this document
set. set.
skipping to change at page 25, line 33 skipping to change at page 26, line 29
evaluation, or refine the meaning of responses. evaluation, or refine the meaning of responses.
A proxy MUST forward unrecognized header fields unless the field-name A proxy MUST forward unrecognized header fields unless the field-name
is listed in the Connection header field (Section 9.1 of [Messaging]) is listed in the Connection header field (Section 9.1 of [Messaging])
or the proxy is specifically configured to block, or otherwise or the proxy is specifically configured to block, or otherwise
transform, such fields. Other recipients SHOULD ignore unrecognized transform, such fields. Other recipients SHOULD ignore unrecognized
header fields. These requirements allow HTTP's functionality to be header fields. These requirements allow HTTP's functionality to be
enhanced without requiring prior update of deployed intermediaries. enhanced without requiring prior update of deployed intermediaries.
All defined header fields ought to be registered with IANA in the All defined header fields ought to be registered with IANA in the
"Message Headers" registry. "HTTP Header Field Name" registry.
4.1.3. Considerations for New Header Fields 4.1.3. Considerations for New Header Fields
Authors of specifications defining new fields are advised to keep the Authors of specifications defining new fields are advised to keep the
name as short as practical and not to prefix the name with "X-" name as short as practical and not to prefix the name with "X-"
unless the header field will never be used on the Internet. (The unless the header field will never be used on the Internet. (The
"X-" prefix idiom has been extensively misused in practice; it was "X-" prefix idiom has been extensively misused in practice; it was
intended to only be used as a mechanism for avoiding name collisions intended to only be used as a mechanism for avoiding name collisions
inside proprietary software or intranet processing, since the prefix inside proprietary software or intranet processing, since the prefix
would ensure that private names never collide with a newly registered would ensure that private names never collide with a newly registered
skipping to change at page 27, line 45 skipping to change at page 28, line 36
The order in which header fields with differing field names are The order in which header fields with differing field names are
received is not significant. However, it is good practice to send received is not significant. However, it is good practice to send
header fields that contain control data first, such as Host on header fields that contain control data first, such as Host on
requests and Date on responses, so that implementations can decide requests and Date on responses, so that implementations can decide
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 fields might include header section is received, since later header fields might include
conditionals, authentication credentials, or deliberately misleading conditionals, authentication credentials, or deliberately misleading
duplicate header fields that would impact request processing. duplicate header fields that would impact request processing.
A sender MUST NOT generate multiple header fields with the same field Aside from the well-known exception noted below, a sender MUST NOT
name in a message unless either the entire field value for that generate multiple header fields with the same field name in a
header field is defined as a comma-separated list [i.e., #(values)] message, or append a header field when a field of the same name
or the header field is a well-known exception (as noted below). already exists in the message, unless that field's definition allows
multiple field values to be recombined as a comma-separated list
[i.e., at least one alternative of the field's definition allows a
comma-separated list, such as an ABNF rule of #(values)].
A recipient MAY combine multiple header fields with the same field A recipient MAY combine multiple header fields with the same field
name into one "field-name: field-value" pair, without changing the name into one "field-name: field-value" pair, without changing the
semantics of the message, by appending each subsequent field value to semantics of the message, by appending each subsequent field value to
the combined field value in order, separated by a comma. The order the combined field value in order, separated by a comma. The order
in which header fields with the same field name are received is in which header fields with the same field name are received is
therefore significant to the interpretation of the combined field therefore significant to the interpretation of the combined field
value; a proxy MUST NOT change the order of these field values when value; a proxy MUST NOT change the order of these field values when
forwarding a message. forwarding a message.
skipping to change at page 37, line 20 skipping to change at page 38, line 11
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 request-target when forwarding it to the next inbound
server, except as noted above to replace an empty path with "/" or server, 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 directive (Section 5.2 of that contains a no-transform cache-control response directive
[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
payload of a 200 (OK) response can inform downstream recipients that payload of a 200 (OK) response can inform downstream recipients that
a transformation has been applied by changing the response status a transformation has been applied by changing the response status
code to 203 (Non-Authoritative Information) (Section 9.3.4). code to 203 (Non-Authoritative Information) (Section 9.3.4).
A proxy SHOULD NOT modify header fields that provide information A proxy SHOULD NOT modify header fields that provide information
about the endpoints of the communication chain, the resource state, about the endpoints of the communication chain, the resource state,
or the selected representation (other than the payload) unless the or the selected representation (other than the payload) unless the
skipping to change at page 38, line 51 skipping to change at page 39, line 44
parameter = token "=" ( token / quoted-string ) parameter = token "=" ( token / quoted-string )
The type, subtype, and parameter name tokens are case-insensitive. The type, subtype, and parameter name tokens are case-insensitive.
Parameter values might or might not be case-sensitive, depending on Parameter values might or might not be case-sensitive, depending on
the semantics of the parameter name. The presence or absence of a the semantics of the parameter name. The presence or absence of a
parameter might be significant to the processing of a media-type, parameter might be significant to the processing of a media-type,
depending on its definition within the media type registry. depending on its definition within the media type registry.
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. For example, the following and unquoted values are equivalent.
examples are all equivalent, but the first is preferred for
consistency: For example, the following examples are all equivalent, but the first
is preferred for consistency:
text/html;charset=utf-8 text/html;charset=utf-8
text/html;charset=UTF-8
Text/HTML;Charset="utf-8" Text/HTML;Charset="utf-8"
text/html; charset="utf-8" text/html; charset="utf-8"
Furthermore, the example below is equivalent as well, as the
"charset" parameter value is defined as case-insensitive ([RFC2046],
Section 4.1.2):
text/html;charset=UTF-8
Media types ought to be registered with IANA according to the Media types ought to be registered with IANA according to the
procedures defined in [BCP13]. procedures defined in [BCP13].
Note: Unlike some similar constructs in other header fields, media Note: Unlike some similar constructs in other header fields, media
type parameters do not allow whitespace (even "bad" whitespace) type parameters do not allow whitespace (even "bad" whitespace)
around the "=" character. around the "=" character.
6.1.1.1. Charset 6.1.1.1. Charset
HTTP uses charset names to indicate or negotiate the character HTTP uses charset names to indicate or negotiate the character
skipping to change at page 41, line 11 skipping to change at page 42, line 8
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.4)
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 |
| | | .1.2.1 | | | | 6.1.2.1 |
| deflate | "deflate" compressed data ([RFC1951]) | Section 6 | | deflate | "deflate" compressed data ([RFC1951]) | Section |
| | inside the "zlib" data format | .1.2.2 | | | inside the "zlib" data format | 6.1.2.2 |
| | ([RFC1950]) | | | | ([RFC1950]) | |
| gzip | GZIP file format [RFC1952] | Section 6 | | gzip | GZIP file format [RFC1952] | Section |
| | | .1.2.3 | | | | 6.1.2.3 |
| identity | Reserved (synonym for "no encoding" in | Section 8 | | identity | Reserved (synonym for "no encoding" in | Section |
| | Accept-Encoding) | .4.4 | | | Accept-Encoding) | 8.4.4 |
| x-compress | Deprecated (alias for compress) | Section 6 | | x-compress | Deprecated (alias for compress) | Section |
| | | .1.2.1 | | | | 6.1.2.1 |
| x-gzip | Deprecated (alias for gzip) | Section 6 | | x-gzip | Deprecated (alias for gzip) | Section |
| | | .1.2.3 | | | | 6.1.2.3 |
+------------+------------------------------------------+-----------+ +------------+------------------------------------------+-----------+
6.1.2.1. Compress Coding 6.1.2.1. Compress Coding
The "compress" coding is an adaptive Lempel-Ziv-Welch (LZW) coding The "compress" coding is an adaptive Lempel-Ziv-Welch (LZW) coding
[Welch] that is commonly produced by the UNIX file compression [Welch] that is commonly produced by the UNIX file compression
program "compress". A recipient SHOULD consider "x-compress" to be program "compress". A recipient SHOULD consider "x-compress" to be
equivalent to "compress". equivalent to "compress".
6.1.2.2. Deflate Coding 6.1.2.2. Deflate Coding
skipping to change at page 43, line 31 skipping to change at page 44, line 26
describe which part of a representation is being transferred. describe which part of a representation is being transferred.
range-unit = bytes-unit / other-range-unit range-unit = bytes-unit / other-range-unit
The following range unit names are defined by this document: The following range unit names are defined by this document:
+-------------+---------------------------------------+-------------+ +-------------+---------------------------------------+-------------+
| Range Unit | Description | Reference | | Range Unit | Description | Reference |
| Name | | | | Name | | |
+-------------+---------------------------------------+-------------+ +-------------+---------------------------------------+-------------+
| bytes | a range of octets | Section 6.1 | | bytes | a range of octets | Section |
| | | .4.1 | | | | 6.1.4.1 |
| none | reserved as keyword, indicating no | Section 10. | | none | reserved as keyword, indicating no | Section |
| | ranges are supported | 4.1 | | | ranges are supported | 10.4.1 |
+-------------+---------------------------------------+-------------+ +-------------+---------------------------------------+-------------+
6.1.4.1. Byte Ranges 6.1.4.1. Byte Ranges
Since representation data is transferred in payloads as a sequence of Since representation data is transferred in payloads as a sequence of
octets, a byte range is a meaningful substructure for any octets, a byte range is a meaningful substructure for any
representation transferable over HTTP (Section 6). The "bytes" range representation transferable over HTTP (Section 6). The "bytes" range
unit is defined for expressing subranges of the data's octet unit is defined for expressing subranges of the data's octet
sequence. sequence.
skipping to change at page 69, line 46 skipping to change at page 71, line 9
o a 204 (No Content) status code if the action has been enacted and o a 204 (No Content) status code if the action has been enacted and
no further information is to be supplied, or no further information is to be supplied, or
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 payload within a DELETE request message has no defined semantics; A payload within a DELETE request message has no defined semantics;
sending a payload body on a DELETE request might cause some existing sending a payload body on a DELETE request might cause some existing
implementations to reject the request. implementations to reject the request.
Responses to the DELETE method are not cacheable. If a DELETE Responses to the DELETE method are not cacheable. If a successful
request passes through a cache that has one or more stored responses DELETE request passes through a cache that has one or more stored
for the effective request URI, those stored responses will be responses for the effective request URI, those stored responses will
invalidated (see Section 4.4 of [Caching]). be 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 packets, in both directions, until the tunnel is closed. Tunnels
are commonly used to create an end-to-end virtual connection, through are commonly used to create an end-to-end virtual connection, through
one or more proxies, which can then be secured using TLS (Transport one or more proxies, which can then be secured using TLS (Transport
Layer Security, [RFC5246]). Layer Security, [RFC5246]).
skipping to change at page 79, line 16 skipping to change at page 80, line 38
cannot act as a cache for requests on the target resource MUST NOT cannot act as a cache for requests on the target resource MUST NOT
evaluate the conditional request header fields defined by this evaluate the conditional request header fields defined by this
specification, and it MUST forward them if the request is forwarded, specification, and it MUST forward them if the request is forwarded,
since the generating client intends that they be evaluated by a since the generating client intends that they be evaluated by a
server that can provide a current representation. Likewise, a server server that can provide a current representation. Likewise, a server
MUST ignore the conditional request header fields defined by this MUST ignore the conditional request header fields defined by this
specification when received with a request method that does not specification when received with a request method that does not
involve the selection or modification of a selected representation, involve the selection or modification of a selected representation,
such as CONNECT, OPTIONS, or TRACE. such as CONNECT, OPTIONS, or TRACE.
Note that protocol extensions can modify the conditions under which
revalidation is triggered. For example, the "immutable" cache
directive (defined by [RFC8246]) instructs caches to forgo
revalidation of fresh responses even when requested by the client.
Conditional request header fields that are defined by extensions to Conditional request header fields that are defined by extensions to
HTTP might place conditions on all recipients, on the state of the HTTP might place conditions on all recipients, on the state of the
target resource in general, or on a group of resources. For target resource in general, or on a group of resources. For
instance, the "If" header field in WebDAV can make a request instance, the "If" header field in WebDAV can make a request
conditional on various aspects of multiple resources, such as locks, conditional on various aspects of multiple resources, such as locks,
if the recipient understands and implements that field ([RFC4918], if the recipient understands and implements that field ([RFC4918],
Section 10.4). Section 10.4).
Although conditional request header fields are defined as being Although conditional request header fields are defined as being
usable with the HEAD method (to keep HEAD's semantics consistent with usable with the HEAD method (to keep HEAD's semantics consistent with
skipping to change at page 89, line 14 skipping to change at page 91, line 14
+-------------------+---------------+ +-------------------+---------------+
| Header Field Name | Defined in... | | Header Field Name | Defined in... |
+-------------------+---------------+ +-------------------+---------------+
| Accept | Section 8.4.2 | | Accept | Section 8.4.2 |
| Accept-Charset | Section 8.4.3 | | Accept-Charset | Section 8.4.3 |
| Accept-Encoding | Section 8.4.4 | | Accept-Encoding | Section 8.4.4 |
| Accept-Language | Section 8.4.5 | | Accept-Language | Section 8.4.5 |
+-------------------+---------------+ +-------------------+---------------+
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
negotiation. If the header field is present in a request and none of
the available representations for the response can be considered
acceptable according to it, the origin server can either honor the
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
content negotiation for that request header field. This does not
imply, however, that the client will be able to use the
representation.
Note: Sending these header fields makes it easier for a server to
identify an individual by virtue of the user agent's request
characteristics (Section 12.11).
Each of these header fields defines a wildcard value (often, "*") to
select unspecified values. If no wildcard is present, all values not
explicitly mentioned in the field are considered "not acceptable" to
the client.
Note: In practice, using wildcards in content negotiation has limited
practical value, because it is seldom useful to say, for example, "I
prefer image/* more or less than (some other specific value)".
Clients can explicitly request a 406 (Not Acceptable) response if a
more preferred format is not available by sending Accept: */*;q=0,
but they still need to be able to handle a different response, since
the server is allowed to ignore their preference.
8.4.1. Quality Values 8.4.1. Quality Values
Many of the request header fields for proactive negotiation use a Many of the request header fields for proactive negotiation use a
common parameter, named "q" (case-insensitive), to assign a relative common parameter, named "q" (case-insensitive), to assign a relative
"weight" to the preference for that associated kind of content. This "weight" to the preference for that associated kind of content. This
weight is referred to as a "quality value" (or "qvalue") because the weight is referred to as a "quality value" (or "qvalue") because the
same parameter name is often used within server configurations to same parameter name is often used within server configurations to
assign a weight to the relative quality of the various assign a weight to the relative quality of the various
representations that can be selected for a resource. representations that can be selected for a resource.
skipping to change at page 89, line 39 skipping to change at page 92, line 20
weight = OWS ";" OWS "q=" qvalue weight = OWS ";" OWS "q=" qvalue
qvalue = ( "0" [ "." 0*3DIGIT ] ) qvalue = ( "0" [ "." 0*3DIGIT ] )
/ ( "1" [ "." 0*3("0") ] ) / ( "1" [ "." 0*3("0") ] )
A sender of qvalue MUST NOT generate more than three digits after the A sender of qvalue MUST NOT generate more than three digits after the
decimal point. User configuration of these values ought to be decimal point. User configuration of these values ought to be
limited in the same fashion. limited in the same fashion.
8.4.2. Accept 8.4.2. Accept
The "Accept" header field can be used by user agents to specify The "Accept" header field can be used by user agents to specify their
response media types that are acceptable. Accept header fields can preferences regarding response media types. For example, Accept
be used to indicate that the request is specifically limited to a header fields can be used to indicate that the request is
small set of desired types, as in the case of a request for an in- specifically limited to a small set of desired types, as in the case
line image. of a request for an in-line image.
Accept = #( media-range [ accept-params ] ) Accept = #( media-range [ accept-params ] )
media-range = ( "*/*" media-range = ( "*/*"
/ ( type "/" "*" ) / ( type "/" "*" )
/ ( type "/" subtype ) / ( type "/" subtype )
) *( OWS ";" OWS parameter ) ) *( OWS ";" OWS parameter )
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 ) ]
skipping to change at page 90, line 33 skipping to change at page 93, line 14
parameters in Accept. Future media types are discouraged from parameters in Accept. Future media types are discouraged from
registering any parameter named "q". registering any parameter named "q".
The example The example
Accept: audio/*; q=0.2, audio/basic Accept: audio/*; q=0.2, audio/basic
is interpreted as "I prefer audio/basic, but send me any audio type is interpreted as "I prefer audio/basic, but send me any audio type
if it is the best available after an 80% markdown in quality". if it is the best available after an 80% markdown in quality".
A request without any Accept header field implies that the user agent
will accept any media type in response. If the header field is
present in a request and none of the available representations for
the response have a media type that is listed as acceptable, the
origin server can either honor the 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 content negotiation.
A more elaborate example is A more elaborate example is
Accept: text/plain; q=0.5, text/html, Accept: text/plain; q=0.5, text/html,
text/x-dvi; q=0.8, text/x-c text/x-dvi; q=0.8, text/x-c
Verbally, this would be interpreted as "text/html and text/x-c are Verbally, this would be interpreted as "text/html and text/x-c are
the equally preferred media types, but if they do not exist, then the equally preferred media types, but if they do not exist, then
send the text/x-dvi representation, and if that does not exist, send send the text/x-dvi representation, and if that does not exist, send
the text/plain representation". the text/plain representation".
skipping to change at page 91, line 49 skipping to change at page 94, line 24
+-------------------+---------------+ +-------------------+---------------+
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.3. 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 what charsets are acceptable in textual response content. indicate its preferences for charsets in textual response content.
This field allows user agents capable of understanding more For example, this field allows user agents capable of understanding
comprehensive or special-purpose charsets to signal that capability more comprehensive or special-purpose charsets to signal that
to an origin server that is capable of representing information in capability to an origin server that is capable of representing
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 8.4.1.
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. If no "*" is present in an Accept-Charset field, then Charset field.
any charsets not explicitly mentioned in the field are considered
"not acceptable" to the client.
A request without any Accept-Charset header field implies that the
user agent will accept any charset in response. Most general-purpose
user agents do not send Accept-Charset, unless specifically
configured to do so, because a detailed list of supported charsets
makes it easier for a server to identify an individual by virtue of
the user agent's request characteristics (Section 12.11).
If an Accept-Charset header field is present in a request and none of Note: Accept-Charset is deprecated because UTF-8 has become nearly
the available representations for the response has a charset that is ubiquitous and sending a detailed list of user-preferred charsets
listed as acceptable, the origin server can either honor the header wastes bandwidth, increases latency, and makes passive fingerprinting
field, by sending a 406 (Not Acceptable) response, or disregard the far too easy (Section 12.11). Most general-purpose user agents do
header field by treating the resource as if it is not subject to not send Accept-Charset, unless specifically configured to do so.
content negotiation.
8.4.4. Accept-Encoding 8.4.4. Accept-Encoding
The "Accept-Encoding" header field can be used by user agents to The "Accept-Encoding" header field can be used by user agents to
indicate what response content-codings (Section 6.1.2) are acceptable indicate their preferences regarding response content-codings
in the response. An "identity" token is used as a synonym for "no (Section 6.1.2). An "identity" token is used as a synonym for "no
encoding" in order to communicate when no encoding is preferred. encoding" in order to communicate when no encoding is preferred.
Accept-Encoding = #( codings [ weight ] ) Accept-Encoding = #( codings [ weight ] )
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 8.4.1. 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
A request without an Accept-Encoding header field implies that the
user agent has no preferences regarding content-codings. Although
this allows the server to use any content-coding in a response, it
does not imply that the user agent will be able to correctly process
all encodings.
A server tests whether a content-coding for a given representation is A server tests whether a content-coding for a given representation is
acceptable using these rules: acceptable using these rules:
1. If no Accept-Encoding field is in the request, any content-coding 1. If no Accept-Encoding field is in the request, any content-coding
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".
skipping to change at page 94, line 24 skipping to change at page 96, line 30
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 8.4.1. 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".
A request without any Accept-Language header field implies that the
user agent will accept any language in response. If the header field
is present in a request and none of the available representations for
the response have a matching language tag, the origin server can
either disregard the header field by treating the response as if it
is not subject to content negotiation or honor the header field by
sending a 406 (Not Acceptable) response. However, the latter is not
encouraged, as doing so can prevent users from accessing content that
they might be able to use (with translation software, for example).
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
maximize interoperability, many user agents assign each language tag maximize interoperability, many user agents assign each language tag
a unique quality value while also listing them in order of decreasing a unique quality value while also listing them in order of decreasing
quality. Additional discussion of language priority lists can be quality. Additional discussion of language priority lists can be
found in Section 2.3 of [RFC4647]. found in Section 2.3 of [RFC4647].
For matching, Section 3 of [RFC4647] defines several matching For matching, Section 3 of [RFC4647] defines several matching
skipping to change at page 101, line 10 skipping to change at page 103, line 10
o The credentials carried in an Authorization header field are o The credentials carried in an Authorization header field are
specific to the user agent and, therefore, have the same effect on specific to the user agent and, therefore, have the same effect on
HTTP caches as the "private" Cache-Control response directive HTTP caches as the "private" Cache-Control response directive
(Section 5.2.2.6 of [Caching]), within the scope of the request in (Section 5.2.2.6 of [Caching]), within the scope of the request in
which they appear. which they appear.
Therefore, new authentication schemes that choose not to carry Therefore, new authentication schemes that choose not to carry
credentials in the Authorization header field (e.g., using a newly credentials in the Authorization header field (e.g., using a newly
defined header field) will need to explicitly disallow caching, by defined header field) will need to explicitly disallow caching, by
mandating the use of either Cache-Control request directives mandating the use of Cache-Control response directives (e.g.,
(e.g., "no-store", Section 5.2.1.5 of [Caching]) or response "private").
directives (e.g., "private").
o Schemes using Authentication-Info, Proxy-Authentication-Info, or o Schemes using Authentication-Info, Proxy-Authentication-Info, or
any other authentication related response header field need to any other authentication related response header field need to
consider and document the related security considerations (see consider and document the related security considerations (see
Section 12.14.4). Section 12.14.4).
8.6. Request Context 8.6. Request Context
The following request header fields provide additional information The following request header fields provide additional information
about the request context, including information about the user, user about the request context, including information about the user, user
skipping to change at page 106, line 25 skipping to change at page 107, line 44
| 205 | Reset Content | Section 9.3.6 | | 205 | Reset Content | Section 9.3.6 |
| 206 | Partial Content | Section 9.3.7 | | 206 | Partial Content | Section 9.3.7 |
| 300 | Multiple Choices | Section 9.4.1 | | 300 | Multiple Choices | Section 9.4.1 |
| 301 | Moved Permanently | Section 9.4.2 | | 301 | Moved Permanently | Section 9.4.2 |
| 302 | Found | Section 9.4.3 | | 302 | Found | Section 9.4.3 |
| 303 | See Other | Section 9.4.4 | | 303 | See Other | Section 9.4.4 |
| 304 | Not Modified | Section 9.4.5 | | 304 | Not Modified | Section 9.4.5 |
| 305 | Use Proxy | Section 9.4.6 | | 305 | Use Proxy | Section 9.4.6 |
| 306 | (Unused) | Section 9.4.7 | | 306 | (Unused) | Section 9.4.7 |
| 307 | Temporary Redirect | Section 9.4.8 | | 307 | Temporary Redirect | Section 9.4.8 |
| 308 | Permanent Redirect | Section 9.4.9 |
| 400 | Bad Request | Section 9.5.1 | | 400 | Bad Request | Section 9.5.1 |
| 401 | Unauthorized | Section 9.5.2 | | 401 | Unauthorized | Section 9.5.2 |
| 402 | Payment Required | Section 9.5.3 | | 402 | Payment Required | Section 9.5.3 |
| 403 | Forbidden | Section 9.5.4 | | 403 | Forbidden | Section 9.5.4 |
| 404 | Not Found | Section 9.5.5 | | 404 | Not Found | Section 9.5.5 |
| 405 | Method Not Allowed | Section 9.5.6 | | 405 | Method Not Allowed | Section 9.5.6 |
| 406 | Not Acceptable | Section 9.5.7 | | 406 | Not Acceptable | Section 9.5.7 |
| 407 | Proxy Authentication Required | Section 9.5.8 | | 407 | Proxy Authentication Required | Section 9.5.8 |
| 408 | Request Timeout | Section 9.5.9 | | 408 | Request Timeout | Section 9.5.9 |
| 409 | Conflict | Section 9.5.10 | | 409 | Conflict | Section 9.5.10 |
skipping to change at page 114, line 39 skipping to change at page 116, line 12
the user agent MAY automatically redirect its request to the URI the user agent MAY automatically redirect its request to the URI
referenced by the Location field value, even if the specific status referenced by the Location field value, even if the specific status
code is not understood. Automatic redirection needs to be done with code is not understood. Automatic redirection needs to be done with
care for methods not known to be safe, as defined in Section 7.2.1, care for methods not known to be safe, as defined in Section 7.2.1,
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), and 307 status codes 301 (Moved Permanently), 302 (Found), 307 (Temporary
(Temporary 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 request target, 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
skipping to change at page 115, line 22 skipping to change at page 116, line 36
Note: In HTTP/1.0, the status codes 301 (Moved Permanently) and Note: In HTTP/1.0, the status codes 301 (Moved Permanently) and
302 (Found) were defined for the first type of redirect 302 (Found) were defined for the first type of redirect
([RFC1945], Section 9.3). Early user agents split on whether the ([RFC1945], Section 9.3). Early user agents split on whether the
method applied to the redirect target would be the same as the method applied to the redirect target would be the same as the
original request or would be rewritten as GET. Although HTTP original request or would be rewritten as GET. Although HTTP
originally defined the former semantics for 301 and 302 (to match originally defined the former semantics for 301 and 302 (to match
its original implementation at CERN), and defined 303 (See Other) its original implementation at CERN), and defined 303 (See Other)
to match the latter semantics, prevailing practice gradually to match the latter semantics, prevailing practice gradually
converged on the latter semantics for 301 and 302 as well. The converged on the latter semantics for 301 and 302 as well. The
first revision of HTTP/1.1 added 307 (Temporary Redirect) to first revision of HTTP/1.1 added 307 (Temporary Redirect) to
indicate the former semantics without being impacted by divergent indicate the former semantics of 302 without being impacted by
practice. Over 10 years later, most user agents still do method divergent practice. For the same reason, 308 (Permanent Redirect)
rewriting for 301 and 302; therefore, this specification makes was later on added in [RFC7538] to match 301. Over 10 years
that behavior conformant when the original request is POST. later, most user agents still do method rewriting for 301 and 302;
therefore, [RFC7231] made that behavior conformant when the
original request is POST.
A client SHOULD detect and intervene in cyclical redirections (i.e., A client SHOULD detect and intervene in cyclical redirections (i.e.,
"infinite" redirection loops). "infinite" redirection loops).
Note: An earlier version of this specification recommended a Note: An earlier version of this specification recommended a
maximum of five redirections ([RFC2068], Section 10.3). Content maximum of five redirections ([RFC2068], Section 10.3). Content
developers need to be aware that some clients might implement such developers need to be aware that some clients might implement such
a fixed limitation. a fixed limitation.
9.4.1. 300 Multiple Choices 9.4.1. 300 Multiple Choices
skipping to change at page 116, line 51 skipping to change at page 118, line 24
references sent by the server, where possible. references sent by the server, where possible.
The server SHOULD generate a Location header field in the response The server SHOULD generate a Location header field in the response
containing a preferred URI reference for the new permanent URI. The containing a preferred URI reference for the new permanent URI. The
user agent MAY use the Location field value for automatic user agent MAY use the Location field value for automatic
redirection. The server's response payload usually contains a short redirection. The server's response payload usually contains a short
hypertext note with a hyperlink to the new URI(s). hypertext note with a hyperlink to the new URI(s).
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 308 (Permanent Redirect) status code
can be used instead. can be used instead.
A 301 response is cacheable by default; i.e., unless otherwise A 301 response is cacheable by default; 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
skipping to change at page 119, line 25 skipping to change at page 121, line 5
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 effective request URI
for future requests. 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: This status code is similar to 302 (Found), except that it 9.4.9. 308 Permanent Redirect
does not allow changing the request method from POST to GET. This
specification defines no equivalent counterpart for 301 (Moved The 308 (Permanent Redirect) status code indicates that the target
Permanently) ([RFC7538], however, defines the status code 308 resource has been assigned a new permanent URI and any future
(Permanent Redirect) for this purpose). references to this resource ought to use one of the enclosed URIs.
Clients with link editing capabilities ought to automatically re-link
references to the effective request URI to one or more of the new
references sent by the server, where possible.
The server SHOULD generate a Location header field in the response
containing a preferred URI reference for the new permanent URI. The
user agent MAY use the Location field value for automatic
redirection. The server's response payload usually contains a short
hypertext note with a hyperlink to the new URI(s).
A 308 response is cacheable by default; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [Caching]).
Note: This status code is much younger (June 2014) than its
sibling codes, and thus might not be recognized everywhere. See
Section 4 of [RFC7538] for deployment considerations.
9.5. Client Error 4xx 9.5. Client Error 4xx
The 4xx (Client Error) class of status code indicates that the client The 4xx (Client Error) class of status code indicates that the client
seems to have erred. Except when responding to a HEAD request, the seems to have erred. Except when responding to a HEAD request, the
server SHOULD send a representation containing an explanation of the server SHOULD send a representation containing an explanation of the
error situation, and whether it is a temporary or permanent error situation, and whether it is a temporary or permanent
condition. These status codes are applicable to any request method. condition. These status codes are applicable to any request method.
User agents SHOULD display any included representation to the user. User agents SHOULD display any included representation to the user.
skipping to change at page 130, line 11 skipping to change at page 132, line 11
to be in UTC. A sender that generates HTTP-date values from a local to be in UTC. A sender that generates HTTP-date values from a local
clock ought to use NTP ([RFC5905]) or some similar protocol to clock ought to use NTP ([RFC5905]) or some similar protocol to
synchronize its clock to UTC. synchronize its clock to UTC.
Preferred format: Preferred format:
IMF-fixdate = day-name "," SP date1 SP time-of-day SP GMT IMF-fixdate = day-name "," SP date1 SP time-of-day SP GMT
; fixed length/zone/capitalization subset of the format ; fixed length/zone/capitalization subset of the format
; see Section 3.3 of [RFC5322] ; see Section 3.3 of [RFC5322]
day-name = %x4D.6F.6E ; "Mon", case-sensitive day-name = %s"Mon" / %s"Tue" / %s"Wed"
/ %x54.75.65 ; "Tue", case-sensitive / %s"Thu" / %s"Fri" / %s"Sat" / %s"Sun"
/ %x57.65.64 ; "Wed", case-sensitive
/ %x54.68.75 ; "Thu", case-sensitive
/ %x46.72.69 ; "Fri", case-sensitive
/ %x53.61.74 ; "Sat", case-sensitive
/ %x53.75.6E ; "Sun", case-sensitive
date1 = day SP month SP year date1 = day SP month SP year
; e.g., 02 Jun 1982 ; e.g., 02 Jun 1982
day = 2DIGIT day = 2DIGIT
month = %x4A.61.6E ; "Jan", case-sensitive month = %s"Jan" / %s"Feb" / %s"Mar" / %s"Apr"
/ %x46.65.62 ; "Feb", case-sensitive / %s"May" / %s"Jun" / %s"Jul" / %s"Aug"
/ %x4D.61.72 ; "Mar", case-sensitive / %s"Sep" / %s"Oct" / %s"Nov" / %s"Dec"
/ %x41.70.72 ; "Apr", case-sensitive
/ %x4D.61.79 ; "May", case-sensitive
/ %x4A.75.6E ; "Jun", case-sensitive
/ %x4A.75.6C ; "Jul", case-sensitive
/ %x41.75.67 ; "Aug", case-sensitive
/ %x53.65.70 ; "Sep", case-sensitive
/ %x4F.63.74 ; "Oct", case-sensitive
/ %x4E.6F.76 ; "Nov", case-sensitive
/ %x44.65.63 ; "Dec", case-sensitive
year = 4DIGIT year = 4DIGIT
GMT = %x47.4D.54 ; "GMT", case-sensitive GMT = %s"GMT"
time-of-day = hour ":" minute ":" second time-of-day = hour ":" minute ":" second
; 00:00:00 - 23:59:60 (leap second) ; 00:00:00 - 23:59:60 (leap second)
hour = 2DIGIT hour = 2DIGIT
minute = 2DIGIT minute = 2DIGIT
second = 2DIGIT second = 2DIGIT
Obsolete formats: Obsolete formats:
skipping to change at page 131, line 4 skipping to change at page 132, line 35
time-of-day = hour ":" minute ":" second time-of-day = hour ":" minute ":" second
; 00:00:00 - 23:59:60 (leap second) ; 00:00:00 - 23:59:60 (leap second)
hour = 2DIGIT hour = 2DIGIT
minute = 2DIGIT minute = 2DIGIT
second = 2DIGIT second = 2DIGIT
Obsolete formats: Obsolete formats:
obs-date = rfc850-date / asctime-date obs-date = rfc850-date / asctime-date
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
date2 = day "-" month "-" 2DIGIT date2 = day "-" month "-" 2DIGIT
; e.g., 02-Jun-82 ; e.g., 02-Jun-82
day-name-l = %x4D.6F.6E.64.61.79 ; "Monday", case-sensitive day-name-l = %s"Monday" / %s"Tuesday" / %s"Wednesday"
/ %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive / %s"Thursday" / %s"Friday" / %s"Saturday" / %s"Sunday"
/ %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive
/ %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive
/ %x46.72.69.64.61.79 ; "Friday", case-sensitive
/ %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive
/ %x53.75.6E.64.61.79 ; "Sunday", case-sensitive
asctime-date = day-name SP date3 SP time-of-day SP year asctime-date = day-name SP date3 SP time-of-day SP year
date3 = month SP ( 2DIGIT / ( SP 1DIGIT )) date3 = month SP ( 2DIGIT / ( SP 1DIGIT ))
; e.g., Jun 2 ; e.g., Jun 2
HTTP-date is case sensitive. A sender MUST NOT generate additional HTTP-date is case sensitive. A sender MUST NOT generate additional
whitespace in an HTTP-date beyond that specifically included as SP in whitespace in an HTTP-date beyond that specifically included as SP in
the grammar. The semantics of day-name, day, month, year, and time- the grammar. The semantics of day-name, day, month, year, and time-
of-day are the same as those defined for the Internet Message Format of-day are the same as those defined for the Internet Message Format
constructs with the corresponding name ([RFC5322], Section 3.3). constructs with the corresponding name ([RFC5322], Section 3.3).
skipping to change at page 135, line 35 skipping to change at page 137, line 14
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 request target, 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 directives Likewise, an origin server might use Cache-Control response
(Section 5.2 of [Caching]) to supplant Vary if it considers the directives (Section 5.2 of [Caching]) to supplant Vary if it
variance less significant than the performance cost of Vary's impact considers the variance less significant than the performance cost of
on caching. Vary's impact on caching.
10.2. Validators 10.2. Validators
Validator header fields convey metadata about the selected Validator header fields convey metadata about the selected
representation (Section 6). In responses to safe requests, validator representation (Section 6). In responses to safe requests, validator
fields describe the selected representation chosen by the origin fields describe the selected representation chosen by the origin
server while handling the response. Note that, depending on the server while handling the response. Note that, depending on the
status code semantics, the selected representation for a given status code semantics, the selected representation for a given
response is not necessarily the same as the representation enclosed response is not necessarily the same as the representation enclosed
as response payload. as response payload.
skipping to change at page 140, line 33 skipping to change at page 142, line 11
differentiating between multiple representations of the same differentiating between multiple representations of the same
resource, regardless of whether those multiple representations are resource, regardless of whether those multiple representations are
due to resource state changes over time, content negotiation due to resource state changes over time, content negotiation
resulting in multiple representations being valid at the same time, resulting in multiple representations being valid at the same time,
or both. An entity-tag consists of an opaque quoted string, possibly or both. An entity-tag consists of an opaque quoted string, possibly
prefixed by a weakness indicator. prefixed by a weakness indicator.
ETag = entity-tag ETag = entity-tag
entity-tag = [ weak ] opaque-tag entity-tag = [ weak ] opaque-tag
weak = %x57.2F ; "W/", case-sensitive weak = %s"W/"
opaque-tag = DQUOTE *etagc DQUOTE opaque-tag = DQUOTE *etagc DQUOTE
etagc = %x21 / %x23-7E / obs-text etagc = %x21 / %x23-7E / obs-text
; VCHAR except double quotes, plus obs-text ; VCHAR except double quotes, plus obs-text
Note: Previously, opaque-tag was defined to be a quoted-string Note: Previously, opaque-tag was defined to be a quoted-string
([RFC2616], Section 3.11); thus, some recipients might perform ([RFC2616], Section 3.11); thus, some recipients might perform
backslash unescaping. Servers therefore ought to avoid backslash backslash unescaping. Servers therefore ought to avoid backslash
characters in entity tags. characters in entity tags.
An entity-tag can be more reliable for validation than a modification An entity-tag can be more reliable for validation than a modification
skipping to change at page 160, line 16 skipping to change at page 162, line 7
Transfer Protocol (HTTP) Status Code Registry: Transfer Protocol (HTTP) Status Code Registry:
Value: 418 Value: 418
Description: (Unused) Description: (Unused)
Reference Section 9.5.19 Reference Section 9.5.19
13.4. Header Field Registration 13.4. Header Field Registration
Please update the "Message Headers" registry of "Permanent Message Please create a new registry as outlined in Section 4.1.1.
Header Field Names" at <https://www.iana.org/assignments/message-
headers> with the header field names listed in the table of After creating the registry, all entries in the Permanent and
Section 4.1. Provisional Message Header Registries with the protocol 'http' are to
be moved to it, with the following changes applied:
1. The 'Applicable Protocol' field is to be omitted.
2. Entries with a status of 'standard', 'experimental', or
'informational' are to have a status of 'permanent'.
3. Entries with a status of 'deprecated' are to have a status of
'obsoleted'.
4. Provisional entries without a status are to have a status of
'provisional'.
5. Permanent entries without a status (after confirmation that the
registration document did not define one) will have a status of
'provisional'. The Expert(s) can choose to update their status
if there is evidence that another is more appropriate.
Please annotate the Permanent and Provisional Message Header
registries to indicate that HTTP header field registrations have
moved, with an appropriate link.
After that is complete, please update the new registry with the
header field names listed in the table of Section 4.1.
Finally, please update the "Content-MD5" entry in the new registry to
have a status of 'obsoleted' with references to Section 14.15 of
[RFC2616] (for the definition of the header field) and Appendix B of
[RFC7231] (which removed the field definition from the updated
specification).
13.5. Authentication Scheme Registration 13.5. Authentication Scheme Registration
Please update the "Hypertext Transfer Protocol (HTTP) Authentication Please update the "Hypertext Transfer Protocol (HTTP) Authentication
Scheme Registry" at <https://www.iana.org/assignments/http- Scheme Registry" at <https://www.iana.org/assignments/http-
authschemes> with the registration procedure of Section 8.5.5.1. No authschemes> with the registration procedure of Section 8.5.5.1. No
authentication schemes are defined in this document. authentication schemes are defined in this document.
13.6. Content Coding Registration 13.6. Content Coding Registration
skipping to change at page 161, line 10 skipping to change at page 163, line 31
Please update the "Media Types" registry at Please update the "Media Types" registry at
<https://www.iana.org/assignments/media-types> with the registration <https://www.iana.org/assignments/media-types> with the registration
information in Section 6.3.4 for the media type "multipart/ information in Section 6.3.4 for the media type "multipart/
byteranges". byteranges".
14. References 14. References
14.1. Normative References 14.1. Normative References
[Caching] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [Caching] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Caching", draft-ietf-httpbis-cache-03 (work in Ed., "HTTP Caching", draft-ietf-httpbis-cache-04 (work in
progress), October 2018. progress), March 2019.
[Messaging] [Messaging]
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP/1.1 Messaging", draft-ietf-httpbis-messaging-03 Ed., "HTTP/1.1 Messaging", draft-ietf-httpbis-messaging-04
(work in progress), October 2018. (work in progress), March 2019.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>. <https://www.rfc-editor.org/info/rfc793>.
[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format
Specification version 3.3", RFC 1950, Specification version 3.3", RFC 1950,
DOI 10.17487/RFC1950, May 1996, DOI 10.17487/RFC1950, May 1996,
<https://www.rfc-editor.org/info/rfc1950>. <https://www.rfc-editor.org/info/rfc1950>.
skipping to change at page 162, line 32 skipping to change at page 165, line 5
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,
September 2009, <https://www.rfc-editor.org/info/rfc5646>. September 2009, <https://www.rfc-editor.org/info/rfc5646>.
[RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in
Internationalization in the IETF", BCP 166, RFC 6365, Internationalization in the IETF", BCP 166, RFC 6365,
DOI 10.17487/RFC6365, September 2011, DOI 10.17487/RFC6365, September 2011,
<https://www.rfc-editor.org/info/rfc6365>. <https://www.rfc-editor.org/info/rfc6365>.
[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
RFC 7405, DOI 10.17487/RFC7405, December 2014,
<https://www.rfc-editor.org/info/rfc7405>.
[USASCII] American National Standards Institute, "Coded Character [USASCII] American National Standards Institute, "Coded Character
Set -- 7-bit American Standard Code for Information Set -- 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986. Interchange", ANSI X3.4, 1986.
[Welch] Welch, T., "A Technique for High-Performance Data [Welch] Welch, T., "A Technique for High-Performance Data
Compression", IEEE Computer 17(6), Compression", IEEE Computer 17(6),
DOI 10.1109/MC.1984.1659158, June 1984, DOI 10.1109/MC.1984.1659158, June 1984,
<https://ieeexplore.ieee.org/document/1659158/>. <https://ieeexplore.ieee.org/document/1659158/>.
14.2. Informative References 14.2. Informative References
skipping to change at page 167, line 24 skipping to change at page 169, line 47
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8187] Reschke, J., "Indicating Character Encoding and Language [RFC8187] Reschke, J., "Indicating Character Encoding and Language
for HTTP Header Field Parameters", RFC 8187, for HTTP Header Field Parameters", RFC 8187,
DOI 10.17487/RFC8187, September 2017, DOI 10.17487/RFC8187, September 2017,
<https://www.rfc-editor.org/info/rfc8187>. <https://www.rfc-editor.org/info/rfc8187>.
[RFC8246] McManus, P., "HTTP Immutable Responses", RFC 8246,
DOI 10.17487/RFC8246, September 2017,
<https://www.rfc-editor.org/info/rfc8246>.
[RFC8288] Nottingham, M., "Web Linking", RFC 8288, [RFC8288] Nottingham, M., "Web Linking", RFC 8288,
DOI 10.17487/RFC8288, October 2017, DOI 10.17487/RFC8288, October 2017,
<https://www.rfc-editor.org/info/rfc8288>. <https://www.rfc-editor.org/info/rfc8288>.
Appendix A. Collected ABNF Appendix A. Collected ABNF
In the collected ABNF below, list rules are expanded as per In the collected ABNF below, list rules are expanded as per
Section 11. Section 11.
Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [ Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
skipping to change at page 173, line 7 skipping to change at page 176, line 7
Appendix B. Changes from RFC 7230 Appendix B. Changes from RFC 7230
Most of the sections introducing HTTP's design goals, history, Most of the sections introducing HTTP's design goals, history,
architecture, conformance criteria, protocol versioning, URIs, architecture, conformance criteria, protocol versioning, URIs,
message routing, and header field values have been moved here message routing, and header field values have been moved here
(without substantive change). (without substantive change).
Furthermore: Furthermore:
Add status code 308 (previously defined in [RFC7538]) so that it's
defined closer to status codes 301, 302, and 307. (Section 9.4.9)
Add status code 422 (previously defined in Section 11.2 of [RFC4918]) Add status code 422 (previously defined in Section 11.2 of [RFC4918])
because of it's general applicability. (Section 9.5.20) because of it's general applicability. (Section 9.5.20)
Appendix C. Changes from RFC 7231 Appendix C. Changes from RFC 7231
None yet. None yet.
Appendix D. Changes from RFC 7232 Appendix D. Changes from RFC 7232
None yet. None yet.
Appendix E. Changes from RFC 7233 Appendix E. Changes from RFC 7233
None yet. None yet.
Appendix F. Changes from RFC 7235 Appendix F. Changes from RFC 7235
None yet. None yet.
Appendix G. Changes from RFC 7615 Appendix G. Changes from RFC 7538
None yet. None yet.
Appendix H. Change Log Appendix H. Changes from RFC 7615
None yet.
Appendix I. Change Log
This section is to be removed before publishing as an RFC. This section is to be removed before publishing as an RFC.
H.1. Between RFC723x and draft 00 I.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.
H.2. Since draft-ietf-httpbis-semantics-00 I.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 174, line 32 skipping to change at page 177, line 39
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.
H.3. Since draft-ietf-httpbis-semantics-01 I.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 176, line 5 skipping to change at page 179, line 10
o In Section 11, fixed an example that had trailing whitespace where o In Section 11, fixed an example that had trailing whitespace where
it shouldn't (<https://github.com/httpwg/http-core/issues/104>, it shouldn't (<https://github.com/httpwg/http-core/issues/104>,
<https://www.rfc-editor.org/errata/eid4169>) <https://www.rfc-editor.org/errata/eid4169>)
o In Section 9.3.7, remove words that were potentially misleading o In Section 9.3.7, remove words that were potentially misleading
with respect to the relation to the requested ranges with respect to the relation to the requested ranges
(<https://github.com/httpwg/http-core/issues/102>, (<https://github.com/httpwg/http-core/issues/102>,
<https://www.rfc-editor.org/errata/eid4358>) <https://www.rfc-editor.org/errata/eid4358>)
H.4. Since draft-ietf-httpbis-semantics-02 I.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 177, line 5 skipping to change at page 180, line 5
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>)
I.5. Since draft-ietf-httpbis-semantics-03
o In Section 9.4.9, include status code 308 from RFC 7538
(<https://github.com/httpwg/http-core/issues/3>)
o In Section 6.1.1, clarify that the charset parameter value is
case-insensitive due to the definition in RFC 2046
(<https://github.com/httpwg/http-core/issues/13>)
o Define a separate registry for HTTP header field names
(<https://github.com/httpwg/http-core/issues/42>)
o In Section 8.4, refactor and clarify description of wildcard ("*")
handling (<https://github.com/httpwg/http-core/issues/46>)
o Deprecate Accept-Charset (<https://github.com/httpwg/http-core/
issues/61>)
o In Section 8.2.1, mention Cache-Control: immutable
(<https://github.com/httpwg/http-core/issues/69>)
o In Section 4.2.1, clarify when header field combination is allowed
(<https://github.com/httpwg/http-core/issues/74>)
o In Section 13.4, instruct IANA to mark Content-MD5 as obsolete
(<https://github.com/httpwg/http-core/issues/93>)
o Use RFC 7405 ABNF notation for case-sensitive string constants
(<https://github.com/httpwg/http-core/issues/133>)
o Rework Section 2.1 to be more version-independent
(<https://github.com/httpwg/http-core/issues/142>)
o In Section 7.3.5, clarify that DELETE needs to be successful to
invalidate cache (<https://github.com/httpwg/http-core/
issues/167>, <https://www.rfc-editor.org/errata/eid5541>)
Index Index
1 1
100 Continue (status code) 107 100 Continue (status code) 108
100-continue (expect value) 74 100-continue (expect value) 76
101 Switching Protocols (status code) 107 101 Switching Protocols (status code) 109
1xx Informational (status code class) 107 1xx Informational (status code class) 108
2 2
200 OK (status code) 108 200 OK (status code) 109
201 Created (status code) 109 201 Created (status code) 110
202 Accepted (status code) 109 202 Accepted (status code) 110
203 Non-Authoritative Information (status code) 109 203 Non-Authoritative Information (status code) 111
204 No Content (status code) 110 204 No Content (status code) 111
205 Reset Content (status code) 110 205 Reset Content (status code) 112
206 Partial Content (status code) 111 206 Partial Content (status code) 112
2xx Successful (status code class) 108 2xx Successful (status code class) 109
3 3
300 Multiple Choices (status code) 115 300 Multiple Choices (status code) 117
301 Moved Permanently (status code) 116 301 Moved Permanently (status code) 118
302 Found (status code) 117 302 Found (status code) 118
303 See Other (status code) 117 303 See Other (status code) 119
304 Not Modified (status code) 118 304 Not Modified (status code) 119
305 Use Proxy (status code) 118 305 Use Proxy (status code) 120
306 (Unused) (status code) 119 306 (Unused) (status code) 120
307 Temporary Redirect (status code) 119 307 Temporary Redirect (status code) 120
3xx Redirection (status code class) 114 308 Permanent Redirect (status code) 121
3xx Redirection (status code class) 115
4 4
400 Bad Request (status code) 119 400 Bad Request (status code) 121
401 Unauthorized (status code) 119 401 Unauthorized (status code) 121
402 Payment Required (status code) 120 402 Payment Required (status code) 122
403 Forbidden (status code) 120 403 Forbidden (status code) 122
404 Not Found (status code) 120 404 Not Found (status code) 122
405 Method Not Allowed (status code) 121 405 Method Not Allowed (status code) 123
406 Not Acceptable (status code) 121 406 Not Acceptable (status code) 123
407 Proxy Authentication Required (status code) 121 407 Proxy Authentication Required (status code) 123
408 Request Timeout (status code) 121 408 Request Timeout (status code) 123
409 Conflict (status code) 122 409 Conflict (status code) 124
410 Gone (status code) 122 410 Gone (status code) 124
411 Length Required (status code) 122 411 Length Required (status code) 124
412 Precondition Failed (status code) 123 412 Precondition Failed (status code) 125
413 Payload Too Large (status code) 123 413 Payload Too Large (status code) 125
414 URI Too Long (status code) 123 414 URI Too Long (status code) 125
415 Unsupported Media Type (status code) 123 415 Unsupported Media Type (status code) 125
416 Range Not Satisfiable (status code) 124 416 Range Not Satisfiable (status code) 126
417 Expectation Failed (status code) 124 417 Expectation Failed (status code) 126
418 (Unused) (status code) 124 418 (Unused) (status code) 126
422 Unprocessable Entity (status code) 125 422 Unprocessable Entity (status code) 127
426 Upgrade Required (status code) 125 426 Upgrade Required (status code) 127
4xx Client Error (status code class) 119 4xx Client Error (status code class) 121
5 5
500 Internal Server Error (status code) 126 500 Internal Server Error (status code) 128
501 Not Implemented (status code) 126 501 Not Implemented (status code) 128
502 Bad Gateway (status code) 126 502 Bad Gateway (status code) 128
503 Service Unavailable (status code) 126 503 Service Unavailable (status code) 128
504 Gateway Timeout (status code) 126 504 Gateway Timeout (status code) 128
505 HTTP Version Not Supported (status code) 126 505 HTTP Version Not Supported (status code) 128
5xx Server Error (status code class) 125 5xx Server Error (status code class) 127
A A
Accept header field 89 Accept header field 92
Accept-Charset header field 91 Accept-Charset header field 94
Accept-Encoding header field 92 Accept-Encoding header field 95
Accept-Language header field 94 Accept-Language header field 96
Accept-Ranges header field 147 Accept-Ranges header field 149
Allow header field 148 Allow header field 149
Authentication-Info header field 146 Authentication-Info header field 147
Authorization header field 98 Authorization header field 100
accelerator 13 accelerator 12
authoritative response 150 authoritative response 152
B B
browser 10 browser 10
C C
CONNECT method 70 CONNECT method 71
Canonical Root URI 97 Canonical Root URI 99
Content-Encoding header field 47 Content-Encoding header field 48
Content-Language header field 48 Content-Language header field 49
Content-Length header field 49 Content-Length header field 50
Content-Location header field 50 Content-Location header field 51
Content-Range header field 54 Content-MD5 header field 162
Content-Type header field 46 Content-Range header field 55
Content-Type header field 47
cache 14 cache 14
cacheable 14, 63 cacheable 14, 64
captive portal 14 captive portal 13
client 10 client 10
compress (Coding Format) 41 compress (Coding Format) 42
compress (content coding) 40 compress (content coding) 41
conditional request 77 conditional request 79
connection 10 connection 10
content coding 40 content coding 41
content negotiation 8 content negotiation 8
D D
DELETE method 68 DELETE method 70
Date header field 131 Date header field 133
Delimiters 28 Delimiters 29
deflate (Coding Format) 41 deflate (Coding Format) 42
deflate (content coding) 40 deflate (content coding) 41
downstream 12 downstream 12
E E
ETag header field 140 ETag header field 141
Expect header field 74 Expect header field 76
effective request URI 32 effective request URI 33
F F
Fragment Identifiers 18 Fragment Identifiers 18
From header field 101 From header field 103
G G
GET method 64 GET method 65
Grammar Grammar
absolute-path 15 absolute-path 15
absolute-URI 15 absolute-URI 15
Accept 89 Accept 92
Accept-Charset 92 Accept-Charset 94
Accept-Encoding 92 Accept-Encoding 95
accept-ext 89 accept-ext 92
Accept-Language 94 Accept-Language 96
accept-params 89 accept-params 92
Accept-Ranges 147 Accept-Ranges 149
acceptable-ranges 147 acceptable-ranges 149
Allow 148 Allow 149
ALPHA 9 ALPHA 9
asctime-date 131 asctime-date 132
auth-param 96 auth-param 98
auth-scheme 96 auth-scheme 98
Authentication-Info 146 Authentication-Info 147
authority 15 authority 15
Authorization 98 Authorization 100
BWS 30 BWS 31
byte-content-range 54 byte-content-range 55
byte-range 54 byte-range 55
byte-range-resp 54 byte-range-resp 55
byte-range-set 44 byte-range-set 44
byte-range-spec 44 byte-range-spec 44
byte-ranges-specifier 44 byte-ranges-specifier 44
bytes-unit 43 bytes-unit 44
challenge 96 challenge 98
charset 39 charset 40
codings 92 codings 95
comment 29 comment 30
complete-length 54 complete-length 55
content-coding 40 content-coding 41
Content-Encoding 47 Content-Encoding 48
Content-Language 48 Content-Language 49
Content-Length 49 Content-Length 50
Content-Location 50 Content-Location 51
Content-Range 54 Content-Range 55
Content-Type 46 Content-Type 47
CR 9 CR 9
credentials 97 credentials 99
CRLF 9 CRLF 9
ctext 29 ctext 30
CTL 9 CTL 9
Date 131 Date 133
date1 130 date1 132
day 130 day 132
day-name 130 day-name 132
day-name-l 130 day-name-l 132
delay-seconds 134 delay-seconds 135
DIGIT 9 DIGIT 9
DQUOTE 9 DQUOTE 9
entity-tag 140 entity-tag 142
ETag 140 ETag 142
etagc 140 etagc 142
Expect 74 Expect 76
field-content 27 field-content 28
field-name 23, 31 field-name 23, 31
field-value 27 field-value 28
field-vchar 27 field-vchar 28
first-byte-pos 44 first-byte-pos 44
From 101 From 103
GMT 130 GMT 132
HEXDIG 9 HEXDIG 9
Host 33 Host 34
hour 130 hour 132
HTAB 9 HTAB 9
HTTP-date 129 HTTP-date 131
http-URI 16 http-URI 16
https-URI 18 https-URI 17
If-Match 81 If-Match 83
If-Modified-Since 83 If-Modified-Since 85
If-None-Match 82 If-None-Match 84
If-Range 86 If-Range 88
If-Unmodified-Since 84 If-Unmodified-Since 86
IMF-fixdate 130 IMF-fixdate 132
language-range 94 language-range 96
language-tag 42 language-tag 43
last-byte-pos 44 last-byte-pos 44
Last-Modified 138 Last-Modified 139
LF 9 LF 9
Location 132 Location 134
Max-Forwards 77 Max-Forwards 78
media-range 89 media-range 92
media-type 38 media-type 39
method 60 method 61
minute 130 minute 132
month 130 month 132
obs-date 130 obs-date 132
obs-text 29 obs-text 29
OCTET 9 OCTET 9
opaque-tag 140 opaque-tag 142
other-content-range 54 other-content-range 55
other-range-resp 54 other-range-resp 55
other-range-unit 43, 45 other-range-unit 44, 46
OWS 30 OWS 31
parameter 38 parameter 39
partial-URI 15 partial-URI 15
port 15 port 15
product 103 product 105
product-version 103 product-version 105
protocol-name 35 protocol-name 35
protocol-version 35 protocol-version 35
Proxy-Authenticate 145 Proxy-Authenticate 147
Proxy-Authentication-Info 147 Proxy-Authentication-Info 148
Proxy-Authorization 98 Proxy-Authorization 100
pseudonym 35 pseudonym 35
qdtext 29 qdtext 29
query 15 query 15
quoted-pair 29 quoted-pair 30
quoted-string 29 quoted-string 29
qvalue 89 qvalue 92
Range 87 Range 89
range-unit 43 range-unit 44
ranges-specifier 44 ranges-specifier 44
received-by 35 received-by 35
received-protocol 35 received-protocol 35
Referer 102 Referer 104
Retry-After 134 Retry-After 135
rfc850-date 131 rfc850-date 132
RWS 30 RWS 31
second 130 second 132
segment 15 segment 15
Server 148 Server 150
SP 9 SP 9
subtype 38 subtype 39
suffix-byte-range-spec 44 suffix-byte-range-spec 45
suffix-length 44 suffix-length 45
tchar 28 tchar 29
time-of-day 130 time-of-day 132
token 28 token 29
token68 96 token68 98
Trailer 31 Trailer 31
type 38 type 39
unsatisfied-range 54 unsatisfied-range 55
uri-host 15 uri-host 15
URI-reference 15 URI-reference 15
User-Agent 103 User-Agent 105
Vary 134 Vary 136
VCHAR 9 VCHAR 9
Via 35 Via 35
weak 140 weak 142
weight 89 weight 92
WWW-Authenticate 144 WWW-Authenticate 146
year 130 year 132
gateway 13 gateway 12
gzip (Coding Format) 41 gzip (Coding Format) 42
gzip (content coding) 40 gzip (content coding) 41
H H
HEAD method 64 HEAD method 66
Host header field 33 Host header field 33
http URI scheme 16 http URI scheme 16
https URI scheme 18 https URI scheme 17
I I
If-Match header field 81 If-Match header field 83
If-Modified-Since header field 83 If-Modified-Since header field 85
If-None-Match header field 82 If-None-Match header field 84
If-Range header field 85 If-Range header field 87
If-Unmodified-Since header field 84 If-Unmodified-Since header field 86
idempotent 63 idempotent 64
inbound 12 inbound 12
interception proxy 14 interception proxy 13
intermediary 12 intermediary 12
L L
Last-Modified header field 138 Last-Modified header field 139
Location header field 132 Location header field 134
M M
Max-Forwards header field 77 Max-Forwards header field 78
Media Type Media Type
multipart/byteranges 55 multipart/byteranges 57
multipart/x-byteranges 56 multipart/x-byteranges 57
message 10 message 10
metadata 135 metadata 137
multipart/byteranges Media Type 55 multipart/byteranges Media Type 57
multipart/x-byteranges Media Type 56 multipart/x-byteranges Media Type 57
N N
non-transforming proxy 36 non-transforming proxy 37
O O
OPTIONS method 71 OPTIONS method 72
origin server 10 origin server 10
outbound 12 outbound 12
P P
POST method 65 POST method 66
PUT method 66 PUT method 67
Protection Space 97 Protection Space 99
Proxy-Authenticate header field 145 Proxy-Authenticate header field 147
Proxy-Authentication-Info header field 147 Proxy-Authentication-Info header field 148
Proxy-Authorization header field 98 Proxy-Authorization header field 100
payload 52 payload 53
phishing 150 phishing 152
proxy 13 proxy 12
R R
Range header field 87 Range header field 89
Realm 97 Realm 99
Referer header field 102 Referer header field 104
Retry-After header field 133 Retry-After header field 135
recipient 10 recipient 10
representation 37 representation 38
request 10 request 10
resource 15 resource 14
response 10 response 10
reverse proxy 13 reverse proxy 12
S S
Server header field 148 Server header field 150
Status Codes Classes Status Codes Classes
1xx Informational 107 1xx Informational 108
2xx Successful 108 2xx Successful 109
3xx Redirection 114 3xx Redirection 115
4xx Client Error 119 4xx Client Error 121
5xx Server Error 125 5xx Server Error 127
safe 62 safe 63
selected representation 37, 78, 135 selected representation 38, 79, 137
sender 10 sender 10
server 10 server 10
spider 10 spider 10
T T
TRACE method 72 TRACE method 73
Trailer header field 31 Trailer header field 31
target URI 31 target URI 32
target resource 31 target resource 32
transforming proxy 36 transforming proxy 37
transparent proxy 14 transparent proxy 13
tunnel 13 tunnel 13
U U
URI scheme URI scheme
http 16 http 16
https 18 https 17
User-Agent header field 103 User-Agent header field 105
upstream 12 upstream 12
user agent 10 user agent 10
V V
Vary header field 134 Vary header field 136
Via header field 34 Via header field 35
validator 135 validator 137
strong 136 strong 138
weak 136 weak 138
W W
WWW-Authenticate header field 144 WWW-Authenticate header field 146
X X
x-compress (content coding) 40 x-compress (content coding) 41
x-gzip (content coding) 40 x-gzip (content coding) 41
Acknowledgments Acknowledgments
This edition of the HTTP specification builds on the many This edition of the HTTP specification builds on the many
contributions that went into RFC 1945, RFC 2068, RFC 2145, and RFC contributions that went into RFC 1945, RFC 2068, RFC 2145, and RFC
2616, including substantial contributions made by the previous 2616, including substantial contributions made by the previous
authors, editors, and Working Group Chairs: Tim Berners-Lee, Ari authors, editors, and Working Group Chairs: Tim Berners-Lee, Ari
Luotonen, Roy T. Fielding, Henrik Frystyk Nielsen, Jim Gettys, Luotonen, Roy T. Fielding, Henrik Frystyk Nielsen, Jim Gettys,
Jeffrey C. Mogul, Larry Masinter, Paul J. Leach, and Yves Lafon. Jeffrey C. Mogul, Larry Masinter, Paul J. Leach, and Yves Lafon.
 End of changes. 132 change blocks. 
682 lines changed or deleted 820 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/