draft-ietf-httpbis-semantics-07.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: M. Nottingham, Ed. Obsoletes: 2818,7230,7231,7232,7233,7235 M. Nottingham, Ed.
2818,7230,7231,7232,7233,7235 Fastly ,7538,7615,7694 (if approved) Fastly
,7538,7615 (if approved) J. Reschke, Ed. Intended status: Standards Track J. Reschke, Ed.
Intended status: Standards Track greenbytes Expires: October 1, 2020 greenbytes
Expires: September 8, 2020 March 7, 2020 March 30, 2020
HTTP Semantics HTTP Semantics
draft-ietf-httpbis-semantics-07 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 2818, RFC 7231, RFC 7232, RFC 7233, RFC This document obsoletes RFC 2818, RFC 7231, RFC 7232, RFC 7233, RFC
7235, RFC 7538, RFC 7615, and portions of RFC 7230. 7235, RFC 7538, RFC 7615, RFC 7694, and portions of RFC 7230.
Editorial Note Editorial Note
This note is to be removed before publishing as an RFC. This note is to be removed before publishing as an RFC.
Discussion of this draft takes place on the HTTP working group Discussion of this draft takes place on the HTTP working group
mailing list (ietf-http-wg@w3.org), which is archived at mailing list (ietf-http-wg@w3.org), which is archived at
<https://lists.w3.org/Archives/Public/ietf-http-wg/>. <https://lists.w3.org/Archives/Public/ietf-http-wg/>.
Working Group information can be found at <https://httpwg.org/>; Working Group information can be found at <https://httpwg.org/>;
source code and issues list for this draft can be found at source code and issues list for this draft can be found at
<https://github.com/httpwg/http-core>. <https://github.com/httpwg/http-core>.
The changes in this draft are summarized in Appendix C.8. The changes in this draft are summarized in Appendix D.9.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 8, 2020. This Internet-Draft will expire on October 1, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 16 skipping to change at page 4, line 16
6.2.5. Content-Location . . . . . . . . . . . . . . . . . . 62 6.2.5. Content-Location . . . . . . . . . . . . . . . . . . 62
6.3. Payload . . . . . . . . . . . . . . . . . . . . . . . . . 64 6.3. Payload . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.3.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 64 6.3.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 64
6.3.2. Identification . . . . . . . . . . . . . . . . . . . 65 6.3.2. Identification . . . . . . . . . . . . . . . . . . . 65
6.3.3. Payload Body . . . . . . . . . . . . . . . . . . . . 66 6.3.3. Payload Body . . . . . . . . . . . . . . . . . . . . 66
6.3.4. Content-Range . . . . . . . . . . . . . . . . . . . . 66 6.3.4. Content-Range . . . . . . . . . . . . . . . . . . . . 66
6.3.5. Media Type multipart/byteranges . . . . . . . . . . . 68 6.3.5. Media Type multipart/byteranges . . . . . . . . . . . 68
6.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 70 6.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 70
6.4.1. Proactive Negotiation . . . . . . . . . . . . . . . . 71 6.4.1. Proactive Negotiation . . . . . . . . . . . . . . . . 71
6.4.2. Reactive Negotiation . . . . . . . . . . . . . . . . 72 6.4.2. Reactive Negotiation . . . . . . . . . . . . . . . . 72
7. Request Methods . . . . . . . . . . . . . . . . . . . . . . . 73 6.4.3. Request Payload Negotiation . . . . . . . . . . . . . 73
7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 73 6.4.4. Quality Values . . . . . . . . . . . . . . . . . . . 73
7.2. Common Method Properties . . . . . . . . . . . . . . . . 74 7. Request Methods . . . . . . . . . . . . . . . . . . . . . . . 74
7.2.1. Safe Methods . . . . . . . . . . . . . . . . . . . . 75 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 74
7.2.2. Idempotent Methods . . . . . . . . . . . . . . . . . 76 7.2. Common Method Properties . . . . . . . . . . . . . . . . 75
7.2.3. Methods and Caching . . . . . . . . . . . . . . . . . 77 7.2.1. Safe Methods . . . . . . . . . . . . . . . . . . . . 76
7.3. Method Definitions . . . . . . . . . . . . . . . . . . . 77 7.2.2. Idempotent Methods . . . . . . . . . . . . . . . . . 77
7.3.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 77 7.2.3. Methods and Caching . . . . . . . . . . . . . . . . . 78
7.3.2. HEAD . . . . . . . . . . . . . . . . . . . . . . . . 78 7.3. Method Definitions . . . . . . . . . . . . . . . . . . . 78
7.3.3. POST . . . . . . . . . . . . . . . . . . . . . . . . 79 7.3.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 78
7.3.4. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 80 7.3.2. HEAD . . . . . . . . . . . . . . . . . . . . . . . . 79
7.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . 82 7.3.3. POST . . . . . . . . . . . . . . . . . . . . . . . . 80
7.3.6. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 83 7.3.4. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 81
7.3.7. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 85 7.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . 83
7.3.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . 86 7.3.6. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 84
7.4. Method Extensibility . . . . . . . . . . . . . . . . . . 86 7.3.7. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 86
7.4.1. Method Registry . . . . . . . . . . . . . . . . . . . 86 7.3.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . 87
7.4.2. Considerations for New Methods . . . . . . . . . . . 87 7.4. Method Extensibility . . . . . . . . . . . . . . . . . . 87
8. Request Header Fields . . . . . . . . . . . . . . . . . . . . 87 7.4.1. Method Registry . . . . . . . . . . . . . . . . . . . 87
8.1. Controls . . . . . . . . . . . . . . . . . . . . . . . . 88 7.4.2. Considerations for New Methods . . . . . . . . . . . 88
8.1.1. Expect . . . . . . . . . . . . . . . . . . . . . . . 88 8. Request Header Fields . . . . . . . . . . . . . . . . . . . . 88
8.1.2. Max-Forwards . . . . . . . . . . . . . . . . . . . . 90 8.1. Controls . . . . . . . . . . . . . . . . . . . . . . . . 89
8.2. Preconditions . . . . . . . . . . . . . . . . . . . . . . 91 8.1.1. Expect . . . . . . . . . . . . . . . . . . . . . . . 89
8.2.1. Evaluation . . . . . . . . . . . . . . . . . . . . . 92 8.1.2. Max-Forwards . . . . . . . . . . . . . . . . . . . . 91
8.2.2. Precedence . . . . . . . . . . . . . . . . . . . . . 93 8.2. Preconditions . . . . . . . . . . . . . . . . . . . . . . 92
8.2.3. If-Match . . . . . . . . . . . . . . . . . . . . . . 95 8.2.1. Evaluation . . . . . . . . . . . . . . . . . . . . . 93
8.2.4. If-None-Match . . . . . . . . . . . . . . . . . . . . 96 8.2.2. Precedence . . . . . . . . . . . . . . . . . . . . . 94
8.2.5. If-Modified-Since . . . . . . . . . . . . . . . . . . 97 8.2.3. If-Match . . . . . . . . . . . . . . . . . . . . . . 96
8.2.6. If-Unmodified-Since . . . . . . . . . . . . . . . . . 98 8.2.4. If-None-Match . . . . . . . . . . . . . . . . . . . . 97
8.2.7. If-Range . . . . . . . . . . . . . . . . . . . . . . 100 8.2.5. If-Modified-Since . . . . . . . . . . . . . . . . . . 98
8.3. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 101 8.2.6. If-Unmodified-Since . . . . . . . . . . . . . . . . . 99
8.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 102 8.2.7. If-Range . . . . . . . . . . . . . . . . . . . . . . 101
8.4.1. Quality Values . . . . . . . . . . . . . . . . . . . 103 8.3. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 102
8.4.2. Accept . . . . . . . . . . . . . . . . . . . . . . . 104 8.4. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 103
8.4.3. Accept-Charset . . . . . . . . . . . . . . . . . . . 106 8.4.1. Accept . . . . . . . . . . . . . . . . . . . . . . . 104
8.4.4. Accept-Encoding . . . . . . . . . . . . . . . . . . . 107 8.4.2. Accept-Charset . . . . . . . . . . . . . . . . . . . 106
8.4.5. Accept-Language . . . . . . . . . . . . . . . . . . . 108 8.4.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . 107
8.5. Authentication Credentials . . . . . . . . . . . . . . . 109 8.4.4. Accept-Language . . . . . . . . . . . . . . . . . . . 109
8.5.1. Challenge and Response . . . . . . . . . . . . . . . 109 8.5. Authentication Credentials . . . . . . . . . . . . . . . 110
8.5.2. Protection Space (Realm) . . . . . . . . . . . . . . 111 8.5.1. Challenge and Response . . . . . . . . . . . . . . . 110
8.5.3. Authorization . . . . . . . . . . . . . . . . . . . . 112 8.5.2. Protection Space (Realm) . . . . . . . . . . . . . . 112
8.5.4. Proxy-Authorization . . . . . . . . . . . . . . . . . 112 8.5.3. Authorization . . . . . . . . . . . . . . . . . . . . 113
8.5.5. Authentication Scheme Extensibility . . . . . . . . . 113 8.5.4. Proxy-Authorization . . . . . . . . . . . . . . . . . 113
8.6. Request Context . . . . . . . . . . . . . . . . . . . . . 115 8.5.5. Authentication Scheme Extensibility . . . . . . . . . 114
8.6.1. From . . . . . . . . . . . . . . . . . . . . . . . . 115 8.6. Request Context . . . . . . . . . . . . . . . . . . . . . 116
8.6.2. Referer . . . . . . . . . . . . . . . . . . . . . . . 116 8.6.1. From . . . . . . . . . . . . . . . . . . . . . . . . 116
8.6.3. User-Agent . . . . . . . . . . . . . . . . . . . . . 117 8.6.2. Referer . . . . . . . . . . . . . . . . . . . . . . . 117
9. Response Status Codes . . . . . . . . . . . . . . . . . . . . 118 8.6.3. User-Agent . . . . . . . . . . . . . . . . . . . . . 118
9.1. Overview of Status Codes . . . . . . . . . . . . . . . . 119 9. Response Status Codes . . . . . . . . . . . . . . . . . . . . 119
9.2. Informational 1xx . . . . . . . . . . . . . . . . . . . . 120 9.1. Overview of Status Codes . . . . . . . . . . . . . . . . 120
9.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 121 9.2. Informational 1xx . . . . . . . . . . . . . . . . . . . . 121
9.2.2. 101 Switching Protocols . . . . . . . . . . . . . . . 121 9.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 122
9.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . 121 9.2.2. 101 Switching Protocols . . . . . . . . . . . . . . . 122
9.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 121 9.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . 122
9.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 122 9.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 122
9.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . 122 9.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 123
9.3.4. 203 Non-Authoritative Information . . . . . . . . . . 123 9.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . 123
9.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . 123 9.3.4. 203 Non-Authoritative Information . . . . . . . . . . 124
9.3.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 124 9.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . 124
9.3.7. 206 Partial Content . . . . . . . . . . . . . . . . . 124 9.3.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 125
9.4. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 127 9.3.7. 206 Partial Content . . . . . . . . . . . . . . . . . 125
9.4.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 129 9.4. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 129
9.4.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 130 9.4.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 130
9.4.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 130 9.4.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 131
9.4.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 131 9.4.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 131
9.4.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 131 9.4.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 132
9.4.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 132 9.4.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 132
9.4.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . 132 9.4.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 133
9.4.8. 307 Temporary Redirect . . . . . . . . . . . . . . . 132 9.4.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . 133
9.4.9. 308 Permanent Redirect . . . . . . . . . . . . . . . 133 9.4.8. 307 Temporary Redirect . . . . . . . . . . . . . . . 133
9.5. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 133 9.4.9. 308 Permanent Redirect . . . . . . . . . . . . . . . 134
9.5.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 133 9.5. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 134
9.5.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 133 9.5.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 134
9.5.3. 402 Payment Required . . . . . . . . . . . . . . . . 134 9.5.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 134
9.5.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 134 9.5.3. 402 Payment Required . . . . . . . . . . . . . . . . 135
9.5.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 134 9.5.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 135
9.5.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 135 9.5.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 135
9.5.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 135 9.5.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 136
9.5.8. 407 Proxy Authentication Required . . . . . . . . . . 135 9.5.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 136
9.5.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 135 9.5.8. 407 Proxy Authentication Required . . . . . . . . . . 136
9.5.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . 136 9.5.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 136
9.5.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 136 9.5.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . 137
9.5.12. 411 Length Required . . . . . . . . . . . . . . . . . 136 9.5.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 137
9.5.13. 412 Precondition Failed . . . . . . . . . . . . . . . 137 9.5.12. 411 Length Required . . . . . . . . . . . . . . . . . 137
9.5.14. 413 Payload Too Large . . . . . . . . . . . . . . . . 137 9.5.13. 412 Precondition Failed . . . . . . . . . . . . . . . 138
9.5.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . 137 9.5.14. 413 Payload Too Large . . . . . . . . . . . . . . . . 138
9.5.16. 415 Unsupported Media Type . . . . . . . . . . . . . 137 9.5.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . 138
9.5.17. 416 Range Not Satisfiable . . . . . . . . . . . . . . 138 9.5.16. 415 Unsupported Media Type . . . . . . . . . . . . . 138
9.5.18. 417 Expectation Failed . . . . . . . . . . . . . . . 138 9.5.17. 416 Range Not Satisfiable . . . . . . . . . . . . . . 139
9.5.19. 418 (Unused) . . . . . . . . . . . . . . . . . . . . 138 9.5.18. 417 Expectation Failed . . . . . . . . . . . . . . . 139
9.5.20. 422 Unprocessable Payload . . . . . . . . . . . . . . 139 9.5.19. 418 (Unused) . . . . . . . . . . . . . . . . . . . . 139
9.5.21. 426 Upgrade Required . . . . . . . . . . . . . . . . 139 9.5.20. 422 Unprocessable Payload . . . . . . . . . . . . . . 140
9.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 139 9.5.21. 426 Upgrade Required . . . . . . . . . . . . . . . . 140
9.6.1. 500 Internal Server Error . . . . . . . . . . . . . . 140 9.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 140
9.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 140 9.6.1. 500 Internal Server Error . . . . . . . . . . . . . . 141
9.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 140 9.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 141
9.6.4. 503 Service Unavailable . . . . . . . . . . . . . . . 140 9.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 141
9.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 140 9.6.4. 503 Service Unavailable . . . . . . . . . . . . . . . 141
9.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . 140 9.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 141
9.7. Status Code Extensibility . . . . . . . . . . . . . . . . 141 9.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . 141
9.7.1. Status Code Registry . . . . . . . . . . . . . . . . 141 9.7. Status Code Extensibility . . . . . . . . . . . . . . . . 142
9.7.2. Considerations for New Status Codes . . . . . . . . . 141 9.7.1. Status Code Registry . . . . . . . . . . . . . . . . 142
10. Response Header Fields . . . . . . . . . . . . . . . . . . . 142 9.7.2. Considerations for New Status Codes . . . . . . . . . 142
10.1. Control Data . . . . . . . . . . . . . . . . . . . . . . 142 10. Response Header Fields . . . . . . . . . . . . . . . . . . . 143
10.1.1. Origination Date . . . . . . . . . . . . . . . . . . 143 10.1. Control Data . . . . . . . . . . . . . . . . . . . . . . 143
10.1.2. Location . . . . . . . . . . . . . . . . . . . . . . 146 10.1.1. Origination Date . . . . . . . . . . . . . . . . . . 144
10.1.3. Retry-After . . . . . . . . . . . . . . . . . . . . 147 10.1.2. Location . . . . . . . . . . . . . . . . . . . . . . 147
10.1.4. Vary . . . . . . . . . . . . . . . . . . . . . . . . 147 10.1.3. Retry-After . . . . . . . . . . . . . . . . . . . . 148
10.2. Validators . . . . . . . . . . . . . . . . . . . . . . . 149 10.1.4. Vary . . . . . . . . . . . . . . . . . . . . . . . . 148
10.2.1. Weak versus Strong . . . . . . . . . . . . . . . . . 150 10.2. Validators . . . . . . . . . . . . . . . . . . . . . . . 150
10.2.2. Last-Modified . . . . . . . . . . . . . . . . . . . 151 10.2.1. Weak versus Strong . . . . . . . . . . . . . . . . . 151
10.2.3. ETag . . . . . . . . . . . . . . . . . . . . . . . . 153 10.2.2. Last-Modified . . . . . . . . . . . . . . . . . . . 152
10.2.4. When to Use Entity-Tags and Last-Modified Dates . . 157 10.2.3. ETag . . . . . . . . . . . . . . . . . . . . . . . . 154
10.3. Authentication Challenges . . . . . . . . . . . . . . . 157 10.2.4. When to Use Entity-Tags and Last-Modified Dates . . 158
10.3.1. WWW-Authenticate . . . . . . . . . . . . . . . . . . 158 10.3. Authentication Challenges . . . . . . . . . . . . . . . 158
10.3.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . 159 10.3.1. WWW-Authenticate . . . . . . . . . . . . . . . . . . 159
10.3.3. Authentication-Info . . . . . . . . . . . . . . . . 159 10.3.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . 160
10.3.4. Proxy-Authentication-Info . . . . . . . . . . . . . 160 10.3.3. Authentication-Info . . . . . . . . . . . . . . . . 160
10.4. Response Context . . . . . . . . . . . . . . . . . . . . 161 10.3.4. Proxy-Authentication-Info . . . . . . . . . . . . . 161
10.4.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . 161 10.4. Response Context . . . . . . . . . . . . . . . . . . . . 162
10.4.2. Allow . . . . . . . . . . . . . . . . . . . . . . . 161 10.4.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . 162
10.4.3. Server . . . . . . . . . . . . . . . . . . . . . . . 162 10.4.2. Allow . . . . . . . . . . . . . . . . . . . . . . . 162
11. Security Considerations . . . . . . . . . . . . . . . . . . . 163 10.4.3. Server . . . . . . . . . . . . . . . . . . . . . . . 163
11.1. Establishing Authority . . . . . . . . . . . . . . . . . 163 11. Security Considerations . . . . . . . . . . . . . . . . . . . 164
11.2. Risks of Intermediaries . . . . . . . . . . . . . . . . 164 11.1. Establishing Authority . . . . . . . . . . . . . . . . . 164
11.3. Attacks Based on File and Path Names . . . . . . . . . . 165 11.2. Risks of Intermediaries . . . . . . . . . . . . . . . . 165
11.4. Attacks Based on Command, Code, or Query Injection . . . 165 11.3. Attacks Based on File and Path Names . . . . . . . . . . 166
11.5. Attacks via Protocol Element Length . . . . . . . . . . 166 11.4. Attacks Based on Command, Code, or Query Injection . . . 166
11.6. Disclosure of Personal Information . . . . . . . . . . . 166 11.5. Attacks via Protocol Element Length . . . . . . . . . . 167
11.7. Privacy of Server Log Information . . . . . . . . . . . 166 11.6. Disclosure of Personal Information . . . . . . . . . . . 167
11.8. Disclosure of Sensitive Information in URIs . . . . . . 167 11.7. Privacy of Server Log Information . . . . . . . . . . . 167
11.9. Disclosure of Fragment after Redirects . . . . . . . . . 167 11.8. Disclosure of Sensitive Information in URIs . . . . . . 168
11.10. Disclosure of Product Information . . . . . . . . . . . 168 11.9. Disclosure of Fragment after Redirects . . . . . . . . . 168
11.11. Browser Fingerprinting . . . . . . . . . . . . . . . . . 168 11.10. Disclosure of Product Information . . . . . . . . . . . 169
11.12. Validator Retention . . . . . . . . . . . . . . . . . . 169 11.11. Browser Fingerprinting . . . . . . . . . . . . . . . . . 169
11.13. Denial-of-Service Attacks Using Range . . . . . . . . . 170 11.12. Validator Retention . . . . . . . . . . . . . . . . . . 170
11.14. Authentication Considerations . . . . . . . . . . . . . 170 11.13. Denial-of-Service Attacks Using Range . . . . . . . . . 171
11.14.1. Confidentiality of Credentials . . . . . . . . . . 170 11.14. Authentication Considerations . . . . . . . . . . . . . 171
11.14.2. Credentials and Idle Clients . . . . . . . . . . . 171 11.14.1. Confidentiality of Credentials . . . . . . . . . . 171
11.14.3. Protection Spaces . . . . . . . . . . . . . . . . . 171 11.14.2. Credentials and Idle Clients . . . . . . . . . . . 172
11.14.4. Additional Response Fields . . . . . . . . . . . . 172 11.14.3. Protection Spaces . . . . . . . . . . . . . . . . . 172
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 172 11.14.4. Additional Response Fields . . . . . . . . . . . . 173
12.1. URI Scheme Registration . . . . . . . . . . . . . . . . 172 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 173
12.2. Method Registration . . . . . . . . . . . . . . . . . . 172 12.1. URI Scheme Registration . . . . . . . . . . . . . . . . 173
12.3. Status Code Registration . . . . . . . . . . . . . . . . 172 12.2. Method Registration . . . . . . . . . . . . . . . . . . 173
12.4. HTTP Field Name Registration . . . . . . . . . . . . . . 173 12.3. Status Code Registration . . . . . . . . . . . . . . . . 173
12.5. Authentication Scheme Registration . . . . . . . . . . . 173 12.4. HTTP Field Name Registration . . . . . . . . . . . . . . 174
12.6. Content Coding Registration . . . . . . . . . . . . . . 173 12.5. Authentication Scheme Registration . . . . . . . . . . . 174
12.7. Range Unit Registration . . . . . . . . . . . . . . . . 174 12.6. Content Coding Registration . . . . . . . . . . . . . . 174
12.8. Media Type Registration . . . . . . . . . . . . . . . . 174 12.7. Range Unit Registration . . . . . . . . . . . . . . . . 175
12.9. Port Registration . . . . . . . . . . . . . . . . . . . 174 12.8. Media Type Registration . . . . . . . . . . . . . . . . 175
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 174 12.9. Port Registration . . . . . . . . . . . . . . . . . . . 175
13.1. Normative References . . . . . . . . . . . . . . . . . . 174 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 175
13.2. Informative References . . . . . . . . . . . . . . . . . 176 13.1. Normative References . . . . . . . . . . . . . . . . . . 175
Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 182 13.2. Informative References . . . . . . . . . . . . . . . . . 177
Appendix B. Changes from previous RFCs . . . . . . . . . . . . . 186 Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 183
B.1. Changes from RFC 2818 . . . . . . . . . . . . . . . . . . 186 Appendix B. Changes from previous RFCs . . . . . . . . . . . . . 187
B.2. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 186 B.1. Changes from RFC 2818 . . . . . . . . . . . . . . . . . . 187
B.3. Changes from RFC 7231 . . . . . . . . . . . . . . . . . . 187 B.2. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 187
B.4. Changes from RFC 7232 . . . . . . . . . . . . . . . . . . 188 B.3. Changes from RFC 7231 . . . . . . . . . . . . . . . . . . 188
B.5. Changes from RFC 7233 . . . . . . . . . . . . . . . . . . 188 B.4. Changes from RFC 7232 . . . . . . . . . . . . . . . . . . 189
B.6. Changes from RFC 7235 . . . . . . . . . . . . . . . . . . 188 B.5. Changes from RFC 7233 . . . . . . . . . . . . . . . . . . 189
B.7. Changes from RFC 7538 . . . . . . . . . . . . . . . . . . 188 B.6. Changes from RFC 7235 . . . . . . . . . . . . . . . . . . 189
B.8. Changes from RFC 7615 . . . . . . . . . . . . . . . . . . 188 B.7. Changes from RFC 7538 . . . . . . . . . . . . . . . . . . 189
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 188 B.8. Changes from RFC 7615 . . . . . . . . . . . . . . . . . . 189
C.1. Between RFC723x and draft 00 . . . . . . . . . . . . . . 188 Appendix C. Changes from RFC 7694 . . . . . . . . . . . . . . . 189
C.2. Since draft-ietf-httpbis-semantics-00 . . . . . . . . . . 189 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 189
C.3. Since draft-ietf-httpbis-semantics-01 . . . . . . . . . . 189 D.1. Between RFC723x and draft 00 . . . . . . . . . . . . . . 190
C.4. Since draft-ietf-httpbis-semantics-02 . . . . . . . . . . 191 D.2. Since draft-ietf-httpbis-semantics-00 . . . . . . . . . . 190
C.5. Since draft-ietf-httpbis-semantics-03 . . . . . . . . . . 192 D.3. Since draft-ietf-httpbis-semantics-01 . . . . . . . . . . 191
C.6. Since draft-ietf-httpbis-semantics-04 . . . . . . . . . . 192 D.4. Since draft-ietf-httpbis-semantics-02 . . . . . . . . . . 192
C.7. Since draft-ietf-httpbis-semantics-05 . . . . . . . . . . 193 D.5. Since draft-ietf-httpbis-semantics-03 . . . . . . . . . . 193
C.8. Since draft-ietf-httpbis-semantics-06 . . . . . . . . . . 194 D.6. Since draft-ietf-httpbis-semantics-04 . . . . . . . . . . 194
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 D.7. Since draft-ietf-httpbis-semantics-05 . . . . . . . . . . 194
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 205 D.8. Since draft-ietf-httpbis-semantics-06 . . . . . . . . . . 195
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 206 D.9. Since draft-ietf-httpbis-semantics-07 . . . . . . . . . . 197
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 207
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 207
1. Introduction 1. Introduction
The Hypertext Transfer Protocol (HTTP) is a stateless application- The Hypertext Transfer Protocol (HTTP) is a stateless application-
level request/response protocol that uses extensible semantics and level request/response protocol that uses extensible semantics and
self-descriptive messages for flexible interaction with network-based self-descriptive messages for flexible interaction with network-based
hypertext information systems. HTTP is defined by a series of hypertext information systems. HTTP is defined by a series of
documents that collectively form the HTTP/1.1 specification: documents that collectively form the HTTP/1.1 specification:
o "HTTP Semantics" (this document) o "HTTP Semantics" (this document)
skipping to change at page 9, line 35 skipping to change at page 9, line 35
This document defines HTTP range requests, partial responses, and the This document defines HTTP range requests, partial responses, and the
multipart/byteranges media type. multipart/byteranges media type.
This document obsoletes the portions of RFC 7230 that are independent This document obsoletes the portions of RFC 7230 that are independent
of the HTTP/1.1 messaging syntax and connection management, with the of the HTTP/1.1 messaging syntax and connection management, with the
changes being summarized in Appendix B.2. The other parts of RFC changes being summarized in Appendix B.2. The other parts of RFC
7230 are obsoleted by "HTTP/1.1 Messaging" [Messaging]. This 7230 are obsoleted by "HTTP/1.1 Messaging" [Messaging]. This
document also obsoletes RFC 2818 (see Appendix B.1), RFC 7231 (see document also obsoletes RFC 2818 (see Appendix B.1), RFC 7231 (see
Appendix B.3), RFC 7232 (see Appendix B.4), RFC 7233 (see Appendix B.3), RFC 7232 (see Appendix B.4), RFC 7233 (see
Appendix B.5), RFC 7235 (see Appendix B.6), RFC 7538 (see Appendix B.5), RFC 7235 (see Appendix B.6), RFC 7538 (see
Appendix B.7), and RFC 7615 (see Appendix B.8). Appendix B.7), RFC 7615 (see Appendix B.8), and RFC 7694 (see
Appendix C).
1.1. Requirements Notation 1.1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Conformance criteria and considerations regarding error handling are Conformance criteria and considerations regarding error handling are
skipping to change at page 25, line 43 skipping to change at page 25, line 43
This means that, aside from the well-known exception noted below, a This means that, aside from the well-known exception noted below, a
sender MUST NOT generate multiple field lines with the same name in a sender MUST NOT generate multiple field lines with the same name in a
message (whether in the headers or trailers), or append a field line message (whether in the headers or trailers), or append a field line
when a field line of the same name already exists in the message, when a field line of the same name already exists in the message,
unless that field's definition allows multiple field line values to unless that field's definition allows multiple field line values to
be recombined as a comma-separated list [i.e., at least one be recombined as a comma-separated list [i.e., at least one
alternative of the field's definition allows a comma-separated list, alternative of the field's definition allows a comma-separated list,
such as an ABNF rule of #(values) defined in Section 4.5]. such as an ABNF rule of #(values) defined in Section 4.5].
Note: In practice, the "Set-Cookie" header field ([RFC6265]) often Note: In practice, the "Set-Cookie" header field ([RFC6265]) often
appears in a response message across multiple field and does not appears in a response message across multiple field lines and does
use the list syntax, violating the above requirements on multiple not use the list syntax, violating the above requirements on
field lines with the same field name. Since it cannot be combined multiple field lines with the same field name. Since it cannot be
into a single field value, recipients ought to handle "Set-Cookie" combined into a single field value, recipients ought to handle
as a special case while processing fields. (See Appendix A.2.3 of "Set-Cookie" as a special case while processing fields. (See
[Kri2001] for details.) Appendix A.2.3 of [Kri2001] for details.)
4.2. Field Limits 4.2. Field Limits
HTTP does not place a predefined limit on the length of each field HTTP does not place a predefined limit on the length of each field
line, field value, or on the length of the header or trailer section line, field value, or on the length of the header or trailer section
as a whole, as described in Section 3. Various ad hoc limitations on as a whole, as described in Section 3. Various ad hoc limitations on
individual lengths are found in practice, often depending on the individual lengths are found in practice, often depending on the
specific field's semantics. specific field's semantics.
A server that receives a request header field line, field value, or A server that receives a request header field line, field value, or
skipping to change at page 31, line 23 skipping to change at page 31, line 23
preceding semicolon. preceding semicolon.
parameter = parameter-name "=" parameter-value parameter = parameter-name "=" parameter-value
parameter-name = token parameter-name = token
parameter-value = ( token / quoted-string ) parameter-value = ( token / quoted-string )
Parameter names are case-insensitive. Parameter values might or Parameter names are case-insensitive. Parameter values might or
might not be case-sensitive, depending on the semantics of the might not be case-sensitive, depending on the semantics of the
parameter name. Examples of parameters and some equivalent forms can parameter name. Examples of parameters and some equivalent forms can
be seen in media types (Section 6.1.1) and the Accept header field be seen in media types (Section 6.1.1) and the Accept header field
(Section 8.4.2). (Section 8.4.1).
A parameter value that matches the token production can be A parameter value that matches the token production can be
transmitted either as a token or within a quoted-string. The quoted transmitted either as a token or within a quoted-string. The quoted
and unquoted values are equivalent. and unquoted values are equivalent.
Note: Parameters do not allow whitespace (not even "bad" Note: Parameters do not allow whitespace (not even "bad"
whitespace) around the "=" character. whitespace) around the "=" character.
4.5. ABNF List Extension: #rule 4.5. ABNF List Extension: #rule
skipping to change at page 36, line 8 skipping to change at page 36, line 8
o Whether it introduces any additional security considerations, such o Whether it introduces any additional security considerations, such
as disclosure of privacy-related data. as disclosure of privacy-related data.
4.8. Fields Defined In This Document 4.8. Fields Defined In This Document
The following fields are defined by this document: The following fields are defined by this document:
+---------------------------+------------+-------------------+ +---------------------------+------------+-------------------+
| Field Name | Status | Reference | | Field Name | Status | Reference |
+---------------------------+------------+-------------------+ +---------------------------+------------+-------------------+
| Accept | standard | Section 8.4.2 | | Accept | standard | Section 8.4.1 |
| Accept-Charset | deprecated | Section 8.4.3 | | Accept-Charset | deprecated | Section 8.4.2 |
| Accept-Encoding | standard | Section 8.4.4 | | Accept-Encoding | standard | Section 8.4.3 |
| Accept-Language | standard | Section 8.4.5 | | Accept-Language | standard | Section 8.4.4 |
| Accept-Ranges | standard | Section 10.4.1 | | Accept-Ranges | standard | Section 10.4.1 |
| Allow | standard | Section 10.4.2 | | Allow | standard | Section 10.4.2 |
| Authentication-Info | standard | Section 10.3.3 | | Authentication-Info | standard | Section 10.3.3 |
| Authorization | standard | Section 8.5.3 | | Authorization | standard | Section 8.5.3 |
| Content-Encoding | standard | Section 6.2.2 | | Content-Encoding | standard | Section 6.2.2 |
| Content-Language | standard | Section 6.2.3 | | Content-Language | standard | Section 6.2.3 |
| Content-Length | standard | Section 6.2.4 | | Content-Length | standard | Section 6.2.4 |
| Content-Location | standard | Section 6.2.5 | | Content-Location | standard | Section 6.2.5 |
| Content-Range | standard | Section 6.3.4 | | Content-Range | standard | Section 6.3.4 |
| Content-Type | standard | Section 6.2.1 | | Content-Type | standard | Section 6.2.1 |
skipping to change at page 49, line 14 skipping to change at page 49, line 14
The data type of the representation data is determined via the header The data type of the representation data is determined via the header
fields Content-Type and Content-Encoding. These define a two-layer, fields Content-Type and Content-Encoding. These define a two-layer,
ordered encoding model: ordered encoding model:
representation-data := Content-Encoding( Content-Type( bits ) ) representation-data := Content-Encoding( Content-Type( bits ) )
6.1.1. Media Type 6.1.1. Media Type
HTTP uses media types [RFC2046] in the Content-Type (Section 6.2.1) HTTP uses media types [RFC2046] in the Content-Type (Section 6.2.1)
and Accept (Section 8.4.2) header fields in order to provide open and and Accept (Section 8.4.1) header fields in order to provide open and
extensible data typing and type negotiation. Media types define both extensible data typing and type negotiation. Media types define both
a data format and various processing models: how to process that data a data format and various processing models: how to process that data
in accordance with each context in which it is received. in accordance with each context in which it is received.
media-type = type "/" subtype *( OWS ";" OWS parameter ) media-type = type "/" subtype *( OWS ";" OWS parameter )
type = token type = token
subtype = token subtype = token
The type and subtype tokens are case-insensitive. The type and subtype tokens are case-insensitive.
skipping to change at page 51, line 29 skipping to change at page 51, line 29
underlying media type and without loss of information. Frequently, underlying media type and without loss of information. Frequently,
the representation is stored in coded form, transmitted directly, and the representation is stored in coded form, transmitted directly, and
only decoded by the final recipient. only decoded by the final recipient.
content-coding = token content-coding = token
All content codings are case-insensitive and ought to be registered All content codings are case-insensitive and ought to be registered
within the "HTTP Content Coding Registry", as defined in within the "HTTP Content Coding Registry", as defined in
Section 6.1.2.4 Section 6.1.2.4
Content-coding values are used in the Accept-Encoding (Section 8.4.4) Content-coding values are used in the Accept-Encoding (Section 8.4.3)
and Content-Encoding (Section 6.2.2) header fields. and Content-Encoding (Section 6.2.2) header fields.
The following content-coding values are defined by this The following content-coding values are defined by this
specification: specification:
+------------+------------------------------------------+-----------+ +------------+------------------------------------------+-----------+
| Name | Description | Reference | | Name | Description | Reference |
+------------+------------------------------------------+-----------+ +------------+------------------------------------------+-----------+
| compress | UNIX "compress" data format [Welch] | Section 6 | | compress | UNIX "compress" data format [Welch] | Section 6 |
| | | .1.2.1 | | | | .1.2.1 |
| deflate | "deflate" compressed data ([RFC1951]) | Section 6 | | deflate | "deflate" compressed data ([RFC1951]) | Section 6 |
| | inside the "zlib" data format | .1.2.2 | | | inside the "zlib" data format | .1.2.2 |
| | ([RFC1950]) | | | | ([RFC1950]) | |
| gzip | GZIP file format [RFC1952] | Section 6 | | gzip | GZIP file format [RFC1952] | Section 6 |
| | | .1.2.3 | | | | .1.2.3 |
| identity | Reserved (synonym for "no encoding" in | Section 8 | | identity | Reserved (synonym for "no encoding" in | Section 8 |
| | Accept-Encoding) | .4.4 | | | Accept-Encoding) | .4.3 |
| x-compress | Deprecated (alias for compress) | Section 6 | | x-compress | Deprecated (alias for compress) | Section 6 |
| | | .1.2.1 | | | | .1.2.1 |
| x-gzip | Deprecated (alias for gzip) | Section 6 | | x-gzip | Deprecated (alias for gzip) | Section 6 |
| | | .1.2.3 | | | | .1.2.3 |
+------------+------------------------------------------+-----------+ +------------+------------------------------------------+-----------+
Table 2 Table 2
6.1.2.1. Compress Coding 6.1.2.1. Compress Coding
skipping to change at page 53, line 31 skipping to change at page 53, line 31
6.1.3. Language Tags 6.1.3. Language Tags
A language tag, as defined in [RFC5646], identifies a natural A language tag, as defined in [RFC5646], identifies a natural
language spoken, written, or otherwise conveyed by human beings for language spoken, written, or otherwise conveyed by human beings for
communication of information to other human beings. Computer communication of information to other human beings. Computer
languages are explicitly excluded. languages are explicitly excluded.
HTTP uses language tags within the Accept-Language and Content- HTTP uses language tags within the Accept-Language and Content-
Language header fields. Accept-Language uses the broader language- Language header fields. Accept-Language uses the broader language-
range production defined in Section 8.4.5, whereas Content-Language range production defined in Section 8.4.4, whereas Content-Language
uses the language-tag production defined below. uses the language-tag production defined below.
language-tag = <Language-Tag, see [RFC5646], Section 2.1> language-tag = <Language-Tag, see [RFC5646], Section 2.1>
A language tag is a sequence of one or more case-insensitive subtags, A language tag is a sequence of one or more case-insensitive subtags,
each separated by a hyphen character ("-", %x2D). In most cases, a each separated by a hyphen character ("-", %x2D). In most cases, a
language tag consists of a primary language subtag that identifies a language tag consists of a primary language subtag that identifies a
broad family of related languages (e.g., "en" = English), which is broad family of related languages (e.g., "en" = English), which is
optionally followed by a series of subtags that refine or narrow that optionally followed by a series of subtags that refine or narrow that
language's range (e.g., "en-CA" = the variety of English as language's range (e.g., "en-CA" = the variety of English as
skipping to change at page 70, line 43 skipping to change at page 70, line 43
When responses convey payload information, whether indicating a When responses convey payload information, whether indicating a
success or an error, the origin server often has different ways of success or an error, the origin server often has different ways of
representing that information; for example, in different formats, representing that information; for example, in different formats,
languages, or encodings. Likewise, different users or user agents languages, or encodings. Likewise, different users or user agents
might have differing capabilities, characteristics, or preferences might have differing capabilities, characteristics, or preferences
that could influence which representation, among those available, that could influence which representation, among those available,
would be best to deliver. For this reason, HTTP provides mechanisms would be best to deliver. For this reason, HTTP provides mechanisms
for content negotiation. for content negotiation.
This specification defines two patterns of content negotiation that This specification defines three patterns of content negotiation that
can be made visible within the protocol: "proactive", where the can be made visible within the protocol: "proactive" negotiation,
server selects the representation based upon the user agent's stated where the server selects the representation based upon the user
preferences, and "reactive" negotiation, where the server provides a agent's stated preferences, "reactive" negotiation, where the server
list of representations for the user agent to choose from. Other provides a list of representations for the user agent to choose from,
patterns of content negotiation include "conditional content", where and "request payload" negotiation, where the user agent selects the
the representation consists of multiple parts that are selectively representation for a future request based upon the server's stated
rendered based on user agent parameters, "active content", where the preferences in past responses. Other patterns of content negotiation
representation contains a script that makes additional (more include "conditional content", where the representation consists of
specific) requests based on the user agent characteristics, and multiple parts that are selectively rendered based on user agent
"Transparent Content Negotiation" ([RFC2295]), where content parameters, "active content", where the representation contains a
selection is performed by an intermediary. These patterns are not script that makes additional (more specific) requests based on the
mutually exclusive, and each has trade-offs in applicability and user agent characteristics, and "Transparent Content Negotiation"
practicality. ([RFC2295]), where content selection is performed by an intermediary.
These patterns are not mutually exclusive, and each has trade-offs in
applicability and practicality.
Note that, in all cases, HTTP is not aware of the resource semantics. Note that, in all cases, HTTP is not aware of the resource semantics.
The consistency with which an origin server responds to requests, The consistency with which an origin server responds to requests,
over time and over the varying dimensions of content negotiation, and over time and over the varying dimensions of content negotiation, and
thus the "sameness" of a resource's observed representations over thus the "sameness" of a resource's observed representations over
time, is determined entirely by whatever entity or algorithm selects time, is determined entirely by whatever entity or algorithm selects
or generates those responses. HTTP pays no attention to the man or generates those responses.
behind the curtain.
6.4.1. Proactive Negotiation 6.4.1. Proactive Negotiation
When content negotiation preferences are sent by the user agent in a When content negotiation preferences are sent by the user agent in a
request to encourage an algorithm located at the server to select the request to encourage an algorithm located at the server to select the
preferred representation, it is called proactive negotiation (a.k.a., preferred representation, it is called proactive negotiation (a.k.a.,
server-driven negotiation). Selection is based on the available server-driven negotiation). Selection is based on the available
representations for a response (the dimensions over which it might representations for a response (the dimensions over which it might
vary, such as language, content-coding, etc.) compared to various vary, such as language, content-coding, etc.) compared to various
information supplied in the request, including both the explicit information supplied in the request, including both the explicit
skipping to change at page 73, line 16 skipping to change at page 73, line 16
caches are used to distribute server load and reduce network usage. caches are used to distribute server load and reduce network usage.
Reactive negotiation suffers from the disadvantages of transmitting a Reactive negotiation suffers from the disadvantages of transmitting a
list of alternatives to the user agent, which degrades user-perceived list of alternatives to the user agent, which degrades user-perceived
latency if transmitted in the header section, and needing a second latency if transmitted in the header section, and needing a second
request to obtain an alternate representation. Furthermore, this request to obtain an alternate representation. Furthermore, this
specification does not define a mechanism for supporting automatic specification does not define a mechanism for supporting automatic
selection, though it does not prevent such a mechanism from being selection, though it does not prevent such a mechanism from being
developed as an extension. developed as an extension.
6.4.3. Request Payload Negotiation
When content negotiation preferences are sent in a server's response,
the listed preferences are called request payload negotiation because
they intend to influence selection of an appropriate payload for
subsequent requests to that resource. For example, the Accept-
Encoding field (Section 8.4.3) can be sent in a response to indicate
preferred content codings for subsequent requests to that resource
[RFC7694].
Similarly, Section 3.1 of [RFC5789] defines the "Accept-Patch"
response header field which allows discovery of which content
types are accepted in PATCH requests.
6.4.4. Quality Values
The content negotiation fields defined by this specification use a
common parameter, named "q" (case-insensitive), to assign a relative
"weight" to the preference for that associated kind of content. This
weight is referred to as a "quality value" (or "qvalue") because the
same parameter name is often used within server configurations to
assign a weight to the relative quality of the various
representations that can be selected for a resource.
The weight is normalized to a real number in the range 0 through 1,
where 0.001 is the least preferred and 1 is the most preferred; a
value of 0 means "not acceptable". If no "q" parameter is present,
the default weight is 1.
weight = OWS ";" OWS "q=" qvalue
qvalue = ( "0" [ "." 0*3DIGIT ] )
/ ( "1" [ "." 0*3("0") ] )
A sender of qvalue MUST NOT generate more than three digits after the
decimal point. User configuration of these values ought to be
limited in the same fashion.
7. Request Methods 7. Request Methods
7.1. Overview 7.1. Overview
The request method token is the primary source of request semantics; The request method token is the primary source of request semantics;
it indicates the purpose for which the client has made this request it indicates the purpose for which the client has made this request
and what is expected by the client as a successful result. and what is expected by the client as a successful result.
The request method's semantics might be further specialized by the The request method's semantics might be further specialized by the
semantics of some header fields when present in a request (Section 8) semantics of some header fields when present in a request (Section 8)
skipping to change at page 102, line 38 skipping to change at page 103, line 38
valid and satisfiable (as defined in Section 6.1.4.2), the server valid and satisfiable (as defined in Section 6.1.4.2), the server
SHOULD send a 206 (Partial Content) response with a payload SHOULD send a 206 (Partial Content) response with a payload
containing one or more partial representations that correspond to the containing one or more partial representations that correspond to the
satisfiable ranges requested. satisfiable ranges requested.
If all of the preconditions are true, the server supports the Range If all of the preconditions are true, the server supports the Range
header field for the target resource, and the specified range(s) are header field for the target resource, and the specified range(s) are
invalid or unsatisfiable, the server SHOULD send a 416 (Range Not invalid or unsatisfiable, the server SHOULD send a 416 (Range Not
Satisfiable) response. Satisfiable) response.
8.4. Content Negotiation 8.4. Negotiation
The following request header fields are sent by a user agent to The following request header fields can be sent by a user agent to
engage in proactive negotiation of the response content, as defined engage in proactive negotiation of the response content, as defined
in Section 6.4.1. The preferences sent in these fields apply to any in Section 6.4.1. The preferences sent in these fields apply to any
content in the response, including representations of the target content in the response, including representations of the target
resource, representations of error or processing status, and resource, representations of error or processing status, and
potentially even the miscellaneous text strings that might appear potentially even the miscellaneous text strings that might appear
within the protocol. within the protocol.
+-----------------+---------------+ +-----------------+---------------+
| Field Name | Defined in... | | Field Name | Defined in... |
+-----------------+---------------+ +-----------------+---------------+
| Accept | Section 8.4.2 | | Accept | Section 8.4.1 |
| Accept-Charset | Section 8.4.3 | | Accept-Charset | Section 8.4.2 |
| Accept-Encoding | Section 8.4.4 | | Accept-Encoding | Section 8.4.3 |
| Accept-Language | Section 8.4.5 | | Accept-Language | Section 8.4.4 |
+-----------------+---------------+ +-----------------+---------------+
For each of these header fields, a request that does not contain it For each of these header fields, a request that does not contain it
implies that the user agent has no preference on that axis of implies that the user agent has no preference on that axis of
negotiation. If the header field is present in a request and none of negotiation. If the header field is present in a request and none of
the available representations for the response can be considered the available representations for the response can be considered
acceptable according to it, the origin server can either honor the acceptable according to it, the origin server can either honor the
header field by sending a 406 (Not Acceptable) response or disregard header field by sending a 406 (Not Acceptable) response or disregard
the header field by treating the response as if it is not subject to the header field by treating the response as if it is not subject to
content negotiation for that request header field. This does not content negotiation for that request header field. This does not
skipping to change at page 103, line 42 skipping to change at page 104, line 42
the client. the client.
Note: In practice, using wildcards in content negotiation has limited Note: In practice, using wildcards in content negotiation has limited
practical value, because it is seldom useful to say, for example, "I practical value, because it is seldom useful to say, for example, "I
prefer image/* more or less than (some other specific value)". prefer image/* more or less than (some other specific value)".
Clients can explicitly request a 406 (Not Acceptable) response if a Clients can explicitly request a 406 (Not Acceptable) response if a
more preferred format is not available by sending Accept: */*;q=0, more preferred format is not available by sending Accept: */*;q=0,
but they still need to be able to handle a different response, since but they still need to be able to handle a different response, since
the server is allowed to ignore their preference. the server is allowed to ignore their preference.
8.4.1. Quality Values 8.4.1. Accept
Many of the request header fields for proactive negotiation use a
common parameter, named "q" (case-insensitive), to assign a relative
"weight" to the preference for that associated kind of content. This
weight is referred to as a "quality value" (or "qvalue") because the
same parameter name is often used within server configurations to
assign a weight to the relative quality of the various
representations that can be selected for a resource.
The weight is normalized to a real number in the range 0 through 1,
where 0.001 is the least preferred and 1 is the most preferred; a
value of 0 means "not acceptable". If no "q" parameter is present,
the default weight is 1.
weight = OWS ";" OWS "q=" qvalue
qvalue = ( "0" [ "." 0*3DIGIT ] )
/ ( "1" [ "." 0*3("0") ] )
A sender of qvalue MUST NOT generate more than three digits after the
decimal point. User configuration of these values ought to be
limited in the same fashion.
8.4.2. Accept
The "Accept" header field can be used by user agents to specify their The "Accept" header field can be used by user agents to specify their
preferences regarding response media types. For example, Accept preferences regarding response media types. For example, Accept
header fields can be used to indicate that the request is header fields can be used to indicate that the request is
specifically limited to a small set of desired types, as in the case specifically limited to a small set of desired types, as in the case
of a request for an in-line image. of a request for an in-line image.
Accept = #( media-range [ accept-params ] ) Accept = #( media-range [ accept-params ] )
media-range = ( "*/*" media-range = ( "*/*"
skipping to change at page 104, line 42 skipping to change at page 105, line 21
accept-params = weight *( accept-ext ) accept-params = weight *( accept-ext )
accept-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ] accept-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ]
The asterisk "*" character is used to group media types into ranges, The asterisk "*" character is used to group media types into ranges,
with "*/*" indicating all media types and "type/*" indicating all with "*/*" indicating all media types and "type/*" indicating all
subtypes of that type. The media-range can include media type subtypes of that type. The media-range can include media type
parameters that are applicable to that range. parameters that are applicable to that range.
Each media-range might be followed by zero or more applicable media Each media-range might be followed by zero or more applicable media
type parameters (e.g., charset), an optional "q" parameter for type parameters (e.g., charset), an optional "q" parameter for
indicating a relative weight (Section 8.4.1), and then zero or more indicating a relative weight (Section 6.4.4), and then zero or more
extension parameters. The "q" parameter is necessary if any extension parameters. The "q" parameter is necessary if any
extensions (accept-ext) are present, since it acts as a separator extensions (accept-ext) are present, since it acts as a separator
between the two parameter sets. between the two parameter sets.
Note: Use of the "q" parameter name to separate media type Note: Use of the "q" parameter name to separate media type
parameters from Accept extension parameters is due to historical parameters from Accept extension parameters is due to historical
practice. Although this prevents any media type parameter named practice. Although this prevents any media type parameter named
"q" from being used with a media range, such an event is believed "q" from being used with a media range, such an event is believed
to be unlikely given the lack of any "q" parameters in the IANA to be unlikely given the lack of any "q" parameters in the IANA
media type registry and the rare usage of any media type media type registry and the rare usage of any media type
skipping to change at page 106, line 21 skipping to change at page 106, line 46
| image/jpeg | 0.5 | | image/jpeg | 0.5 |
| text/html;level=2 | 0.4 | | text/html;level=2 | 0.4 |
| text/html;level=3 | 0.7 | | text/html;level=3 | 0.7 |
+-------------------+---------------+ +-------------------+---------------+
Note: A user agent might be provided with a default set of quality Note: A user agent might be provided with a default set of quality
values for certain media ranges. However, unless the user agent is a values for certain media ranges. However, unless the user agent is a
closed system that cannot interact with other rendering agents, this closed system that cannot interact with other rendering agents, this
default set ought to be configurable by the user. default set ought to be configurable by the user.
8.4.3. Accept-Charset 8.4.2. Accept-Charset
The "Accept-Charset" header field can be sent by a user agent to The "Accept-Charset" header field can be sent by a user agent to
indicate its preferences for charsets in textual response content. indicate its preferences for charsets in textual response content.
For example, this field allows user agents capable of understanding For example, this field allows user agents capable of understanding
more comprehensive or special-purpose charsets to signal that more comprehensive or special-purpose charsets to signal that
capability to an origin server that is capable of representing capability to an origin server that is capable of representing
information in those charsets. information in those charsets.
Accept-Charset = 1#( ( charset / "*" ) [ weight ] ) Accept-Charset = 1#( ( charset / "*" ) [ weight ] )
Charset names are defined in Section 6.1.1.1. A user agent MAY Charset names are defined in Section 6.1.1.1. A user agent MAY
associate a quality value with each charset to indicate the user's associate a quality value with each charset to indicate the user's
relative preference for that charset, as defined in Section 8.4.1. relative preference for that charset, as defined in Section 6.4.4.
An example is An example is
Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
The special value "*", if present in the Accept-Charset field, The special value "*", if present in the Accept-Charset field,
matches every charset that is not mentioned elsewhere in the Accept- matches every charset that is not mentioned elsewhere in the Accept-
Charset field. Charset field.
Note: Accept-Charset is deprecated because UTF-8 has become nearly Note: Accept-Charset is deprecated because UTF-8 has become nearly
ubiquitous and sending a detailed list of user-preferred charsets ubiquitous and sending a detailed list of user-preferred charsets
wastes bandwidth, increases latency, and makes passive fingerprinting wastes bandwidth, increases latency, and makes passive fingerprinting
far too easy (Section 11.11). Most general-purpose user agents do far too easy (Section 11.11). Most general-purpose user agents do
not send Accept-Charset, unless specifically configured to do so. not send Accept-Charset, unless specifically configured to do so.
8.4.4. Accept-Encoding 8.4.3. Accept-Encoding
The "Accept-Encoding" header field can be used by user agents to The "Accept-Encoding" header field can be used to indicate
indicate their preferences regarding response content-codings preferences regarding the use of content codings (Section 6.1.2).
(Section 6.1.2). An "identity" token is used as a synonym for "no
encoding" in order to communicate when no encoding is preferred. When sent by a user agent in a request, Accept-Encoding indicates the
content codings acceptable in a response.
When sent by a server in a response, Accept-Encoding provides
information about what content codings are preferred in the payload
of a subsequent request to the same resource.
An "identity" token is used as a synonym for "no encoding" in order
to communicate when no encoding is preferred.
Accept-Encoding = #( codings [ weight ] ) Accept-Encoding = #( codings [ weight ] )
codings = content-coding / "identity" / "*" codings = content-coding / "identity" / "*"
Each codings value MAY be given an associated quality value Each codings value MAY be given an associated quality value
representing the preference for that encoding, as defined in representing the preference for that encoding, as defined in
Section 8.4.1. The asterisk "*" symbol in an Accept-Encoding field Section 6.4.4. The asterisk "*" symbol in an Accept-Encoding field
matches any available content-coding not explicitly listed in the matches any available content-coding not explicitly listed in the
header field. header field.
For example, For example,
Accept-Encoding: compress, gzip Accept-Encoding: compress, gzip
Accept-Encoding: Accept-Encoding:
Accept-Encoding: * Accept-Encoding: *
Accept-Encoding: compress;q=0.5, gzip;q=1.0 Accept-Encoding: compress;q=0.5, gzip;q=1.0
Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0 Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0
A server tests whether a content-coding for a given representation is A server tests whether a content-coding for a given representation is
acceptable using these rules: acceptable using these rules:
1. If no Accept-Encoding field is in the request, any content-coding 1. If no Accept-Encoding field is in the request, any content-coding
is considered acceptable by the user agent. is considered acceptable by the user agent.
2. If the representation has no content-coding, then it is 2. If the representation has no content-coding, then it is
acceptable by default unless specifically excluded by the Accept- acceptable by default unless specifically excluded by the Accept-
Encoding field stating either "identity;q=0" or "*;q=0" without a Encoding field stating either "identity;q=0" or "*;q=0" without a
more specific entry for "identity". more specific entry for "identity".
3. If the representation's content-coding is one of the content- 3. If the representation's content-coding is one of the content-
codings listed in the Accept-Encoding field value, then it is codings listed in the Accept-Encoding field value, then it is
acceptable unless it is accompanied by a qvalue of 0. (As acceptable unless it is accompanied by a qvalue of 0. (As
defined in Section 8.4.1, a qvalue of 0 means "not acceptable".) defined in Section 6.4.4, a qvalue of 0 means "not acceptable".)
4. If multiple content-codings are acceptable, then the acceptable 4. If multiple content-codings are acceptable, then the acceptable
content-coding with the highest non-zero qvalue is preferred. content-coding with the highest non-zero qvalue is preferred.
An Accept-Encoding header field with a field value that is empty An Accept-Encoding header field with a field value that is empty
implies that the user agent does not want any content-coding in implies that the user agent does not want any content-coding in
response. If an Accept-Encoding header field is present in a request response. If an Accept-Encoding header field is present in a request
and none of the available representations for the response have a and none of the available representations for the response have a
content-coding that is listed as acceptable, the origin server SHOULD content-coding that is listed as acceptable, the origin server SHOULD
send a response without any content-coding. send a response without any content-coding.
When the Accept-Encoding header field is present in a response, it
indicates what content codings the resource was willing to accept in
the associated request. The field value is evaluated the same way as
in a request.
Note that this information is specific to the associated request; the
set of supported encodings might be different for other resources on
the same server and could change over time or depend on other aspects
of the request (such as the request method).
Servers that fail a request due to an unsupported content coding
ought to respond with a 415 (Unsupported Media Type) status and
include an Accept-Encoding header field in that response, allowing
clients to distinguish between issues related to content codings and
media types. In order to avoid confusion with issues related to
media types, servers that fail a request with a 415 status for
reasons unrelated to content codings MUST NOT include the Accept-
Encoding header field.
The most common use of Accept-Encoding is in responses with a 415
(Unsupported Media Type) status code, in response to optimistic use
of a content coding by clients. However, the header field can also
be used to indicate to clients that content codings are supported, to
optimize future interactions. For example, a resource might include
it in a 2xx (Successful) response when the request payload was big
enough to justify use of a compression coding but the client failed
do so.
Note: Most HTTP/1.0 applications do not recognize or obey qvalues Note: Most HTTP/1.0 applications do not recognize or obey qvalues
associated with content-codings. This means that qvalues might associated with content-codings. This means that qvalues might
not work and are not permitted with x-gzip or x-compress. not work and are not permitted with x-gzip or x-compress.
8.4.5. Accept-Language 8.4.4. Accept-Language
The "Accept-Language" header field can be used by user agents to The "Accept-Language" header field can be used by user agents to
indicate the set of natural languages that are preferred in the indicate the set of natural languages that are preferred in the
response. Language tags are defined in Section 6.1.3. response. Language tags are defined in Section 6.1.3.
Accept-Language = 1#( language-range [ weight ] ) Accept-Language = 1#( language-range [ weight ] )
language-range = language-range =
<language-range, see [RFC4647], Section 2.1> <language-range, see [RFC4647], Section 2.1>
Each language-range can be given an associated quality value Each language-range can be given an associated quality value
representing an estimate of the user's preference for the languages representing an estimate of the user's preference for the languages
specified by that range, as defined in Section 8.4.1. For example, specified by that range, as defined in Section 6.4.4. For example,
Accept-Language: da, en-gb;q=0.8, en;q=0.7 Accept-Language: da, en-gb;q=0.8, en;q=0.7
would mean: "I prefer Danish, but will accept British English and would mean: "I prefer Danish, but will accept British English and
other types of English". other types of English".
Note that some recipients treat the order in which language tags are Note that some recipients treat the order in which language tags are
listed as an indication of descending priority, particularly for tags listed as an indication of descending priority, particularly for tags
that are assigned equal quality values (no value is the same as q=1). that are assigned equal quality values (no value is the same as q=1).
However, this behavior cannot be relied upon. For consistency and to However, this behavior cannot be relied upon. For consistency and to
skipping to change at page 137, line 46 skipping to change at page 138, line 46
A 414 response is heuristically cacheable; i.e., unless otherwise A 414 response is heuristically cacheable; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [Caching]). Section 4.2.2 of [Caching]).
9.5.16. 415 Unsupported Media Type 9.5.16. 415 Unsupported Media Type
The 415 (Unsupported Media Type) status code indicates that the The 415 (Unsupported Media Type) status code indicates that the
origin server is refusing to service the request because the payload origin server is refusing to service the request because the payload
is in a format not supported by this method on the target resource. is in a format not supported by this method on the target resource.
The format problem might be due to the request's indicated Content- The format problem might be due to the request's indicated Content-
Type or Content-Encoding, or as a result of inspecting the data Type or Content-Encoding, or as a result of inspecting the data
directly. directly. If the problem was caused by an unsupported content
coding, the Accept-Encoding response header field (Section 8.4.3)
ought to be used to indicate what (if any) content codings would have
been accepted in the request.
9.5.17. 416 Range Not Satisfiable 9.5.17. 416 Range Not Satisfiable
The 416 (Range Not Satisfiable) status code indicates that none of The 416 (Range Not Satisfiable) status code indicates that none of
the ranges in the request's Range header field (Section 8.3) overlap the ranges in the request's Range header field (Section 8.3) overlap
the current extent of the selected representation or that the set of the current extent of the selected representation or that the set of
ranges requested has been rejected due to invalid ranges or an ranges requested has been rejected due to invalid ranges or an
excessive request of small or overlapping ranges. excessive request of small or overlapping ranges.
For byte ranges, failing to overlap the current extent means that the For byte ranges, failing to overlap the current extent means that the
skipping to change at page 155, line 46 skipping to change at page 156, line 46
| W/"1" | W/"2" | no match | no match | | W/"1" | W/"2" | no match | no match |
| W/"1" | "1" | no match | match | | W/"1" | "1" | no match | match |
| "1" | "1" | match | match | | "1" | "1" | match | match |
+--------+--------+-------------------+-----------------+ +--------+--------+-------------------+-----------------+
10.2.3.3. Example: Entity-Tags Varying on Content-Negotiated Resources 10.2.3.3. Example: Entity-Tags Varying on Content-Negotiated Resources
Consider a resource that is subject to content negotiation Consider a resource that is subject to content negotiation
(Section 6.4), and where the representations sent in response to a (Section 6.4), and where the representations sent in response to a
GET request vary based on the Accept-Encoding request header field GET request vary based on the Accept-Encoding request header field
(Section 8.4.4): (Section 8.4.3):
>> Request: >> Request:
GET /index HTTP/1.1 GET /index HTTP/1.1
Host: www.example.com Host: www.example.com
Accept-Encoding: gzip Accept-Encoding: gzip
In this case, the response might or might not use the gzip content In this case, the response might or might not use the gzip content
coding. If it does not, the response might look like: coding. If it does not, the response might look like:
skipping to change at page 160, line 10 skipping to change at page 161, line 10
The Authentication-Info header field can be used in any HTTP The Authentication-Info header field can be used in any HTTP
response, independently of request method and status code. Its response, independently of request method and status code. Its
semantics are defined by the authentication scheme indicated by the semantics are defined by the authentication scheme indicated by the
Authorization header field (Section 8.5.3) of the corresponding Authorization header field (Section 8.5.3) of the corresponding
request. request.
A proxy forwarding a response is not allowed to modify the field A proxy forwarding a response is not allowed to modify the field
value in any way. value in any way.
Authentication-Info can be used inside trailers (Section 7.1.2 of Authentication-Info can be used inside trailers (Section 4.6) when
[Messaging]) when the authentication scheme explicitly allows this. the authentication scheme explicitly allows this.
10.3.3.1. Parameter Value Format 10.3.3.1. Parameter Value Format
Parameter values can be expressed either as "token" or as "quoted- Parameter values can be expressed either as "token" or as "quoted-
string" (Section 4.4.1). string" (Section 4.4.1).
Authentication scheme definitions need to allow both notations, both Authentication scheme definitions need to allow both notations, both
for senders and recipients. This allows recipients to use generic for senders and recipients. This allows recipients to use generic
parsing components, independent of the authentication scheme in use. parsing components, independent of the authentication scheme in use.
skipping to change at page 181, line 9 skipping to change at page 182, line 9
[RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP [RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP
Digest Access Authentication", RFC 7616, Digest Access Authentication", RFC 7616,
DOI 10.17487/RFC7616, September 2015, DOI 10.17487/RFC7616, September 2015,
<https://www.rfc-editor.org/info/rfc7616>. <https://www.rfc-editor.org/info/rfc7616>.
[RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", [RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme",
RFC 7617, DOI 10.17487/RFC7617, September 2015, RFC 7617, DOI 10.17487/RFC7617, September 2015,
<https://www.rfc-editor.org/info/rfc7617>. <https://www.rfc-editor.org/info/rfc7617>.
[RFC7694] Reschke, J., "Hypertext Transfer Protocol (HTTP) Client-
Initiated Content-Encoding", RFC 7694,
DOI 10.17487/RFC7694, November 2015,
<https://www.rfc-editor.org/info/rfc7694>.
[RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP
Alternative Services", RFC 7838, DOI 10.17487/RFC7838, Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
April 2016, <https://www.rfc-editor.org/info/rfc7838>. April 2016, <https://www.rfc-editor.org/info/rfc7838>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8187] Reschke, J., "Indicating Character Encoding and Language [RFC8187] Reschke, J., "Indicating Character Encoding and Language
skipping to change at page 188, line 7 skipping to change at page 189, line 7
(Section 6.1.4) (Section 6.1.4)
Restrictions on client retries have been loosened, to reflect Restrictions on client retries have been loosened, to reflect
implementation behavior. (Section 7.2.2) implementation behavior. (Section 7.2.2)
Clarified that request bodies on GET and DELETE are not Clarified that request bodies on GET and DELETE are not
interoperable. (Section 7.3.1, Section 7.3.5) interoperable. (Section 7.3.1, Section 7.3.5)
Removed a superfluous requirement about setting Content-Length from Removed a superfluous requirement about setting Content-Length from
the description of the OPTIONS method. (Section 7.3.7) the description of the OPTIONS method. (Section 7.3.7)
Allow Accept-Encoding in response messages, as introduced by
[RFC7694]. (Section 8.4)
B.4. Changes from RFC 7232 B.4. Changes from RFC 7232
None yet. None yet.
B.5. Changes from RFC 7233 B.5. Changes from RFC 7233
Refactored the range-unit and ranges-specifier grammars to simplify Refactored the range-unit and ranges-specifier grammars to simplify
and reduce artificial distinctions between bytes and other and reduce artificial distinctions between bytes and other
(extension) range units, removing the overlapping grammar of other- (extension) range units, removing the overlapping grammar of other-
range-unit by defining range units generically as a token and placing range-unit by defining range units generically as a token and placing
skipping to change at page 188, line 36 skipping to change at page 189, line 39
None yet. None yet.
B.7. Changes from RFC 7538 B.7. Changes from RFC 7538
None yet. None yet.
B.8. Changes from RFC 7615 B.8. Changes from RFC 7615
None yet. None yet.
Appendix C. Change Log Appendix C. Changes from RFC 7694
This specification includes the extension defined in [RFC7694], but
leaves out examples and deployment considerations.
Appendix D. Change Log
This section is to be removed before publishing as an RFC. This section is to be removed before publishing as an RFC.
C.1. Between RFC723x and draft 00 D.1. Between RFC723x and draft 00
The changes were purely editorial: The changes were purely editorial:
o Change boilerplate and abstract to indicate the "draft" status, o Change boilerplate and abstract to indicate the "draft" status,
and update references to ancestor specifications. and update references to ancestor specifications.
o Remove version "1.1" from document title, indicating that this o Remove version "1.1" from document title, indicating that this
specification applies to all HTTP versions. specification applies to all HTTP versions.
o Adjust historical notes. o Adjust historical notes.
o Update links to sibling specifications. o Update links to sibling specifications.
o Replace sections listing changes from RFC 2616 by new empty o Replace sections listing changes from RFC 2616 by new empty
sections referring to RFC 723x. sections referring to RFC 723x.
o Remove acknowledgements specific to RFC 723x. o Remove acknowledgements specific to RFC 723x.
o Move "Acknowledgements" to the very end and make them unnumbered. o Move "Acknowledgements" to the very end and make them unnumbered.
C.2. Since draft-ietf-httpbis-semantics-00 D.2. Since draft-ietf-httpbis-semantics-00
The changes in this draft are editorial, with respect to HTTP as a The changes in this draft are editorial, with respect to HTTP as a
whole, to merge core HTTP semantics into this document: whole, to merge core HTTP semantics into this document:
o Merged introduction, architecture, conformance, and ABNF o Merged introduction, architecture, conformance, and ABNF
extensions from RFC 7230 (Messaging). extensions from RFC 7230 (Messaging).
o Rearranged architecture to extract conformance, http(s) schemes, o Rearranged architecture to extract conformance, http(s) schemes,
and protocol versioning into a separate major section. and protocol versioning into a separate major section.
skipping to change at page 189, line 39 skipping to change at page 191, line 5
o Merged entire content of RFC 7233 (Range Requests). o Merged entire content of RFC 7233 (Range Requests).
o Merged entire content of RFC 7235 (Auth Framework). o Merged entire content of RFC 7235 (Auth Framework).
o Moved all extensibility tips, registration procedures, and o Moved all extensibility tips, registration procedures, and
registry tables from the IANA considerations to normative registry tables from the IANA considerations to normative
sections, reducing the IANA considerations to just instructions sections, reducing the IANA considerations to just instructions
that will be removed prior to publication as an RFC. that will be removed prior to publication as an RFC.
C.3. Since draft-ietf-httpbis-semantics-01 D.3. Since draft-ietf-httpbis-semantics-01
o Improve [Welch] citation (<https://github.com/httpwg/http-core/ o Improve [Welch] citation (<https://github.com/httpwg/http-core/
issues/63>) issues/63>)
o Remove HTTP/1.1-ism about Range Requests o Remove HTTP/1.1-ism about Range Requests
(<https://github.com/httpwg/http-core/issues/71>) (<https://github.com/httpwg/http-core/issues/71>)
o Cite RFC 8126 instead of RFC 5226 (<https://github.com/httpwg/ o Cite RFC 8126 instead of RFC 5226 (<https://github.com/httpwg/
http-core/issues/75>) http-core/issues/75>)
skipping to change at page 191, line 10 skipping to change at page 192, line 22
o In Section 4.5, fixed an example that had trailing whitespace o In Section 4.5, fixed an example that had trailing whitespace
where it shouldn't (<https://github.com/httpwg/http-core/ where it shouldn't (<https://github.com/httpwg/http-core/
issues/104>, <https://www.rfc-editor.org/errata/eid4169>) issues/104>, <https://www.rfc-editor.org/errata/eid4169>)
o In Section 9.3.7, remove words that were potentially misleading o In Section 9.3.7, remove words that were potentially misleading
with respect to the relation to the requested ranges with respect to the relation to the requested ranges
(<https://github.com/httpwg/http-core/issues/102>, (<https://github.com/httpwg/http-core/issues/102>,
<https://www.rfc-editor.org/errata/eid4358>) <https://www.rfc-editor.org/errata/eid4358>)
C.4. Since draft-ietf-httpbis-semantics-02 D.4. Since draft-ietf-httpbis-semantics-02
o Included (Proxy-)Auth-Info header field definition from RFC 7615 o Included (Proxy-)Auth-Info header field definition from RFC 7615
(<https://github.com/httpwg/http-core/issues/9>) (<https://github.com/httpwg/http-core/issues/9>)
o In Section 7.3.3, clarify POST caching o In Section 7.3.3, clarify POST caching
(<https://github.com/httpwg/http-core/issues/17>) (<https://github.com/httpwg/http-core/issues/17>)
o Add Section 9.5.19 to reserve the 418 status code o Add Section 9.5.19 to reserve the 418 status code
(<https://github.com/httpwg/http-core/issues/43>) (<https://github.com/httpwg/http-core/issues/43>)
skipping to change at page 192, line 5 skipping to change at page 193, line 17
issues/123>) issues/123>)
o In Section 9.5.17, fixed prose about byte range comparison o In Section 9.5.17, fixed prose about byte range comparison
(<https://github.com/httpwg/http-core/issues/135>, (<https://github.com/httpwg/http-core/issues/135>,
<https://www.rfc-editor.org/errata/eid5474>) <https://www.rfc-editor.org/errata/eid5474>)
o In Section 2.1, explain that request/response correlation is o In Section 2.1, explain that request/response correlation is
version specific (<https://github.com/httpwg/http-core/ version specific (<https://github.com/httpwg/http-core/
issues/145>) issues/145>)
C.5. Since draft-ietf-httpbis-semantics-03 D.5. Since draft-ietf-httpbis-semantics-03
o In Section 9.4.9, include status code 308 from RFC 7538 o In Section 9.4.9, include status code 308 from RFC 7538
(<https://github.com/httpwg/http-core/issues/3>) (<https://github.com/httpwg/http-core/issues/3>)
o In Section 6.1.1, clarify that the charset parameter value is o In Section 6.1.1, clarify that the charset parameter value is
case-insensitive due to the definition in RFC 2046 case-insensitive due to the definition in RFC 2046
(<https://github.com/httpwg/http-core/issues/13>) (<https://github.com/httpwg/http-core/issues/13>)
o Define a separate registry for HTTP header field names o Define a separate registry for HTTP header field names
(<https://github.com/httpwg/http-core/issues/42>) (<https://github.com/httpwg/http-core/issues/42>)
skipping to change at page 192, line 42 skipping to change at page 194, line 5
o Use RFC 7405 ABNF notation for case-sensitive string constants o Use RFC 7405 ABNF notation for case-sensitive string constants
(<https://github.com/httpwg/http-core/issues/133>) (<https://github.com/httpwg/http-core/issues/133>)
o Rework Section 2.1 to be more version-independent o Rework Section 2.1 to be more version-independent
(<https://github.com/httpwg/http-core/issues/142>) (<https://github.com/httpwg/http-core/issues/142>)
o In Section 7.3.5, clarify that DELETE needs to be successful to o In Section 7.3.5, clarify that DELETE needs to be successful to
invalidate cache (<https://github.com/httpwg/http-core/ invalidate cache (<https://github.com/httpwg/http-core/
issues/167>, <https://www.rfc-editor.org/errata/eid5541>) issues/167>, <https://www.rfc-editor.org/errata/eid5541>)
C.6. Since draft-ietf-httpbis-semantics-04 D.6. Since draft-ietf-httpbis-semantics-04
o In Section 4.4, fix field-content ABNF o In Section 4.4, fix field-content ABNF
(<https://github.com/httpwg/http-core/issues/19>, (<https://github.com/httpwg/http-core/issues/19>,
<https://www.rfc-editor.org/errata/eid4189>) <https://www.rfc-editor.org/errata/eid4189>)
o Move Section 4.4.1.4 into its own section o Move Section 4.4.1.4 into its own section
(<https://github.com/httpwg/http-core/issues/45>) (<https://github.com/httpwg/http-core/issues/45>)
o In Section 6.2.1, reference MIME Sniffing o In Section 6.2.1, reference MIME Sniffing
(<https://github.com/httpwg/http-core/issues/51>) (<https://github.com/httpwg/http-core/issues/51>)
skipping to change at page 193, line 23 skipping to change at page 194, line 35
o Fix editorial issue in Section 6 (<https://github.com/httpwg/http- o Fix editorial issue in Section 6 (<https://github.com/httpwg/http-
core/issues/223>) core/issues/223>)
o In Section 9.5.20, rephrase language not to use "entity" anymore, o In Section 9.5.20, rephrase language not to use "entity" anymore,
and also avoid lowercase "may" (<https://github.com/httpwg/http- and also avoid lowercase "may" (<https://github.com/httpwg/http-
core/issues/224>) core/issues/224>)
o Move discussion of retries from [Messaging] into Section 7.2.2 o Move discussion of retries from [Messaging] into Section 7.2.2
(<https://github.com/httpwg/http-core/issues/230>) (<https://github.com/httpwg/http-core/issues/230>)
C.7. Since draft-ietf-httpbis-semantics-05 D.7. Since draft-ietf-httpbis-semantics-05
o Moved transport-independent part of the description of trailers o Moved transport-independent part of the description of trailers
into Section 4.6 (<https://github.com/httpwg/http-core/issues/16>) into Section 4.6 (<https://github.com/httpwg/http-core/issues/16>)
o Loosen requirements on retries based upon implementation behavior o Loosen requirements on retries based upon implementation behavior
(<https://github.com/httpwg/http-core/issues/27>) (<https://github.com/httpwg/http-core/issues/27>)
o In Section 12.9, update IANA port registry for TCP/UDP on ports 80 o In Section 12.9, update IANA port registry for TCP/UDP on ports 80
and 443 (<https://github.com/httpwg/http-core/issues/36>) and 443 (<https://github.com/httpwg/http-core/issues/36>)
skipping to change at page 194, line 31 skipping to change at page 195, line 42
o In Section 7.3.7, removed a misleading statement about Content- o In Section 7.3.7, removed a misleading statement about Content-
Length (<https://github.com/httpwg/http-core/issues/235>, Length (<https://github.com/httpwg/http-core/issues/235>,
<https://www.rfc-editor.org/errata/eid5806>) <https://www.rfc-editor.org/errata/eid5806>)
o In Section 11.1, add text from RFC 2818 o In Section 11.1, add text from RFC 2818
(<https://github.com/httpwg/http-core/issues/236>) (<https://github.com/httpwg/http-core/issues/236>)
o Changed "cacheable by default" to "heuristically cacheable" o Changed "cacheable by default" to "heuristically cacheable"
throughout (<https://github.com/httpwg/http-core/issues/242>) throughout (<https://github.com/httpwg/http-core/issues/242>)
C.8. Since draft-ietf-httpbis-semantics-06 D.8. Since draft-ietf-httpbis-semantics-06
o In Section 5.7.1, simplify received-by grammar (and disallow comma o In Section 5.7.1, simplify received-by grammar (and disallow comma
character) (<https://github.com/httpwg/http-core/issues/24>) character) (<https://github.com/httpwg/http-core/issues/24>)
o In Section 4.3, give guidance on interoperable field names o In Section 4.3, give guidance on interoperable field names
(<https://github.com/httpwg/http-core/issues/30>) (<https://github.com/httpwg/http-core/issues/30>)
o In Section 1.2.1, define the semantics and possible replacement of o In Section 1.2.1, define the semantics and possible replacement of
whitespace when it is known to occur (<https://github.com/httpwg/ whitespace when it is known to occur (<https://github.com/httpwg/
http-core/issues/53>) http-core/issues/53>)
skipping to change at page 196, line 5 skipping to change at page 197, line 10
o In Section 2.5.1, Section 2.5.2, Section 5.2, and Section 5.4, o In Section 2.5.1, Section 2.5.2, Section 5.2, and Section 5.4,
refactored schemes to define origin and authoritative access to an refactored schemes to define origin and authoritative access to an
origin server for both "http" and "https" URIs to account for origin server for both "http" and "https" URIs to account for
alternative services and secured connections that are not alternative services and secured connections that are not
necessarily based on TCP (<https://github.com/httpwg/http-core/ necessarily based on TCP (<https://github.com/httpwg/http-core/
issues/237>) issues/237>)
o In Section 1.1, reference RFC 8174 as well o In Section 1.1, reference RFC 8174 as well
(<https://github.com/httpwg/http-core/issues/303>) (<https://github.com/httpwg/http-core/issues/303>)
D.9. Since draft-ietf-httpbis-semantics-07
o In Section 6.4, introduce the concept of request payload
negotiation (Section 6.4.3) and define for Accept-Encoding
(<https://github.com/httpwg/http-core/issues/119>)
Index Index
1 1
100 Continue (status code) 121 100 Continue (status code) 122
100-continue (expect value) 88 100-continue (expect value) 89
101 Switching Protocols (status code) 121 101 Switching Protocols (status code) 122
1xx Informational (status code class) 120 1xx Informational (status code class) 121
2 2
200 OK (status code) 121 200 OK (status code) 122
201 Created (status code) 122 201 Created (status code) 123
202 Accepted (status code) 122 202 Accepted (status code) 123
203 Non-Authoritative Information (status code) 123 203 Non-Authoritative Information (status code) 124
204 No Content (status code) 123 204 No Content (status code) 124
205 Reset Content (status code) 124 205 Reset Content (status code) 125
206 Partial Content (status code) 124 206 Partial Content (status code) 125
2xx Successful (status code class) 121 2xx Successful (status code class) 122
3 3
300 Multiple Choices (status code) 129 300 Multiple Choices (status code) 130
301 Moved Permanently (status code) 130 301 Moved Permanently (status code) 131
302 Found (status code) 130 302 Found (status code) 131
303 See Other (status code) 131 303 See Other (status code) 132
304 Not Modified (status code) 131 304 Not Modified (status code) 132
305 Use Proxy (status code) 132 305 Use Proxy (status code) 133
306 (Unused) (status code) 132 306 (Unused) (status code) 133
307 Temporary Redirect (status code) 132 307 Temporary Redirect (status code) 133
308 Permanent Redirect (status code) 133 308 Permanent Redirect (status code) 134
3xx Redirection (status code class) 127 3xx Redirection (status code class) 129
4 4
400 Bad Request (status code) 133 400 Bad Request (status code) 134
401 Unauthorized (status code) 133 401 Unauthorized (status code) 134
402 Payment Required (status code) 134 402 Payment Required (status code) 135
403 Forbidden (status code) 134 403 Forbidden (status code) 135
404 Not Found (status code) 134 404 Not Found (status code) 135
405 Method Not Allowed (status code) 135 405 Method Not Allowed (status code) 136
406 Not Acceptable (status code) 135 406 Not Acceptable (status code) 136
407 Proxy Authentication Required (status code) 135 407 Proxy Authentication Required (status code) 136
408 Request Timeout (status code) 135 408 Request Timeout (status code) 136
409 Conflict (status code) 136 409 Conflict (status code) 137
410 Gone (status code) 136 410 Gone (status code) 137
411 Length Required (status code) 136 411 Length Required (status code) 137
412 Precondition Failed (status code) 137 412 Precondition Failed (status code) 138
413 Payload Too Large (status code) 137 413 Payload Too Large (status code) 138
414 URI Too Long (status code) 137 414 URI Too Long (status code) 138
415 Unsupported Media Type (status code) 137 415 Unsupported Media Type (status code) 138
416 Range Not Satisfiable (status code) 138 416 Range Not Satisfiable (status code) 139
417 Expectation Failed (status code) 138 417 Expectation Failed (status code) 139
418 (Unused) (status code) 138 418 (Unused) (status code) 139
422 Unprocessable Payload (status code) 139 422 Unprocessable Payload (status code) 140
426 Upgrade Required (status code) 139 426 Upgrade Required (status code) 140
4xx Client Error (status code class) 133 4xx Client Error (status code class) 134
5 5
500 Internal Server Error (status code) 140 500 Internal Server Error (status code) 141
501 Not Implemented (status code) 140 501 Not Implemented (status code) 141
502 Bad Gateway (status code) 140 502 Bad Gateway (status code) 141
503 Service Unavailable (status code) 140 503 Service Unavailable (status code) 141
504 Gateway Timeout (status code) 140 504 Gateway Timeout (status code) 141
505 HTTP Version Not Supported (status code) 140 505 HTTP Version Not Supported (status code) 141
5xx Server Error (status code class) 139 5xx Server Error (status code class) 140
A A
Accept header field 104 Accept header field 104
Accept-Charset header field 106 Accept-Charset header field 106
Accept-Encoding header field 107 Accept-Encoding header field 107
Accept-Language header field 108 Accept-Language header field 109
Accept-Ranges header field 161 Accept-Ranges header field 162
Allow header field 161 Allow header field 162
Authentication-Info header field 159 Authentication-Info header field 160
Authorization header field 112 Authorization header field 113
accelerator 14 accelerator 14
authoritative response 163 authoritative response 164
B B
browser 11 browser 11
C C
CONNECT method 83 CONNECT method 84
Canonical Root URI 111 Canonical Root URI 112
Content-Encoding header field 59 Content-Encoding header field 59
Content-Language header field 60 Content-Language header field 60
Content-Length header field 61 Content-Length header field 61
Content-Location header field 62 Content-Location header field 62
Content-MD5 header field 173 Content-MD5 header field 174
Content-Range header field 66 Content-Range header field 66
Content-Type header field 58 Content-Type header field 58
cache 15 cache 15
cacheable 15 cacheable 15
captive portal 15 captive portal 15
client 11 client 11
compress (Coding Format) 52 compress (Coding Format) 52
compress (content coding) 51 compress (content coding) 51
conditional request 91 conditional request 92
connection 11 connection 11
content coding 51 content coding 51
content negotiation 9 content negotiation 9
D D
DELETE method 82 DELETE method 83
Date header field 145 Date header field 146
Delimiters 30 Delimiters 30
deflate (Coding Format) 52 deflate (Coding Format) 52
deflate (content coding) 51 deflate (content coding) 51
downstream 14 downstream 14
E E
ETag field 153 ETag field 154
Expect header field 88 Expect header field 89
effective request URI 43 effective request URI 43
F F
Fields Fields
Accept 104 Accept 104
Accept-Charset 106 Accept-Charset 106
Accept-Encoding 107 Accept-Encoding 107
Accept-Language 108 Accept-Language 109
Accept-Ranges 161 Accept-Ranges 162
Allow 161 Allow 162
Authentication-Info 159 Authentication-Info 160
Authorization 112 Authorization 113
Content-Encoding 59 Content-Encoding 59
Content-Language 60 Content-Language 60
Content-Length 61 Content-Length 61
Content-Location 62 Content-Location 62
Content-MD5 173 Content-MD5 174
Content-Range 66 Content-Range 66
Content-Type 58 Content-Type 58
Date 145 Date 146
ETag 153 ETag 154
Expect 88 Expect 89
From 115 From 116
Host 43 Host 43
If-Match 95 If-Match 96
If-Modified-Since 97 If-Modified-Since 98
If-None-Match 96 If-None-Match 97
If-Range 100 If-Range 101
If-Unmodified-Since 98 If-Unmodified-Since 99
Last-Modified 151 Last-Modified 152
Location 146 Location 147
Max-Forwards 90 Max-Forwards 91
Proxy-Authenticate 159 Proxy-Authenticate 160
Proxy-Authentication-Info 160 Proxy-Authentication-Info 161
Proxy-Authorization 112 Proxy-Authorization 113
Range 101 Range 102
Referer 116 Referer 117
Retry-After 147 Retry-After 148
Server 162 Server 163
Trailer 34 Trailer 34
User-Agent 117 User-Agent 118
Vary 147 Vary 148
Via 45 Via 45
WWW-Authenticate 158 WWW-Authenticate 159
Fragment Identifiers 20 Fragment Identifiers 20
From header field 115 From header field 116
field 24 field 24
field line 24 field line 24
field line value 24 field line value 24
field name 24 field name 24
field value 24 field value 24
G G
GET method 77 GET method 78
Grammar Grammar
absolute-path 16 absolute-path 16
absolute-URI 16 absolute-URI 16
Accept 104 Accept 105
Accept-Charset 106 Accept-Charset 107
Accept-Encoding 107 Accept-Encoding 107
accept-ext 104 accept-ext 105
Accept-Language 108 Accept-Language 109
accept-params 104 accept-params 105
Accept-Ranges 161 Accept-Ranges 162
acceptable-ranges 161 acceptable-ranges 162
Allow 161 Allow 162
ALPHA 10 ALPHA 10
asctime-date 144 asctime-date 145
auth-param 110 auth-param 111
auth-scheme 110 auth-scheme 111
Authentication-Info 159 Authentication-Info 160
authority 16 authority 16
Authorization 112 Authorization 113
BWS 11 BWS 11
challenge 110 challenge 111
charset 49 charset 49
codings 107 codings 107
comment 31 comment 31
complete-length 67 complete-length 67
content-coding 51 content-coding 51
Content-Encoding 59 Content-Encoding 59
Content-Language 60 Content-Language 60
Content-Length 61 Content-Length 61
Content-Location 62 Content-Location 62
Content-Range 67 Content-Range 67
Content-Type 58 Content-Type 58
CR 10 CR 10
credentials 111 credentials 112
CRLF 10 CRLF 10
ctext 31 ctext 31
CTL 10 CTL 10
Date 145 Date 146
date1 144 date1 145
day 144 day 145
day-name 144 day-name 145
day-name-l 144 day-name-l 145
delay-seconds 147 delay-seconds 148
DIGIT 10 DIGIT 10
DQUOTE 10 DQUOTE 10
entity-tag 154 entity-tag 155
ETag 154 ETag 155
etagc 154 etagc 155
Expect 88 Expect 89
field-content 28 field-content 28
field-name 26, 34 field-name 26, 34
field-value 28 field-value 28
field-vchar 28 field-vchar 28
first-pos 55, 67 first-pos 55, 67
From 115 From 116
GMT 144 GMT 145
HEXDIG 10 HEXDIG 10
Host 43 Host 43
hour 144 hour 145
HTAB 10 HTAB 10
HTTP-date 143 HTTP-date 144
http-URI 17 http-URI 17
https-URI 18 https-URI 18
If-Match 95 If-Match 96
If-Modified-Since 97 If-Modified-Since 98
If-None-Match 96 If-None-Match 97
If-Range 100 If-Range 101
If-Unmodified-Since 98 If-Unmodified-Since 99
IMF-fixdate 144 IMF-fixdate 145
incl-range 67 incl-range 67
int-range 55 int-range 55
language-range 108 language-range 109
language-tag 53 language-tag 53
Last-Modified 151 Last-Modified 152
last-pos 55, 67 last-pos 55, 67
LF 10 LF 10
Location 146 Location 147
Max-Forwards 90 Max-Forwards 91
media-range 104 media-range 105
media-type 49 media-type 49
method 73 method 74
minute 144 minute 145
month 144 month 145
obs-date 144 obs-date 145
obs-text 30 obs-text 30
OCTET 10 OCTET 10
opaque-tag 154 opaque-tag 155
other-range 55 other-range 55
OWS 11 OWS 11
parameter 31 parameter 31
parameter-name 31 parameter-name 31
parameter-value 31 parameter-value 31
partial-URI 16 partial-URI 16
port 16 port 16
product 117 product 118
product-version 117 product-version 118
protocol-name 45 protocol-name 45
protocol-version 45 protocol-version 45
Proxy-Authenticate 159 Proxy-Authenticate 160
Proxy-Authentication-Info 160 Proxy-Authentication-Info 161
Proxy-Authorization 112 Proxy-Authorization 113
pseudonym 45 pseudonym 45
qdtext 30 qdtext 30
query 16 query 16
quoted-pair 30 quoted-pair 30
quoted-string 30 quoted-string 30
qvalue 104 qvalue 73
Range 101 Range 102
range-resp 67 range-resp 67
range-set 55 range-set 55
range-spec 55 range-spec 55
range-unit 54 range-unit 54
ranges-specifier 55 ranges-specifier 55
received-by 45 received-by 45
received-protocol 45 received-protocol 45
Referer 116 Referer 117
Retry-After 147 Retry-After 148
rfc850-date 144 rfc850-date 145
RWS 11 RWS 11
second 144 second 145
segment 16 segment 16
Server 162 Server 163
SP 10 SP 10
subtype 49 subtype 49
suffix-length 55 suffix-length 55
suffix-range 55 suffix-range 55
tchar 30 tchar 30
time-of-day 144 time-of-day 145
token 30 token 30
token68 110 token68 111
Trailer 34 Trailer 34
type 49 type 49
unsatisfied-range 67 unsatisfied-range 67
uri-host 16 uri-host 16
URI-reference 16 URI-reference 16
User-Agent 117 User-Agent 118
Vary 148 Vary 149
VCHAR 10 VCHAR 10
Via 45 Via 45
weak 154 weak 155
weight 104 weight 73
WWW-Authenticate 158 WWW-Authenticate 159
year 144 year 145
gateway 14 gateway 14
gzip (Coding Format) 52 gzip (Coding Format) 52
gzip (content coding) 51 gzip (content coding) 51
H H
HEAD method 78 HEAD method 79
Header Fields Header Fields
Accept 104 Accept 104
Accept-Charset 106 Accept-Charset 106
Accept-Encoding 107 Accept-Encoding 107
Accept-Language 108 Accept-Language 109
Accept-Ranges 161 Accept-Ranges 162
Allow 161 Allow 162
Authentication-Info 159 Authentication-Info 160
Authorization 112 Authorization 113
Content-Encoding 59 Content-Encoding 59
Content-Language 60 Content-Language 60
Content-Length 61 Content-Length 61
Content-Location 62 Content-Location 62
Content-MD5 173 Content-MD5 174
Content-Range 66 Content-Range 66
Content-Type 58 Content-Type 58
Date 145 Date 146
ETag 153 ETag 154
Expect 88 Expect 89
From 115 From 116
Host 43 Host 43
If-Match 95 If-Match 96
If-Modified-Since 97 If-Modified-Since 98
If-None-Match 96 If-None-Match 97
If-Range 100 If-Range 101
If-Unmodified-Since 98 If-Unmodified-Since 99
Last-Modified 151 Last-Modified 152
Location 146 Location 147
Max-Forwards 90 Max-Forwards 91
Proxy-Authenticate 159 Proxy-Authenticate 160
Proxy-Authentication-Info 160 Proxy-Authentication-Info 161
Proxy-Authorization 112 Proxy-Authorization 113
Range 101 Range 102
Referer 116 Referer 117
Retry-After 147 Retry-After 148
Server 162 Server 163
Trailer 34 Trailer 34
User-Agent 117 User-Agent 118
Vary 147 Vary 148
Via 45 Via 45
WWW-Authenticate 158 WWW-Authenticate 159
Host header field 43 Host header field 43
header section 24 header section 24
http URI scheme 17 http URI scheme 17
https URI scheme 18 https URI scheme 18
I I
If-Match header field 95 If-Match header field 96
If-Modified-Since header field 97 If-Modified-Since header field 98
If-None-Match header field 96 If-None-Match header field 97
If-Range header field 100 If-Range header field 101
If-Unmodified-Since header field 98 If-Unmodified-Since header field 99
idempotent 76 idempotent 77
inbound 14 inbound 14
interception proxy 15 interception proxy 15
intermediary 13 intermediary 13
L L
Last-Modified header field 151 Last-Modified header field 152
Location header field 146 Location header field 147
M M
Max-Forwards header field 90 Max-Forwards header field 91
Media Type Media Type
multipart/byteranges 68 multipart/byteranges 68
multipart/x-byteranges 69 multipart/x-byteranges 69
message 12 message 12
metadata 149 metadata 150
multipart/byteranges Media Type 68 multipart/byteranges Media Type 68
multipart/x-byteranges Media Type 69 multipart/x-byteranges Media Type 69
N N
non-transforming proxy 47 non-transforming proxy 47
O O
OPTIONS method 85 OPTIONS method 86
origin 37 origin 37
origin server 11 origin server 11
outbound 14 outbound 14
P P
POST method 79 POST method 80
PUT method 80 PUT method 81
Protection Space 111 Protection Space 112
Proxy-Authenticate header field 159 Proxy-Authenticate header field 160
Proxy-Authentication-Info header field 160 Proxy-Authentication-Info header field 161
Proxy-Authorization header field 112 Proxy-Authorization header field 113
payload 64 payload 64
phishing 163 phishing 164
proxy 14 proxy 14
R R
Range header field 101 Range header field 102
Realm 111 Realm 112
Referer header field 116 Referer header field 117
Retry-After header field 147 Retry-After header field 148
recipient 11 recipient 11
representation 48 representation 48
request 12 request 12
resource 16 resource 16
response 12 response 12
reverse proxy 14 reverse proxy 14
S S
Server header field 162 Server header field 163
Status Code 118 Status Code 119
Status Codes Status Codes
Final 119 Final 120
Informational 119 Informational 120
Interim 119 Interim 120
Status Codes Classes Status Codes Classes
1xx Informational 120 1xx Informational 121
2xx Successful 121 2xx Successful 122
3xx Redirection 127 3xx Redirection 129
4xx Client Error 133 4xx Client Error 134
5xx Server Error 139 5xx Server Error 140
safe 75 safe 76
secured 18 secured 18
selected representation 48, 91, 149 selected representation 48, 92, 150
sender 11 sender 11
server 11 server 11
spider 11 spider 11
T T
TRACE method 86 TRACE method 87
Trailer Fields Trailer Fields
ETag 153 ETag 154
Trailer header field 34 Trailer header field 34
target URI 37 target URI 37
target resource 37 target resource 37
trailer fields 33 trailer fields 33
trailer section 24 trailer section 24
trailers 33 trailers 33
transforming proxy 47 transforming proxy 47
transparent proxy 15 transparent proxy 15
tunnel 14 tunnel 14
U U
URI URI
origin 37 origin 37
URI scheme URI scheme
http 17 http 17
https 18 https 18
User-Agent header field 117 User-Agent header field 118
upstream 14 upstream 14
user agent 11 user agent 11
V V
Vary header field 147 Vary header field 148
Via header field 45 Via header field 45
validator 149 validator 150
strong 150 strong 151
weak 150 weak 151
W W
WWW-Authenticate header field 158 WWW-Authenticate header field 159
X X
x-compress (content coding) 51 x-compress (content coding) 51
x-gzip (content coding) 51 x-gzip (content coding) 51
Acknowledgments Acknowledgments
This edition of the HTTP specification builds on the many This edition of the HTTP specification builds on the many
contributions that went into RFC 1945, RFC 2068, RFC 2145, RFC 2616, contributions that went into RFC 1945, RFC 2068, RFC 2145, RFC 2616,
and RFC 2818, including substantial contributions made by the and RFC 2818, including substantial contributions made by the
 End of changes. 120 change blocks. 
504 lines changed or deleted 581 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/