draft-ietf-httpbis-semantics-02.txt   draft-ietf-httpbis-semantics-latest.txt 
HTTP Working Group R. Fielding, Ed. HTTP Working Group R. Fielding, Ed.
Internet-Draft Adobe Internet-Draft Adobe
Obsoletes: 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: February 10, 2019 greenbytes
July 2, 2018 August 9, 2018
HTTP Semantics HTTP Semantics
draft-ietf-httpbis-semantics-02 draft-ietf-httpbis-semantics-latest
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is a stateless application- The Hypertext Transfer Protocol (HTTP) is a stateless application-
level protocol for distributed, collaborative, hypertext information level protocol for distributed, collaborative, hypertext information
systems. This document defines the semantics of HTTP: its systems. This document defines the semantics of HTTP: its
architecture, terminology, the "http" and "https" Uniform Resource architecture, terminology, the "http" and "https" Uniform Resource
Identifier (URI) schemes, core request methods, request header Identifier (URI) schemes, core request methods, request header
fields, response status codes, response header fields, and content fields, response status codes, response header fields, and content
negotiation. negotiation.
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 February 10, 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 . . . . . . . . . . . . . . . . . . . . . 11
2.3. Caches . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3. Caches . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4. Uniform Resource Identifiers . . . . . . . . . . . . . . 14 2.4. Uniform Resource Identifiers . . . . . . . . . . . . . . 14
2.5. Resources . . . . . . . . . . . . . . . . . . . . . . . . 15 2.5. Resources . . . . . . . . . . . . . . . . . . . . . . . . 15
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 . . . . . . . . . . . . . . . . . . 17
2.5.3. http and https URI Normalization and Comparison . . . 18 2.5.3. http and https URI Normalization and Comparison . . . 18
3. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 18 3. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1. Implementation Diversity . . . . . . . . . . . . . . . . 18 3.1. Implementation Diversity . . . . . . . . . . . . . . . . 18
3.2. Role-based Requirements . . . . . . . . . . . . . . . . . 19 3.2. Role-based Requirements . . . . . . . . . . . . . . . . . 19
3.3. Parsing Elements . . . . . . . . . . . . . . . . . . . . 20 3.3. Parsing Elements . . . . . . . . . . . . . . . . . . . . 20
3.4. Error Handling . . . . . . . . . . . . . . . . . . . . . 20 3.4. Error Handling . . . . . . . . . . . . . . . . . . . . . 20
3.5. Protocol Versioning . . . . . . . . . . . . . . . . . . . 21 3.5. Protocol Versioning . . . . . . . . . . . . . . . . . . . 21
4. Message Abstraction . . . . . . . . . . . . . . . . . . . . . 22 4. Message Abstraction . . . . . . . . . . . . . . . . . . . . . 22
4.1. Field Names . . . . . . . . . . . . . . . . . . . . . . . 22 4.1. Field Names . . . . . . . . . . . . . . . . . . . . . . . 22
4.1.1. Field Name Registry . . . . . . . . . . . . . . . . . 24 4.1.1. Field Name Registry . . . . . . . . . . . . . . . . . 25
4.1.2. Field Extensibility . . . . . . . . . . . . . . . . . 24 4.1.2. Field Extensibility . . . . . . . . . . . . . . . . . 25
4.1.3. Considerations for New Fields . . . . . . . . . . . . 24 4.1.3. Considerations for New Fields . . . . . . . . . . . . 25
4.2. Field Values . . . . . . . . . . . . . . . . . . . . . . 26 4.2. Field Values . . . . . . . . . . . . . . . . . . . . . . 27
4.2.1. Field Order . . . . . . . . . . . . . . . . . . . . . 26 4.2.1. Field Order . . . . . . . . . . . . . . . . . . . . . 27
4.2.2. Field Limits . . . . . . . . . . . . . . . . . . . . 27 4.2.2. Field Limits . . . . . . . . . . . . . . . . . . . . 28
4.2.3. Field Value Components . . . . . . . . . . . . . . . 27 4.2.3. Field Value Components . . . . . . . . . . . . . . . 28
4.2.4. Designing New Field Values . . . . . . . . . . . . . 28 4.2.4. Designing New 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. Associating a Response to a Request . . . . . . . . . . . 34
5.6. Message Forwarding . . . . . . . . . . . . . . . . . . . 33 5.6. Message Forwarding . . . . . . . . . . . . . . . . . . . 34
5.6.1. Via . . . . . . . . . . . . . . . . . . . . . . . . . 34 5.6.1. Via . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.6.2. Transformations . . . . . . . . . . . . . . . . . . . 35 5.6.2. Transformations . . . . . . . . . . . . . . . . . . . 36
6. Representations . . . . . . . . . . . . . . . . . . . . . . . 37 6. Representations . . . . . . . . . . . . . . . . . . . . . . . 38
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 . . . . . . . . . . . . . . . . . . . 41
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 . . . . . . . . . . . 56
6.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 57 6.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 58
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 . . . . . . . . . . . . . . . . . . . . . . . 69
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 . . . . . . . . . . . . . . . . . . . . . . . 75
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 . . . . . . . . . . . . . . . . . . . . . . 86
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. 422 Unprocessable Entity . . . . . . . . . . . . . . 124
9.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 124 9.5.20. 426 Upgrade Required . . . . . . . . . . . . . . . . 125
9.6.1. 500 Internal Server Error . . . . . . . . . . . . . . 124 9.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 125
9.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 124 9.6.1. 500 Internal Server Error . . . . . . . . . . . . . . 125
9.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 124 9.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 125
9.6.4. 503 Service Unavailable . . . . . . . . . . . . . . . 125 9.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 126
9.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 125 9.6.4. 503 Service Unavailable . . . . . . . . . . . . . . . 126
9.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . 125 9.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 126
9.7. Status Code Extensibility . . . . . . . . . . . . . . . . 125 9.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . 126
9.7.1. Status Code Registry . . . . . . . . . . . . . . . . 125
9.7.2. Considerations for New Status Codes . . . . . . . . . 126
10. Response Header Fields . . . . . . . . . . . . . . . . . . . 127
10.1. Control Data . . . . . . . . . . . . . . . . . . . . . . 127
10.1.1. Origination Date . . . . . . . . . . . . . . . . . . 127
10.1.2. Location . . . . . . . . . . . . . . . . . . . . . . 131
10.1.3. Retry-After . . . . . . . . . . . . . . . . . . . . 132
10.1.4. Vary . . . . . . . . . . . . . . . . . . . . . . . . 133
10.2. Validators . . . . . . . . . . . . . . . . . . . . . . . 134
10.2.1. Weak versus Strong . . . . . . . . . . . . . . . . . 135
10.2.2. Last-Modified . . . . . . . . . . . . . . . . . . . 137
10.2.3. ETag . . . . . . . . . . . . . . . . . . . . . . . . 139
10.2.4. When to Use Entity-Tags and Last-Modified Dates . . 142
10.3. Authentication Challenges . . . . . . . . . . . . . . . 143
10.3.1. WWW-Authenticate . . . . . . . . . . . . . . . . . . 143
10.3.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . 144
10.4. Response Context . . . . . . . . . . . . . . . . . . . . 144
10.4.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . 145
10.4.2. Allow . . . . . . . . . . . . . . . . . . . . . . . 145
10.4.3. Server . . . . . . . . . . . . . . . . . . . . . . . 146
11. ABNF List Extension: #rule . . . . . . . . . . . . . . . . . 146
12. Security Considerations . . . . . . . . . . . . . . . . . . . 148
12.1. Establishing Authority . . . . . . . . . . . . . . . . . 148
12.2. Risks of Intermediaries . . . . . . . . . . . . . . . . 149
12.3. Attacks Based on File and Path Names . . . . . . . . . . 149
12.4. Attacks Based on Command, Code, or Query Injection . . . 150
12.5. Attacks via Protocol Element Length . . . . . . . . . . 151
12.6. Disclosure of Personal Information . . . . . . . . . . . 151
12.7. Privacy of Server Log Information . . . . . . . . . . . 151
12.8. Disclosure of Sensitive Information in URIs . . . . . . 152
12.9. Disclosure of Fragment after Redirects . . . . . . . . . 152
12.10. Disclosure of Product Information . . . . . . . . . . . 153
12.11. Browser Fingerprinting . . . . . . . . . . . . . . . . . 153
12.12. Validator Retention . . . . . . . . . . . . . . . . . . 154
12.13. Denial-of-Service Attacks Using Range . . . . . . . . . 154
12.14. Authentication Considerations . . . . . . . . . . . . . 155
12.14.1. Confidentiality of Credentials . . . . . . . . . . 155
12.14.2. Credentials and Idle Clients . . . . . . . . . . . 155
12.14.3. Protection Spaces . . . . . . . . . . . . . . . . . 156
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 156
13.1. URI Scheme Registration . . . . . . . . . . . . . . . . 156
13.2. Method Registration . . . . . . . . . . . . . . . . . . 157
13.3. Status Code Registration . . . . . . . . . . . . . . . . 157
13.4. Header Field Registration . . . . . . . . . . . . . . . 157
13.5. Authentication Scheme Registration . . . . . . . . . . . 157
13.6. Content Coding Registration . . . . . . . . . . . . . . 157
13.7. Range Unit Registration . . . . . . . . . . . . . . . . 157
13.8. Media Type Registration . . . . . . . . . . . . . . . . 157
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 158 9.7. Status Code Extensibility . . . . . . . . . . . . . . . . 126
14.1. Normative References . . . . . . . . . . . . . . . . . . 158 9.7.1. Status Code Registry . . . . . . . . . . . . . . . . 127
14.2. Informative References . . . . . . . . . . . . . . . . . 159 9.7.2. Considerations for New Status Codes . . . . . . . . . 127
Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 165 10. Response Header Fields . . . . . . . . . . . . . . . . . . . 128
Appendix B. Changes from RFC 7230 . . . . . . . . . . . . . . . 169 10.1. Control Data . . . . . . . . . . . . . . . . . . . . . . 128
Appendix C. Changes from RFC 7231 . . . . . . . . . . . . . . . 170 10.1.1. Origination Date . . . . . . . . . . . . . . . . . . 128
Appendix D. Changes from RFC 7232 . . . . . . . . . . . . . . . 170 10.1.2. Location . . . . . . . . . . . . . . . . . . . . . . 132
Appendix E. Changes from RFC 7233 . . . . . . . . . . . . . . . 170 10.1.3. Retry-After . . . . . . . . . . . . . . . . . . . . 133
Appendix F. Changes from RFC 7235 . . . . . . . . . . . . . . . 170 10.1.4. Vary . . . . . . . . . . . . . . . . . . . . . . . . 134
Appendix G. Change Log . . . . . . . . . . . . . . . . . . . . . 170 10.2. Validators . . . . . . . . . . . . . . . . . . . . . . . 135
G.1. Between RFC723x and draft 00 . . . . . . . . . . . . . . 170 10.2.1. Weak versus Strong . . . . . . . . . . . . . . . . . 136
G.2. Since draft-ietf-httpbis-semantics-00 . . . . . . . . . . 170 10.2.2. Last-Modified . . . . . . . . . . . . . . . . . . . 138
G.3. Since draft-ietf-httpbis-semantics-01 . . . . . . . . . . 171 10.2.3. ETag . . . . . . . . . . . . . . . . . . . . . . . . 140
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 10.2.4. When to Use Entity-Tags and Last-Modified Dates . . 143
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 180 10.3. Authentication Challenges . . . . . . . . . . . . . . . 144
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 180 10.3.1. WWW-Authenticate . . . . . . . . . . . . . . . . . . 144
10.3.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . 145
10.3.3. Authentication-Info . . . . . . . . . . . . . . . . 146
10.3.4. Proxy-Authentication-Info . . . . . . . . . . . . . 147
10.4. Response Context . . . . . . . . . . . . . . . . . . . . 147
10.4.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . 147
10.4.2. Allow . . . . . . . . . . . . . . . . . . . . . . . 148
10.4.3. Server . . . . . . . . . . . . . . . . . . . . . . . 148
11. ABNF List Extension: #rule . . . . . . . . . . . . . . . . . 149
12. Security Considerations . . . . . . . . . . . . . . . . . . . 150
12.1. Establishing Authority . . . . . . . . . . . . . . . . . 150
12.2. Risks of Intermediaries . . . . . . . . . . . . . . . . 151
12.3. Attacks Based on File and Path Names . . . . . . . . . . 152
12.4. Attacks Based on Command, Code, or Query Injection . . . 152
12.5. Attacks via Protocol Element Length . . . . . . . . . . 153
12.6. Disclosure of Personal Information . . . . . . . . . . . 154
12.7. Privacy of Server Log Information . . . . . . . . . . . 154
12.8. Disclosure of Sensitive Information in URIs . . . . . . 154
12.9. Disclosure of Fragment after Redirects . . . . . . . . . 155
12.10. Disclosure of Product Information . . . . . . . . . . . 155
12.11. Browser Fingerprinting . . . . . . . . . . . . . . . . . 155
12.12. Validator Retention . . . . . . . . . . . . . . . . . . 156
12.13. Denial-of-Service Attacks Using Range . . . . . . . . . 157
12.14. Authentication Considerations . . . . . . . . . . . . . 157
12.14.1. Confidentiality of Credentials . . . . . . . . . . 157
12.14.2. Credentials and Idle Clients . . . . . . . . . . . 158
12.14.3. Protection Spaces . . . . . . . . . . . . . . . . . 158
12.14.4. Additional Response Header Fields . . . . . . . . . 159
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 159
13.1. URI Scheme Registration . . . . . . . . . . . . . . . . 159
13.2. Method Registration . . . . . . . . . . . . . . . . . . 159
13.3. Status Code Registration . . . . . . . . . . . . . . . . 159
13.4. Header Field Registration . . . . . . . . . . . . . . . 160
13.5. Authentication Scheme Registration . . . . . . . . . . . 160
13.6. Content Coding Registration . . . . . . . . . . . . . . 160
13.7. Range Unit Registration . . . . . . . . . . . . . . . . 160
13.8. Media Type Registration . . . . . . . . . . . . . . . . 160
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 160
14.1. Normative References . . . . . . . . . . . . . . . . . . 160
14.2. Informative References . . . . . . . . . . . . . . . . . 162
Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 168
Appendix B. Changes from RFC 7230 . . . . . . . . . . . . . . . 173
Appendix C. Changes from RFC 7231 . . . . . . . . . . . . . . . 173
Appendix D. Changes from RFC 7232 . . . . . . . . . . . . . . . 173
Appendix E. Changes from RFC 7233 . . . . . . . . . . . . . . . 173
Appendix F. Changes from RFC 7235 . . . . . . . . . . . . . . . 173
Appendix G. Changes from RFC 7615 . . . . . . . . . . . . . . . 173
Appendix H. Change Log . . . . . . . . . . . . . . . . . . . . . 173
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 184
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 184
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 22, line 15 skipping to change at page 22, line 22
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.
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.6.1 |
| WWW-Authenticate | http | standard | Section 10.3.1 |
+---------------------------+----------+----------+-----------------+
4.1.1. Field Name Registry 4.1.1. 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. Field Extensibility
Header fields are fully extensible: there is no limit on the Header fields are fully extensible: there is no limit on the
skipping to change at page 26, line 20 skipping to change at page 27, line 20
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
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 48, line 12 skipping to change at page 49, line 12
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 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 | | 422 | Unprocessable Entity | Section 9.5.19 |
| 426 | Upgrade Required | Section 9.5.20 |
| 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 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. 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.20. 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.7 of
[Messaging]). [Messaging]).
Example: Example:
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 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 158, line 10 skipping to change at page 160, line 45
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-latest (work
progress), July 2018. in progress), August 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-
(work in progress), July 2018. latest (work in progress), August 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 163, line 38 skipping to change at page 166, line 28
<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 170, line 5 skipping to change at page 173, line 12
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.19)
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 39
o Merged entire content of RFC 7233 (Range Requests). o Merged entire content of RFC 7233 (Range Requests).
o Merged entire content of RFC 7235 (Auth Framework). o Merged entire content of RFC 7235 (Auth Framework).
o Moved all extensibility tips, registration procedures, and o Moved all extensibility tips, registration procedures, and
registry tables from the IANA considerations to normative registry tables from the IANA considerations to normative
sections, reducing the IANA considerations to just instructions sections, reducing the IANA considerations to just instructions
that will be removed prior to publication as an RFC. that will be removed prior to publication as an RFC.
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 10
o In Section 11, fixed an example that had trailing whitespace where o In Section 11, fixed an example that had trailing whitespace where
it shouldn't (<https://github.com/httpwg/http-core/issues/104>, it shouldn't (<https://github.com/httpwg/http-core/issues/104>,
<https://www.rfc-editor.org/errata/eid4169>) <https://www.rfc-editor.org/errata/eid4169>)
o In Section 9.3.7, remove words that were potentially misleading o In Section 9.3.7, remove words that were potentially misleading
with respect to the relation to the requested ranges with respect to the relation to the requested ranges
(<https://github.com/httpwg/http-core/issues/102>, (<https://github.com/httpwg/http-core/issues/102>,
<https://www.rfc-editor.org/errata/eid4358>) <https://www.rfc-editor.org/errata/eid4358>)
H.4. Since draft-ietf-httpbis-semantics-02
o Included (Proxy-)Auth-Info header field definition from RFC 7615
(<https://github.com/httpwg/http-core/issues/9>)
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.19 for status code 422, previously defined in
Section 11.2 of [RFC4918] (<https://github.com/httpwg/http-core/
issues/123>)
Index Index
1 1
100 Continue (status code) 106 100 Continue (status code) 107
100-continue (expect value) 74 100-continue (expect value) 75
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 422 Unprocessable Entity (status code) 124
4xx Client Error (status code class) 118 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) 125
501 Not Implemented (status code) 124 501 Not Implemented (status code) 125
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
Authorization header field 98
accelerator 12 accelerator 12
authoritative response 148 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 13
client 10 client 10
compress (Coding Format) 40 compress (Coding Format) 41
compress (content coding) 40 compress (content coding) 41
conditional request 76 conditional request 77
connection 10 connection 10
content coding 40 content coding 41
content negotiation 8 content negotiation 8
D D
DELETE method 68 DELETE method 69
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) 41
downstream 12 downstream 12
E E
ETag header field 139 ETag header field 140
Expect header field 74 Expect header field 75
effective request URI 31 effective request URI 32
F F
From header field 100 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-44
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 41
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 75
field-content 26 field-content 27
field-name 22, 30 field-name 22, 31
field-value 26 field-value 27
field-vchar 26 field-vchar 27
first-byte-pos 43 first-byte-pos 44
fragment 15 fragment 15
From 100 From 101
GMT 129 GMT 130
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 43
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 39
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 39
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 39
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 39
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 12
gzip (Coding Format) 41 gzip (Coding Format) 42
gzip (content coding) 40 gzip (content coding) 41
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 17
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 86
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 13
intermediary 11 intermediary 11
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 56
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 56
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
phishing 150
proxy 12 proxy 12
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 38
request 10 request 10
resource 14 resource 14
response 10 response 10
reverse proxy 12 reverse proxy 12
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 38, 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 13
tunnel 13 tunnel 13
U U
URI scheme URI scheme
http 16 http 16
https 17 https 17
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 35
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) 41
x-gzip (content coding) 40 x-gzip (content coding) 41
Acknowledgments Acknowledgments
This edition of the HTTP specification builds on the many This edition of the HTTP specification builds on the many
contributions that went into RFC 1945, RFC 2068, RFC 2145, and RFC contributions that went into RFC 1945, RFC 2068, RFC 2145, and RFC
2616, including substantial contributions made by the previous 2616, including substantial contributions made by the previous
authors, editors, and Working Group Chairs: Tim Berners-Lee, Ari authors, editors, and Working Group Chairs: Tim Berners-Lee, Ari
Luotonen, Roy T. Fielding, Henrik Frystyk Nielsen, Jim Gettys, Luotonen, Roy T. Fielding, Henrik Frystyk Nielsen, Jim Gettys,
Jeffrey C. Mogul, Larry Masinter, Paul J. Leach, and Yves Lafon. Jeffrey C. Mogul, Larry Masinter, Paul J. Leach, and Yves Lafon.
 End of changes. 87 change blocks. 
526 lines changed or deleted 674 lines changed or added

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