draft-ietf-httpbis-semantics-02.txt   draft-ietf-httpbis-semantics-03.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 (if M. Nottingham, Ed. Obsoletes: 7230,7231,7232,7233,7235,7615 M. Nottingham, Ed.
approved) Fastly (if approved) Fastly
Intended status: Standards Track J. Reschke, Ed. Intended status: Standards Track J. Reschke, Ed.
Expires: January 3, 2019 greenbytes Expires: April 21, 2019 greenbytes
July 2, 2018 October 18, 2018
HTTP Semantics HTTP Semantics
draft-ietf-httpbis-semantics-02 draft-ietf-httpbis-semantics-03
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, and This document obsoletes RFC 7231, RFC 7232, RFC 7233, RFC 7235, RFC
portions of RFC 7230. 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 G.3. The changes in this draft are summarized in Appendix H.4.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 3, 2019. This Internet-Draft will expire on April 21, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 44 skipping to change at page 2, line 44
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
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 . . . . . . . . . . . . . . . . . . . . . . . . 9 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 10 2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 10
2.2. Intermediaries . . . . . . . . . . . . . . . . . . . . . 11 2.2. Intermediaries . . . . . . . . . . . . . . . . . . . . . 12
2.3. Caches . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3. Caches . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4. Uniform Resource Identifiers . . . . . . . . . . . . . . 14 2.4. Uniform Resource Identifiers . . . . . . . . . . . . . . 15
2.5. Resources . . . . . . . . . . . . . . . . . . . . . . . . 15 2.5. Resources . . . . . . . . . . . . . . . . . . . . . . . . 16
2.5.1. http URI Scheme . . . . . . . . . . . . . . . . . . . 16 2.5.1. http URI Scheme . . . . . . . . . . . . . . . . . . . 16
2.5.2. https URI Scheme . . . . . . . . . . . . . . . . . . 17 2.5.2. https URI Scheme . . . . . . . . . . . . . . . . . . 18
2.5.3. http and https URI Normalization and Comparison . . . 18 2.5.3. Fragment Identifiers on http(s) URI References . . . 18
2.5.4. http and https URI Normalization and Comparison . . . 19
3. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 18 3. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1. Implementation Diversity . . . . . . . . . . . . . . . . 18 3.1. Implementation Diversity . . . . . . . . . . . . . . . . 19
3.2. Role-based Requirements . . . . . . . . . . . . . . . . . 19 3.2. Role-based Requirements . . . . . . . . . . . . . . . . . 20
3.3. Parsing Elements . . . . . . . . . . . . . . . . . . . . 20 3.3. Parsing Elements . . . . . . . . . . . . . . . . . . . . 20
3.4. Error Handling . . . . . . . . . . . . . . . . . . . . . 20 3.4. Error Handling . . . . . . . . . . . . . . . . . . . . . 21
3.5. Protocol Versioning . . . . . . . . . . . . . . . . . . . 21 3.5. Protocol Versioning . . . . . . . . . . . . . . . . . . . 21
4. Message Abstraction . . . . . . . . . . . . . . . . . . . . . 22 4. Message Abstraction . . . . . . . . . . . . . . . . . . . . . 23
4.1. Field Names . . . . . . . . . . . . . . . . . . . . . . . 22 4.1. Header Field Names . . . . . . . . . . . . . . . . . . . 23
4.1.1. Field Name Registry . . . . . . . . . . . . . . . . . 24 4.1.1. Header Field Name Registry . . . . . . . . . . . . . 25
4.1.2. Field Extensibility . . . . . . . . . . . . . . . . . 24 4.1.2. Header Field Extensibility . . . . . . . . . . . . . 25
4.1.3. Considerations for New Fields . . . . . . . . . . . . 24 4.1.3. Considerations for New Header Fields . . . . . . . . 25
4.2. Field Values . . . . . . . . . . . . . . . . . . . . . . 26 4.2. Header Field Values . . . . . . . . . . . . . . . . . . . 27
4.2.1. Field Order . . . . . . . . . . . . . . . . . . . . . 26 4.2.1. Header Field Order . . . . . . . . . . . . . . . . . 27
4.2.2. Field Limits . . . . . . . . . . . . . . . . . . . . 27 4.2.2. Header Field Limits . . . . . . . . . . . . . . . . . 28
4.2.3. Field Value Components . . . . . . . . . . . . . . . 27 4.2.3. Header Field Value Components . . . . . . . . . . . . 28
4.2.4. Designing New Field Values . . . . . . . . . . . . . 28 4.2.4. Designing New Header Field Values . . . . . . . . . . 29
4.3. Whitespace . . . . . . . . . . . . . . . . . . . . . . . 29 4.3. Whitespace . . . . . . . . . . . . . . . . . . . . . . . 30
4.4. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.4. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 31
5. Message Routing . . . . . . . . . . . . . . . . . . . . . . . 30 5. Message Routing . . . . . . . . . . . . . . . . . . . . . . . 31
5.1. Identifying a Target Resource . . . . . . . . . . . . . . 30 5.1. Identifying a Target Resource . . . . . . . . . . . . . . 31
5.2. Routing Inbound . . . . . . . . . . . . . . . . . . . . . 30 5.2. Routing Inbound . . . . . . . . . . . . . . . . . . . . . 31
5.3. Effective Request URI . . . . . . . . . . . . . . . . . . 31 5.3. Effective Request URI . . . . . . . . . . . . . . . . . . 32
5.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . 32 5.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.5. Associating a Response to a Request . . . . . . . . . . . 33 5.5. Message Forwarding . . . . . . . . . . . . . . . . . . . 34
5.6. Message Forwarding . . . . . . . . . . . . . . . . . . . 33 5.5.1. Via . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.6.1. Via . . . . . . . . . . . . . . . . . . . . . . . . . 34 5.5.2. Transformations . . . . . . . . . . . . . . . . . . . 36
5.6.2. Transformations . . . . . . . . . . . . . . . . . . . 35
6. Representations . . . . . . . . . . . . . . . . . . . . . . . 37 6. Representations . . . . . . . . . . . . . . . . . . . . . . . 37
6.1. Representation Data . . . . . . . . . . . . . . . . . . . 37 6.1. Representation Data . . . . . . . . . . . . . . . . . . . 38
6.1.1. Media Type . . . . . . . . . . . . . . . . . . . . . 37 6.1.1. Media Type . . . . . . . . . . . . . . . . . . . . . 38
6.1.2. Content Codings . . . . . . . . . . . . . . . . . . . 40 6.1.2. Content Codings . . . . . . . . . . . . . . . . . . . 40
6.1.3. Language Tags . . . . . . . . . . . . . . . . . . . . 41 6.1.3. Language Tags . . . . . . . . . . . . . . . . . . . . 42
6.1.4. Range Units . . . . . . . . . . . . . . . . . . . . . 42 6.1.4. Range Units . . . . . . . . . . . . . . . . . . . . . 43
6.2. Representation Metadata . . . . . . . . . . . . . . . . . 45 6.2. Representation Metadata . . . . . . . . . . . . . . . . . 46
6.2.1. Content-Type . . . . . . . . . . . . . . . . . . . . 45 6.2.1. Content-Type . . . . . . . . . . . . . . . . . . . . 46
6.2.2. Content-Encoding . . . . . . . . . . . . . . . . . . 46 6.2.2. Content-Encoding . . . . . . . . . . . . . . . . . . 47
6.2.3. Content-Language . . . . . . . . . . . . . . . . . . 47 6.2.3. Content-Language . . . . . . . . . . . . . . . . . . 48
6.2.4. Content-Length . . . . . . . . . . . . . . . . . . . 48 6.2.4. Content-Length . . . . . . . . . . . . . . . . . . . 49
6.2.5. Content-Location . . . . . . . . . . . . . . . . . . 49 6.2.5. Content-Location . . . . . . . . . . . . . . . . . . 50
6.3. Payload . . . . . . . . . . . . . . . . . . . . . . . . . 51 6.3. Payload . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.3.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 51 6.3.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 52
6.3.2. Identification . . . . . . . . . . . . . . . . . . . 52 6.3.2. Identification . . . . . . . . . . . . . . . . . . . 53
6.3.3. Content-Range . . . . . . . . . . . . . . . . . . . . 53 6.3.3. Content-Range . . . . . . . . . . . . . . . . . . . . 54
6.3.4. Media Type multipart/byteranges . . . . . . . . . . . 55 6.3.4. Media Type multipart/byteranges . . . . . . . . . . . 55
6.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 57 6.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 57
6.4.1. Proactive Negotiation . . . . . . . . . . . . . . . . 57 6.4.1. Proactive Negotiation . . . . . . . . . . . . . . . . 58
6.4.2. Reactive Negotiation . . . . . . . . . . . . . . . . 58 6.4.2. Reactive Negotiation . . . . . . . . . . . . . . . . 59
7. Request Methods . . . . . . . . . . . . . . . . . . . . . . . 59 7. Request Methods . . . . . . . . . . . . . . . . . . . . . . . 60
7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 59 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 60
7.2. Common Method Properties . . . . . . . . . . . . . . . . 61 7.2. Common Method Properties . . . . . . . . . . . . . . . . 62
7.2.1. Safe Methods . . . . . . . . . . . . . . . . . . . . 61 7.2.1. Safe Methods . . . . . . . . . . . . . . . . . . . . 62
7.2.2. Idempotent Methods . . . . . . . . . . . . . . . . . 62 7.2.2. Idempotent Methods . . . . . . . . . . . . . . . . . 63
7.2.3. Cacheable Methods . . . . . . . . . . . . . . . . . . 62 7.2.3. Cacheable Methods . . . . . . . . . . . . . . . . . . 63
7.3. Method Definitions . . . . . . . . . . . . . . . . . . . 63 7.3. Method Definitions . . . . . . . . . . . . . . . . . . . 64
7.3.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 63 7.3.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 64
7.3.2. HEAD . . . . . . . . . . . . . . . . . . . . . . . . 63 7.3.2. HEAD . . . . . . . . . . . . . . . . . . . . . . . . 64
7.3.3. POST . . . . . . . . . . . . . . . . . . . . . . . . 64 7.3.3. POST . . . . . . . . . . . . . . . . . . . . . . . . 65
7.3.4. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 65 7.3.4. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 66
7.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . 68 7.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . 68
7.3.6. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 69 7.3.6. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 70
7.3.7. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 70 7.3.7. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 71
7.3.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . 71 7.3.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . 72
7.4. Method Extensibility . . . . . . . . . . . . . . . . . . 72 7.4. Method Extensibility . . . . . . . . . . . . . . . . . . 73
7.4.1. Method Registry . . . . . . . . . . . . . . . . . . . 72 7.4.1. Method Registry . . . . . . . . . . . . . . . . . . . 73
7.4.2. Considerations for New Methods . . . . . . . . . . . 72 7.4.2. Considerations for New Methods . . . . . . . . . . . 73
8. Request Header Fields . . . . . . . . . . . . . . . . . . . . 73 8. Request Header Fields . . . . . . . . . . . . . . . . . . . . 74
8.1. Controls . . . . . . . . . . . . . . . . . . . . . . . . 73 8.1. Controls . . . . . . . . . . . . . . . . . . . . . . . . 74
8.1.1. Expect . . . . . . . . . . . . . . . . . . . . . . . 74 8.1.1. Expect . . . . . . . . . . . . . . . . . . . . . . . 74
8.1.2. Max-Forwards . . . . . . . . . . . . . . . . . . . . 76 8.1.2. Max-Forwards . . . . . . . . . . . . . . . . . . . . 77
8.2. Preconditions . . . . . . . . . . . . . . . . . . . . . . 76 8.2. Preconditions . . . . . . . . . . . . . . . . . . . . . . 77
8.2.1. Evaluation . . . . . . . . . . . . . . . . . . . . . 77 8.2.1. Evaluation . . . . . . . . . . . . . . . . . . . . . 78
8.2.2. Precedence . . . . . . . . . . . . . . . . . . . . . 78 8.2.2. Precedence . . . . . . . . . . . . . . . . . . . . . 79
8.2.3. If-Match . . . . . . . . . . . . . . . . . . . . . . 80 8.2.3. If-Match . . . . . . . . . . . . . . . . . . . . . . 81
8.2.4. If-None-Match . . . . . . . . . . . . . . . . . . . . 81 8.2.4. If-None-Match . . . . . . . . . . . . . . . . . . . . 82
8.2.5. If-Modified-Since . . . . . . . . . . . . . . . . . . 82 8.2.5. If-Modified-Since . . . . . . . . . . . . . . . . . . 83
8.2.6. If-Unmodified-Since . . . . . . . . . . . . . . . . . 83 8.2.6. If-Unmodified-Since . . . . . . . . . . . . . . . . . 84
8.2.7. If-Range . . . . . . . . . . . . . . . . . . . . . . 85 8.2.7. If-Range . . . . . . . . . . . . . . . . . . . . . . 85
8.3. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 86 8.3. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 87
8.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 87 8.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 88
8.4.1. Quality Values . . . . . . . . . . . . . . . . . . . 88 8.4.1. Quality Values . . . . . . . . . . . . . . . . . . . 89
8.4.2. Accept . . . . . . . . . . . . . . . . . . . . . . . 88 8.4.2. Accept . . . . . . . . . . . . . . . . . . . . . . . 89
8.4.3. Accept-Charset . . . . . . . . . . . . . . . . . . . 90 8.4.3. Accept-Charset . . . . . . . . . . . . . . . . . . . 91
8.4.4. Accept-Encoding . . . . . . . . . . . . . . . . . . . 91 8.4.4. Accept-Encoding . . . . . . . . . . . . . . . . . . . 92
8.4.5. Accept-Language . . . . . . . . . . . . . . . . . . . 93 8.4.5. Accept-Language . . . . . . . . . . . . . . . . . . . 94
8.5. Authentication Credentials . . . . . . . . . . . . . . . 94 8.5. Authentication Credentials . . . . . . . . . . . . . . . 95
8.5.1. Challenge and Response . . . . . . . . . . . . . . . 94 8.5.1. Challenge and Response . . . . . . . . . . . . . . . 95
8.5.2. Protection Space (Realm) . . . . . . . . . . . . . . 96 8.5.2. Protection Space (Realm) . . . . . . . . . . . . . . 97
8.5.3. Authorization . . . . . . . . . . . . . . . . . . . . 97 8.5.3. Authorization . . . . . . . . . . . . . . . . . . . . 98
8.5.4. Proxy-Authorization . . . . . . . . . . . . . . . . . 97 8.5.4. Proxy-Authorization . . . . . . . . . . . . . . . . . 98
8.5.5. Authentication Scheme Extensibility . . . . . . . . . 98 8.5.5. Authentication Scheme Extensibility . . . . . . . . . 99
8.6. Request Context . . . . . . . . . . . . . . . . . . . . . 100 8.6. Request Context . . . . . . . . . . . . . . . . . . . . . 101
8.6.1. From . . . . . . . . . . . . . . . . . . . . . . . . 100 8.6.1. From . . . . . . . . . . . . . . . . . . . . . . . . 101
8.6.2. Referer . . . . . . . . . . . . . . . . . . . . . . . 101 8.6.2. Referer . . . . . . . . . . . . . . . . . . . . . . . 102
8.6.3. User-Agent . . . . . . . . . . . . . . . . . . . . . 102 8.6.3. User-Agent . . . . . . . . . . . . . . . . . . . . . 103
9. Response Status Codes . . . . . . . . . . . . . . . . . . . . 103 9. Response Status Codes . . . . . . . . . . . . . . . . . . . . 104
9.1. Overview of Status Codes . . . . . . . . . . . . . . . . 104 9.1. Overview of Status Codes . . . . . . . . . . . . . . . . 105
9.2. Informational 1xx . . . . . . . . . . . . . . . . . . . . 106 9.2. Informational 1xx . . . . . . . . . . . . . . . . . . . . 107
9.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 106 9.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 107
9.2.2. 101 Switching Protocols . . . . . . . . . . . . . . . 106 9.2.2. 101 Switching Protocols . . . . . . . . . . . . . . . 107
9.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . 107 9.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . 108
9.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 107 9.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 108
9.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 108 9.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 109
9.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . 108 9.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . 109
9.3.4. 203 Non-Authoritative Information . . . . . . . . . . 108 9.3.4. 203 Non-Authoritative Information . . . . . . . . . . 109
9.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . 109 9.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . 110
9.3.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 109 9.3.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 110
9.3.7. 206 Partial Content . . . . . . . . . . . . . . . . . 110 9.3.7. 206 Partial Content . . . . . . . . . . . . . . . . . 111
9.4. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 113 9.4. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 114
9.4.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 114 9.4.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 115
9.4.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 115 9.4.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 116
9.4.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 116 9.4.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 117
9.4.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 116 9.4.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 117
9.4.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 117 9.4.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 118
9.4.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 117 9.4.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 118
9.4.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . 118 9.4.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . 119
9.4.8. 307 Temporary Redirect . . . . . . . . . . . . . . . 118 9.4.8. 307 Temporary Redirect . . . . . . . . . . . . . . . 119
9.5. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 118 9.5. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 119
9.5.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 118 9.5.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 119
9.5.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 118 9.5.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 119
9.5.3. 402 Payment Required . . . . . . . . . . . . . . . . 119 9.5.3. 402 Payment Required . . . . . . . . . . . . . . . . 120
9.5.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 119 9.5.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 120
9.5.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 119 9.5.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 120
9.5.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 120 9.5.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 121
9.5.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 120 9.5.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 121
9.5.8. 407 Proxy Authentication Required . . . . . . . . . . 120 9.5.8. 407 Proxy Authentication Required . . . . . . . . . . 121
9.5.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 120 9.5.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 121
9.5.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . 121 9.5.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . 122
9.5.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 121 9.5.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 122
9.5.12. 411 Length Required . . . . . . . . . . . . . . . . . 121 9.5.12. 411 Length Required . . . . . . . . . . . . . . . . . 122
9.5.13. 412 Precondition Failed . . . . . . . . . . . . . . . 122 9.5.13. 412 Precondition Failed . . . . . . . . . . . . . . . 123
9.5.14. 413 Payload Too Large . . . . . . . . . . . . . . . . 122 9.5.14. 413 Payload Too Large . . . . . . . . . . . . . . . . 123
9.5.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . 122 9.5.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . 123
9.5.16. 415 Unsupported Media Type . . . . . . . . . . . . . 122 9.5.16. 415 Unsupported Media Type . . . . . . . . . . . . . 123
9.5.17. 416 Range Not Satisfiable . . . . . . . . . . . . . . 123 9.5.17. 416 Range Not Satisfiable . . . . . . . . . . . . . . 124
9.5.18. 417 Expectation Failed . . . . . . . . . . . . . . . 123 9.5.18. 417 Expectation Failed . . . . . . . . . . . . . . . 124
9.5.19. 426 Upgrade Required . . . . . . . . . . . . . . . . 123 9.5.19. 418 (Unused) . . . . . . . . . . . . . . . . . . . . 124
9.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 124 9.5.20. 422 Unprocessable Entity . . . . . . . . . . . . . . 125
9.6.1. 500 Internal Server Error . . . . . . . . . . . . . . 124 9.5.21. 426 Upgrade Required . . . . . . . . . . . . . . . . 125
9.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 124 9.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 125
9.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 124 9.6.1. 500 Internal Server Error . . . . . . . . . . . . . . 126
9.6.4. 503 Service Unavailable . . . . . . . . . . . . . . . 125 9.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 126
9.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 125 9.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 126
9.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . 125 9.6.4. 503 Service Unavailable . . . . . . . . . . . . . . . 126
9.7. Status Code Extensibility . . . . . . . . . . . . . . . . 125 9.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 126
9.7.1. Status Code Registry . . . . . . . . . . . . . . . . 125 9.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . 126
9.7.2. Considerations for New Status Codes . . . . . . . . . 126 9.7. Status Code Extensibility . . . . . . . . . . . . . . . . 127
10. Response Header Fields . . . . . . . . . . . . . . . . . . . 127 9.7.1. Status Code Registry . . . . . . . . . . . . . . . . 127
10.1. Control Data . . . . . . . . . . . . . . . . . . . . . . 127 9.7.2. Considerations for New Status Codes . . . . . . . . . 127
10.1.1. Origination Date . . . . . . . . . . . . . . . . . . 127 10. Response Header Fields . . . . . . . . . . . . . . . . . . . 128
10.1.2. Location . . . . . . . . . . . . . . . . . . . . . . 131 10.1. Control Data . . . . . . . . . . . . . . . . . . . . . . 128
10.1.3. Retry-After . . . . . . . . . . . . . . . . . . . . 132 10.1.1. Origination Date . . . . . . . . . . . . . . . . . . 129
10.1.4. Vary . . . . . . . . . . . . . . . . . . . . . . . . 133 10.1.2. Location . . . . . . . . . . . . . . . . . . . . . . 132
10.2. Validators . . . . . . . . . . . . . . . . . . . . . . . 134 10.1.3. Retry-After . . . . . . . . . . . . . . . . . . . . 133
10.2.1. Weak versus Strong . . . . . . . . . . . . . . . . . 135 10.1.4. Vary . . . . . . . . . . . . . . . . . . . . . . . . 134
10.2.2. Last-Modified . . . . . . . . . . . . . . . . . . . 137 10.2. Validators . . . . . . . . . . . . . . . . . . . . . . . 135
10.2.3. ETag . . . . . . . . . . . . . . . . . . . . . . . . 139 10.2.1. Weak versus Strong . . . . . . . . . . . . . . . . . 136
10.2.4. When to Use Entity-Tags and Last-Modified Dates . . 142 10.2.2. Last-Modified . . . . . . . . . . . . . . . . . . . 138
10.3. Authentication Challenges . . . . . . . . . . . . . . . 143 10.2.3. ETag . . . . . . . . . . . . . . . . . . . . . . . . 140
10.3.1. WWW-Authenticate . . . . . . . . . . . . . . . . . . 143 10.2.4. When to Use Entity-Tags and Last-Modified Dates . . 143
10.3.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . 144 10.3. Authentication Challenges . . . . . . . . . . . . . . . 144
10.4. Response Context . . . . . . . . . . . . . . . . . . . . 144 10.3.1. WWW-Authenticate . . . . . . . . . . . . . . . . . . 144
10.4.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . 145 10.3.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . 145
10.4.2. Allow . . . . . . . . . . . . . . . . . . . . . . . 145 10.3.3. Authentication-Info . . . . . . . . . . . . . . . . 146
10.4.3. Server . . . . . . . . . . . . . . . . . . . . . . . 146 10.3.4. Proxy-Authentication-Info . . . . . . . . . . . . . 147
11. ABNF List Extension: #rule . . . . . . . . . . . . . . . . . 146 10.4. Response Context . . . . . . . . . . . . . . . . . . . . 147
12. Security Considerations . . . . . . . . . . . . . . . . . . . 148 10.4.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . 147
12.1. Establishing Authority . . . . . . . . . . . . . . . . . 148 10.4.2. Allow . . . . . . . . . . . . . . . . . . . . . . . 148
12.2. Risks of Intermediaries . . . . . . . . . . . . . . . . 149 10.4.3. Server . . . . . . . . . . . . . . . . . . . . . . . 148
12.3. Attacks Based on File and Path Names . . . . . . . . . . 149 11. ABNF List Extension: #rule . . . . . . . . . . . . . . . . . 149
12.4. Attacks Based on Command, Code, or Query Injection . . . 150 12. Security Considerations . . . . . . . . . . . . . . . . . . . 150
12.5. Attacks via Protocol Element Length . . . . . . . . . . 151 12.1. Establishing Authority . . . . . . . . . . . . . . . . . 150
12.6. Disclosure of Personal Information . . . . . . . . . . . 151 12.2. Risks of Intermediaries . . . . . . . . . . . . . . . . 151
12.7. Privacy of Server Log Information . . . . . . . . . . . 151 12.3. Attacks Based on File and Path Names . . . . . . . . . . 152
12.8. Disclosure of Sensitive Information in URIs . . . . . . 152 12.4. Attacks Based on Command, Code, or Query Injection . . . 152
12.9. Disclosure of Fragment after Redirects . . . . . . . . . 152 12.5. Attacks via Protocol Element Length . . . . . . . . . . 153
12.10. Disclosure of Product Information . . . . . . . . . . . 153 12.6. Disclosure of Personal Information . . . . . . . . . . . 154
12.11. Browser Fingerprinting . . . . . . . . . . . . . . . . . 153 12.7. Privacy of Server Log Information . . . . . . . . . . . 154
12.12. Validator Retention . . . . . . . . . . . . . . . . . . 154 12.8. Disclosure of Sensitive Information in URIs . . . . . . 154
12.13. Denial-of-Service Attacks Using Range . . . . . . . . . 154 12.9. Disclosure of Fragment after Redirects . . . . . . . . . 155
12.14. Authentication Considerations . . . . . . . . . . . . . 155 12.10. Disclosure of Product Information . . . . . . . . . . . 155
12.14.1. Confidentiality of Credentials . . . . . . . . . . 155 12.11. Browser Fingerprinting . . . . . . . . . . . . . . . . . 155
12.14.2. Credentials and Idle Clients . . . . . . . . . . . 155 12.12. Validator Retention . . . . . . . . . . . . . . . . . . 156
12.14.3. Protection Spaces . . . . . . . . . . . . . . . . . 156 12.13. Denial-of-Service Attacks Using Range . . . . . . . . . 157
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 156 12.14. Authentication Considerations . . . . . . . . . . . . . 157
13.1. URI Scheme Registration . . . . . . . . . . . . . . . . 156 12.14.1. Confidentiality of Credentials . . . . . . . . . . 157
13.2. Method Registration . . . . . . . . . . . . . . . . . . 157 12.14.2. Credentials and Idle Clients . . . . . . . . . . . 158
13.3. Status Code Registration . . . . . . . . . . . . . . . . 157 12.14.3. Protection Spaces . . . . . . . . . . . . . . . . . 158
13.4. Header Field Registration . . . . . . . . . . . . . . . 157 12.14.4. Additional Response Header Fields . . . . . . . . . 159
13.5. Authentication Scheme Registration . . . . . . . . . . . 157 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 159
13.6. Content Coding Registration . . . . . . . . . . . . . . 157 13.1. URI Scheme Registration . . . . . . . . . . . . . . . . 159
13.7. Range Unit Registration . . . . . . . . . . . . . . . . 157 13.2. Method Registration . . . . . . . . . . . . . . . . . . 159
13.8. Media Type Registration . . . . . . . . . . . . . . . . 157 13.3. Status Code Registration . . . . . . . . . . . . . . . . 159
13.4. Header Field Registration . . . . . . . . . . . . . . . 160
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 158 13.5. Authentication Scheme Registration . . . . . . . . . . . 160
14.1. Normative References . . . . . . . . . . . . . . . . . . 158 13.6. Content Coding Registration . . . . . . . . . . . . . . 160
14.2. Informative References . . . . . . . . . . . . . . . . . 159 13.7. Range Unit Registration . . . . . . . . . . . . . . . . 160
Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 165 13.8. Media Type Registration . . . . . . . . . . . . . . . . 160
Appendix B. Changes from RFC 7230 . . . . . . . . . . . . . . . 169 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 161
Appendix C. Changes from RFC 7231 . . . . . . . . . . . . . . . 170 14.1. Normative References . . . . . . . . . . . . . . . . . . 161
Appendix D. Changes from RFC 7232 . . . . . . . . . . . . . . . 170 14.2. Informative References . . . . . . . . . . . . . . . . . 162
Appendix E. Changes from RFC 7233 . . . . . . . . . . . . . . . 170 Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 168
Appendix F. Changes from RFC 7235 . . . . . . . . . . . . . . . 170 Appendix B. Changes from RFC 7230 . . . . . . . . . . . . . . . 172
Appendix G. Change Log . . . . . . . . . . . . . . . . . . . . . 170 Appendix C. Changes from RFC 7231 . . . . . . . . . . . . . . . 173
G.1. Between RFC723x and draft 00 . . . . . . . . . . . . . . 170 Appendix D. Changes from RFC 7232 . . . . . . . . . . . . . . . 173
G.2. Since draft-ietf-httpbis-semantics-00 . . . . . . . . . . 170 Appendix E. Changes from RFC 7233 . . . . . . . . . . . . . . . 173
G.3. Since draft-ietf-httpbis-semantics-01 . . . . . . . . . . 171 Appendix F. Changes from RFC 7235 . . . . . . . . . . . . . . . 173
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 Appendix G. Changes from RFC 7615 . . . . . . . . . . . . . . . 173
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 180 Appendix H. Change Log . . . . . . . . . . . . . . . . . . . . . 173
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 180 H.1. Between RFC723x and draft 00 . . . . . . . . . . . . . . 173
H.2. Since draft-ietf-httpbis-semantics-00 . . . . . . . . . . 174
H.3. Since draft-ietf-httpbis-semantics-01 . . . . . . . . . . 174
H.4. Since draft-ietf-httpbis-semantics-02 . . . . . . . . . . 176
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 184
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 185
1. Introduction 1. Introduction
The Hypertext Transfer Protocol (HTTP) is a stateless application- The Hypertext Transfer Protocol (HTTP) is a stateless application-
level request/response protocol that uses extensible semantics and level request/response protocol that uses extensible semantics and
self-descriptive messages for flexible interaction with network-based self-descriptive messages for flexible interaction with network-based
hypertext information systems. HTTP is defined by a series of hypertext information systems. HTTP is defined by a series of
documents that collectively form the HTTP/1.1 specification: documents that collectively form the HTTP/1.1 specification:
o "HTTP Semantics" (this document) o "HTTP Semantics" (this document)
skipping to change at page 8, line 50 skipping to change at page 9, line 10
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). RFC 7233 (see Appendix E), and RFC 7235 (see Appendix F), and RFC
7615 (see Appendix G).
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.
skipping to change at page 9, line 36 skipping to change at page 9, line 44
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).
The rules below are defined in [Messaging]: The rules below are defined in [Messaging]:
obs-fold = <obs-fold, see [Messaging], Section 5.2> obs-fold = <obs-fold, see [Messaging], Section 5.2>
protocol-name = <protocol-name, see [Messaging], Section 9.7> protocol-name = <protocol-name, see [Messaging], Section 9.8>
protocol-version = <protocol-version, see [Messaging], Section 9.7> protocol-version = <protocol-version, see [Messaging], Section 9.8>
request-target = <request-target, see [Messaging], Section 3.2> request-target = <request-target, see [Messaging], Section 3.2>
This specification uses the terms "character", "character encoding This specification uses the terms "character", "character encoding
scheme", "charset", and "protocol element" as they are defined in scheme", "charset", and "protocol element" as they are defined in
[RFC6365]. [RFC6365].
2. Architecture 2. Architecture
HTTP was created for the World Wide Web (WWW) architecture and has HTTP was created for the World Wide Web (WWW) architecture and has
evolved over time to support the scalability needs of a worldwide evolved over time to support the scalability needs of a worldwide
skipping to change at page 11, line 8 skipping to change at page 11, line 16
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 status line that includes
the protocol version, a success or error code, and textual reason the protocol version, a success or error code, and textual reason
phrase (Section 4 of [Messaging]), possibly followed by header fields phrase (Section 4 of [Messaging]), possibly followed by header fields
containing server information, resource metadata, and representation containing server information, resource metadata, and representation
metadata (Section 5 of [Messaging]), an empty line to indicate the metadata (Section 5 of [Messaging]), an empty line to indicate the
end of the header section, and finally a message body containing 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]).
The mechanism used to correlate between request and response messages
is version dependent; some versions of HTTP use implicit ordering of
messages, while others use an explicit identifier.
A connection might be used for multiple request/response exchanges, A connection might be used for multiple request/response exchanges,
as defined in Section 9.3 of [Messaging]. as defined in Section 9.4 of [Messaging].
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,
clients (including intermediaries) might abandon a request if the
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:
GET /hello.txt HTTP/1.1 GET /hello.txt HTTP/1.1
User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
Host: www.example.com Host: www.example.com
skipping to change at page 12, line 34 skipping to change at page 13, line 16
client, usually via local configuration rules, to receive requests client, usually via local configuration rules, to receive requests
for some type(s) of absolute URI and attempt to satisfy those for some type(s) of absolute URI and attempt to satisfy those
requests via translation through the HTTP interface. Some requests via translation through the HTTP interface. Some
translations are minimal, such as for proxy requests for "http" URIs, translations are minimal, such as for proxy requests for "http" URIs,
whereas other requests might require translation to and from entirely whereas other requests might require translation to and from entirely
different application-level protocols. Proxies are often used to different application-level protocols. Proxies are often used to
group an organization's HTTP requests through a common intermediary group an organization's HTTP requests through a common intermediary
for the sake of security, annotation services, or shared caching. for the sake of security, annotation services, or shared caching.
Some proxies are designed to apply transformations to selected Some proxies are designed to apply transformations to selected
messages or payloads while they are being forwarded, as described in messages or payloads while they are being forwarded, as described in
Section 5.6.2. Section 5.5.2.
A "gateway" (a.k.a. "reverse proxy") is an intermediary that acts as A "gateway" (a.k.a. "reverse proxy") is an intermediary that acts as
an origin server for the outbound connection but translates received an origin server for the outbound connection but translates received
requests and forwards them inbound to another server or servers. requests and forwards them inbound to another server or servers.
Gateways are often used to encapsulate legacy or untrusted Gateways are often used to encapsulate legacy or untrusted
information services, to improve server performance through information services, to improve server performance through
"accelerator" caching, and to enable partitioning or load balancing "accelerator" caching, and to enable partitioning or load balancing
of HTTP services across multiple machines. of HTTP services across multiple machines.
All HTTP requirements applicable to an origin server also apply to All HTTP requirements applicable to an origin server also apply to
skipping to change at page 14, line 38 skipping to change at page 15, line 20
use in off-line or high-latency environments, and so on. use in off-line or high-latency environments, and so on.
2.4. Uniform Resource Identifiers 2.4. Uniform Resource Identifiers
Uniform Resource Identifiers (URIs) [RFC3986] are used throughout Uniform Resource Identifiers (URIs) [RFC3986] are used throughout
HTTP as the means for identifying resources (Section 2.5). URI HTTP as the means for identifying resources (Section 2.5). URI
references are used to target requests, indicate redirects, and references are used to target requests, indicate redirects, and
define relationships. define relationships.
The definitions of "URI-reference", "absolute-URI", "relative-part", The definitions of "URI-reference", "absolute-URI", "relative-part",
"authority", "port", "host", "path-abempty", "segment", "query", and "authority", "port", "host", "path-abempty", "segment", and "query"
"fragment" are adopted from the URI generic syntax. An "absolute- are adopted from the URI generic syntax. An "absolute-path" rule is
path" rule is defined for protocol elements that can contain a non- defined for protocol elements that can contain a non-empty path
empty path component. (This rule differs slightly from the path- component. (This rule differs slightly from the path-abempty rule of
abempty rule of RFC 3986, which allows for an empty path to be used RFC 3986, which allows for an empty path to be used in references,
in references, and path-absolute rule, which does not allow paths and path-absolute rule, which does not allow paths that begin with
that begin with "//".) A "partial-URI" rule is defined for protocol "//".) A "partial-URI" rule is defined for protocol elements that
elements that can contain a relative URI but not a fragment can contain a relative URI but not a fragment component.
component.
URI-reference = <URI-reference, see [RFC3986], Section 4.1> URI-reference = <URI-reference, see [RFC3986], Section 4.1>
absolute-URI = <absolute-URI, see [RFC3986], Section 4.3> absolute-URI = <absolute-URI, see [RFC3986], Section 4.3>
relative-part = <relative-part, see [RFC3986], Section 4.2> relative-part = <relative-part, see [RFC3986], Section 4.2>
authority = <authority, see [RFC3986], Section 3.2> authority = <authority, see [RFC3986], Section 3.2>
uri-host = <host, see [RFC3986], Section 3.2.2> uri-host = <host, see [RFC3986], Section 3.2.2>
port = <port, see [RFC3986], Section 3.2.3> port = <port, see [RFC3986], Section 3.2.3>
path-abempty = <path-abempty, see [RFC3986], Section 3.3> path-abempty = <path-abempty, see [RFC3986], Section 3.3>
segment = <segment, see [RFC3986], Section 3.3> segment = <segment, see [RFC3986], Section 3.3>
query = <query, see [RFC3986], Section 3.4> query = <query, see [RFC3986], Section 3.4>
fragment = <fragment, see [RFC3986], Section 3.5>
absolute-path = 1*( "/" segment ) absolute-path = 1*( "/" segment )
partial-URI = relative-part [ "?" query ] partial-URI = relative-part [ "?" query ]
Each protocol element in HTTP that allows a URI reference will Each protocol element in HTTP that allows a URI reference will
indicate in its ABNF production whether the element allows any form indicate in its ABNF production whether the element allows any form
of reference (URI-reference), only a URI in absolute form (absolute- of reference (URI-reference), only a URI in absolute form (absolute-
URI), only the path and optional query components, or some URI), only the path and optional query components, or some
combination of the above. Unless otherwise indicated, URI references combination of the above. Unless otherwise indicated, URI references
are parsed relative to the effective request URI (Section 5.3). are parsed relative to the effective request URI (Section 5.3).
skipping to change at page 16, line 13 skipping to change at page 16, line 40
+------------+------------------------------------+---------------+ +------------+------------------------------------+---------------+
2.5.1. http URI Scheme 2.5.1. http URI Scheme
The "http" URI scheme is hereby defined for the purpose of minting The "http" URI scheme is hereby defined for the purpose of minting
identifiers according to their association with the hierarchical identifiers according to their association with the hierarchical
namespace governed by a potential HTTP origin server listening for namespace governed by a potential HTTP origin server listening for
TCP ([RFC0793]) connections on a given port. TCP ([RFC0793]) connections on a given port.
http-URI = "http:" "//" authority path-abempty [ "?" query ] http-URI = "http:" "//" authority path-abempty [ "?" query ]
[ "#" fragment ]
The origin server for an "http" URI is identified by the authority The origin server for an "http" URI is identified by the authority
component, which includes a host identifier and optional TCP port component, which includes a host identifier and optional TCP port
([RFC3986], Section 3.2.2). The hierarchical path component and ([RFC3986], Section 3.2.2). The hierarchical path component and
optional query component serve as an identifier for a potential optional query component serve as an identifier for a potential
target resource within that origin server's name space. The optional target resource within that origin server's name space.
fragment component allows for indirect identification of a secondary
resource, independent of the URI scheme, as defined in Section 3.5 of
[RFC3986].
A sender MUST NOT generate an "http" URI with an empty host A sender MUST NOT generate an "http" URI with an empty host
identifier. A recipient that processes such a URI reference MUST identifier. A recipient that processes such a URI reference MUST
reject it as invalid. reject it as invalid.
If the host identifier is provided as an IP address, the origin If the host identifier is provided as an IP address, the origin
server is the listener (if any) on the indicated TCP port at that IP server is the listener (if any) on the indicated TCP port at that IP
address. If host is a registered name, the registered name is an address. If host is a registered name, the registered name is an
indirect identifier for use with a name resolution service, such as indirect identifier for use with a name resolution service, such as
DNS, to find an address for that origin server. If the port DNS, to find an address for that origin server. If the port
skipping to change at page 17, line 46 skipping to change at page 18, line 20
given TCP port for TLS-secured connections ([RFC5246]). given TCP port for TLS-secured connections ([RFC5246]).
All of the requirements listed above for the "http" scheme are also All of the requirements listed above for the "http" scheme are also
requirements for the "https" scheme, except that TCP port 443 is the requirements for the "https" scheme, except that TCP port 443 is the
default if the port subcomponent is empty or not given, and the user default if the port subcomponent is empty or not given, and the user
agent MUST ensure that its connection to the origin server is secured agent MUST ensure that its connection to the origin server is secured
through the use of strong encryption, end-to-end, prior to sending through the use of strong encryption, end-to-end, prior to sending
the first HTTP request. the first HTTP request.
https-URI = "https:" "//" authority path-abempty [ "?" query ] https-URI = "https:" "//" authority path-abempty [ "?" query ]
[ "#" fragment ]
Note that the "https" URI scheme depends on both TLS and TCP for Note that the "https" URI scheme depends on both TLS and TCP for
establishing authority. Resources made available via the "https" establishing authority. Resources made available via the "https"
scheme have no shared identity with the "http" scheme even if their scheme have no shared identity with the "http" scheme even if their
resource identifiers indicate the same authority (the same host resource identifiers indicate the same authority (the same host
listening to the same TCP port). They are distinct namespaces and listening to the same TCP port). They are distinct namespaces and
are considered to be distinct origin servers. However, an extension are considered to be distinct origin servers. However, an extension
to HTTP that is defined to apply to entire host domains, such as the to HTTP that is defined to apply to entire host domains, such as the
Cookie protocol [RFC6265], can allow information set by one service Cookie protocol [RFC6265], can allow information set by one service
to impact communication with other services within a matching group to impact communication with other services within a matching group
of host domains. of host domains.
The process for authoritative access to an "https" identified The process for authoritative access to an "https" identified
resource is defined in [RFC2818]. resource is defined in [RFC2818].
2.5.3. http and https URI Normalization and Comparison 2.5.3. Fragment Identifiers on http(s) URI References
Fragment identifiers allow for indirect identification of a secondary
resource, independent of the URI scheme, as defined in Section 3.5 of
[RFC3986]. Some protocol elements that refer to a URI allow
inclusion of a fragment, while others do not. They are distinguished
by use of the ABNF rule for elements where fragment is allowed;
otherwise, a specific rule that excludes fragments is used (see
Section 5.1).
Note: the fragment identifier component is not part of the actual
scheme definition for a URI scheme (see Section 4.3 of [RFC3986]),
thus does not appear in the ABNF definitions for the "http" and
"https" URI schemes above.
2.5.4. http and https URI Normalization and Comparison
Since the "http" and "https" schemes conform to the URI generic Since the "http" and "https" schemes conform to the URI generic
syntax, such URIs are normalized and compared according to the syntax, such URIs are normalized and compared according to the
algorithm defined in Section 6 of [RFC3986], using the defaults algorithm defined in Section 6 of [RFC3986], using the defaults
described above for each scheme. described above for each scheme.
If the port is equal to the default port for a scheme, the normal If the port is equal to the default port for a scheme, the normal
form is to omit the port subcomponent. When not being used in form is to omit the port subcomponent. When not being used in
absolute form as the request target of an OPTIONS request, an empty absolute form as the request target of an OPTIONS request, an empty
path component is equivalent to an absolute path of "/", so the path component is equivalent to an absolute path of "/", so the
skipping to change at page 22, line 15 skipping to change at page 23, line 5
When an HTTP message is received with a major version number that the When an HTTP message is received with a major version number that the
recipient implements, but a higher minor version number than what the recipient implements, but a higher minor version number than what the
recipient implements, the recipient SHOULD process the message as if recipient implements, the recipient SHOULD process the message as if
it were in the highest minor version within that major version to it were in the highest minor version within that major version to
which the recipient is conformant. A recipient can assume that a which the recipient is conformant. A recipient can assume that a
message with a higher minor version, when sent to a recipient that message with a higher minor version, when sent to a recipient that
has not yet indicated support for that higher version, is has not yet indicated support for that higher version, is
sufficiently backwards-compatible to be safely processed by any sufficiently backwards-compatible to be safely processed by any
implementation of the same major version. implementation of the same major version.
[[CREF1: When a major version of HTTP does not define any minor When a major version of HTTP does not define any minor versions, the
versions, the minor version "0" is implied and ought to be used when minor version "0" is implied and is used when referring to that
referring to that protocol within a protocol element that requires protocol within a protocol element that requires sending a minor
sending a minor version. ]] version.
4. Message Abstraction 4. Message Abstraction
Each major version of HTTP defines its own syntax for the inclusion Each major version of HTTP defines its own syntax for the inclusion
of information in messages. Nevertheless, a common abstraction is of information in messages. Nevertheless, a common abstraction is
that a message includes some form of envelope/framing, a potential that a message includes some form of envelope/framing, a potential
set of named data fields, and a potential body. This section defines set of named data fields, and a potential body. This section defines
the abstraction for message fields as field-name and field-value the abstraction for message fields as field-name and field-value
pairs. pairs.
4.1. Field Names 4.1. Header Field Names
Header fields are key:value pairs that can be used to communicate Header fields are key:value pairs that can be used to communicate
data about the message, its payload, the target resource, or the data about the message, its payload, the target resource, or the
connection (i.e., control data). connection (i.e., control data).
The requirements for header field names are defined in [BCP90]. The requirements for header field names are defined in [BCP90].
The field-name token labels the corresponding field-value as having The field-name token labels the corresponding field-value as having
the semantics defined by that header field. For example, the Date the semantics defined by that header field. For example, the Date
header field is defined in Section 10.1.1.2 as containing the header field is defined in Section 10.1.1.2 as containing the
skipping to change at page 23, line 12 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 | Protocol | Status | Reference |
+---------------------+----------+----------+-------------------+ +---------------------------+----------+----------+-----------------+
| Accept | http | standard | Section 8.4.2 | | Accept | http | standard | Section 8.4.2 |
| Accept-Charset | http | standard | Section 8.4.3 | | Accept-Charset | http | standard | Section 8.4.3 |
| Accept-Encoding | http | standard | Section 8.4.4 | | Accept-Encoding | http | standard | Section 8.4.4 |
| Accept-Language | http | standard | Section 8.4.5 | | Accept-Language | http | standard | Section 8.4.5 |
| Accept-Ranges | http | standard | Section 10.4.1 | | Accept-Ranges | http | standard | Section 10.4.1 |
| Allow | http | standard | Section 10.4.2 | | Allow | http | standard | Section 10.4.2 |
| Authorization | http | standard | Section 8.5.3 | | Authentication-Info | http | standard | Section 10.3.3 |
| Content-Encoding | http | standard | Section 6.2.2 | | Authorization | http | standard | Section 8.5.3 |
| Content-Language | http | standard | Section 6.2.3 | | Content-Encoding | http | standard | Section 6.2.2 |
| Content-Length | http | standard | Section 6.2.4 | | Content-Language | http | standard | Section 6.2.3 |
| Content-Location | http | standard | Section 6.2.5 | | Content-Length | http | standard | Section 6.2.4 |
| Content-Range | http | standard | Section 6.3.3 | | Content-Location | http | standard | Section 6.2.5 |
| Content-Type | http | standard | Section 6.2.1 | | Content-Range | http | standard | Section 6.3.3 |
| Date | http | standard | Section 10.1.1.2 | | Content-Type | http | standard | Section 6.2.1 |
| ETag | http | standard | Section 10.2.3 | | Date | http | standard | Section 10.1.1. |
| Expect | http | standard | Section 8.1.1 | | | | | 2 |
| From | http | standard | Section 8.6.1 | | ETag | http | standard | Section 10.2.3 |
| Host | http | standard | Section 5.4 | | Expect | http | standard | Section 8.1.1 |
| If-Match | http | standard | Section 8.2.3 | | From | http | standard | Section 8.6.1 |
| If-Modified-Since | http | standard | Section 8.2.5 | | Host | http | standard | Section 5.4 |
| If-None-Match | http | standard | Section 8.2.4 | | If-Match | http | standard | Section 8.2.3 |
| If-Range | http | standard | Section 8.2.7 | | If-Modified-Since | http | standard | Section 8.2.5 |
| If-Unmodified-Since | http | standard | Section 8.2.6 | | If-None-Match | http | standard | Section 8.2.4 |
| Last-Modified | http | standard | Section 10.2.2 | | If-Range | http | standard | Section 8.2.7 |
| Location | http | standard | Section 10.1.2 | | If-Unmodified-Since | http | standard | Section 8.2.6 |
| Max-Forwards | http | standard | Section 8.1.2 | | Last-Modified | http | standard | Section 10.2.2 |
| Proxy-Authenticate | http | standard | Section 10.3.2 | | Location | http | standard | Section 10.1.2 |
| Proxy-Authorization | http | standard | Section 8.5.4 | | Max-Forwards | http | standard | Section 8.1.2 |
| Range | http | standard | Section 8.3 | | Proxy-Authenticate | http | standard | Section 10.3.2 |
| Referer | http | standard | Section 8.6.2 | | Proxy-Authentication-Info | http | standard | Section 10.3.4 |
| Retry-After | http | standard | Section 10.1.3 | | Proxy-Authorization | http | standard | Section 8.5.4 |
| Server | http | standard | Section 10.4.3 | | Range | http | standard | Section 8.3 |
| Trailer | http | standard | Section 4.4 | | Referer | http | standard | Section 8.6.2 |
| User-Agent | http | standard | Section 8.6.3 | | Retry-After | http | standard | Section 10.1.3 |
| Vary | http | standard | Section 10.1.4 | | Server | http | standard | Section 10.4.3 |
| Via | http | standard | Section 5.6.1 | | Trailer | http | standard | Section 4.4 |
| WWW-Authenticate | http | standard | Section 10.3.1 | | User-Agent | http | standard | Section 8.6.3 |
+---------------------+----------+----------+-------------------+ | Vary | http | standard | Section 10.1.4 |
| Via | http | standard | Section 5.5.1 |
| WWW-Authenticate | http | standard | Section 10.3.1 |
+---------------------------+----------+----------+-----------------+
4.1.1. Field Name Registry 4.1.1. Header Field Name Registry
HTTP header fields are registered within the "Message Headers" HTTP header fields are registered within the "Message Headers"
registry located at <https://www.iana.org/assignments/message- registry located at <https://www.iana.org/assignments/message-
headers>, as defined by [BCP90], with the protocol "http". headers>, as defined by [BCP90], with the protocol "http".
4.1.2. 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.
New header fields can be defined such that, when they are understood New header fields can be defined such that, when they are understood
by a recipient, they might override or enhance the interpretation of by a recipient, they might override or enhance the interpretation of
skipping to change at page 24, line 35 skipping to change at page 25, line 35
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. "Message Headers" registry.
4.1.3. Considerations for New 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
Internet name; see [BCP178] for further information). Internet name; see [BCP178] for further information).
skipping to change at page 26, line 5 skipping to change at page 27, line 5
Section 10.1.4). Section 10.1.4).
o Whether the header field is useful or allowable in trailers (see o Whether the header field is useful or allowable in trailers (see
Section 7.1 of [Messaging]). Section 7.1 of [Messaging]).
o Whether the header field ought to be preserved across redirects. o Whether the header field ought to be preserved across redirects.
o Whether it introduces any additional security considerations, such o Whether it introduces any additional security considerations, such
as disclosure of privacy-related data. as disclosure of privacy-related data.
4.2. Field Values 4.2. Header Field Values
This specification does not use ABNF rules to define each "Field- This specification does not use ABNF rules to define each "Field-
Name: Field Value" pair, as was done in earlier editions. Instead, Name: Field Value" pair, as was done in earlier editions. Instead,
this specification uses ABNF rules that are named according to each this specification uses ABNF rules that are named according to each
registered field name, wherein the rule defines the valid grammar for registered field name, wherein the rule defines the valid grammar for
that field's corresponding field values (i.e., after the field-value that field's corresponding field values (i.e., after the field-value
has been extracted by a generic field parser). has been extracted by a generic field parser).
field-value = *( field-content / obs-fold ) field-value = *( field-content / obs-fold )
field-content = field-vchar [ 1*( SP / HTAB ) field-vchar ] field-content = field-vchar [ 1*( SP / HTAB ) field-vchar ]
field-vchar = VCHAR / obs-text field-vchar = VCHAR / obs-text
Historically, HTTP header field values could be extended over Historically, HTTP header field values could be extended over
multiple lines by preceding each extra line with at least one space multiple lines by preceding each extra line with at least one space
or horizontal tab (obs-fold). [[CREF2: This document assumes that or horizontal tab (obs-fold). [[CREF1: This document assumes that
any such obs-fold has been replaced with one or more SP octets prior any such obs-fold has been replaced with one or more SP octets prior
to interpreting the field value, as described in Section 5.2 of to interpreting the field value, as described in Section 5.2 of
[Messaging].]] [Messaging].]]
Historically, HTTP has allowed field content with text in the Historically, HTTP has allowed field content with text in the
ISO-8859-1 charset [ISO-8859-1], supporting other charsets only ISO-8859-1 charset [ISO-8859-1], supporting other charsets only
through use of [RFC2047] encoding. In practice, most HTTP header through use of [RFC2047] encoding. In practice, most HTTP header
field values use only a subset of the US-ASCII charset [USASCII]. field values use only a subset of the US-ASCII charset [USASCII].
Newly defined header fields SHOULD limit their field values to Newly defined header fields SHOULD limit their field values to
US-ASCII octets. A recipient SHOULD treat other octets in field US-ASCII octets. A recipient SHOULD treat other octets in field
content (obs-text) as opaque data. content (obs-text) as opaque data.
4.2.1. Field Order 4.2.1. Header Field Order
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.
skipping to change at page 27, line 18 skipping to change at page 28, line 18
forwarding a message. forwarding a message.
Note: In practice, the "Set-Cookie" header field ([RFC6265]) often Note: In practice, the "Set-Cookie" header field ([RFC6265]) often
appears multiple times in a response message and does not use the appears multiple times in a response message and does not use the
list syntax, violating the above requirements on multiple header list syntax, violating the above requirements on multiple header
fields with the same name. Since it cannot be combined into a fields with the same name. Since it cannot be combined into a
single field-value, recipients ought to handle "Set-Cookie" as a single field-value, recipients ought to handle "Set-Cookie" as a
special case while processing header fields. (See Appendix A.2.3 special case while processing header fields. (See Appendix A.2.3
of [Kri2001] for details.) of [Kri2001] for details.)
4.2.2. Field Limits 4.2.2. Header Field Limits
HTTP does not place a predefined limit on the length of each header HTTP does not place a predefined limit on the length of each header
field or on the length of the header section as a whole, as described field or on the length of the header section as a whole, as described
in Section 3. Various ad hoc limitations on individual header field in Section 3. Various ad hoc limitations on individual header field
length are found in practice, often depending on the specific field length are found in practice, often depending on the specific field
semantics. semantics.
A server that receives a request header field, or set of fields, A server that receives a request header field, or set of fields,
larger than it wishes to process MUST respond with an appropriate 4xx larger than it wishes to process MUST respond with an appropriate 4xx
(Client Error) status code. Ignoring such header fields would (Client Error) status code. Ignoring such header fields would
increase the server's vulnerability to request smuggling attacks increase the server's vulnerability to request smuggling attacks
(Section 11.2 of [Messaging]). (Section 11.2 of [Messaging]).
A client MAY discard or truncate received header fields that are A client MAY discard or truncate received header fields that are
larger than the client wishes to process if the field semantics are larger than the client wishes to process if the field semantics are
such that the dropped value(s) can be safely ignored without changing such that the dropped value(s) can be safely ignored without changing
the message framing or response semantics. the message framing or response semantics.
4.2.3. Field Value Components 4.2.3. Header Field Value Components
Most HTTP header field values are defined using common syntax Most HTTP header field values are defined using common syntax
components (token, quoted-string, and comment) separated by components (token, quoted-string, and comment) separated by
whitespace or specific delimiting characters. Delimiters are chosen whitespace or specific delimiting characters. Delimiters are chosen
from the set of US-ASCII visual characters not allowed in a token from the set of US-ASCII visual characters not allowed in a token
(DQUOTE and "(),/:;<=>?@[\]{}"). (DQUOTE and "(),/:;<=>?@[\]{}").
token = 1*tchar token = 1*tchar
tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*"
skipping to change at page 28, line 32 skipping to change at page 29, line 32
as if it were replaced by the octet following the backslash. as if it were replaced by the octet following the backslash.
quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text ) quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
A sender SHOULD NOT generate a quoted-pair in a quoted-string except A sender SHOULD NOT generate a quoted-pair in a quoted-string except
where necessary to quote DQUOTE and backslash octets occurring within where necessary to quote DQUOTE and backslash octets occurring within
that string. A sender SHOULD NOT generate a quoted-pair in a comment that string. A sender SHOULD NOT generate a quoted-pair in a comment
except where necessary to quote parentheses ["(" and ")"] and except where necessary to quote parentheses ["(" and ")"] and
backslash octets occurring within that comment. backslash octets occurring within that comment.
4.2.4. Designing New Field Values 4.2.4. Designing New Header Field Values
New header field values typically have their syntax defined using New header field values typically have their syntax defined using
ABNF ([RFC5234]), using the extension defined in Section 11 as ABNF ([RFC5234]), using the extension defined in Section 11 as
necessary, and are usually constrained to the range of US-ASCII necessary, and are usually constrained to the range of US-ASCII
characters. Header fields needing a greater range of characters can characters. Header fields needing a greater range of characters can
use an encoding such as the one defined in [RFC8187]. use an encoding such as the one defined in [RFC8187].
Leading and trailing whitespace in raw field values is removed upon Leading and trailing whitespace in raw field values is removed upon
field parsing (Section 5.1 of [Messaging]). Field definitions where field parsing (Section 5.1 of [Messaging]). Field definitions where
leading or trailing whitespace in values is significant will have to leading or trailing whitespace in values is significant will have to
skipping to change at page 30, line 7 skipping to change at page 31, line 7
OWS = *( SP / HTAB ) OWS = *( SP / HTAB )
; optional whitespace ; optional whitespace
RWS = 1*( SP / HTAB ) RWS = 1*( SP / HTAB )
; required whitespace ; required whitespace
BWS = OWS BWS = OWS
; "bad" whitespace ; "bad" whitespace
4.4. Trailer 4.4. Trailer
[[CREF3: The "Trailer" header field in a message indicates fields [[CREF2: The "Trailer" header field in a message indicates fields
that the sender anticipates sending after the message header block that the sender anticipates sending after the message header block
(i.e., during or after the payload is sent). This is typically used (i.e., during or after the payload is sent). This is typically used
to supply metadata that might be dynamically generated while the data to supply metadata that might be dynamically generated while the data
is sent, such as a message integrity check, digital signature, or is sent, such as a message integrity check, digital signature, or
post-processing status. ]] post-processing status. ]]
Trailer = 1#field-name Trailer = 1#field-name
[[CREF4: How, where, and when trailer fields might be sent depends on [[CREF3: How, where, and when trailer fields might be sent depends on
both the protocol in use (HTTP version and/or transfer coding) and both the protocol in use (HTTP version and/or transfer coding) and
the semantics of each named header field. Many header fields cannot the semantics of each named header field. Many header fields cannot
be processed outside the header section because their evaluation is be processed outside the header section because their evaluation is
necessary for message routing, authentication, or configuration prior necessary for message routing, authentication, or configuration prior
to receiving the representation data. ]] to receiving the representation data. ]]
5. Message Routing 5. Message Routing
HTTP request message routing is determined by each client based on HTTP request message routing is determined by each client based on
the target resource, the client's proxy configuration, and the target resource, the client's proxy configuration, and
skipping to change at page 33, line 12 skipping to change at page 34, line 12
Host field-value for redirecting requests to internal servers, or for Host field-value for redirecting requests to internal servers, or for
use as a cache key in a shared cache, without first verifying that use as a cache key in a shared cache, without first verifying that
the intercepted connection is targeting a valid IP address for that the intercepted connection is targeting a valid IP address for that
host. host.
A server MUST respond with a 400 (Bad Request) status code to any A server MUST respond with a 400 (Bad Request) status code to any
HTTP/1.1 request message that lacks a Host header field and to any HTTP/1.1 request message that lacks a Host header field and to any
request message that contains more than one Host header field or a request message that contains more than one Host header field or a
Host header field with an invalid field-value. Host header field with an invalid field-value.
5.5. Associating a Response to a Request 5.5. Message Forwarding
HTTP does not include a request identifier for associating a given
request message with its corresponding one or more response messages.
Hence, it relies on the order of response arrival to correspond
exactly to the order in which requests are made on the same
connection. More than one response message per request only occurs
when one or more informational responses (1xx, see Section 9.2)
precede a final response to the same request.
A client that has more than one outstanding request on a connection
MUST maintain a list of outstanding requests in the order sent and
MUST associate each received response message on that connection to
the highest ordered request that has not yet received a final (non-
1xx) response.
5.6. Message Forwarding
As described in Section 2.2, intermediaries can serve a variety of As described in Section 2.2, intermediaries can serve a variety of
roles in the processing of HTTP requests and responses. Some roles in the processing of HTTP requests and responses. Some
intermediaries are used to improve performance or availability. intermediaries are used to improve performance or availability.
Others are used for access control or to filter content. Since an Others are used for access control or to filter content. Since an
HTTP stream has characteristics similar to a pipe-and-filter HTTP stream has characteristics similar to a pipe-and-filter
architecture, there are no inherent limits to the extent an architecture, there are no inherent limits to the extent an
intermediary can enhance (or interfere) with either direction of the intermediary can enhance (or interfere) with either direction of the
stream. stream.
skipping to change at page 34, line 8 skipping to change at page 34, line 40
ought to recognize its own server names, including any aliases, local ought to recognize its own server names, including any aliases, local
variations, or literal IP addresses, and respond to such requests variations, or literal IP addresses, and respond to such requests
directly. directly.
An HTTP message can be parsed as a stream for incremental processing An HTTP message can be parsed as a stream for incremental processing
or forwarding downstream. However, recipients cannot rely on or forwarding downstream. However, recipients cannot rely on
incremental delivery of partial messages, since some implementations incremental delivery of partial messages, since some implementations
will buffer or delay message forwarding for the sake of network will buffer or delay message forwarding for the sake of network
efficiency, security checks, or payload transformations. efficiency, security checks, or payload transformations.
5.6.1. Via 5.5.1. Via
The "Via" header field indicates the presence of intermediate The "Via" header field indicates the presence of intermediate
protocols and recipients between the user agent and the server (on protocols and recipients between the user agent and the server (on
requests) or between the origin server and the client (on responses), requests) or between the origin server and the client (on responses),
similar to the "Received" header field in email (Section 3.6.7 of similar to the "Received" header field in email (Section 3.6.7 of
[RFC5322]). Via can be used for tracking message forwards, avoiding [RFC5322]). Via can be used for tracking message forwards, avoiding
request loops, and identifying the protocol capabilities of senders request loops, and identifying the protocol capabilities of senders
along the request/response chain. along the request/response chain.
Via = 1#( received-protocol RWS received-by [ RWS comment ] ) Via = 1#( received-protocol RWS received-by [ RWS comment ] )
received-protocol = [ protocol-name "/" ] protocol-version received-protocol = [ protocol-name "/" ] protocol-version
; see [Messaging], Section 9.7 ; see [Messaging], Section 9.8
received-by = ( uri-host [ ":" port ] ) / pseudonym received-by = ( uri-host [ ":" port ] ) / pseudonym
pseudonym = token pseudonym = token
Multiple Via field values represent each proxy or gateway that has Multiple Via field values represent each proxy or gateway that has
forwarded the message. Each intermediary appends its own information forwarded the message. Each intermediary appends its own information
about how the message was received, such that the end result is about how the message was received, such that the end result is
ordered according to the sequence of forwarding recipients. ordered according to the sequence of forwarding recipients.
A proxy MUST send an appropriate Via header field, as described A proxy MUST send an appropriate Via header field, as described
below, in each message that it forwards. An HTTP-to-HTTP gateway below, in each message that it forwards. An HTTP-to-HTTP gateway
skipping to change at page 35, line 43 skipping to change at page 36, line 28
could be collapsed to could be collapsed to
Via: 1.0 ricky, 1.1 mertz, 1.0 lucy Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
A sender SHOULD NOT combine multiple entries unless they are all A sender SHOULD NOT combine multiple entries unless they are all
under the same organizational control and the hosts have already been under the same organizational control and the hosts have already been
replaced by pseudonyms. A sender MUST NOT combine entries that have replaced by pseudonyms. A sender MUST NOT combine entries that have
different received-protocol values. different received-protocol values.
5.6.2. Transformations 5.5.2. Transformations
Some intermediaries include features for transforming messages and Some intermediaries include features for transforming messages and
their payloads. A proxy might, for example, convert between image their payloads. A proxy might, for example, convert between image
formats in order to save cache space or to reduce the amount of formats in order to save cache space or to reduce the amount of
traffic on a slow link. However, operational problems might occur traffic on a slow link. However, operational problems might occur
when these transformations are applied to payloads intended for when these transformations are applied to payloads intended for
critical applications, such as medical imaging or scientific data critical applications, such as medical imaging or scientific data
analysis, particularly when integrity checks or digital signatures analysis, particularly when integrity checks or digital signatures
are used to ensure that the payload received is identical to the are used to ensure that the payload received is identical to the
original. original.
skipping to change at page 36, line 38 skipping to change at page 37, line 24
"*". "*".
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 directive (Section 5.2 of
[Caching]). [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 a a no-transform cache-control directive. A proxy that transforms the
payload MUST add a Warning header field with the warn-code of 214 payload of a 200 (OK) response can inform downstream recipients that
("Transformation Applied") if one is not already in the message (see a transformation has been applied by changing the response status
Section 5.5 of [Caching]). A proxy that transforms the payload of a code to 203 (Non-Authoritative Information) (Section 9.3.4).
200 (OK) response can further inform downstream recipients that a
transformation has been applied by changing the response status 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
field's definition specifically allows such modification or the field's definition specifically allows such modification or the
modification is deemed necessary for privacy or security. modification is deemed necessary for privacy or security.
6. Representations 6. Representations
Considering that a resource could be anything, and that the uniform Considering that a resource could be anything, and that the uniform
skipping to change at page 38, line 48 skipping to change at page 39, line 29
6.1.1.1. Charset 6.1.1.1. Charset
HTTP uses charset names to indicate or negotiate the character HTTP uses charset names to indicate or negotiate the character
encoding scheme of a textual representation [RFC6365]. A charset is encoding scheme of a textual representation [RFC6365]. A charset is
identified by a case-insensitive token. identified by a case-insensitive token.
charset = token charset = token
Charset names ought to be registered in the IANA "Character Sets" Charset names ought to be registered in the IANA "Character Sets"
registry (<https://www.iana.org/assignments/character-sets>) registry (<https://www.iana.org/assignments/character-sets>)
according to the procedures defined in [RFC2978]. according to the procedures defined in Section 2 of [RFC2978].
Note: in practice, charset names are furthermore restricted by the
"mime-charset" ABNF rule defined in Section 2.3 of [RFC2978] (as
corrected in [Err1912]). However, that rule allows two characters
not included in "token" ("{" and "}"), but at the time of this
writing no character set using these was registered (see
[Err5433]).
6.1.1.2. Canonicalization and Text Defaults 6.1.1.2. Canonicalization and Text Defaults
Media types are registered with a canonical form in order to be Media types are registered with a canonical form in order to be
interoperable among systems with varying native encoding formats. interoperable among systems with varying native encoding formats.
Representations selected or transferred via HTTP ought to be in Representations selected or transferred via HTTP ought to be in
canonical form, for many of the same reasons described by the canonical form, for many of the same reasons described by the
Multipurpose Internet Mail Extensions (MIME) [RFC2045]. However, the Multipurpose Internet Mail Extensions (MIME) [RFC2045]. However, the
performance characteristics of email deployments (i.e., store and performance characteristics of email deployments (i.e., store and
forward messages to peers) are significantly different from those forward messages to peers) are significantly different from those
skipping to change at page 48, line 12 skipping to change at page 49, line 7
linguistic audiences. An example would be a beginner's language linguistic audiences. An example would be a beginner's language
primer, such as "A First Lesson in Latin", which is clearly intended primer, such as "A First Lesson in Latin", which is clearly intended
to be used by an English-literate audience. In this case, the to be used by an English-literate audience. In this case, the
Content-Language would properly only include "en". Content-Language would properly only include "en".
Content-Language MAY be applied to any media type -- it is not Content-Language MAY be applied to any media type -- it is not
limited to textual documents. limited to textual documents.
6.2.4. Content-Length 6.2.4. Content-Length
[[CREF5: The "Content-Length" header field indicates the number of [[CREF4: The "Content-Length" header field indicates the number of
data octets (body length) for the representation. In some cases, data octets (body length) for the representation. In some cases,
Content-Length is used to define or estimate message framing. ]] Content-Length is used to define or estimate message framing. ]]
Content-Length = 1*DIGIT Content-Length = 1*DIGIT
An example is An example is
Content-Length: 3495 Content-Length: 3495
A sender MUST NOT send a Content-Length header field in any message A sender MUST NOT send a Content-Length header field in any message
skipping to change at page 60, line 9 skipping to change at page 60, line 48
example, a client can send conditional request header fields example, a client can send conditional request header fields
(Section 8.2) to make the requested action conditional on the current (Section 8.2) to make the requested action conditional on the current
state of the target resource. state of the target resource.
method = token method = token
HTTP was originally designed to be usable as an interface to HTTP was originally designed to be usable as an interface to
distributed object systems. The request method was envisioned as distributed object systems. The request method was envisioned as
applying semantics to a target resource in much the same way as applying semantics to a target resource in much the same way as
invoking a defined method on an identified object would apply invoking a defined method on an identified object would apply
semantics. The method token is case-sensitive because it might be semantics.
used as a gateway to object-based systems with case-sensitive method
names. The method token is case-sensitive because it might be used as a
gateway to object-based systems with case-sensitive method names. By
convention, standardized methods are defined in all-uppercase US-
ASCII letters.
Unlike distributed objects, the standardized request methods in HTTP Unlike distributed objects, the standardized request methods in HTTP
are not resource-specific, since uniform interfaces provide for are not resource-specific, since uniform interfaces provide for
better visibility and reuse in network-based systems [REST]. Once better visibility and reuse in network-based systems [REST]. Once
defined, a standardized method ought to have the same semantics when defined, a standardized method ought to have the same semantics when
applied to any resource, though each resource determines for itself applied to any resource, though each resource determines for itself
whether those semantics are implemented or allowed. whether those semantics are implemented or allowed.
This specification defines a number of standardized methods that are This specification defines a number of standardized methods that are
commonly used in HTTP, as outlined by the following table. By commonly used in HTTP, as outlined by the following table.
convention, standardized methods are defined in all-uppercase US-
ASCII letters.
+---------+-------------------------------------------------+-------+ +---------+-------------------------------------------------+-------+
| Method | Description | Sec. | | Method | Description | Sec. |
+---------+-------------------------------------------------+-------+ +---------+-------------------------------------------------+-------+
| GET | Transfer a current representation of the target | 7.3.1 | | GET | Transfer a current representation of the target | 7.3.1 |
| | resource. | | | | resource. | |
| HEAD | Same as GET, but only transfer the status line | 7.3.2 | | HEAD | Same as GET, but only transfer the status line | 7.3.2 |
| | and header section. | | | | and header section. | |
| POST | Perform resource-specific processing on the | 7.3.3 | | POST | Perform resource-specific processing on the | 7.3.3 |
| | request payload. | | | | request payload. | |
skipping to change at page 65, line 6 skipping to change at page 65, line 50
Satisfiable)). Satisfiable)).
If one or more resources has been created on the origin server as a If one or more resources has been created on the origin server as a
result of successfully processing a POST request, the origin server result of successfully processing a POST request, the origin server
SHOULD send a 201 (Created) response containing a Location header SHOULD send a 201 (Created) response containing a Location header
field that provides an identifier for the primary resource created field that provides an identifier for the primary resource created
(Section 10.1.2) and a representation that describes the status of (Section 10.1.2) and a representation that describes the status of
the request while referring to the new resource(s). the request while referring to the new resource(s).
Responses to POST requests are only cacheable when they include Responses to POST requests are only cacheable when they include
explicit freshness information (see Section 4.2.1 of [Caching]). explicit freshness information (see Section 4.2.1 of [Caching]) and a
However, POST caching is not widely implemented. For cases where an Content-Location header field that has the same value as the POST's
origin server wishes the client to be able to cache the result of a effective request URI (Section 6.2.5). A cached POST response can be
POST in a way that can be reused by a later GET, the origin server reused to satisfy a later GET or HEAD request, but not a POST
MAY send a 200 (OK) response containing the result and a Content- request, since POST is required to be written through to the origin
Location header field that has the same value as the POST's effective server, because it is unsafe; see Section 4 of [Caching].
request URI (Section 6.2.5).
If the result of processing a POST would be equivalent to a If the result of processing a POST would be equivalent to a
representation of an existing resource, an origin server MAY redirect representation of an existing resource, an origin server MAY redirect
the user agent to that resource by sending a 303 (See Other) response the user agent to that resource by sending a 303 (See Other) response
with the existing resource's identifier in the Location field. This with the existing resource's identifier in the Location field. This
has the benefits of providing the user agent a resource identifier has the benefits of providing the user agent a resource identifier
and transferring the representation via a method more amenable to and transferring the representation via a method more amenable to
shared caching, though at the cost of an extra request if the user shared caching, though at the cost of an extra request if the user
agent does not already have the representation cached. agent does not already have the representation cached.
skipping to change at page 71, line 49 skipping to change at page 72, line 44
A client MUST NOT generate header fields in a TRACE request A client MUST NOT generate header fields in a TRACE request
containing sensitive data that might be disclosed by the response. containing sensitive data that might be disclosed by the response.
For example, it would be foolish for a user agent to send stored user For example, it would be foolish for a user agent to send stored user
credentials Section 8.5 or cookies [RFC6265] in a TRACE request. The credentials Section 8.5 or cookies [RFC6265] in a TRACE request. The
final recipient of the request SHOULD exclude any request header final recipient of the request SHOULD exclude any request header
fields that are likely to contain sensitive data when that recipient fields that are likely to contain sensitive data when that recipient
generates the response body. generates the response body.
TRACE allows the client to see what is being received at the other TRACE allows the client to see what is being received at the other
end of the request chain and use that data for testing or diagnostic end of the request chain and use that data for testing or diagnostic
information. The value of the Via header field (Section 5.6.1) is of information. The value of the Via header field (Section 5.5.1) is of
particular interest, since it acts as a trace of the request chain. particular interest, since it acts as a trace of the request chain.
Use of the Max-Forwards header field allows the client to limit the Use of the Max-Forwards header field allows the client to limit the
length of the request chain, which is useful for testing a chain of length of the request chain, which is useful for testing a chain of
proxies forwarding messages in an infinite loop. proxies forwarding messages in an infinite loop.
A client MUST NOT send a message body in a TRACE request. A client MUST NOT send a message body in a TRACE request.
Responses to the TRACE method are not cacheable. Responses to the TRACE method are not cacheable.
7.4. Method Extensibility 7.4. Method Extensibility
skipping to change at page 75, line 33 skipping to change at page 76, line 26
o A server MAY omit sending a 100 (Continue) response if it has o A server MAY omit sending a 100 (Continue) response if it has
already received some or all of the message body for the already received some or all of the message body for the
corresponding request, or if the framing indicates that there is corresponding request, or if the framing indicates that there is
no message body. no message body.
o A server that sends a 100 (Continue) response MUST ultimately send o A server that sends a 100 (Continue) response MUST ultimately send
a final status code, once the message body is received and a final status code, once the message body is received and
processed, unless the connection is closed prematurely. processed, unless the connection is closed prematurely.
o A server that responds with a final status code before reading the o A server that responds with a final status code before reading the
entire message body SHOULD indicate in that response whether it entire request payload body SHOULD indicate whether it intends to
intends to close the connection or continue reading and discarding close the connection (see Section 9.7 of [Messaging]) or continue
the request message (see Section 9.6 of [Messaging]). reading the payload body.
An origin server MUST, upon receiving an HTTP/1.1 (or later) request- An origin server MUST, upon receiving an HTTP/1.1 (or later) request-
line and a complete header section that contains a 100-continue line and a complete header section that contains a 100-continue
expectation and indicates a request message body will follow, either expectation and indicates a request message body will follow, either
send an immediate response with a final status code, if that status send an immediate response with a final status code, if that status
can be determined by examining just the request-line and header can be determined by examining just the request-line and header
fields, or send an immediate 100 (Continue) response to encourage the fields, or send an immediate 100 (Continue) response to encourage the
client to send the request's message body. The origin server MUST client to send the request's message body. The origin server MUST
NOT wait for the message body before sending the 100 (Continue) NOT wait for the message body before sending the 100 (Continue)
response. response.
skipping to change at page 100, line 14 skipping to change at page 101, line 14
(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 either Cache-Control request directives
(e.g., "no-store", Section 5.2.1.5 of [Caching]) or response (e.g., "no-store", Section 5.2.1.5 of [Caching]) or response
directives (e.g., "private"). directives (e.g., "private").
o Schemes using Authentication-Info, Proxy-Authentication-Info, or
any other authentication related response header field need to
consider and document the related security considerations (see
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
agent, and resource behind the request. agent, and resource behind the request.
+-------------------+---------------+ +-------------------+---------------+
| Header Field Name | Defined in... | | Header Field Name | Defined in... |
+-------------------+---------------+ +-------------------+---------------+
| From | Section 8.6.1 | | From | Section 8.6.1 |
skipping to change at page 105, line 43 skipping to change at page 106, line 43
| 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 |
| 410 | Gone | Section 9.5.11 | | 410 | Gone | Section 9.5.11 |
| 411 | Length Required | Section 9.5.12 | | 411 | Length Required | Section 9.5.12 |
| 412 | Precondition Failed | Section 9.5.13 | | 412 | Precondition Failed | Section 9.5.13 |
| 413 | Payload Too Large | Section 9.5.14 | | 413 | Payload Too Large | Section 9.5.14 |
| 414 | URI Too Long | Section 9.5.15 | | 414 | URI Too Long | Section 9.5.15 |
| 415 | Unsupported Media Type | Section 9.5.16 | | 415 | Unsupported Media Type | Section 9.5.16 |
| 416 | Range Not Satisfiable | Section 9.5.17 | | 416 | Range Not Satisfiable | Section 9.5.17 |
| 417 | Expectation Failed | Section 9.5.18 | | 417 | Expectation Failed | Section 9.5.18 |
| 426 | Upgrade Required | Section 9.5.19 | | 418 | (Unused) | Section 9.5.19 |
| 422 | Unprocessable Entity | Section 9.5.20 |
| 426 | Upgrade Required | Section 9.5.21 |
| 500 | Internal Server Error | Section 9.6.1 | | 500 | Internal Server Error | Section 9.6.1 |
| 501 | Not Implemented | Section 9.6.2 | | 501 | Not Implemented | Section 9.6.2 |
| 502 | Bad Gateway | Section 9.6.3 | | 502 | Bad Gateway | Section 9.6.3 |
| 503 | Service Unavailable | Section 9.6.4 | | 503 | Service Unavailable | Section 9.6.4 |
| 504 | Gateway Timeout | Section 9.6.5 | | 504 | Gateway Timeout | Section 9.6.5 |
| 505 | HTTP Version Not Supported | Section 9.6.6 | | 505 | HTTP Version Not Supported | Section 9.6.6 |
+-------+-------------------------------+-----------------+ +-------+-------------------------------+-----------------+
Note that this list is not exhaustive -- it does not include Note that this list is not exhaustive -- it does not include
extension status codes defined in other specifications (Section 9.7). extension status codes defined in other specifications (Section 9.7).
skipping to change at page 106, line 47 skipping to change at page 107, line 47
discard the 100 response. discard the 100 response.
If the request did not contain an Expect header field containing the If the request did not contain an Expect header field containing the
100-continue expectation, the client can simply discard this interim 100-continue expectation, the client can simply discard this interim
response. response.
9.2.2. 101 Switching Protocols 9.2.2. 101 Switching Protocols
The 101 (Switching Protocols) status code indicates that the server The 101 (Switching Protocols) status code indicates that the server
understands and is willing to comply with the client's request, via understands and is willing to comply with the client's request, via
the Upgrade header field (Section 9.7 of [Messaging]), for a change the Upgrade header field (Section 9.8 of [Messaging]), for a change
in the application protocol being used on this connection. The in the application protocol being used on this connection. The
server MUST generate an Upgrade header field in the response that server MUST generate an Upgrade header field in the response that
indicates which protocol(s) will be switched to immediately after the indicates which protocol(s) will be switched to immediately after the
empty line that terminates the 101 response. empty line that terminates the 101 response.
It is assumed that the server will only agree to switch protocols It is assumed that the server will only agree to switch protocols
when it is advantageous to do so. For example, switching to a newer when it is advantageous to do so. For example, switching to a newer
version of HTTP might be advantageous over older versions, and version of HTTP might be advantageous over older versions, and
switching to a real-time, synchronous protocol might be advantageous switching to a real-time, synchronous protocol might be advantageous
when delivering resources that use such features. when delivering resources that use such features.
skipping to change at page 108, line 41 skipping to change at page 109, line 41
until the process is completed. The representation sent with this until the process is completed. The representation sent with this
response ought to describe the request's current status and point to response ought to describe the request's current status and point to
(or embed) a status monitor that can provide the user with an (or embed) a status monitor that can provide the user with an
estimate of when the request will be fulfilled. estimate of when the request will be fulfilled.
9.3.4. 203 Non-Authoritative Information 9.3.4. 203 Non-Authoritative Information
The 203 (Non-Authoritative Information) status code indicates that The 203 (Non-Authoritative Information) status code indicates that
the request was successful but the enclosed payload has been modified the request was successful but the enclosed payload has been modified
from that of the origin server's 200 (OK) response by a transforming from that of the origin server's 200 (OK) response by a transforming
proxy (Section 5.6.2). This status code allows the proxy to notify proxy (Section 5.5.2). This status code allows the proxy to notify
recipients when a transformation has been applied, since that recipients when a transformation has been applied, since that
knowledge might impact later decisions regarding the content. For knowledge might impact later decisions regarding the content. For
example, future cache validation requests for the content might only example, future cache validation requests for the content might only
be applicable along the same request path (through the same proxies). be applicable along the same request path (through the same proxies).
The 203 response is similar to the Warning code of 214 Transformation The 203 response is similar to the Warning code of 214 Transformation
Applied (Section 5.5 of [Caching]), which has the advantage of being Applied (Section 5.5 of [Caching]), which has the advantage of being
applicable to responses with any status code. applicable to responses with any status code.
A 203 response is cacheable by default; i.e., unless otherwise A 203 response is cacheable by default; i.e., unless otherwise
skipping to change at page 123, line 15 skipping to change at page 124, line 15
9.5.17. 416 Range Not Satisfiable 9.5.17. 416 Range Not Satisfiable
The 416 (Range Not Satisfiable) status code indicates that none of The 416 (Range Not Satisfiable) status code indicates that none of
the ranges in the request's Range header field (Section 8.3) overlap the ranges in the request's Range header field (Section 8.3) overlap
the current extent of the selected representation or that the set of the current extent of the selected representation or that the set of
ranges requested has been rejected due to invalid ranges or an ranges requested has been rejected due to invalid ranges or an
excessive request of small or overlapping ranges. excessive request of small or overlapping ranges.
For byte ranges, failing to overlap the current extent means that the For byte ranges, failing to overlap the current extent means that the
first-byte-pos of all of the byte-range-spec values were greater than first-byte-pos of all of the byte-range-spec values were greater than
the current length of the selected representation. When this status or equal to the current length of the selected representation. When
code is generated in response to a byte-range request, the sender this status code is generated in response to a byte-range request,
SHOULD generate a Content-Range header field specifying the current the sender SHOULD generate a Content-Range header field specifying
length of the selected representation (Section 6.3.3). the current length of the selected representation (Section 6.3.3).
For example: For example:
HTTP/1.1 416 Range Not Satisfiable HTTP/1.1 416 Range Not Satisfiable
Date: Fri, 20 Jan 2012 15:41:54 GMT Date: Fri, 20 Jan 2012 15:41:54 GMT
Content-Range: bytes */47022 Content-Range: bytes */47022
Note: Because servers are free to ignore Range, many Note: Because servers are free to ignore Range, many
implementations will simply respond with the entire selected implementations will simply respond with the entire selected
representation in a 200 (OK) response. That is partly because representation in a 200 (OK) response. That is partly because
skipping to change at page 123, line 43 skipping to change at page 124, line 43
on receiving a 416 (Range Not Satisfiable) response even when it on receiving a 416 (Range Not Satisfiable) response even when it
is most appropriate. is most appropriate.
9.5.18. 417 Expectation Failed 9.5.18. 417 Expectation Failed
The 417 (Expectation Failed) status code indicates that the The 417 (Expectation Failed) status code indicates that the
expectation given in the request's Expect header field expectation given in the request's Expect header field
(Section 8.1.1) could not be met by at least one of the inbound (Section 8.1.1) could not be met by at least one of the inbound
servers. servers.
9.5.19. 426 Upgrade Required 9.5.19. 418 (Unused)
[RFC2324] was an April 1 RFC that lampooned the various ways HTTP was
abused; one such abuse was the definition of an application-specific
418 status code. In the intervening years, this status code has been
widely implemented as an "Easter Egg", and therefore is effectively
consumed by this use.
Therefore, the 418 status code is reserved in the IANA HTTP Status
Code registry. This indicates that the status code cannot be
assigned to other applications currently. If future circumstances
require its use (e.g., exhaustion of 4NN status codes), it can be re-
assigned to another use.
9.5.20. 422 Unprocessable Entity
The 422 (Unprocessable Entity) status code indicates that the server
understands the content type of the request entity (hence a 415
(Unsupported Media Type) status code is inappropriate), and the
syntax of the request entity is correct but was unable to process the
contained instructions. For example, this error condition may occur
if an XML request body contains well-formed (i.e., syntactically
correct), but semantically erroneous, XML instructions.
9.5.21. 426 Upgrade Required
The 426 (Upgrade Required) status code indicates that the server The 426 (Upgrade Required) status code indicates that the server
refuses to perform the request using the current protocol but might refuses to perform the request using the current protocol but might
be willing to do so after the client upgrades to a different be willing to do so after the client upgrades to a different
protocol. The server MUST send an Upgrade header field in a 426 protocol. The server MUST send an Upgrade header field in a 426
response to indicate the required protocol(s) (Section 9.7 of response to indicate the required protocol(s) (Section 9.8 of
[Messaging]). [Messaging]).
Example: Example:
HTTP/1.1 426 Upgrade Required HTTP/1.1 426 Upgrade Required
Upgrade: HTTP/3.0 Upgrade: HTTP/3.0
Connection: Upgrade Connection: Upgrade
Content-Length: 53 Content-Length: 53
Content-Type: text/plain Content-Type: text/plain
skipping to change at page 143, line 27 skipping to change at page 144, line 27
Authentication challenges indicate what mechanisms are available for Authentication challenges indicate what mechanisms are available for
the client to provide authentication credentials in future requests. the client to provide authentication credentials in future requests.
+--------------------+----------------+ +--------------------+----------------+
| Header Field Name | Defined in... | | Header Field Name | Defined in... |
+--------------------+----------------+ +--------------------+----------------+
| WWW-Authenticate | Section 10.3.1 | | WWW-Authenticate | Section 10.3.1 |
| Proxy-Authenticate | Section 10.3.2 | | Proxy-Authenticate | Section 10.3.2 |
+--------------------+----------------+ +--------------------+----------------+
Furthermore, the "Authentication-Info" and "Proxy-Authentication-
Info" response header fields are defined for use in authentication
schemes that need to return information once the client's
authentication credentials have been accepted.
+---------------------------+----------------+
| Header Field Name | Defined in... |
+---------------------------+----------------+
| Authentication-Info | Section 10.3.3 |
| Proxy-Authentication-Info | Section 10.3.4 |
+---------------------------+----------------+
10.3.1. WWW-Authenticate 10.3.1. WWW-Authenticate
The "WWW-Authenticate" header field indicates the authentication The "WWW-Authenticate" header field indicates the authentication
scheme(s) and parameters applicable to the target resource. scheme(s) and parameters applicable to the target resource.
WWW-Authenticate = 1#challenge WWW-Authenticate = 1#challenge
A server generating a 401 (Unauthorized) response MUST send a WWW- A server generating a 401 (Unauthorized) response MUST send a WWW-
Authenticate header field containing at least one challenge. A Authenticate header field containing at least one challenge. A
server MAY generate a WWW-Authenticate header field in other response server MAY generate a WWW-Authenticate header field in other response
skipping to change at page 144, line 46 skipping to change at page 146, line 8
proxies are used within the same administrative domain, such as proxies are used within the same administrative domain, such as
office and regional caching proxies within a large corporate network, office and regional caching proxies within a large corporate network,
it is common for credentials to be generated by the user agent and it is common for credentials to be generated by the user agent and
passed through the hierarchy until consumed. Hence, in such a passed through the hierarchy until consumed. Hence, in such a
configuration, it will appear as if Proxy-Authenticate is being configuration, it will appear as if Proxy-Authenticate is being
forwarded because each proxy will send the same challenge set. forwarded because each proxy will send the same challenge set.
Note that the parsing considerations for WWW-Authenticate apply to Note that the parsing considerations for WWW-Authenticate apply to
this header field as well; see Section 10.3.1 for details. this header field as well; see Section 10.3.1 for details.
10.3.3. Authentication-Info
HTTP authentication schemes can use the Authentication-Info response
header field to communicate information after the client's
authentication credentials have been accepted. This information can
include a finalization message from the server (e.g., it can contain
the server authentication).
The field value is a list of parameters (name/value pairs), using the
"auth-param" syntax defined in Section 8.5.1. This specification
only describes the generic format; authentication schemes using
Authentication-Info will define the individual parameters. The
"Digest" Authentication Scheme, for instance, defines multiple
parameters in Section 3.5 of [RFC7616].
Authentication-Info = #auth-param
The Authentication-Info header field can be used in any HTTP
response, independently of request method and status code. Its
semantics are defined by the authentication scheme indicated by the
Authorization header field (Section 8.5.3) of the corresponding
request.
A proxy forwarding a response is not allowed to modify the field
value in any way.
Authentication-Info can be used inside trailers (Section 7.1.2 of
[Messaging]) when the authentication scheme explicitly allows this.
10.3.3.1. Parameter Value Format
Parameter values can be expressed either as "token" or as "quoted-
string" (Section 4.2.3).
Authentication scheme definitions need to allow both notations, both
for senders and recipients. This allows recipients to use generic
parsing components, independent of the authentication scheme in use.
For backwards compatibility, authentication scheme definitions can
restrict the format for senders to one of the two variants. This can
be important when it is known that deployed implementations will fail
when encountering one of the two formats.
10.3.4. Proxy-Authentication-Info
The Proxy-Authentication-Info response header field is equivalent to
Authentication-Info, except that it applies to proxy authentication
(Section 8.5.1) and its semantics are defined by the authentication
scheme indicated by the Proxy-Authorization header field
(Section 8.5.4) of the corresponding request:
Proxy-Authentication-Info = #auth-param
However, unlike Authentication-Info, the Proxy-Authentication-Info
header field applies only to the next outbound client on the response
chain. This is because only the client that chose a given proxy is
likely to have the credentials necessary for authentication.
However, when multiple proxies are used within the same
administrative domain, such as office and regional caching proxies
within a large corporate network, it is common for credentials to be
generated by the user agent and passed through the hierarchy until
consumed. Hence, in such a configuration, it will appear as if
Proxy-Authentication-Info is being forwarded because each proxy will
send the same field value.
10.4. Response Context 10.4. Response Context
The remaining response header fields provide more information about The remaining response header fields provide more information about
the target resource for potential use in later requests. the target resource for potential use in later requests.
+-------------------+----------------+ +-------------------+----------------+
| Header Field Name | Defined in... | | Header Field Name | Defined in... |
+-------------------+----------------+ +-------------------+----------------+
| Accept-Ranges | Section 10.4.1 | | Accept-Ranges | Section 10.4.1 |
| Allow | Section 10.4.2 | | Allow | Section 10.4.2 |
skipping to change at page 153, line 7 skipping to change at page 155, line 30
of the response. In particular, when a redirect occurs and the of the response. In particular, when a redirect occurs and the
original request's fragment identifier is inherited by the new original request's fragment identifier is inherited by the new
reference in Location (Section 10.1.2), this might have the effect of reference in Location (Section 10.1.2), this might have the effect of
disclosing one site's fragment to another site. If the first site disclosing one site's fragment to another site. If the first site
uses personal information in fragments, it ought to ensure that uses personal information in fragments, it ought to ensure that
redirects to other sites include a (possibly empty) fragment redirects to other sites include a (possibly empty) fragment
component in order to block that inheritance. component in order to block that inheritance.
12.10. Disclosure of Product Information 12.10. Disclosure of Product Information
The User-Agent (Section 8.6.3), Via (Section 5.6.1), and Server The User-Agent (Section 8.6.3), Via (Section 5.5.1), and Server
(Section 10.4.3) header fields often reveal information about the (Section 10.4.3) header fields often reveal information about the
respective sender's software systems. In theory, this can make it respective sender's software systems. In theory, this can make it
easier for an attacker to exploit known security holes; in practice, easier for an attacker to exploit known security holes; in practice,
attackers tend to try all potential holes regardless of the apparent attackers tend to try all potential holes regardless of the apparent
software versions being used. software versions being used.
Proxies that serve as a portal through a network firewall ought to Proxies that serve as a portal through a network firewall ought to
take special precautions regarding the transfer of header information take special precautions regarding the transfer of header information
that might identify hosts behind the firewall. The Via header field that might identify hosts behind the firewall. The Via header field
allows intermediaries to replace sensitive machine names with allows intermediaries to replace sensitive machine names with
skipping to change at page 156, line 41 skipping to change at page 159, line 17
authentication credentials for other resources. authentication credentials for other resources.
This is of particular concern when an origin server hosts resources This is of particular concern when an origin server hosts resources
for multiple parties under the same canonical root URI for multiple parties under the same canonical root URI
(Section 8.5.2). Possible mitigation strategies include restricting (Section 8.5.2). Possible mitigation strategies include restricting
direct access to authentication credentials (i.e., not making the direct access to authentication credentials (i.e., not making the
content of the Authorization request header field available), and content of the Authorization request header field available), and
separating protection spaces by using a different host name (or port separating protection spaces by using a different host name (or port
number) for each party. number) for each party.
12.14.4. Additional Response Header Fields
Adding information to responses that are sent over an unencrypted
channel can affect security and privacy. The presence of the
Authentication-Info and Proxy-Authentication-Info header fields alone
indicates that HTTP authentication is in use. Additional information
could be exposed by the contents of the authentication-scheme
specific parameters; this will have to be considered in the
definitions of these schemes.
13. IANA Considerations 13. IANA Considerations
The change controller for the following registrations is: "IETF The change controller for the following registrations is: "IETF
(iesg@ietf.org) - Internet Engineering Task Force". (iesg@ietf.org) - Internet Engineering Task Force".
13.1. URI Scheme Registration 13.1. URI Scheme Registration
Please update the registry of URI Schemes [BCP35] at Please update the registry of URI Schemes [BCP35] at
<https://www.iana.org/assignments/uri-schemes/> with the permanent <https://www.iana.org/assignments/uri-schemes/> with the permanent
schemes listed in the first table of Section 2.5. schemes listed in the first table of Section 2.5.
skipping to change at page 157, line 19 skipping to change at page 160, line 5
registration procedure of Section 7.4.1 and the method names registration procedure of Section 7.4.1 and the method names
summarized in the table of Section 7.2. summarized in the table of Section 7.2.
13.3. Status Code Registration 13.3. Status Code Registration
Please update the "Hypertext Transfer Protocol (HTTP) Status Code Please update the "Hypertext Transfer Protocol (HTTP) Status Code
Registry" at <https://www.iana.org/assignments/http-status-codes> Registry" at <https://www.iana.org/assignments/http-status-codes>
with the registration procedure of Section 9.7.1 and the status code with the registration procedure of Section 9.7.1 and the status code
values summarized in the table of Section 9.1. values summarized in the table of Section 9.1.
Additionally, please update the following entry in the Hypertext
Transfer Protocol (HTTP) Status Code Registry:
Value: 418
Description: (Unused)
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 update the "Message Headers" registry of "Permanent Message
Header Field Names" at <https://www.iana.org/assignments/message- Header Field Names" at <https://www.iana.org/assignments/message-
headers> with the header field names listed in the table of headers> with the header field names listed in the table of
Section 4.1. Section 4.1.
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
skipping to change at page 158, line 10 skipping to change at page 161, line 10
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-02 (work in Ed., "HTTP Caching", draft-ietf-httpbis-cache-03 (work in
progress), July 2018. progress), October 2018.
[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-02 Ed., "HTTP/1.1 Messaging", draft-ietf-httpbis-messaging-03
(work in progress), July 2018. (work in progress), October 2018.
[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 160, line 14 skipping to change at page 163, line 14
[BCP35] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines [BCP35] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines
and Registration Procedures for URI Schemes", BCP 35, and Registration Procedures for URI Schemes", BCP 35,
RFC 7595, June 2015, RFC 7595, June 2015,
<https://www.rfc-editor.org/info/bcp35>. <https://www.rfc-editor.org/info/bcp35>.
[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864, Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004, <https://www.rfc-editor.org/info/bcp90>. September 2004, <https://www.rfc-editor.org/info/bcp90>.
[Err1912] RFC Errata, Erratum ID 1912, RFC 2978,
<https://www.rfc-editor.org/errata/eid1912>.
[Err5433] RFC Errata, Erratum ID 5433, RFC 2978,
<https://www.rfc-editor.org/errata/eid5433>.
[Georgiev] [Georgiev]
Georgiev, M., Iyengar, S., Jana, S., Anubhai, R., Boneh, Georgiev, M., Iyengar, S., Jana, S., Anubhai, R., Boneh,
D., and V. Shmatikov, "The Most Dangerous Code in the D., and V. Shmatikov, "The Most Dangerous Code in the
World: Validating SSL Certificates in Non-browser World: Validating SSL Certificates in Non-browser
Software", In Proceedings of the 2012 ACM Conference on Software", In Proceedings of the 2012 ACM Conference on
Computer and Communications Security (CCS '12), pp. 38-49, Computer and Communications Security (CCS '12), pp. 38-49,
October 2012, October 2012,
<http://doi.acm.org/10.1145/2382196.2382204>. <http://doi.acm.org/10.1145/2382196.2382204>.
[ISO-8859-1] [ISO-8859-1]
skipping to change at page 161, line 24 skipping to change at page 164, line 29
[RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use [RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use
and Interpretation of HTTP Version Numbers", RFC 2145, and Interpretation of HTTP Version Numbers", RFC 2145,
DOI 10.17487/RFC2145, May 1997, DOI 10.17487/RFC2145, May 1997,
<https://www.rfc-editor.org/info/rfc2145>. <https://www.rfc-editor.org/info/rfc2145>.
[RFC2295] Holtman, K. and A. Mutz, "Transparent Content Negotiation [RFC2295] Holtman, K. and A. Mutz, "Transparent Content Negotiation
in HTTP", RFC 2295, DOI 10.17487/RFC2295, March 1998, in HTTP", RFC 2295, DOI 10.17487/RFC2295, March 1998,
<https://www.rfc-editor.org/info/rfc2295>. <https://www.rfc-editor.org/info/rfc2295>.
[RFC2324] Masinter, L., "Hyper Text Coffee Pot Control Protocol
(HTCPCP/1.0)", RFC 2324, DOI 10.17487/RFC2324, April 1998,
<https://www.rfc-editor.org/info/rfc2324>.
[RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud, [RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud,
"MIME Encapsulation of Aggregate Documents, such as HTML "MIME Encapsulation of Aggregate Documents, such as HTML
(MHTML)", RFC 2557, DOI 10.17487/RFC2557, March 1999, (MHTML)", RFC 2557, DOI 10.17487/RFC2557, March 1999,
<https://www.rfc-editor.org/info/rfc2557>. <https://www.rfc-editor.org/info/rfc2557>.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, Transfer Protocol -- HTTP/1.1", RFC 2616,
DOI 10.17487/RFC2616, June 1999, DOI 10.17487/RFC2616, June 1999,
<https://www.rfc-editor.org/info/rfc2616>. <https://www.rfc-editor.org/info/rfc2616>.
skipping to change at page 163, line 38 skipping to change at page 166, line 46
<https://www.rfc-editor.org/info/rfc7235>. <https://www.rfc-editor.org/info/rfc7235>.
[RFC7538] Reschke, J., "The Hypertext Transfer Protocol Status Code [RFC7538] Reschke, J., "The Hypertext Transfer Protocol Status Code
308 (Permanent Redirect)", RFC 7538, DOI 10.17487/RFC7538, 308 (Permanent Redirect)", RFC 7538, DOI 10.17487/RFC7538,
April 2015, <https://www.rfc-editor.org/info/rfc7538>. April 2015, <https://www.rfc-editor.org/info/rfc7538>.
[RFC7578] Masinter, L., "Returning Values from Forms: multipart/ [RFC7578] Masinter, L., "Returning Values from Forms: multipart/
form-data", RFC 7578, DOI 10.17487/RFC7578, July 2015, form-data", RFC 7578, DOI 10.17487/RFC7578, July 2015,
<https://www.rfc-editor.org/info/rfc7578>. <https://www.rfc-editor.org/info/rfc7578>.
[RFC7615] Reschke, J., "HTTP Authentication-Info and Proxy-
Authentication-Info Response Header Fields", RFC 7615,
DOI 10.17487/RFC7615, September 2015,
<https://www.rfc-editor.org/info/rfc7615>.
[RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP [RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP
Digest Access Authentication", RFC 7616, Digest Access Authentication", RFC 7616,
DOI 10.17487/RFC7616, September 2015, DOI 10.17487/RFC7616, September 2015,
<https://www.rfc-editor.org/info/rfc7616>. <https://www.rfc-editor.org/info/rfc7616>.
[RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", [RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme",
RFC 7617, DOI 10.17487/RFC7617, September 2015, RFC 7617, DOI 10.17487/RFC7617, September 2015,
<https://www.rfc-editor.org/info/rfc7617>. <https://www.rfc-editor.org/info/rfc7617>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
skipping to change at page 165, line 20 skipping to change at page 168, line 20
Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [ Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
OWS ( media-range [ accept-params ] ) ] ) ] OWS ( media-range [ accept-params ] ) ] ) ]
Accept-Charset = *( "," OWS ) ( ( charset / "*" ) [ weight ] ) *( OWS Accept-Charset = *( "," OWS ) ( ( charset / "*" ) [ weight ] ) *( OWS
"," [ OWS ( ( charset / "*" ) [ weight ] ) ] ) "," [ OWS ( ( charset / "*" ) [ weight ] ) ] )
Accept-Encoding = [ ( "," / ( codings [ weight ] ) ) *( OWS "," [ OWS Accept-Encoding = [ ( "," / ( codings [ weight ] ) ) *( OWS "," [ OWS
( codings [ weight ] ) ] ) ] ( codings [ weight ] ) ] ) ]
Accept-Language = *( "," OWS ) ( language-range [ weight ] ) *( OWS Accept-Language = *( "," OWS ) ( language-range [ weight ] ) *( OWS
"," [ OWS ( language-range [ weight ] ) ] ) "," [ OWS ( language-range [ weight ] ) ] )
Accept-Ranges = acceptable-ranges Accept-Ranges = acceptable-ranges
Allow = [ ( "," / method ) *( OWS "," [ OWS method ] ) ] Allow = [ ( "," / method ) *( OWS "," [ OWS method ] ) ]
Authentication-Info = [ ( "," / auth-param ) *( OWS "," [ OWS
auth-param ] ) ]
Authorization = credentials Authorization = credentials
BWS = OWS BWS = OWS
Content-Encoding = *( "," OWS ) content-coding *( OWS "," [ OWS Content-Encoding = *( "," OWS ) content-coding *( OWS "," [ OWS
content-coding ] ) content-coding ] )
Content-Language = *( "," OWS ) language-tag *( OWS "," [ OWS Content-Language = *( "," OWS ) language-tag *( OWS "," [ OWS
language-tag ] ) language-tag ] )
Content-Length = 1*DIGIT Content-Length = 1*DIGIT
Content-Location = absolute-URI / partial-URI Content-Location = absolute-URI / partial-URI
skipping to change at page 166, line 4 skipping to change at page 169, line 7
Host = uri-host [ ":" port ] Host = uri-host [ ":" port ]
IMF-fixdate = day-name "," SP date1 SP time-of-day SP GMT IMF-fixdate = day-name "," SP date1 SP time-of-day SP GMT
If-Match = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS If-Match = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS
entity-tag ] ) ) entity-tag ] ) )
If-Modified-Since = HTTP-date If-Modified-Since = HTTP-date
If-None-Match = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS If-None-Match = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS
entity-tag ] ) ) entity-tag ] ) )
If-Range = entity-tag / HTTP-date If-Range = entity-tag / HTTP-date
If-Unmodified-Since = HTTP-date If-Unmodified-Since = HTTP-date
Last-Modified = HTTP-date Last-Modified = HTTP-date
Location = URI-reference Location = URI-reference
Max-Forwards = 1*DIGIT Max-Forwards = 1*DIGIT
OWS = *( SP / HTAB ) OWS = *( SP / HTAB )
Proxy-Authenticate = *( "," OWS ) challenge *( OWS "," [ OWS Proxy-Authenticate = *( "," OWS ) challenge *( OWS "," [ OWS
challenge ] ) challenge ] )
Proxy-Authentication-Info = [ ( "," / auth-param ) *( OWS "," [ OWS
auth-param ] ) ]
Proxy-Authorization = credentials Proxy-Authorization = credentials
RWS = 1*( SP / HTAB ) RWS = 1*( SP / HTAB )
Range = byte-ranges-specifier / other-ranges-specifier Range = byte-ranges-specifier / other-ranges-specifier
Referer = absolute-URI / partial-URI Referer = absolute-URI / partial-URI
Retry-After = HTTP-date / delay-seconds Retry-After = HTTP-date / delay-seconds
Server = product *( RWS ( product / comment ) ) Server = product *( RWS ( product / comment ) )
Trailer = *( "," OWS ) field-name *( OWS "," [ OWS field-name ] ) Trailer = *( "," OWS ) field-name *( OWS "," [ OWS field-name ] )
skipping to change at page 168, line 5 skipping to change at page 171, line 10
entity-tag = [ weak ] opaque-tag entity-tag = [ weak ] opaque-tag
etagc = "!" / %x23-7E ; '#'-'~' etagc = "!" / %x23-7E ; '#'-'~'
/ obs-text / obs-text
field-content = field-vchar [ 1*( SP / HTAB ) field-vchar ] field-content = field-vchar [ 1*( SP / HTAB ) field-vchar ]
field-name = token field-name = token
field-value = *( field-content / obs-fold ) field-value = *( field-content / obs-fold )
field-vchar = VCHAR / obs-text field-vchar = VCHAR / obs-text
first-byte-pos = 1*DIGIT first-byte-pos = 1*DIGIT
fragment = <fragment, see [RFC3986], Section 3.5>
hour = 2DIGIT hour = 2DIGIT
http-URI = "http://" authority path-abempty [ "?" query ] [ "#" http-URI = "http://" authority path-abempty [ "?" query ]
fragment ] https-URI = "https://" authority path-abempty [ "?" query ]
https-URI = "https://" authority path-abempty [ "?" query ] [ "#"
fragment ]
language-range = <language-range, see [RFC4647], Section 2.1> language-range = <language-range, see [RFC4647], Section 2.1>
language-tag = <Language-Tag, see [RFC5646], Section 2.1> language-tag = <Language-Tag, see [RFC5646], Section 2.1>
last-byte-pos = 1*DIGIT last-byte-pos = 1*DIGIT
mailbox = <mailbox, see [RFC5322], Section 3.4> mailbox = <mailbox, see [RFC5322], Section 3.4>
media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS
";" OWS parameter ) ";" OWS parameter )
media-type = type "/" subtype *( OWS ";" OWS parameter ) media-type = type "/" subtype *( OWS ";" OWS parameter )
method = token method = token
skipping to change at page 169, line 4 skipping to change at page 172, line 5
other-range-set = 1*VCHAR other-range-set = 1*VCHAR
other-range-unit = token other-range-unit = token
other-ranges-specifier = other-range-unit "=" other-range-set other-ranges-specifier = other-range-unit "=" other-range-set
parameter = token "=" ( token / quoted-string ) parameter = token "=" ( token / quoted-string )
partial-URI = relative-part [ "?" query ] partial-URI = relative-part [ "?" query ]
path-abempty = <path-abempty, see [RFC3986], Section 3.3> path-abempty = <path-abempty, see [RFC3986], Section 3.3>
port = <port, see [RFC3986], Section 3.2.3> port = <port, see [RFC3986], Section 3.2.3>
product = token [ "/" product-version ] product = token [ "/" product-version ]
product-version = token product-version = token
protocol-name = <protocol-name, see [Messaging], Section 9.7> protocol-name = <protocol-name, see [Messaging], Section 9.8>
protocol-version = <protocol-version, see [Messaging], Section 9.7> protocol-version = <protocol-version, see [Messaging], Section 9.8>
pseudonym = token pseudonym = token
qdtext = HTAB / SP / "!" / %x23-5B ; '#'-'[' qdtext = HTAB / SP / "!" / %x23-5B ; '#'-'['
/ %x5D-7E ; ']'-'~' / %x5D-7E ; ']'-'~'
/ obs-text / obs-text
query = <query, see [RFC3986], Section 3.4> query = <query, see [RFC3986], Section 3.4>
quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text ) quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] ) qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
skipping to change at page 170, line 5 skipping to change at page 173, line 5
year = 4DIGIT year = 4DIGIT
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:
Add status code 422 (previously defined in Section 11.2 of [RFC4918])
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. Change Log Appendix G. Changes from RFC 7615
None yet.
Appendix H. Change Log
This section is to be removed before publishing as an RFC. This section is to be removed before publishing as an RFC.
G.1. Between RFC723x and draft 00 H.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.
G.2. Since draft-ietf-httpbis-semantics-00 H.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 171, line 22 skipping to change at page 174, line 32
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.
G.3. Since draft-ietf-httpbis-semantics-01 H.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 172, line 42 skipping to change at page 176, line 5
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
o Included (Proxy-)Auth-Info header field definition from RFC 7615
(<https://github.com/httpwg/http-core/issues/9>)
o In Section 7.3.3, clarify POST caching
(<https://github.com/httpwg/http-core/issues/17>)
o Add Section 9.5.19 to reserve the 418 status code
(<https://github.com/httpwg/http-core/issues/43>)
o In Section 2.1 and Section 8.1.1, clarified when a response can be
sent (<https://github.com/httpwg/http-core/issues/82>)
o In Section 6.1.1.1, explain the difference between the "token"
production, the RFC 2978 ABNF for charset names, and the actual
registration practice (<https://github.com/httpwg/http-core/
issues/100>, <https://www.rfc-editor.org/errata/eid4689>)
o In Section 2.5, removed the fragment component in the URI scheme
definitions as per Section 4.3 of [RFC3986], furthermore moved
fragment discussion into a separate section
(<https://github.com/httpwg/http-core/issues/103>,
<https://www.rfc-editor.org/errata/eid4251>, <https://www.rfc-
editor.org/errata/eid4252>)
o In Section 3.5, add language about minor HTTP version number
defaulting (<https://github.com/httpwg/http-core/issues/115>)
o Added Section 9.5.20 for status code 422, previously defined in
Section 11.2 of [RFC4918] (<https://github.com/httpwg/http-core/
issues/123>)
o In Section 9.5.17, fixed prose about byte range comparison
(<https://github.com/httpwg/http-core/issues/135>,
<https://www.rfc-editor.org/errata/eid5474>)
o In Section 2.1, explain that request/response correlation is
version specific (<https://github.com/httpwg/http-core/
issues/145>)
Index Index
1 1
100 Continue (status code) 106 100 Continue (status code) 107
100-continue (expect value) 74 100-continue (expect value) 74
101 Switching Protocols (status code) 106 101 Switching Protocols (status code) 107
1xx Informational (status code class) 106 1xx Informational (status code class) 107
2 2
200 OK (status code) 107 200 OK (status code) 108
201 Created (status code) 108 201 Created (status code) 109
202 Accepted (status code) 108 202 Accepted (status code) 109
203 Non-Authoritative Information (status code) 108 203 Non-Authoritative Information (status code) 109
204 No Content (status code) 109 204 No Content (status code) 110
205 Reset Content (status code) 109 205 Reset Content (status code) 110
206 Partial Content (status code) 110 206 Partial Content (status code) 111
2xx Successful (status code class) 107 2xx Successful (status code class) 108
3 3
300 Multiple Choices (status code) 114 300 Multiple Choices (status code) 115
301 Moved Permanently (status code) 115 301 Moved Permanently (status code) 116
302 Found (status code) 116 302 Found (status code) 117
303 See Other (status code) 116 303 See Other (status code) 117
304 Not Modified (status code) 117 304 Not Modified (status code) 118
305 Use Proxy (status code) 117 305 Use Proxy (status code) 118
306 (Unused) (status code) 118 306 (Unused) (status code) 119
307 Temporary Redirect (status code) 118 307 Temporary Redirect (status code) 119
3xx Redirection (status code class) 113 3xx Redirection (status code class) 114
4 4
400 Bad Request (status code) 118 400 Bad Request (status code) 119
401 Unauthorized (status code) 118 401 Unauthorized (status code) 119
402 Payment Required (status code) 119 402 Payment Required (status code) 120
403 Forbidden (status code) 119 403 Forbidden (status code) 120
404 Not Found (status code) 119 404 Not Found (status code) 120
405 Method Not Allowed (status code) 120 405 Method Not Allowed (status code) 121
406 Not Acceptable (status code) 120 406 Not Acceptable (status code) 121
407 Proxy Authentication Required (status code) 120 407 Proxy Authentication Required (status code) 121
408 Request Timeout (status code) 120 408 Request Timeout (status code) 121
409 Conflict (status code) 121 409 Conflict (status code) 122
410 Gone (status code) 121 410 Gone (status code) 122
411 Length Required (status code) 121 411 Length Required (status code) 122
412 Precondition Failed (status code) 122 412 Precondition Failed (status code) 123
413 Payload Too Large (status code) 122 413 Payload Too Large (status code) 123
414 URI Too Long (status code) 122 414 URI Too Long (status code) 123
415 Unsupported Media Type (status code) 122 415 Unsupported Media Type (status code) 123
416 Range Not Satisfiable (status code) 123 416 Range Not Satisfiable (status code) 124
417 Expectation Failed (status code) 123 417 Expectation Failed (status code) 124
426 Upgrade Required (status code) 123 418 (Unused) (status code) 124
4xx Client Error (status code class) 118 422 Unprocessable Entity (status code) 125
426 Upgrade Required (status code) 125
4xx Client Error (status code class) 119
5 5
500 Internal Server Error (status code) 124 500 Internal Server Error (status code) 126
501 Not Implemented (status code) 124 501 Not Implemented (status code) 126
502 Bad Gateway (status code) 124 502 Bad Gateway (status code) 126
503 Service Unavailable (status code) 125 503 Service Unavailable (status code) 126
504 Gateway Timeout (status code) 125 504 Gateway Timeout (status code) 126
505 HTTP Version Not Supported (status code) 125 505 HTTP Version Not Supported (status code) 126
5xx Server Error (status code class) 124 5xx Server Error (status code class) 125
A A
Accept header field 88 Accept header field 89
Accept-Charset header field 90 Accept-Charset header field 91
Accept-Encoding header field 91 Accept-Encoding header field 92
Accept-Language header field 93 Accept-Language header field 94
Accept-Ranges header field 145 Accept-Ranges header field 147
Allow header field 145 Allow header field 148
Authorization header field 97 Authentication-Info header field 146
accelerator 12 Authorization header field 98
authoritative response 148 accelerator 13
authoritative response 150
B B
browser 10 browser 10
C C
CONNECT method 69 CONNECT method 70
Canonical Root URI 96 Canonical Root URI 97
Content-Encoding header field 46 Content-Encoding header field 47
Content-Language header field 47 Content-Language header field 48
Content-Length header field 48 Content-Length header field 49
Content-Location header field 49 Content-Location header field 50
Content-Range header field 53 Content-Range header field 54
Content-Type header field 45 Content-Type header field 46
cache 13 cache 14
cacheable 14, 62 cacheable 14, 63
captive portal 13 captive portal 14
client 10 client 10
compress (Coding Format) 40 compress (Coding Format) 41
compress (content coding) 40 compress (content coding) 40
conditional request 76 conditional request 77
connection 10 connection 10
content coding 40 content coding 40
content negotiation 8 content negotiation 8
D D
DELETE method 68 DELETE method 68
Date header field 130 Date header field 131
Delimiters 27 Delimiters 28
deflate (Coding Format) 40 deflate (Coding Format) 41
deflate (content coding) 40 deflate (content coding) 40
downstream 12 downstream 12
E E
ETag header field 139 ETag header field 140
Expect header field 74 Expect header field 74
effective request URI 31 effective request URI 32
F F
From header field 100 Fragment Identifiers 18
From header field 101
G G
GET method 63 GET method 64
Grammar Grammar
absolute-path 15 absolute-path 15
absolute-URI 15 absolute-URI 15
Accept 88 Accept 89
Accept-Charset 91 Accept-Charset 92
Accept-Encoding 91 Accept-Encoding 92
accept-ext 88 accept-ext 89
Accept-Language 93 Accept-Language 94
accept-params 88 accept-params 89
Accept-Ranges 145 Accept-Ranges 147
acceptable-ranges 145 acceptable-ranges 147
Allow 145 Allow 148
ALPHA 9 ALPHA 9
asctime-date 130 asctime-date 131
auth-param 95 auth-param 96
auth-scheme 95 auth-scheme 96
Authentication-Info 146
authority 15 authority 15
Authorization 97 Authorization 98
BWS 29 BWS 30
byte-content-range 53 byte-content-range 54
byte-range 53 byte-range 54
byte-range-resp 53 byte-range-resp 54
byte-range-set 43 byte-range-set 44
byte-range-spec 43 byte-range-spec 44
byte-ranges-specifier 43 byte-ranges-specifier 44
bytes-unit 42-43 bytes-unit 43
challenge 95 challenge 96
charset 38 charset 39
codings 91 codings 92
comment 28 comment 29
complete-length 53 complete-length 54
content-coding 40 content-coding 40
Content-Encoding 46 Content-Encoding 47
Content-Language 47 Content-Language 48
Content-Length 48 Content-Length 49
Content-Location 49 Content-Location 50
Content-Range 53 Content-Range 54
Content-Type 45 Content-Type 46
CR 9 CR 9
credentials 96 credentials 97
CRLF 9 CRLF 9
ctext 28 ctext 29
CTL 9 CTL 9
Date 130 Date 131
date1 129 date1 130
day 129 day 130
day-name 129 day-name 130
day-name-l 129 day-name-l 130
delay-seconds 133 delay-seconds 134
DIGIT 9 DIGIT 9
DQUOTE 9 DQUOTE 9
entity-tag 139 entity-tag 140
ETag 139 ETag 140
etagc 139 etagc 140
Expect 74 Expect 74
field-content 26 field-content 27
field-name 22, 30 field-name 23, 31
field-value 26 field-value 27
field-vchar 26 field-vchar 27
first-byte-pos 43 first-byte-pos 44
fragment 15 From 101
From 100 GMT 130
GMT 129
HEXDIG 9 HEXDIG 9
Host 32 Host 33
hour 129 hour 130
HTAB 9 HTAB 9
HTTP-date 127 HTTP-date 129
http-URI 16 http-URI 16
https-URI 17 https-URI 18
If-Match 80 If-Match 81
If-Modified-Since 82 If-Modified-Since 83
If-None-Match 81 If-None-Match 82
If-Range 85 If-Range 86
If-Unmodified-Since 83 If-Unmodified-Since 84
IMF-fixdate 129 IMF-fixdate 130
language-range 93 language-range 94
language-tag 42 language-tag 42
last-byte-pos 43 last-byte-pos 44
Last-Modified 137 Last-Modified 138
LF 9 LF 9
Location 131 Location 132
Max-Forwards 76 Max-Forwards 77
media-range 88 media-range 89
media-type 38 media-type 38
method 59 method 60
minute 129 minute 130
month 129 month 130
obs-date 129 obs-date 130
obs-text 28 obs-text 29
OCTET 9 OCTET 9
opaque-tag 139 opaque-tag 140
other-content-range 53 other-content-range 54
other-range-resp 53 other-range-resp 54
other-range-unit 42, 44 other-range-unit 43, 45
OWS 29 OWS 30
parameter 38 parameter 38
partial-URI 15 partial-URI 15
port 15 port 15
product 102 product 103
product-version 102 product-version 103
protocol-name 34 protocol-name 35
protocol-version 34 protocol-version 35
Proxy-Authenticate 144 Proxy-Authenticate 145
Proxy-Authorization 97 Proxy-Authentication-Info 147
pseudonym 34 Proxy-Authorization 98
qdtext 28 pseudonym 35
qdtext 29
query 15 query 15
quoted-pair 28 quoted-pair 29
quoted-string 28 quoted-string 29
qvalue 88 qvalue 89
Range 86 Range 87
range-unit 42 range-unit 43
ranges-specifier 43 ranges-specifier 44
received-by 34 received-by 35
received-protocol 34 received-protocol 35
Referer 101 Referer 102
Retry-After 133 Retry-After 134
rfc850-date 130 rfc850-date 131
RWS 29 RWS 30
second 129 second 130
segment 15 segment 15
Server 146 Server 148
SP 9 SP 9
subtype 38 subtype 38
suffix-byte-range-spec 43 suffix-byte-range-spec 44
suffix-length 43 suffix-length 44
tchar 27 tchar 28
time-of-day 129 time-of-day 130
token 27 token 28
token68 95 token68 96
Trailer 30 Trailer 31
type 38 type 38
unsatisfied-range 53 unsatisfied-range 54
uri-host 15 uri-host 15
URI-reference 15 URI-reference 15
User-Agent 102 User-Agent 103
Vary 133 Vary 134
VCHAR 9 VCHAR 9
Via 34 Via 35
weak 139 weak 140
weight 88 weight 89
WWW-Authenticate 143 WWW-Authenticate 144
year 129 year 130
gateway 12 gateway 13
gzip (Coding Format) 41 gzip (Coding Format) 41
gzip (content coding) 40 gzip (content coding) 40
H H
HEAD method 63 HEAD method 64
Host header field 32 Host header field 33
http URI scheme 16 http URI scheme 16
https URI scheme 17 https URI scheme 18
I I
If-Match header field 80 If-Match header field 81
If-Modified-Since header field 82 If-Modified-Since header field 83
If-None-Match header field 81 If-None-Match header field 82
If-Range header field 85 If-Range header field 85
If-Unmodified-Since header field 83 If-Unmodified-Since header field 84
idempotent 62 idempotent 63
inbound 12 inbound 12
interception proxy 13 interception proxy 14
intermediary 11 intermediary 12
L L
Last-Modified header field 137 Last-Modified header field 138
Location header field 131 Location header field 132
M M
Max-Forwards header field 76 Max-Forwards header field 77
Media Type Media Type
multipart/byteranges 55 multipart/byteranges 55
multipart/x-byteranges 55 multipart/x-byteranges 56
message 10 message 10
metadata 134 metadata 135
multipart/byteranges Media Type 55 multipart/byteranges Media Type 55
multipart/x-byteranges Media Type 55 multipart/x-byteranges Media Type 56
N N
non-transforming proxy 35 non-transforming proxy 36
O O
OPTIONS method 70 OPTIONS method 71
origin server 10 origin server 10
outbound 12 outbound 12
P P
POST method 64 POST method 65
PUT method 65 PUT method 66
Protection Space 96 Protection Space 97
Proxy-Authenticate header field 144 Proxy-Authenticate header field 145
Proxy-Authorization header field 97 Proxy-Authentication-Info header field 147
payload 51 Proxy-Authorization header field 98
phishing 148 payload 52
proxy 12 phishing 150
proxy 13
R R
Range header field 86 Range header field 87
Realm 96 Realm 97
Referer header field 101 Referer header field 102
Retry-After header field 132 Retry-After header field 133
recipient 10 recipient 10
representation 37 representation 37
request 10 request 10
resource 14 resource 15
response 10 response 10
reverse proxy 12 reverse proxy 13
S S
Server header field 146 Server header field 148
Status Codes Classes Status Codes Classes
1xx Informational 106 1xx Informational 107
2xx Successful 107 2xx Successful 108
3xx Redirection 113 3xx Redirection 114
4xx Client Error 118 4xx Client Error 119
5xx Server Error 124 5xx Server Error 125
safe 61 safe 62
selected representation 37, 77, 134 selected representation 37, 78, 135
sender 10 sender 10
server 10 server 10
spider 10 spider 10
T T
TRACE method 71 TRACE method 72
Trailer header field 30 Trailer header field 31
target URI 30 target URI 31
target resource 30 target resource 31
transforming proxy 35 transforming proxy 36
transparent proxy 13 transparent proxy 14
tunnel 13 tunnel 13
U U
URI scheme URI scheme
http 16 http 16
https 17 https 18
User-Agent header field 103
User-Agent header field 102
upstream 12 upstream 12
user agent 10 user agent 10
V V
Vary header field 133 Vary header field 134
Via header field 34 Via header field 34
validator 134 validator 135
strong 135 strong 136
weak 135 weak 136
W W
WWW-Authenticate header field 143 WWW-Authenticate header field 144
X X
x-compress (content coding) 40 x-compress (content coding) 40
x-gzip (content coding) 40 x-gzip (content coding) 40
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
 End of changes. 144 change blocks. 
612 lines changed or deleted 825 lines changed or added

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